Achieve NIST AAL2 with the Azure Active Directory
Table of Contents
The National Institute of Standards and Technology (NIST) develops the technical requirements for US federal agencies that implement identity solutions. Meeting these requirements is also required for organizations working with federal agencies.
Before you attempt to achieve authenticator assurance level 2 (AAL2), you might want to see the following resources:
Permitted authenticator types
The following table provides details about the authenticator types permitted for AAL2:
| Azure AD authentication method | NIST authenticator type |
|---|---|
| Recommended methods | |
| Microsoft Authenticator app for iOS (Passwordless) Windows Hello for Business with software trusted platform module (TPM) |
Multifactor crypto software |
| FIDO 2 security key Microsoft Authenticator app for Android (Passwordless) Windows Hello for Business with hardware TPM Smartcard (Active Directory Federation Services) |
Multifactor crypto hardware |
| Additional methods | |
| Password + Phone (SMS) | Memorized Secret + Out-of-Band |
| Password + Microsoft Authenticator App (OTP) Password + SF OTP |
Memorized Secret + Single-factor one-time password |
| Password + Azure AD joined with software TPM Password + Compliant mobile device Password + Hybrid Azure AD Joined with software TPM Password + Microsoft Authenticator App (Notification) |
Memorized Secret + Single-factor crypto SW |
| Password + Azure AD joined with hardware TPM Password + Hybrid Azure AD joined with hardware TPM |
Memorized Secret + Single-factor crypto hardware |
Note
In a conditional access policy, if you require a device to be either marked as compliant or hybrid Azure AD joined, Authenticator acts as verifier impersonation resistance.
Our recommendations
To achieve AAL2, use multifactor cryptographic hardware or software authenticators. Passwordless authentication eliminates the greatest attack surface (the password), and offers users a streamlined method to authenticate.
For detailed guidance on selecting a passwordless authentication method, see Plan a passwordless authentication deployment in Azure Active Directory.
For more information on implementing Windows Hello for Business, see the Windows Hello for Business deployment guide.
FIPS 140 validation
The following sections discuss achieving FIPS 140 validation.
Verifier requirements
Azure AD uses the Windows FIPS 140 Level 1 overall validated cryptographic module for all its authentication related cryptographic operations. It’s therefore a FIPS 140 compliant verifier as required by government agencies.
Authenticator requirements
The cryptographic authenticators of government agencies are required to be validated for FIPS 140 Level 1 overall. This isn’t a requirement for non-governmental agencies. The following Azure AD authenticators meet the requirement when running on Windows in a FIPS 140 approved mode of operation:
-
Password
-
Azure AD joined with software or with hardware TPM
-
Hybrid Azure AD joined with software or with hardware TPM
-
Windows Hello for Business with software or with hardware TPM
-
Smartcard (Active Directory Federation Services)
While the Microsoft Authenticator app in all its modes (notification, OTP and passwordless) uses FIPS 140 approved cryptography, it is not FIPS 140 Level 1 validated.
FIDO2 security key providers are in various stages of FIPS certification, including some that have completed validation. We recommend you review the list of supported FIDO2 key vendors and check with your provider for current FIPS validation status.
Reauthentication
At the AAL2 level, NIST requires reauthentication every 12 hours, regardless of user activity. Reauthentication is also required after any period of inactivity lasting 30 minutes or longer. Presentation of something you know or something you are is required, because the session secret is something you have.
To meet the requirement for reauthentication regardless of user activity, Microsoft recommends configuring user sign-in frequency to 12 hours.
NIST also allows the use of compensating controls for confirming the subscriber’s presence:
-
You can set session inactivity timeout to 30 minutes by locking the device at the operating system level by using Microsoft System Center Configuration Manager, group policy objects (GPOs), or Intune. You must also require local authentication for the subscriber to unlock it.
-
Timeout regardless of activity can be achieved by running a scheduled task (using Configuration Manager, GPO, or Intune) that locks the machine after 12 hours, regardless of activity.
Man-in-the-middle resistance
All communications between the claimant and Azure AD are performed over an authenticated, protected channel, to provide resistance to man-in-the-middle (MitM) attacks. This satisfies the MitM resistance requirements for AAL1, AAL2, and AAL3.
Replay resistance
All Azure AD authentication methods at AAL2 use either nonce or challenges. The methods are resistant to replay attacks because the verifier easily detects replayed authentication transactions. Such transactions won’t contain the appropriate nonce or timeliness data.
Next steps
NIST overview
Learn about AALs
Authentication basics
NIST authenticator types
Achieve NIST AAL1 with Azure AD
Achieve NIST AAL2 with Azure AD
Achieve NIST AAL3 with Azure AD