NIST authenticator assurance level 3 by using Microsoft Entra ID

Use the information in this article for National Institute of Standards and Technology (NIST) authenticator assurance level 3 (AAL3).

Before obtaining AAL2, you can review the following resources:

Permitted authenticator types

Use Microsoft authentication methods to meet required NIST authenticator types.

Microsoft Entra authentication methods NIST authenticator type
Recommended methods
Multi-factor hardware protected certificate
FIDO 2 security key
Platform SSO for macOS (Secure Enclave)
Windows Hello for Business with hardware TPM
Passkey in Microsoft Authenticator1
Multi-factor cryptographic hardware
Additional methods
Password
AND
Single-factor hardware protected certificate
Memorized secret
AND
Single-factor cryptographic hardware

1 Passkey in Microsoft Authenticator is overall considered partial AAL3 and can qualify as AAL3 on platforms with FIPS 140 Level 2 Overall (or higher) and FIPS 140 level 3 physical security (or higher). For additional information on FIPS 140 compliance for Microsoft Authenticator (iOS/Android) See FIPS 140 compliant for Microsoft Entra authentication

Recommendations

For AAL3, we recommend using a multi-factor cryptographic hardware authenticator that provides passwordless authentication eliminating the greatest attack surface, the password.

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

FIPS 140 validation

Verifier requirements

Microsoft Entra ID uses the Windows FIPS 140 Level 1 overall validated cryptographic module for its authentication cryptographic operations, making Microsoft Entra ID a compliant verifier.

Authenticator requirements

Single-factor and multi-factor cryptographic hardware authenticator requirements.

Single-factor cryptographic hardware

Authenticators are required to be:

  • FIPS 140 Level 1 Overall, or higher

  • FIPS 140 Level 3 Physical Security, or higher

Single-factor hardware protected certificate used with Windows device meet this requirement when:

Consult your mobile device vendor to learn about their adherence with FIPS 140.

Multi-factor cryptographic hardware

Authenticators are required to be:

  • FIPS 140 Level 2 Overall, or higher

  • FIPS 140 Level 3 Physical Security, or higher

FIDO 2 security keys, smart cards, and Windows Hello for Business can help you meet these requirements.

  • Multiple FIDO2 security key providers meet FIPS requirements. We recommend you review the list of supported FIDO2 key vendors. Consult with your provider for current FIPS validation status.

  • Smart cards are a proven technology. Multiple vendor products meet FIPS requirements.

Windows Hello for Business

FIPS 140 requires the cryptographic boundary, including software, firmware, and hardware, to be in scope for evaluation. Windows operating systems can be paired with thousands of these combinations. As such, it is not feasible for Microsoft to have Windows Hello for Business validated at FIPS 140 Security Level 2. Federal customers should conduct risk assessments and evaluate each of the following component certifications as part of their risk acceptance before accepting this service as AAL3:

To determine the TPMs that meet current standards, go to NIST Computer Security Resource Center Cryptographic Module Validation Program. In the Module Name box, enter Trusted Platform Module for a list of hardware TPMs that meet standards.

MacOS Platform SSO

Apple macOS 13 (and above) are FIPS 140 Level 2 Overall, with most devices also FIPS 140 Level 3 Physical Security. We recommend referring to the Apple Platform Certifications.

Passkey in Microsoft Authenticator

For additional information on FIPS 140 compliance for Microsoft Authenticator (iOS/Android) See FIPS 140 compliant for Microsoft Entra authentication

Reauthentication

For AAL3, NIST requirements are reauthentication every 12 hours, regardless of user activity. Reauthentication is recommended after a period of inactivity 15 minutes or longer. Presenting both factors is required.

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

NIST allows for compensating controls to confirm subscriber presence:

  • Set timeout, regardless of activity, by running a scheduled task using Configuration Manager, GPO, or Intune. Lock the machine after 12 hours, regardless of activity.

  • For the recommended inactivity time out, you can set a session inactivity time out of 15 minutes: Lock the device at the OS level by using Microsoft Configuration Manager, Group Policy Object (GPO), or Intune. For the subscriber to unlock it, require local authentication.

Man-in-the-middle resistance

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

Verifier impersonation resistance

Microsoft Entra authentication methods that meet AAL3 use cryptographic authenticators that bind the authenticator output to the session being authenticated. The methods use a private key controlled by the claimant. The public key is known to the verifier. This configuration satisfies the verifier-impersonation resistance requirements for AAL3.

Verifier compromise resistance

All Microsoft Entra authentication methods that meet AAL3:

  • Use a cryptographic authenticator that requires the verifier store a public key corresponding to a private key held by the authenticator
  • Store the expected authenticator output by using FIPS-140 validated hash algorithms

For more information, see Microsoft Entra Data Security Considerations.

Replay resistance

Microsoft Entra authentication methods that meet AAL3 use nonce or challenges. These methods are resistant to replay attacks because the verifier can detect replayed authentication transactions. Such transactions won't contain the needed nonce or timeliness data.

Authentication intent

Requiring authentication intent makes it more difficult for directly connected physical authenticators, like multi-factor cryptographic hardware, to be used without the subject's knowledge (for example, by malware on the endpoint). Microsoft Entra methods that meet AAL3 require user entry of pin or biometric, demonstrating authentication intent.

Next steps

NIST overview

Learn about AALs

Authentication basics

NIST authenticator types

Achieving NIST AAL1 by using Microsoft Entra ID

Achieving NIST AAL2 by using Microsoft Entra ID