FIDO2 as an MFA factor

concept brazil Updated Sep 10, 2026 2 min read mfa-with-fido.md
Raw file servicenow.com

You can configure FIDO2 as an MFA factor policy to enforce MFA for your users.

FIDO2 is a passwordless authentication standard that enables users to authenticate using a physical security key or biometric authentication. It provides a more secure alternative to traditional MFA methods, reducing the risk of phishing and other cyberattacks.

The FIDO2 factor policy enhancement provides a secure authentication method to your multi-factor authentication (MFA) policies. You can configure FIDO2 as an MFA factor policy option, providing a higher level of security compared to traditional methods like Email and SMS.

[Omitted image "biometirc-mfa.png"] Alt text: MFA- Biometric or Hardware keys

You can configure a FIDO2 factor policy. When the user satisfies the factor policy condition and logs in to ServiceNow, FIDO2 setup is displayed for the users who haven't already added registered Hardware key or Biometric on their profile.

If the registration is completed, then second factor validation screen is displayed to log in.

Note: FIDO2 can also be self-enrolled by the users. To know more about how to self-enroll, see Set up multi-factor authentication on your user profile.

Key Benefits

The following are some of the key benefits of using FIDO2 as an MFA factor:

  • Exclusive FIDO2 Authentication

    Limit high-privilege accounts to authenticating by using FIDO2's strong authentication capabilities (biometrics, passkeys, or hardware security keys).

  • Exclusion of less secure methods

    Suppress other authentication methods when FIDO2 is the only matching policy.

  • Forced enrollment

    Require users to register a FIDO2 key if not already enrolled.

  • Granular control

    Apply strict enforcement to specific roles or groups using policy-based targeting.

As a higher-security factor, FIDO2 has exclusive enforcement capabilities. When it's the only matching policy for a user:

  • Overrides other enrolled factors.
  • Forces FIDO2 registration, if the user isn’t enrolled.
  • Becomes the exclusive authentication option.

Example Configurations and User Behaviors

The following table illustrates how different user scenarios are handled based on their roles and enrolled factors.

Example Factor Policy Conditions:

  • FIDO2 Factor Policy: Condition is "ITIL role should be true".
  • EMAIL Factor Policy: Condition is "ASSET role should be true".

Example user

Has roles

Already enrolled factors

Matching policies

Behavior

david.loo

ITIL

None

FIDO2

User is redirected to MFA setup with FIDO2 only. After registration, FIDO2 is the only authentication option.

abel.tuter

ITIL

Authenticator

FIDO2

User is redirected to MFA setup with FIDO2 only, even if the user has Authenticator as self-enrolled factor.Note: If the user hasn't registered to any MFA factor, then the user is redirected to MFA setup with FIDO2.

beth.anglin

ASSET

Authenticator

Email

Sees Email and Authenticator options during log in. The user can choose either factor or optionally register FIDO2.

abraham.lincoln

ASSET, ITIL

Authenticator

Email and FIDO2

Sees Email and Authenticator option during log in. The user can register FIDO2 during validation. After registration, the user can see all the 3 factors.

By configuring FIDO2 as an MFA factor policy, you can enhance the security of your authentication processes.
Search documentation
Search document titles and file paths on the brazil branch