Configure identification and authentication controls to meet FedRAMP High Impact level with Microsoft Entra ID
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 Microsoft Entra tenant.
Control family | Description |
---|---|
IA-2 | Identification and authentication (organizational users) |
IA-3 | Device identification and authentication |
IA-4 | Identifier management |
IA-5 | Authenticator management |
IA-6 | Authenticator feedback |
IA-7 | Cryptographic module authentication |
IA-8 | Identification and authentication (nonorganizational 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
FedRAMP Control ID and description | Microsoft Entra guidance and recommendations |
---|---|
IA-2 User Identification and Authentication The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). |
Uniquely identify and authenticate users or processes acting for users. Microsoft Entra ID uniquely identifies user and service principal objects directly. Microsoft Entra ID 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-2(1) The information system implements multifactor authentication for network access to privileged accounts. IA-2(3) The information system implements multifactor authentication for local access to privileged accounts. |
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, privilege account activation isn't possible without network access, so local access is never privileged. multifactor authentication and Privileged Identity Management |
IA-2(2) The information system implements multifactor authentication for network access to non-privileged accounts. IA-2(4) The information system implements multifactor authentication for local access to nonprivileged accounts. |
Implement multifactor authentication for all access to nonprivileged accounts Configure the following elements as an overall solution to ensure all access to nonprivileged accounts requires MFA. Configure Conditional Access policies to require MFA for all users. Microsoft recommends using a multifactor cryptographic hardware authenticator (for example, FIDO2 security keys, Windows Hello for Business (with hardware TPM), or smart card) to achieve AAL3. If your organization is cloud-based, we recommend using FIDO2 security keys or Windows Hello for Business. Windows Hello for Business hasn't 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 more information regarding Windows Hello for Business FIPS 140 validation, see Microsoft NIST AALs. See the following guidance regarding MDM policies differ slightly based on authentication methods. Smart Card / Windows Hello for Business Hybrid Only Smart Card Only FIDO2 Security Key Authentication Methods Additional Resources: |
IA-2(5) The organization requires individuals to be authenticated with an individual authenticator when a group authenticator is employed. |
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, Microsoft Entra ID permits binding of multiple authenticators to an account so that each user has an individual authenticator. Resources |
IA-2(8) The information system implements replay-resistant authentication mechanisms for network access to privileged accounts. |
Implement replay-resistant authentication mechanisms for network access to privileged accounts. Configure Conditional Access policies to require multifactor authentication for all users. All Microsoft Entra authentication methods at authentication assurance level 2 and 3 use either nonce or challenges and are resistant to replay attacks. References |
IA-2(11) The information system implements multifactor authentication for remote access to privileged and nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access and the device meets [FedRAMP Assignment: FIPS 140-2, NIAP Certification, or NSA approval*]. *National Information Assurance Partnership (NIAP) Additional FedRAMP Requirements and Guidance: Guidance: PIV = separate device. Refer to NIST SP 800-157 Guidelines for Derived Personal Identity Verification (PIV) Credentials. FIPS 140-2 means validated by the Cryptographic Module Validation Program (CMVP). |
Implement Microsoft Entra 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). Microsoft Entra authentication methods to consider at AAL3 meeting the separate device requirements are: FIDO2 security keys References |
**IA-2(12)* The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials. IA-2 (12) Additional FedRAMP Requirements and Guidance: Guidance: Include Common Access Card (CAC), that is, the DoD technical implementation of PIV/FIPS 201/HSPD-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 Microsoft Entra ID with setting federatedIdpMfaBehavior to Resources |
IA-3 Device Identification and Authentication The information system uniquely identifies and authenticates [Assignment: organization-defined specific and/or types of devices] before establishing a [Selection (one or more): local; remote; network] connection. |
Implement device identification and authentication prior to establishing a connection. Configure Microsoft Entra ID to identify and authenticate Microsoft Entra registered, Microsoft Entra joined, and Microsoft Entra hybrid joined devices. Resources |
IA-04 Identifier Management The organization manages information system identifiers for users and devices by: (a.) Receiving authorization from [FedRAMP Assignment at a minimum, the ISSO (or similar role within the organization)] to assign an individual, group, role, or device identifier; (b.) Selecting an identifier that identifies an individual, group, role, or device; (c.) Assigning the identifier to the intended individual, group, role, or device; (d.) Preventing reuse of identifiers for [FedRAMP Assignment: at least two (2) years]; and (e.) Disabling the identifier after [FedRAMP Assignment: thirty-five (35) days (see requirements and guidance)] IA-4e Additional FedRAMP Requirements and Guidance: Requirement: The service provider defines the time period of inactivity for device identifiers. Guidance: For DoD clouds, see DoD cloud website for specific DoD requirements that go above and beyond FedRAMP. IA-4(4) The organization manages individual identifiers by uniquely identifying each individual as [FedRAMP Assignment: contractors; foreign nationals]. |
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 Microsoft Entra ID 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-5 Authenticator Management The organization manages information system authenticators by: (a.) Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, or device receiving the authenticator; (b.) Establishing initial authenticator content for authenticators defined by the organization; (c.) Ensuring that authenticators have sufficient strength of mechanism for their intended use; (d.) Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators; (e.) Changing default content of authenticators prior to information system installation; (f.) Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators; (g.) Changing/refreshing authenticators [Assignment: organization-defined time period by authenticator type]. (h.) Protecting authenticator content from unauthorized disclosure and modification; (i.) Requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators; and (j.) Changing authenticators for group/role accounts when membership to those accounts changes. IA-5 Additional FedRAMP Requirements and Guidance: Requirement: Authenticators must be compliant with NIST SP 800-63-3 Digital Identity Guidelines IAL, AAL, FAL level 3. Link https://pages.nist.gov/800-63-3 |
Configure and manage information system authenticators. Microsoft Entra ID 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 Microsoft Entra 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-5(1) The information system, for password-based authentication: (a.) Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type]; (b.) Enforces at least the following number of changed characters when new passwords are created: [FedRAMP Assignment: at least fifty percent (50%)]; (c.) Stores and transmits only cryptographically protected passwords; (d.) Enforces password minimum and maximum lifetime restrictions of [Assignment: organization- defined numbers for lifetime minimum, lifetime maximum]; (e.)** Prohibits password reuse for [FedRAMP Assignment: twenty-four (24)] generations; and (f.) Allows the use of a temporary password for system logons with an immediate change to a permanent password. IA-5 (1) a and d Additional FedRAMP Requirements and Guidance: Guidance: If password policies are compliant with NIST SP 800-63B Memorized Secret (Section 5.1.1) Guidance, the control may be considered compliant. |
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 Microsoft Entra password protection, default global banned password lists are automatically applied to all users in a Microsoft Entra 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-5(2) The information system, for PKI-based authentication: (a.) Validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information; (b.) Enforces authorized access to the corresponding private key; (c.) Maps the authenticated identity to the account of the individual or group; and (d.) Implements a local cache of revocation data to support path discovery and validation during inability to access revocation information via the network. |
Implement PKI-based authentication requirements. Federate Microsoft Entra ID 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-5(4) The organization employs automated tools to determine if password authenticators are sufficiently strong to satisfy [FedRAMP Assignment: complexity as identified in IA-5 (1) Control Enhancement (H) Part A]. IA-5(4) Additional FedRAMP Requirements and Guidance: Guidance: If automated mechanisms that enforce password authenticator strength at creation aren't used, automated mechanisms must be used to audit strength of created password authenticators. |
Employ automated tools to validate password strength requirements. Microsoft Entra ID 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-5(6) The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access. |
Protect authenticators as defined in the FedRAMP High Impact level. For more information on how Microsoft Entra ID protects authenticators, see Microsoft Entra data security considerations. |
IA-05(7) The organization ensures that unencrypted static authenticators are not embedded in applications or access scripts or stored on function keys. |
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-5(8) The organization implements [FedRAMP Assignment: different authenticators on different systems] to manage the risk of compromise due to individuals having accounts on multiple information systems. |
Implement security safeguards when individuals have accounts on multiple information systems. Implement single sign-on by connecting all applications to Microsoft Entra ID, as opposed to having individual accounts on multiple information systems. |
IA-5(11) The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. |
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-5(13) The information system prohibits the use of cached authenticators after [Assignment: organization-defined time period]. |
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-6 Authenticator Feedback The information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. |
Obscure authentication feedback information during the authentication process. By default, Microsoft Entra ID obscures all authenticator feedback. |
IA-7 Cryptographic Module Authentication The information system implements mechanisms for authentication to a cryptographic module for requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication. |
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 Microsoft Entra ID 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-8 Identification and Authentication (Non-Organizational Users) The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users). |
The information system uniquely identifies and authenticates nonorganizational users (or processes acting for nonorganizational users). Microsoft Entra ID 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-8(1) The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies. IA-8(4) The information system conforms to FICAM-issued profiles. |
Accept and verify PIV credentials issued by other federal agencies. Conform to the profiles issued by the FICAM. Configure Microsoft Entra ID to accept PIV credentials via federation (OIDC, SAML) or locally via integrated Windows authentication. Resources |
IA-8(2) The information system accepts only FICAM-approved third-party credentials. |
Accept only FICAM-approved credentials. Microsoft Entra ID supports authenticators at NIST AALs 1, 2, and 3. Restrict the use of authenticators commensurate with the security category of the system being accessed. Microsoft Entra ID supports a wide variety of authentication methods. Resources |