> For AI agents: [llms.txt](https://docs.trustedauth.com/llms.txt) provides a Markdown index of this documentation. # Authenticator selection guide Use this guide to compare Entrust Identity as a Service (IDaaS) authenticators, understand the strengths and limitations of each option, and choose where to use each authenticator in your authentication flows. ## Authenticator comparison The following table summarizes the most common IDaaS authenticators and links to where you configure and manage each one. | Authenticator | What it is | Strengths | Limitations | Best fit | Configure and manage | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Password | A memorized secret entered during sign-in. Can be IDaaS-managed or Active Directory-managed. | Familiar for users, broad compatibility, strong policy controls. | Phishing and password reuse risk, user friction for resets and complexity. | Baseline first-factor authentication and environments that need directory password validation. | [Manage password authenticators](/docs/authentication-and-security/manage-authenticators/manage-password-authenticators.md) | | One-time password (OTP) | A one-time code delivered by email, SMS, voice, WeChat, or WhatsApp. | Simple to deploy, broad reach, useful for step-up and fallback. | Lower phishing resistance than device-bound factors, delivery dependencies, telecom and email risk. | Moderate-assurance second-factor authentication and account recovery scenarios. | [Manage One Time Password (OTP) settings](/docs/authentication-and-security/manage-authenticators/manage-one-time-passwords-otp.md) | | Entrust Soft Token and other soft tokens | A software token app that generates OTP values on a registered mobile device. | Stronger than SMS and email OTP, supports transaction use cases, broad deployment flexibility. | Mobile device dependency, enrollment and lifecycle overhead. | General-purpose second-factor authentication for workforce and customer users. | [Manage soft token authenticators](/docs/authentication-and-security/manage-authenticators/manage-soft-token-authenticators.md) | | Soft Token Push | A push challenge sent to the Entrust soft token app, where the user approves authentication. | Strong user experience, fast challenge approval, strong possession factor with app binding. | Push delivery and mobile connectivity dependencies, mobile app enrollment required. | Day-to-day second-factor authentication with low user friction. | [Manage soft token authenticators](/docs/authentication-and-security/manage-authenticators/manage-soft-token-authenticators.md) | | Smart Credential Push | A push challenge sent to a mobile smart credential, where the user approves authentication. | Strong assurance, supports smart credential strategies, good user experience for enrolled users. | Smart credential enrollment and lifecycle management overhead, push connectivity dependencies. | Certificate- and credential-centric environments that require push-based approval. | [Manage smart credential authenticators](/docs/authentication-and-security/manage-authenticators/manage-smart-credentials.md) | | Face Biometric | A biometric authenticator that verifies the user with an Entrust Identity Verification face verification workflow. | Strong user convenience, high assurance when combined with robust policy and workflow controls. | Requires Entrust Identity Verification integration and workflow setup, camera/device quality and environment can affect UX. | Identity verification and higher-assurance user verification journeys. | [Manage Face Biometrics with Entrust Identity Verification](/docs/authentication-and-security/manage-authenticators/manage-face-biometrics-by-onfido.md) | | Hardware tokens | A physical token device that generates OTP or challenge-response values. | Strong possession factor, works in restricted or offline-style environments, resilient to SIM-swap attacks. | Distribution and inventory overhead, replacement logistics, user carry burden. | High-assurance and regulated scenarios, users without mobile access, controlled environments. | [Manage hardware token authenticators](/docs/authentication-and-security/manage-authenticators/manage-hardware-tokens.md) | | Passkey/FIDO2 | Public-key authentication using platform or roaming authenticators with local user verification. Credentials can be synced passkeys (for example, iOS or Android) or device-bound security keys. | Strong phishing resistance, passwordless user experience, cryptographic protection. | Application and platform support planning required, rollout and user education needed. | High-assurance sign-in, passwordless strategies, long-term modern authentication programs. | [Manage Passkey/FIDO2 authenticators](/docs/authentication-and-security/manage-authenticators/manage-passkey-fido2-authenticators.md) and [Passkey basics](/docs/authentication-and-security/passkey/passkey-basics.md) | | Grid card | A challenge-response card where users enter values from prompted coordinates. | Works without smartphone apps, supports established operational models, reliable in constrained environments. | Operational card management overhead and user training requirements. | Broad customer deployments and controlled scenarios where grid workflows are established. | [Manage grid card authenticators](/docs/authentication-and-security/manage-authenticators/manage-grid-cards.md) | | Knowledge-based authentication (KBA) | Challenge questions answered with preregistered responses. | No device required, can be useful as a secondary fallback in controlled contexts. | Generally weaker assurance, answer guessability and social discovery risk. | Limited fallback use where stronger authenticators are not available. | [Manage Knowledge-based (KBA) authenticators](/docs/authentication-and-security/manage-authenticators/manage-knowledge-based-authenticators-kba.md) | | Temporary access code | A time-limited or usage-limited code assigned by an administrator. | Fast recovery path when a user loses primary authenticators, controlled short-term access. | Not intended as a long-term authenticator, manual help desk process required. | Account recovery and emergency access scenarios. | [Manage Temporary Access Codes](/docs/authentication-and-security/manage-authenticators/manage-temporary-access-codes.md) | | Magic Link | A link delivered by email to complete authentication actions. | Simple user journey, low friction for onboarding and recovery flows. | Inherent email phishing and forwarding risk, lower assurance for high-risk access. | Lower-assurance applications, registration, and account recovery journeys. | [Manage Magic Links](/docs/authentication-and-security/manage-authenticators/manage-magic-links.md) | | Pass-through authenticator | An IDaaS authenticator that calls your external authentication service through HTTP connectors. | Lets you integrate existing or custom authentication services without custom portal development. | Security and reliability depend on the external service, design and testing effort required. | Hybrid architectures and staged migration from external authentication services. | [Manage pass-through authenticators](/docs/authentication-and-security/manage-authenticators/manage-pass-through-authenticators.md) | | User certificate | Certificate-based authentication using trusted CAs or smart credential certificates. | Strong cryptographic assurance, supports passwordless and step-up patterns. | Certificate lifecycle and PKI management complexity, client and network prerequisites. | High-assurance workforce sign-in, smart credential and certificate programs. | [Manage user certificate authenticators](/docs/authentication-and-security/manage-authenticators/manage-user-certificate-authenticators.md) | ## Operational planning: availability, cost, deployment, and recovery Use the following relative ratings to estimate effort and end-user readiness. Ratings are comparative and can vary by tenant size, regulatory requirements, and support model. | Authenticator | Availability prerequisites | Relative cost | Deployment effort | Recovery effort | Recovery notes | | --------------------- | ----------------------------------------------------------------------------------------- | -------------- | ----------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Password | User can sign in with known credentials. | Low | Low | Medium | Recovery often depends on help desk or self-service reset processes. | | OTP | User has available delivery channel, for example email, SMS, voice, WeChat, or WhatsApp. | Low to Medium | Low | Low | Recovery is usually fast when users have valid contact channels. | | Soft token OTP | User has an enrolled mobile device with soft token app access. | Medium | Medium | Medium | Recovery typically involves re-enrollment on replacement devices. | | Soft Token Push | User has an enrolled mobile device, push connectivity, and access to the push app. | Medium | Medium | Medium | Recovery usually requires device rebind and push channel validation. | | Smart Credential Push | User has enrolled mobile smart credential and push-capable device. | Medium to High | High | Medium to High | Recovery can involve credential lifecycle updates and device reprovisioning. | | Face Biometric | User has supported camera/device conditions and completed Onfido enrollment. | Medium to High | High | Medium | Recovery usually requires fallback authenticator paths for camera, device, or matching issues. | | Hardware token | User has assigned physical token device available at sign-in time. | High | High | High | Recovery includes replacement logistics and reassignment workflows. | | Passkey/FIDO2 | User has an enrolled platform passkey or physical security key on a supported device. | Medium | Medium | Medium | Recovery depends on platform recovery options and alternate sign-in methods. | | Grid card | User has assigned grid or eGrid and can access challenge-response coordinates. | Low to Medium | Low to Medium | Medium | eGrid typically has lower deployment cost than physical devices; recovery usually requires card replacement and user communication. | | KBA | User remembers enrolled answers and can complete challenge prompts. | Low | Low | Medium | Recovery can require question reset and identity verification. | | Temporary access code | User can receive temporary code from support process and enter it during validity period. | Low | Low | Low | Recovery is intentionally simple and short-term when governed by support controls. | | Magic Link | User can access mailbox and receive valid Magic Link email. | Low | Low | Low | Recovery is usually quick if email delivery and mailbox access are available. | | Pass-through | External service is available and reachable, with expected API response behavior. | Medium to High | High | Medium to High | Recovery depends on external service design, support ownership, and API reliability. | | User certificate | User has valid certificate, private key access, and compatible endpoint trust chain. | High | High | High | Recovery often requires certificate reissue, revocation, and endpoint updates. | For authenticators that depend on mobile devices or physical devices, always define at least one fallback authenticator for users who cannot access their primary device. ## How to choose the right authenticator set Select authenticators by balancing assurance, user experience, and operational effort. 1. Classify each application by risk and data sensitivity. 2. Set a required assurance level for each application group. 3. Select one primary authenticator path and at least one fallback path. 4. Reserve lower-assurance methods for lower-risk use cases. 5. Validate the selected authenticators in resource rules and authentication flows. 6. Define help desk processes for token loss, device change, and account recovery. ## Consumer and enterprise deployment patterns Consumer and enterprise populations usually have different constraints for enrollment, device ownership, support coverage, and acceptable sign-in friction. Use the following patterns as starting points. | Population | Typical priorities | Common authenticator mix | Recovery model | | -------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Consumer users | Fast enrollment, low friction, broad device compatibility, low operating cost | Passkey/FIDO2 where available, OTP and Magic Link for broad reach, optional soft token push for stronger step-up | Self-service first, with temporary access code or support-assisted fallback for exceptions | | Enterprise workforce | Higher assurance, policy enforcement, auditability, controlled lifecycle | Passkey/FIDO2, user certificate, smart credential push, hardware tokens for specific roles, grid or OTP where required by environment | IT and help desk workflow with formal device replacement, credential reissue, and policy-driven fallback | When you design for mixed populations, apply separate resource rules and group policies for consumers and workforce users so you can tune assurance and recovery controls without forcing one model on all users. ## Recommended patterns by assurance level Use these patterns as a starting point, then adapt for your regulatory and operational requirements. | Assurance target | Typical authenticator pattern | | ------------------------ | ---------------------------------------------------------------------------------------------------------- | | Higher assurance | Passkey/FIDO2 or user certificate for primary sign-in, with soft token push or hardware token as fallback. | | Moderate assurance | Password plus soft token push, token OTP, or OTP delivery. | | Recovery and break-glass | Temporary access code with short expiry and strict support validation. | | Established deployments | Grid card or KBA where they are operationally established, with policy controls based on application risk. | ## Where authenticator usage is enforced After configuring authenticators, you enforce usage through policy and application access controls. - Use [Create authentication flows](/docs/authentication-and-security/create-and-manage-resource-rules/create-authentication-flows.md) to define allowed authenticator paths. - Use [Create and manage resource rules](/docs/authentication-and-security/create-and-manage-resource-rules/create-resource-rules.md) to apply authenticator requirements by application and risk context. - Use [Manage group policies](/docs/authentication-and-security/manage-group-policies.md) when different user groups need different authenticator settings. ## Next steps - Review [Manage authenticators](/docs/authentication-and-security/manage-authenticators.md) to configure the authenticators you selected. - Review [Manage applications](/docs/applications-and-sso/manage-applications.md) to ensure each application uses the correct resource rule and authentication flow.