NIST authenticator assurance level 2 with Microsoft Entra ID

The National Institute of Standards and Technology (NIST) develops technical requirements for US federal agencies implementing identity solutions. Organizations working with federal agencies must meet these requirements.

Before starting authenticator assurance level 2 (AAL2), you can see the following resources:

Permitted AAL2 authenticator types

The following table has authenticator types permitted for AAL2:

Microsoft Entra authentication method NIST authenticator type
Recommended methods
Multi-factor Software Certificate (PIN Protected)
Windows Hello for Business with software Trusted Platform Module (TPM)
Multi-factor crypto software
Hardware protected certificate (smartcard/security key/TPM)
FIDO 2 security key
Windows Hello for Business with hardware TPM
Multi-factor crypto hardware
Microsoft Authenticator app (Passwordless) Multi-factor out-of-band
Additional methods
- Microsoft Authenticator app (Push Notification)
- OR
- Microsoft Authenticator Lite (Push Notification)
- OR
- Phone (SMS)
Memorized secret
Single-factor out-of-band
- OATH hardware tokens (preview)
- OR
- Microsoft Authenticator app (OTP)
- OR
- Microsoft Authenticator Lite (OTP)
- OR
- OATH software tokens
Memorized secret
Single-factor OTP
- Single-factor software certificate
- OR
- Microsoft Entra joined with software TPM
- OR
- Microsoft Entra hybrid joined with software TPM
- OR
- Compliant mobile device
Memorized secret
Single-factor crypto software
- Microsoft Entra joined with hardware TPM
- OR
- Microsoft Entra hybrid joined with hardware TPM
Memorized secret
Single-factor crypto hardware


Today, Microsoft Authenticator by itself is not phishing resistant. To gain protection from external phishing threats when using Microsoft Authenticator you must additionally configure Conditional Access policy requiring a managed device.

AAL2 recommendations

For AAL2, use multi-factor cryptographic hardware or software authenticators. Passwordless authentication eliminates the greatest attack surface (the password), and offers users a streamlined method to authenticate.

For guidance on selecting a passwordless authentication method, see Plan a passwordless authentication deployment in Microsoft Entra ID. See also, Windows Hello for Business deployment guide

FIPS 140 validation

Use the following sections to learn about FIPS 140 validation.

Verifier requirements

Microsoft Entra ID uses the Windows FIPS 140 Level 1 overall validated cryptographic module for authentication cryptographic operations. It's therefore a FIPS 140-compliant verifier required by government agencies.

Authenticator requirements

Government agency cryptographic authenticators are validated for FIPS 140 Level 1 overall. This requirement isn't for non-governmental agencies. The following Microsoft Entra authenticators meet the requirement when running on Windows in a FIPS 140-approved mode:

  • Password

  • Microsoft Entra joined with software or with hardware TPM

  • Microsoft Entra hybrid joined with software or with hardware TPM

  • Windows Hello for Business with software or with hardware TPM

  • Certificate stored in software or hardware (smartcard/security key/TPM)

Microsoft Authenticator app on both iOS and Android is FIPS 140 compliant. For more information on the FIPS validated cryptographic modules used by Microsoft Authenticator See Microsoft Authenticator app

For OATH hardware tokens and smartcards we recommend you consult with your provider for current FIPS validation status.

FIDO 2 security key providers are in various stages of FIPS certification. We recommend you review the list of supported FIDO 2 key vendors. Consult with your provider for current FIPS validation status.


For AAL2, the NIST requirement is reauthentication every 12 hours, regardless of user activity. Reauthentication is required after a period of inactivity of 30 minutes or longer. Because the session secret is something you have, presenting something you know, or are, is required.

To meet the requirement for reauthentication, regardless of user activity, Microsoft recommends configuring user sign-in frequency to 12 hours.

With NIST you can use compensating controls to confirm subscriber presence:

  • Set session inactivity time out to 30 minutes: Lock the device at the operating system level with Microsoft System Center Configuration Manager, group policy objects (GPOs), or Intune. For the subscriber to unlock it, require local authentication.

  • Time out regardless of activity: Run a scheduled task (Configuration Manager, GPO, or Intune) to lock the machine after 12 hours, regardless of activity.

Man-in-the-middle resistance

Communications between the claimant and Microsoft Entra ID are over an authenticated, protected channel. This configuration provides resistance to man-in-the-middle (MitM) attacks and satisfies the MitM resistance requirements for AAL1, AAL2, and AAL3.

Replay resistance

Microsoft Entra authentication methods at AAL2 use nonce or challenges. The methods resist replay attacks because the verifier detects replayed authentication transactions. Such transactions won't contain needed nonce or timeliness data.

Next steps

NIST overview

Learn about AALs

Authentication basics

NIST authenticator types

Achieve NIST AAL1 with Microsoft Entra ID

Achieve NIST AAL2 with Microsoft Entra ID

Achieve NIST AAL3 with Microsoft Entra ID