Configure identification and authentication controls to meet FedRAMP High Impact level
Identification and authentication are key to achieving a Federal Risk and Authorization Management Program (FedRAMP) High Impact level.
The following list of controls and control enhancements in the identification and authentication (IA) family might require configuration in your Azure Active Directory (Azure AD) tenant.
| Control family | Description |
|---|---|
| IA-02 | Identification and authentication (organizational users) |
| IA-03 | Device identification and authentication |
| IA-04 | Identifier management |
| IA-05 | Authenticator management |
| IA-06 | Authenticator feedback |
| IA-07 | Cryptographic module authentication |
| IA-08 | Identification and authentication (non-organizational users) |
Each row in the following table provides prescriptive guidance to help you develop your organization's response to any shared responsibilities for the control or control enhancement.
Configurations
| Control ID and subpart | Customer responsibilities and guidance |
|---|---|
| IA-02 | Uniquely identify and authenticate users or processes acting for users. Azure AD uniquely identifies user and service principal objects directly. Azure AD provides multiple authentication methods, and you can configure methods that adhere to National Institute of Standards and Technology (NIST) authentication assurance level (AAL) 3. Identifiers Authentication and multifactor authentication |
| IA-02(1) IA-02(3) |
Multifactor authentication for all access to privileged accounts. Configure the following elements for a complete solution to ensure all access to privileged accounts requires multifactor authentication. Configure conditional access policies to require multifactor authentication for all users. With Privileged Identity Management activation requirement in place, privilege account activation isn't possible without network access, so local access is never privileged. Multifactor authentication and Privileged Identity Management |
| IA-02(2) IA-02(4) |
Implement multi-factor authentication for all access to non-privileged accounts Configure the following elements as an overall solution to ensure all access to non-privileged accounts requires MFA. Configure Conditional Access policies to require MFA for all users. Microsoft recommends using a multi-factor cryptographic hardware authenticator (e.g., FIDO2 security keys, Windows Hello for Business (with hardware TPM), or smart card) to achieve AAL3. If your organization is completely cloud-based, we recommend using FIDO2 security keys or Windows Hello for Business. Windows Hello for Business has not been validated at the required FIPS 140 Security Level and as such federal customers would need to conduct risk assessment and evaluation before accepting it as AAL3. For additional details regarding Windows Hello for Business FIPS 140 validation please refer to Microsoft NIST AALs. Guidance regarding MDM polices differ slightly based on authentication methods, they are broken out below. Smart Card / Windows Hello for Business Hybrid Only Smart Card Only FIDO2 Security Key Authentication Methods Additional Resources: |
| IA-02(5) | When multiple users have access to a shared or group account password, require each user to first authenticate by using an individual authenticator. Use an individual account per user. If a shared account is required, Azure AD permits binding of multiple authenticators to an account so that each user has an individual authenticator. Resources |
| IA-02(8) | Implement replay-resistant authentication mechanisms for network access to privileged accounts. Configure conditional access policies to require multifactor authentication for all users. All Azure AD authentication methods at authentication assurance level 2 and 3 use either nonce or challenges and are resistant to replay attacks. References |
| IA-02(11) | Implement Azure AD multifactor authentication to access customer-deployed resources remotely so that one of the factors is provided by a device separate from the system gaining access where the device meets FIPS-140-2, NIAP certification, or NSA approval. See guidance for IA-02(1-4). Azure AD authentication methods to consider at AAL3 meeting the separate device requirements are: FIDO2 security keys References |
| IA-02(12) | Accept and verify personal identity verification (PIV) credentials. This control isn't applicable if the customer doesn't deploy PIV credentials. Configure federated authentication by using Active Directory Federation Services (AD FS) to accept PIV (certificate authentication) as both primary and multifactor authentication methods and issue the multifactor authentication (MultipleAuthN) claim when PIV is used. Configure the federated domain in Azure AD with setting federatedIdpMfaBehavior to Resources |
| IA-03 | Implement device identification and authentication prior to establishing a connection. Configure Azure AD to identify and authenticate Azure AD Registered, Azure AD Joined, and Azure AD Hybrid joined devices. Resources |
| IA-04 IA-04(4) |
Disable account identifiers after 35 days of inactivity and prevent their reuse for two years. Manage individual identifiers by uniquely identifying each individual (for example, contractors and foreign nationals). Assign and manage individual account identifiers and status in Azure AD in accordance with existing organizational policies defined in AC-02. Follow AC-02(3) to automatically disable user and device accounts after 35 days of inactivity. Ensure that organizational policy maintains all accounts that remain in the disabled state for at least two years. After this time, you can remove them. Determine inactivity |
| IA-05 | Configure and manage information system authenticators. Azure AD supports various authentication methods. You can use your existing organizational policies for management. See guidance for authenticator selection in IA-02(1-4). Enable users in combined registration for SSPR and Azure AD multifactor authentication and require users to register a minimum of two acceptable multifactor authentication methods to facilitate self-remediation. You can revoke user-configured authenticators at any time with the authentication methods API. Authenticator strength/protecting authenticator content Authentication methods and combined registration Authenticator revokes |
| IA-05(1) | Implement password-based authentication requirements. Per NIST SP 800-63B Section 5.1.1: Maintain a list of commonly used, expected, or compromised passwords. With Azure AD password protection, default global banned password lists are automatically applied to all users in an Azure AD tenant. To support your business and security needs, you can define entries in a custom banned password list. When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords. We strongly encourage passwordless strategies. This control is only applicable to password authenticators, so removing passwords as an available authenticator renders this control not applicable. NIST reference documents Resource |
| IA-05(2) | Implement PKI-based authentication requirements. Federate Azure AD via AD FS to implement PKI-based authentication. By default, AD FS validates certificates, locally caches revocation data, and maps users to the authenticated identity in Active Directory. Resources |
| IA-05(4) | Employ automated tools to validate password strength requirements. Azure AD implements automated mechanisms that enforce password authenticator strength at creation. This automated mechanism can also be extended to enforce password authenticator strength for on-premises Active Directory. Revision 5 of NIST 800-53 has withdrawn IA-04(4) and incorporated the requirement into IA-5(1). Resources |
| IA-05(6) | Protect authenticators as defined in the FedRAMP High Impact level. For more information on how Azure AD protects authenticators, see Azure AD data security considerations. |
| IA-05(7) | Ensure unencrypted static authenticators (for example, a password) aren't embedded in applications or access scripts or stored on function keys. Implement managed identities or service principal objects (configured with only a certificate). Resources |
| IA-05(8) | Implement security safeguards when individuals have accounts on multiple information systems. Implement single sign-on by connecting all applications to Azure AD, as opposed to having individual accounts on multiple information systems. |
| IA-05(11) | Require hardware token quality requirements as required by the FedRAMP High Impact level. Require the use of hardware tokens that meet AAL3. Achieving NIST authenticator assurance levels with the Microsoft identity platform |
| IA-05(13) | Enforce the expiration of cached authenticators. Cached authenticators are used to authenticate to the local machine when the network isn't available. To limit the use of cached authenticators, configure Windows devices to disable their use. Where this action isn't possible or practical, use the following compensating controls: Configure conditional access session controls by using application-enforced restrictions for Office applications. Resources |
| IA-06 | Obscure authentication feedback information during the authentication process. By default, Azure AD obscures all authenticator feedback. |
| IA-07 | Implement mechanisms for authentication to a cryptographic module that meets applicable federal laws. The FedRAMP High Impact level requires the AAL3 authenticator. All authenticators supported by Azure AD at AAL3 provide mechanisms to authenticate operator access to the module as required. For example, in a Windows Hello for Business deployment with hardware TPM, configure the level of TPM owner authorization. Resources |
| IA-08 | The information system uniquely identifies and authenticates non-organizational users (or processes acting for non-organizational users). Azure AD uniquely identifies and authenticates non-organizational users homed in the organizations tenant or in external directories by using Federal Identity, Credential, and Access Management (FICAM)-approved protocols. Resources |
| IA-08(1) IA-08(4) |
Accept and verify PIV credentials issued by other federal agencies. Conform to the profiles issued by the FICAM. Configure Azure AD to accept PIV credentials via federation (OIDC, SAML) or locally via integrated Windows authentication. Resources |
| IA-08(2) | Accept only FICAM-approved credentials. Azure AD supports authenticators at NIST AALs 1, 2, and 3. Restrict the use of authenticators commensurate with the security category of the system being accessed. Azure AD supports a wide variety of authentication methods. Resources |
Next steps
Feedback
Submit and view feedback for