FIDO2 as an MFA factor

  • Versão de lançamento: Australia
  • Atualizado 12 de mar. de 2026
  • 2 min. de leitura
  • You can configure FIDO2 as an MFA factor policy to enforce MFA for yours.

    FIDO2 is a password-less 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 cyberattack.

    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.


    MFA- Biometric or Hardware keys

    You can configure FIDO2 factor policy and when the users satisfies the factor policy condition, the during log 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.

    Nota:
    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
    Ensure high-privilege accounts can only authenticate 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 enroll-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 Factory 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
    andrew.och 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.
    Nota:
    If the user hasn't registered to any MFA factor, then the user is redirected to MFA setup with FIDO2.
    aileen.motterm 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 significantly enhance the security of your authentication processes.