> For AI agents: [llms.txt](https://docs.trustedauth.com/llms.txt) provides a Markdown index of this documentation. # Configure Passkey/FIDO2 authenticator settings Use this page to configure tenant-level Passkey/FIDO2 authenticator settings, including policy, timeout, and custom app origins. ## Why these settings matter These settings let you define what types of passkeys are trusted in your tenant and how strictly IDaaS enforces passkey behavior during registration and sign-in. Use them to reduce risk from unrecognized authenticators, prevent policy drift over time, and align passkey usage with internal security and compliance requirements. Policy enforcement settings: - **Attestation Preference** controls the assurance level for device identity at registration. - **Authenticator Restrictions** lets you allow or block specific authenticator models. - **Unknown Authenticator Policy** defines whether unrecognized authenticator models can register. - **Non-Compliant Authenticator Policy** controls whether previously registered passkeys that no longer meet policy are allowed or blocked at sign-in. - **Device-Bound Only** enforces passkeys that remain on a single device and blocks synced passkeys. Operational settings: - **Timeout** controls how long users have to complete passkey challenges. - **Authentication API minimum authentication level** controls who can self-manage passkeys through Authentication API flows. - **Passkey/FIDO2 Registration Policy** (**User Verification** and **Resident Key**) controls registration requirements for verification strength and account discoverability. - **Authenticator Attachment** and **User Present Check** control authenticator form factor and user interaction requirements. - **Custom Web or Native App origins** control where passkeys can be registered and used when relying party settings are customized. note A resource rule is required before users can authenticate with Passkey/FIDO2 as part of User ID sign-in. In the associated [authentication flow](/docs/authentication-and-security/create-and-manage-resource-rules/create-authentication-flows.md#edit-an-authentication-flow), include **Passkey/FIDO2** in the **User Login** factors. You can still edit these settings without configuring a resource rule. ## Understand the security choices Passkey/FIDO2 settings control more than one security dimension. Before you choose values, identify whether your goal is broad passkey adoption, passwordless sign-in, hardware security key compatibility, or a high-assurance device-bound deployment. | Concept | Plain meaning | Why it matters | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **User Presence (UP)** | The user interacts with the authenticator, such as touching a security key. | UP confirms interaction with a device, but it does not confirm that the user completed a PIN, biometric, or device unlock check. | | **User Verification (UV)** | The authenticator verifies the user locally, such as with a PIN, biometric, or device unlock. | UV is stronger than UP and is recommended for passwordless sign-in because the passkey is the primary proof of the user's identity. | | **Resident Key (User ID)** | The passkey stores enough user information for IDaaS to identify the user without first asking for a username. | Passwordless passkey sign-in depends on the passkey identifying the user. If resident keys are not required, users may need to enter a username before using Passkey/FIDO2. | | **Attestation** | The authenticator provides information about the model that created the passkey. | Attestation lets IDaaS identify authenticator models and apply allow or block policies. Stronger attestation gives more control, but can reduce compatibility. | | **Authenticator Attestation Globally Unique Identifier (AAGUID)** | A model identifier for an authenticator, not a unique serial number for one user's device. | IDaaS uses AAGUID and metadata to identify authenticator models for reporting, allow lists, block lists, and restrictions for models with known security issues. | | **Platform or cross-platform authenticator** | Whether the authenticator is built into the device or external, such as a hardware security key. | This controls the form factor. It does not, by itself, determine whether the passkey can sync to other devices. | | **Device-bound or synced passkey** | Whether the passkey stays on one device or can be backed up and restored through a cloud provider. | Device-bound passkeys reduce cloud-sync and account-recovery risk. Synced passkeys improve convenience and recovery. | info **Authenticator Attachment** and **Device-Bound Only** control different things. **Authenticator Attachment** controls whether users can register built-in or external authenticators. **Device-Bound Only** controls whether the passkey can be backed up or synced. A platform authenticator can create a synced passkey, so use **Device-Bound Only** when your policy requires non-synced credentials. ## Understand the risks these policies reduce Passkey/FIDO2 controls protect against different failure modes. Use this table to understand what can remain possible when a control is relaxed or left unenforced. | Control | If the control is not enforced | Why this matters | | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **User Present Check** | IDaaS may accept an authenticator response without requiring proof that the user physically interacted with the authenticator. | User presence helps prevent silent authentication with an available authenticator, such as a security key left connected to a workstation. | | **User Verification: Required** | IDaaS may accept authentication that proves access to the credential but does not prove that the user completed a PIN, biometric, or device unlock check. | Passwordless sign-in relies on the passkey as the primary proof of identity. Without user verification, possession-only and synced-passkey attack paths can have more impact. | | **Resident Key (User ID): Required** | Users may need to enter a username before using Passkey/FIDO2, and some passwordless sign-in flows may not work as expected. | Passwordless sign-in needs the passkey to identify the user. If the user identity is not discoverable from the passkey, IDaaS may need another identifier first. | | **Device-Bound Only** | Users can register synced passkeys that can be backed up, restored, or made available through a cloud passkey provider. | Synced passkeys improve convenience, but your trust boundary includes the cloud account, recovery process, enrolled devices, and private key protection model used by the passkey provider. | | **Attestation Preference**, **Authenticator Restrictions**, and **Unknown Authenticator Policy** | Users can register authenticators that IDaaS cannot identify, that your organization has not approved, or that belong to models with known security vulnerabilities. | These settings help you restrict registration to known authenticator models and block models that no longer meet your security requirements. Without them, you have less assurance about key protection, matcher protection, certification, and device provenance. | | **Non-Compliant Authenticator Policy: Block** | Passkeys registered before a policy change can continue to authenticate even when they no longer meet current policy. | This setting is what turns new policy into enforcement for existing passkeys. Without it, stricter settings may apply only to new registrations. | | **Allowed Relying Party ID Hostnames** and custom app origins | Passkeys may be registered or used from origins that are broader than your intended application boundary. | RP ID and origin controls preserve phishing resistance and prevent passkeys from being accepted for unintended domains, subdomains, or mobile app identifiers. | | **Authentication API minimum authentication level** | Users may self-manage passkeys after a weaker session than your organization expects. | Passkey self-service can add, rename, or remove authenticators. Require an authentication level that matches the risk of changing sign-in credentials. | ## Choose a policy posture Use the following starting points to choose a configuration. Adjust the values for your risk model, user population, support process, and regulatory requirements. ### Recommended settings | Goal | User Verification | Resident Key (User ID) | Attestation Preference | Device-Bound Only | Authenticator Attachment | Authenticator Restrictions | Unknown Authenticator Policy | Non-Compliant Authenticator Policy | | ----------------------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------- | ---------------------- | ----------------- | ------------------------ | ------------------------------------------------- | ---------------------------------------------- | ---------------------------------- | | Maximum passkey compatibility | Preferred | Preferred or Required for passwordless sign-in | None or Indirect | Off | Either | Not applicable with None; Allow All with Indirect | Not applicable with None; Allow with Indirect | Allow | | Broad passwordless adoption | Required | Required | Indirect or None | Off | Not applicable | Not applicable with None; Allow All with Indirect | Not applicable | Not applicable | | Enterprise passwordless | Required | Required | Indirect | Not applicable | Not applicable | Not applicable | Allow during rollout or Block after validation | Block after migration | | High-assurance device-bound only | Required | Required | Direct where supported | On | Not applicable | Allow Selected Authenticators | Block (automatic with Direct) | Block | | Hardware security keys as a second factor | Preferred only when supporting hardware keys that provide user presence but not user verification | Preferred or Discouraged | Not applicable | Not applicable | Cross-Platform | Not applicable | Not applicable | Not applicable | | Reduce synced-passkey exposure | Required | Not applicable | Not applicable | On | Not applicable | Not applicable | Not applicable | Block after a migration window | Not applicable means there is no specific recommendation for this use case. ### Benefits and tradeoffs | Goal | Why choose this | Tradeoff | | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Maximum passkey compatibility | Supports the widest range of passkeys and FIDO2 authenticators, including synced platform passkeys and physical security keys that support user presence but not user verification. This can accelerate adoption while still using phishing-resistant public-key authentication. | Provides less assurance about local user verification, authenticator model, device binding, and credential portability. Use stronger settings for high-risk applications or regulated users. | | Broad passwordless adoption | Supports common platform passkeys from Apple, Google, Microsoft, and hardware authenticators while keeping passwordless sign-in protected by local user verification. | Synced passkeys are allowed, so credential recovery and cloud account security become part of the threat model. | | Enterprise passwordless | Balances phishing resistance, inventory visibility, and compatibility. This posture gives administrators authenticator metadata without requiring every authenticator to support direct attestation. | Some unknown authenticators may need review before you block them. | | High-assurance device-bound only | Restricts passkey use to approved, identifiable, non-synced authenticators and enforces the policy at sign-in. | This is the most restrictive posture. It can block synced platform passkeys and authenticators that do not provide verifiable direct attestation. | | Hardware security keys as a second factor | Supports older or simpler security keys that prove user interaction but do not support PIN or biometric user verification. | Do not use this posture for passwordless sign-in that requires user verification assurance. Authentication that requires only user presence proves device interaction, not local user verification. | | Reduce synced-passkey exposure | Reduces exposure to attacks against synchronized passkey ecosystems and cloud credential recovery paths. | Users lose the convenience of synced passkeys across devices and may need recovery or re-registration support. | ## Plan a policy rollout warning Before you tighten any Passkey/FIDO2 policy setting, review existing registered passkeys and plan a migration. Stricter settings can make existing passkeys non-compliant. If you set **Non-Compliant Authenticator Policy** to **Block**, IDaaS denies access the next time a user signs in with a non-compliant passkey. 1. Inventory registered passkeys on the [Passkey/FIDO2 Tokens](/docs/authentication-and-security/manage-authenticators/manage-passkey-fido2-authenticators/manage-passkey-fido2-tokens/view-and-manage-tokens.md) page. 2. Identify whether existing passkeys are synced or device-bound, and whether their authenticator metadata is known. 3. Use [group policies](/docs/authentication-and-security/manage-group-policies.md) to apply stricter Passkey/FIDO2 settings to higher-risk groups, such as IDaaS administrators or privileged users, while keeping broader compatibility settings for other users. 4. Keep **Non-Compliant Authenticator Policy** set to **Allow** only for the migration period if users need time to re-register compatible passkeys. 5. Communicate the new registration requirements before enforcement, especially when you enable **Device-Bound Only**, **Direct** attestation, or selected authenticator restrictions. 6. Set **Non-Compliant Authenticator Policy** to **Block** when you are ready to enforce the new policy for existing passkeys. ### Configure the Passkey/FIDO2 policy settings 1. Click Menu icon **>** **Policies** **> Authenticators**. The **Authenticators** page appears. 2. Select **Passkey/FIDO2**. The **Passkey/FIDO2** page appears. 3. In the **Timeout** field, enter how long (in seconds) the Passkey/FIDO2 authenticator waits for a user response. > If the user does not complete authentication before the timeout expires, IDaaS displays an error message and the user must try again. 4. Select the **Authentication API minimum authentication level**. > This setting defines the minimum session authentication strength a user must reach before they can self-manage passkeys. If the user's current session level is below the configured value, IDaaS rejects the request. > The default is **LEVEL30** (hardware token level). | Level | Description | | ------- | ------------------------------------------------------------ | | LEVEL0 | No authentication required | | LEVEL10 | Password or external Identity Provider (IdP) only | | LEVEL20 | One-time password (OTP) | | LEVEL30 | Hardware token (default) | | LEVEL45 | FIDO authentication | | LEVEL85 | Password/IdP plus FIDO | | LEVEL90 | Password/IdP and Mobile Smart Credential or User Certificate | note This setting applies only to applications that use the Authentication API with passkey self-service enabled. 5. Set the **Passkey/FIDO2 Registration Policy** to configure how passkeys are registered and validated. - User Verification - Resident Key (User ID) note Entrust recommends setting **User Verification** and **Resident Key (User ID)** to **Required** for passwordless authentication. 6. Select whether the token must perform **User Verification**. - **Discouraged.** Avoids verification, if possible. - **Preferred.** Performs verification, if possible. - **Required.** Must perform verification. 7. Select the **Resident Key (User ID)** to set whether the user's identity is stored on the Passkey/FIDO2 token. - **Discouraged.** Avoids storing the User ID, if possible. - **Preferred.** Stores the user ID, if possible. - **Required.** Must store the user ID. 8. Select the **Attestation Preference** to set how much attestation information is requested during registration. - **None.** No attestation information is requested. The authenticator registers without device verification details. - **Indirect.** The server requests attestation but does not validate the certificate chain. This is the **default** setting and balances security with user privacy. - If the authenticator is not found in the [FIDO Metadata Service (MDS)](https://fidoalliance.org/metadata/) blob, IDaaS falls back to a [community-maintained list](/docs/authentication-and-security/manage-authenticators/manage-passkey-fido2-authenticators/manage-passkey-fido2-tokens/community-authenticators.md) to retrieve the authenticator name and icon. - If the authenticator is not found in either source, registration still proceeds and the token is stored using its AAGUID, the authenticator name is recorded as **Unknown**, and the authenticator is marked as unverified. - **Direct.** The server validates the full certificate chain against the FIDO MDS blob. Use this setting when your organization requires that only certified, hardware-backed authenticators can be enrolled. - If the authenticator is not found in the FIDO MDS blob, or its certificates do not match the MDS entry, the registration is strictly rejected. - Authenticators sourced only from community-maintained lists are also rejected. note For more information on attestation preferences and the behavior of each option, see the table, [Attestation preferences](#attestation-preferences). 9. Set the **Authenticator Restrictions** policy to control which authenticator models are permitted to register. - **Allow All** (default): Any authenticator can register. This is the current behavior. - **Allow Selected Authenticators**: Only authenticators you select can register. All others are rejected. - **Block Selected Authenticators**: Authenticators you select are rejected. All others are allowed. note All three options are disabled when **Attestation Preference** is set to **None**. 10. When you select **Allow Selected Authenticators** or **Block Selected Authenticators**, a **Configure Allowed Authenticators** or **Configure Blocked Authenticators** panel appears below the radio buttons depending on the selected mode. The panel is rendered at reduced opacity when **Allow All** is selected. - If no authenticators have been configured yet, the panel shows an **Add** button. - If authenticators have already been configured, the panel shows an **Edit** button and a summary of the selected count and up to five names alphabetically, followed by **+N more** if there are additional selections. 11. Click **Add** or **Edit** to open the authenticator picker. The picker shows a grid of authenticators from the FIDO MDS and the community list, with each entry displaying an icon, name, and AAGUID. Previously saved selections are prechecked when you reopen the picker. Use the search box to filter by authenticator name or AAGUID. note You can only activate one mode at a time. An allow list and a block list cannot both be active simultaneously. You can select up to 200 authenticators. 12. Set the **Unknown Authenticator Policy** to control what happens when a user tries to register an authenticator when an AAGUID is not found in either the FIDO MDS list or the community list. - **Allow (default).** The authenticator is accepted and labeled **Unknown authenticator** in the admin console. - **Block.** The registration is rejected and the user is told their authenticator is not recognized. note The availability of this setting depends on **Attestation Preference**: - **None.** Both options are disabled. No authenticator details are collected, so this check does not apply. - **Indirect.** Both options are enabled. - **Direct.** This policy is automatically set to **Block** and the **Allow** option is disabled. Unknown authenticators are already rejected during Direct attestation verification. 13. Set the **Non-Compliant Authenticator Policy** to control what happens when a user logs in with a registered token that no longer meets the current policy settings. A token is non-compliant when any of the following apply: - **Authenticator Restrictions** is enabled and the token's authenticator is no longer on the allow list or is now on the block list. - **Device-Bound Only** is enabled and the token was registered as a synced passkey. - The current **Attestation Preference** is **Indirect** or **Direct**, and the token was registered before IDaaS 5.46 when **None** was in effect. Because no device details were collected at registration, the token cannot be evaluated against the current policy. - **Allow (default).** Non-compliant tokens continue to work and the user can log in. An audit event is recorded at each login. - **Block.** The next time a user logs in with a non-compliant token, access is denied. An audit event and a webhook event are triggered. note This policy is evaluated at login time. Both options remain available regardless of the **Attestation Preference** setting. 14. Select **Authenticator Attachment** to set whether the authenticator is built into the user's device or external. - **Either.** Allows either a platform (embedded) authenticator or a cross-platform (external) authenticator. - **Platform.** Requires a platform authenticator built into the device, for example, Windows Hello, Face ID, or Touch ID. - **Cross-Platform.** Requires a cross-platform (external) authenticator, for example, a YubiKey or phone. 15. Select **User Present Check** to perform a backend check that confirms the user is physically present with their device during registration and authentication. 16. Select **Device-Bound Only** to allow only device-bound passkeys. When enabled, passkeys that can sync to the cloud are rejected at both registration and authentication. note This setting was previously labeled **Backup Eligible Check**. The behavior is unchanged. 17. Select **Enable Passkeys from Custom Web or Native Apps**. Use this setting when you need to add a custom Web or native app for a hostname other than the current hostname. 1. Click **Add**. The **Add Relying Party Configuration** dialog box appears. 2. Enter a **Relying Party ID**. 3. Optionally select **Allow Subdomain**. 4. Configure domain matching, as follows: - If **Allow Subdomain** is selected, registration origins can be subdomains of the relying party ID. - If **Allow Subdomain** is not selected, the registration origin must exactly match the relying party ID. - The closest parent domain with **Allow Subdomain** selected is used as the registration relying party. 5. In **Android Origin**, click **Add**, then enter **Package Name** and **Fingerprint**. - **Fingerprint** is the SHA-256 hash of your Android app signing certificate used to verify app authenticity. - You can add up to 5 fingerprints for the same app. 6. In **iOS Origin**, enter **App Identifier Prefix** and **Bundle Identifier**. 7. Optional: Click **Sync with Association Files** to fetch association files for the provided relying party ID and auto-populate values in the **Android Origin** and **iOS Origin** sections. 18. Click **Add** to add the relying party configuration and return to the **Passkey/FIDO2** page. 19. Click **Save**. ## Validate your changes After you save, verify the following: 1. Registration and authentication behavior match the configured **User Verification** and **Resident Key** policy settings. 2. Attestation behavior matches the selected **Attestation Preference**. 3. If custom origins are configured, passkey registration works only from allowed origins. 4. The configured **Timeout** is long enough for users to complete sign-in without frequent timeout errors. ### Attestation preferences | Behavior | Indirect | Direct | | ----------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------- | | Certificate chain validation | Not performed | Required: must match the FIDO MDS entry | | FIDO MDS blob lookup | Performed when available | Required | | Community list fallback | Used for authenticator name and icon | Not permitted | | Authenticator not in FIDO MDS or community list | Stored with AAGUID, name as **Unknown**, authenticator marked as unverified | Registration rejected |