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, 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 page.
2. Identify whether existing passkeys are synced or device-bound, and whether their authenticator metadata is known.
3. Use group policies 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 > 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) blob, IDaaS falls back to a community-maintained list 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.

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