Configure identification and authentication controls to meet FedRAMP High Impact level with Azure Active Directory

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-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 (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

FedRAMP Control ID and description Azure AD 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.

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

  • Users: Working with users in Microsoft Graph: ID property
  • Service principals: ServicePrincipal resource type : ID property

    Authentication and multifactor authentication

  • Achieving NIST authenticator assurance levels with the Microsoft identity platform
  • 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.
    Implement Azure AD Privileged Identity Management to require multifactor authentication for activation of privileged role assignment prior to use.

    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

  • Conditional access: Require multifactor authentication for all users
  • Configure Azure AD role settings in 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 non-privileged accounts.
    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.
    Configure device management policies via MDM (such as Microsoft Intune), Microsoft Endpoint Manager (MEM) or group policy objects (GPO) to enforce use of specific authentication methods.
    Configure Conditional Access policies to enforce device compliance.

    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 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.

    Guidance regarding MDM policies differ slightly based on authentication methods, they're broken out below.

    Smart Card / Windows Hello for Business
    Passwordless Strategy - Require Windows Hello for Business or smart card
    Require device to be marked as compliant
    Conditional Access - Require MFA for all users

    Hybrid Only
    Passwordless Strategy - Configure user accounts to disallow password authentication

    Smart Card Only
    Create a Rule to Send an Authentication Method Claim
    Configure Authentication Policies

    FIDO2 Security Key
    Passwordless Strategy - Excluding the password credential provider
    Require device to be marked as compliant
    Conditional Access - Require MFA for all users

    Authentication Methods
    Azure Active Directory passwordless sign-in (preview) | FIDO2 security keys
    Passwordless security key sign-in Windows - Azure Active Directory
    ADFS: Certificate Authentication with Azure AD & Office 365
    How Smart Card Sign-in Works in Windows (Windows 10)
    Windows Hello for Business Overview (Windows 10)

    Additional Resources:
    Policy CSP - Windows Client Management
    Use PowerShell scripts on Windows 10 devices in Intune
    Plan a passwordless authentication deployment with Azure AD

    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, Azure AD permits binding of multiple authenticators to an account so that each user has an individual authenticator.

    Resources

  • How it works: Azure AD multifactor authentication
  • Manage authentication methods for Azure AD multifactor authentication
  • 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 Azure AD authentication methods at authentication assurance level 2 and 3 use either nonce or challenges and are resistant to replay attacks.

    References

  • Conditional access: Require multifactor authentication for all users
  • Achieving NIST authenticator assurance levels with the Microsoft identity platform
  • IA-2(11)
    The information system implements multifactor authentication for remote access to privileged and non-privileged 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. Please 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 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

  • Windows Hello for Business with hardware TPM (TPM is recognized as a valid "something you have" factor by NIST 800-63B Section 5.1.7.1.)
  • Smart card

    References

  • Achieving NIST authenticator assurance levels with the Microsoft identity platform
  • NIST 800-63B Section 5.1.7.1
  • **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), i.e., 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 Azure AD with setting federatedIdpMfaBehavior to enforceMfaByFederatedIdp (recommended) or SupportsMfa to $True to direct multifactor authentication requests originating at Azure AD to AD FS. Alternatively, you can use PIV for sign-in on Windows devices and later use integrated Windows authentication along with seamless single sign-on. Windows Server and client verify certificates by default when used for authentication.

    Resources

  • What is federation with Azure AD?
  • Configure AD FS support for user certificate authentication
  • Configure authentication policies
  • Secure resources with Azure AD multifactor authentication and AD FS
  • Set-MsolDomainFederationSettings
  • Azure AD Connect: Seamless single sign-on
  • 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 Azure AD to identify and authenticate Azure AD Registered, Azure AD Joined, and Azure AD Hybrid joined devices.

    Resources

  • What is a device identity?
  • Plan an Azure AD devices deployment
  • Require managed devices for cloud app access with conditional access
  • 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 additional 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 http://iase.disa.mil/cloud_security/Pages/index.aspx.

    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 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

  • Manage inactive user accounts in Azure AD
  • Manage stale devices in Azure AD
  • See AC-02 guidance
  • 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.

    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

  • Achieving NIST authenticator assurance levels with the Microsoft identity platform

    Authentication methods and combined registration

  • What authentication and verification methods are available in Azure Active Directory?
  • Combined registration for SSPR and Azure AD multifactor authentication

    Authenticator revokes

  • Azure AD authentication methods API overview
  • 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 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

  • NIST Special Publication 800-63B
  • NIST Special Publication 800-53 Revision 5 - IA-5 - Control enhancement (1)

    Resource

  • Eliminate bad passwords using Azure AD password protection
  • 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 in case of inability to access revocation information via the network.
    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

  • What is federation with Azure AD?
  • Configure AD FS support for user certificate authentication
  • 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 which enforce password authenticator strength at creation are not used, automated mechanisms must be used to audit strength of created password authenticators.
    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

  • Eliminate bad passwords using Azure AD password protection
  • Azure AD password protection for Active Directory Domain Services
  • NIST Special Publication 800-53 Revision 5 - IA-5 - Control enhancement (4)
  • 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 Azure AD protects authenticators, see Azure AD 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

  • What are managed identities for Azure resources?
  • Create an Azure AD app and service principal in the portal
  • 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 Azure AD, as opposed to having individual accounts on multiple information systems.

    What is Azure single sign-on?

    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.
    Configure conditional access by using application controls for other applications.

    Resources

  • Interactive logon number of previous logons to cache
  • Session controls in conditional access policy: Application enforced restrictions
  • Session controls in conditional access policy: Conditional access application control
  • 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, Azure AD obscures all authenticator feedback.

    IA-7 Cryptographic Module Authentication
    The information system implements mechanisms for authentication to a cryptographic module that meet the 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 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

  • For more information, see IA-02 (2 and 4).
  • Achieving NIST authenticator assurance levels with the Microsoft identity platform
  • TPM Group Policy settings
  • 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 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

  • What is B2B collaboration in Azure Active Directory?
  • Direct federation with an identity provider for B2B
  • Properties of a B2B guest user
  • 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 Azure AD to accept PIV credentials via federation (OIDC, SAML) or locally via integrated Windows authentication.

    Resources

  • What is federation with Azure AD?
  • Configure AD FS support for user certificate authentication
  • What is B2B collaboration in Azure Active Directory?
  • Direct federation with an identity provider for B2B
  • IA-8(2)
    The information system accepts only FICAM-approved third-party credentials.
    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

  • What authentication and verification methods are available in Azure Active Directory?
  • Azure AD authentication methods policy API overview
  • Achieving NIST authenticator assurance levels with the Microsoft identity platform                                     
  • Next steps