**`TLP:CLEAR`**
# CISA M365 Secure Configuration Baseline for Microsoft Entra ID
Microsoft Entra ID is a cloud-based identity and access control service that provides security and functional capabilities. This Secure Configuration Baseline (SCB) provides specific policies to help secure Microsoft Entra ID.
The Secure Cloud Business Applications (SCuBA) project, run by the Cybersecurity and Infrastructure Security Agency (CISA), provides guidance and capabilities to secure federal civilian executive branch (FCEB) agencies’ cloud business application environments and protect federal information that is created, accessed, shared, and stored in those environments.
The CISA SCuBA SCBs for M365 help secure federal information assets stored within M365 cloud business application environments through consistent, effective, and manageable security configurations. CISA created baselines tailored to the federal government’s threats and risk tolerance with the knowledge that every organization has different threat models and risk tolerance. While use of these baselines will be mandatory for civilian Federal Government agencies, organizations outside of the Federal Government may also find these baselines to be useful references to help reduce risks.
For non-Federal users, the information in this document is being provided “as is” for INFORMATIONAL PURPOSES ONLY. CISA does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial entities or commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoritism by CISA. Without limiting the generality of the foregoing, some controls and settings are not available in all products; CISA has no control over vendor changes to products offerings or features. Accordingly, these SCuBA SCBs for M365 may not be applicable to the products available to you. This document does not address, ensure compliance with, or supersede any law, regulation, or other authority. Entities are responsible for complying with any recordkeeping, privacy, and other laws that may apply to the use of technology. This document is not intended to, and does not, create any right or benefit for anyone against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.
> This document is marked TLP:CLEAR. Recipients may share this information without restriction. Information is subject to standard copyright rules. For more information on the Traffic Light Protocol, see https://www.cisa.gov/tlp.
## License Compliance and Copyright
Portions of this document are adapted from documents in Microsoft’s [M365](https://github.com/MicrosoftDocs/microsoft-365-docs/blob/public/LICENSE) and [Azure](https://github.com/MicrosoftDocs/azure-docs/blob/main/LICENSE) GitHub repositories. The respective documents are subject to copyright and are adapted under the terms of the Creative Commons Attribution 4.0 International license. Sources are linked throughout this document. The United States government has adapted selections of these documents to develop innovative and scalable configuration standards to strengthen the security of widely used cloud-based software services.
## Assumptions
The **License Requirements** sections of this document assume the organization is using an [M365 E3](https://www.microsoft.com/en-us/microsoft-365/compare-microsoft-365-enterprise-plans) or [G3](https://www.microsoft.com/en-us/microsoft-365/government) license level at a minimum. Therefore, only licenses not included in E3/G3 are listed.
Some of the policies in this baseline may link to Microsoft instruction pages which assume that an agency has created emergency access accounts in Microsoft Entra ID and [implemented strong security measures](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access#create-emergency-access-accounts) to protect the credentials of those accounts.
## Key Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
The following are key terms and descriptions used in this document.
**Microsoft Entra ID hybrid**: This term denotes the scenario
when an organization has an on-premises Microsoft Windows Server Active Directory that contains the
master user directory but federates access to the cloud M365
Microsoft Entra ID tenant.
**Resource Tenant & Home Tenant**: In scenarios where guest users are involved the **resource tenant** hosts the M365 target resources that the guest user is accessing. The **home tenant** is the one that hosts the guest user's identity.
**BOD 25-01 Requirement**: This indicator means that the policy is required under CISA BOD 25-01.
**Automated Check**: This indicator means that the policy can be automatically checked via ScubaGear. See the [Quick Start Guide](../../../README.md#quick-start-guide) for help getting started.
**Configurable**: This indicator means that the policy can be customized via config file.
**Manual**: This indicator means that the policy requires manual verification of configuration settings.
## Highly Privileged Roles
This section provides a list of what CISA considers highly privileged [built-in roles in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference).
- Global Administrator
- Privileged Role Administrator
- User Administrator
- SharePoint Administrator
- Exchange Administrator
- Hybrid Identity Administrator
- Application Administrator
- Cloud Application Administrator
Throughout this document, this list of highly privileged roles is referenced in numerous baseline policies. Agencies should consider this list a foundational reference and apply respective baseline policies to additional Microsoft Entra ID roles as necessary.
## Conditional Access Policies
Numerous policies in this baseline rely on Microsoft Entra ID Conditional Access. Conditional Access is a feature that allows administrators to limit access to resources using characteristics such as user or group membership, device, IP location, and real-time risk detection. This section provides guidance and tools when implementing baseline policies which rely on Microsoft Entra ID Conditional Access.
As described in Microsoft’s literature related to conditional access policies, CISA recommends initially setting a policy to **Report-only** when it is created and then performing thorough hands-on testing to help prevent unintended consequences before toggling the policy from **Report-only** to **On**. The policy will only be enforced when it is set to **On**. One tool that can assist with running test simulations is the [What If tool](https://learn.microsoft.com/en-us/entra/identity/conditional-access/what-if-tool). Microsoft also describes [Conditional Access insights and reporting](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-insights-reporting) that can assist with testing.
ScubaGear does not assess Conditions configuration values within conditional access policies aside from the specific conditions specified in the SCuBA policy implementation sections. While these conditions are designed to refine access controls, overly granular or misaligned configurations may exclude certain scenarios from enforcement and can unintentionally introduce gaps in policy coverage. For example:
- **Overlapping or conflicting conditions** can result in users or devices falling outside intended protections.
- **Unaccounted exceptions** (e.g., new cloud apps or unmanaged devices) may bypass critical controls.
- **Dynamic environments** (such as hybrid identities or evolving IP ranges) can render static conditions ineffective over time.
To help mitigate risk from the gaps in conditional access policies, organizations should regularly review conditional access policy logic, validate coverage against all user and device contexts, and implement monitoring to detect unintended exclusions.
# Baseline Policies
## 1. Legacy Authentication
This section provides policies that reduce security risks related to legacy authentication protocols that do not support multifactor authentication (MFA).
### Policies
#### MS.AAD.1.1v1
Legacy authentication SHALL be blocked.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ The security risk of allowing legacy authentication protocols is they do not support MFA. Blocking legacy protocols reduces the impact of user credential theft.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ CM-7
- _MITRE ATT&CK TTP Mapping:_
- [T1110: Brute Force](https://attack.mitre.org/techniques/T1110/)
- [T1110.001: Password Guessing](https://attack.mitre.org/techniques/T1110/001/)
- [T1110.002: Password Cracking](https://attack.mitre.org/techniques/T1110/002/)
- [T1110.003: Password Spraying](https://attack.mitre.org/techniques/T1110/003/)
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/)
### Resources
- [Block legacy authentication with Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-block-legacy)
- [Five steps to securing your identity infrastructure](https://learn.microsoft.com/en-us/azure/security/fundamentals/steps-secure-identity)
### License Requirements
- N/A
### Implementation
#### MS.AAD.1.1v1 Instructions
1. [Determine if an agency’s existing applications use legacy authentication](https://learn.microsoft.com/en-us/entra/identity/conditional-access/block-legacy-authentication#identify-legacy-authentication-use) before blocking legacy authentication across the entire application base.
2. Create a Conditional Access policy to block legacy authentication
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Conditions > Client apps > Configure > Yes > Legacy authentication clients > Select only Exchange ActiveSync clients and Other clients
Access controls > Grant > Block Access
## 2. Risk Based Policies
This section provides policies that reduce security risks related to potentially compromised user accounts. These policies combine Microsoft Entra ID Protection and Microsoft Entra ID Conditional Access. Microsoft Entra ID Protection uses numerous signals to detect the risk level for each user or sign-in and determine if an account may have been compromised.
- _Additional mitigations to reduce risks associated with the authentication of workload identities:_ Although not covered in this baseline due to the need for an additional non-standard license, Microsoft provides support for mitigating risks related to workload identities (Microsoft Entra ID applications or service principals). Agencies should strongly consider implementing this feature because workload identities present many of the same risks as interactive user access and are commonly used in modern systems. CISA urges organizations to [apply Conditional Access policies to workload identities](https://learn.microsoft.com/en-us/entra/identity/conditional-access/workload-identity).
- _Note:_ In this section, the term ["high risk"](https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks) denotes the risk level applied by the Microsoft Entra ID Protection service to a user account or sign-in event.
### Policies
#### MS.AAD.2.1v1
Users detected as high risk SHALL be blocked.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ Blocking high-risk users may prevent compromised accounts from accessing the tenant.
- _Last modified:_ June 2023
- _Note:_ Users identified as high risk by Microsoft Entra ID Identity Protection can be blocked from accessing the system via a Microsoft Entra ID Conditional Access policy. A high-risk user will be blocked until an administrator remediates their account.
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-2(12), AC-2(13)
- _MITRE ATT&CK TTP Mapping:_
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/)
#### MS.AAD.2.2v1
A notification SHOULD be sent to the administrator when high-risk users are detected.
[](#msaad22v1-instructions)
- _Rationale:_ Notification enables the admin to monitor the event and remediate the risk. This helps the organization proactively respond to cyber intrusions as they occur.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-2(12)
- _MITRE ATT&CK TTP Mapping:_
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/)
#### MS.AAD.2.3v1
Sign-ins detected as high risk SHALL be blocked.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ This prevents compromised accounts from accessing the tenant.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-2(12), AC-2(13)
- _MITRE ATT&CK TTP Mapping:_
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/)
### Resources
- [What are risk detections?](https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks)
- [Simulating risk detections in Identity Protection](https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-simulate-risk)
- [Self-remediation experience with Microsoft Entra ID Protection and Conditional Access](https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-user-experience)
### License Requirements
- Requires a Microsoft Entra ID P2 license
### Implementation
#### MS.AAD.2.1v1 Instructions
1. Create a conditional access policy blocking users categorized as high risk by the Identity Protection service. Configure the following policy settings in the new conditional access policy as per the values below:
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Conditions > User risk > High
Access controls > Grant > Block Access
#### MS.AAD.2.2v1 Instructions
1. [Configure Microsoft Entra ID Protection to send a regularly monitored security mailbox email notification](https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-notifications#configure-users-at-risk-detected-alerts) when user accounts are determined to be high risk.
#### MS.AAD.2.3v1 Instructions
1. Create a Conditional Access policy blocking sign-ins determined high risk by the Identity Protection service. Configure the following policy settings in the new Conditional Access policy as per the values below:
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Conditions > Sign-in risk > High
Access controls > Grant > Block Access
## 3. Strong Authentication and a Secure Registration Process
This section provides policies that help reduce security risks related to user authentication and registration.
Phishing-resistant MFA is required per [Office of Management and Budget Memorandum 22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf).
Figure 1: Depiction of MFA methods from weakest to strongest. _Adapted from [Microsoft Page](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods)_
### Policies
#### MS.AAD.3.1v1
Phishing-resistant MFA SHALL be enforced for all users.
The phishing-resistant methods **Microsoft Entra ID certificate-based authentication (CBA)**, **FIDO2 Security Key**, **Windows Hello for Business**, and **device-bound passkeys** are the recommended authentication options since they offer forms of MFA with the least weaknesses. For federal agencies, Microsoft Entra ID CBA supports federal PIV card authentication directly to Microsoft Entra ID.
If on-premises PIV authentication and federation to Microsoft Entra ID is used, [enforce PIV logon via Microsoft Active Directory group policy](https://www.idmanagement.gov/implement/scl-windows/).
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ Weaker forms of MFA do not protect against sophisticated phishing attacks. By enforcing methods resistant to phishing, those risks are minimized.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ IA-2(1), IA-2(2), IA-5c, IA-5g, IA-2(8)
- _MITRE ATT&CK TTP Mapping:_
- [T1566: Phishing](https://attack.mitre.org/techniques/T1566/)
- [T1566.001: Spearphishing Attachment](https://attack.mitre.org/techniques/T1566/001/)
- [T1566.002: Spearphishing Link](https://attack.mitre.org/techniques/T1566/002/)
#### MS.AAD.3.2v2
MFA SHALL be enforced for all users.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ This policy helps protect the tenant for guest users or any other group with multifactor authentication where phishing-resistant MFA is not enforceable due to technical limitations. It protects against the weaknesses inherent in singlefactor authentication.
- _Last modified:_ February 2026
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ IA-2(1), IA-2(2)
- _MITRE ATT&CK TTP Mapping:_
- [T1110: Brute Force](https://attack.mitre.org/techniques/T1110/)
- [T1110.001: Password Guessing](https://attack.mitre.org/techniques/T1110/001/)
- [T1110.002: Password Cracking](https://attack.mitre.org/techniques/T1110/002/)
- [T1110.003: Password Spraying](https://attack.mitre.org/techniques/T1110/003/)
#### MS.AAD.3.3v2
If Microsoft Authenticator is enabled, it SHALL be configured to show login context information.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ This policy helps protect the tenant when Microsoft Authenticator is used by showing user context information, which helps reduce MFA phishing compromises.
- _Last modified:_ March 2025
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ IA-2(1), IA-2(2), IA-5c, IA-5g, IA-2(8), IA-2(13)
- _MITRE ATT&CK TTP Mapping:_
- [T1110: Brute Force](https://attack.mitre.org/techniques/T1110/)
- [T1110.001: Password Guessing](https://attack.mitre.org/techniques/T1110/001/)
- [T1110.002: Password Cracking](https://attack.mitre.org/techniques/T1110/002/)
- [T1110.003: Password Spraying](https://attack.mitre.org/techniques/T1110/003/)
#### MS.AAD.3.4v1
The Authentication Methods Manage Migration feature SHALL be set to Migration Complete.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ To disable the legacy authentication methods screen for the tenant, configure the Manage Migration feature to Migration Complete. The MFA and Self-Service Password Reset (SSPR) authentication methods are both managed from a central admin page, thereby reducing administrative complexity and potential security misconfigurations.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ CM-7
- _MITRE ATT&CK TTP Mapping:_
- None
#### MS.AAD.3.5v2
The authentication methods SMS, Voice Call, and Email One-Time Passcode (OTP) SHALL be disabled.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ SMS, voice call, and email OTP are the weakest authenticators. This policy forces users to use stronger MFA methods.
- _Last modified:_ February 2026
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ CM-7b, IA-5c
- _MITRE ATT&CK TTP Mapping:_
- [T1621: Multi-Factor Authentication Request Generation](https://attack.mitre.org/techniques/T1621/)
- [T1566: Phishing](https://attack.mitre.org/techniques/T1566/)
- [T1566.002: Spearphishing Link](https://attack.mitre.org/techniques/T1566/002/)
#### MS.AAD.3.6v1
Phishing-resistant MFA SHALL be required for highly privileged roles.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ This is a backup security policy to help protect privileged access to the tenant if the conditional access policy, which requires MFA for all users, is disabled or misconfigured.
- _Last modified:_ June 2023
- _Note:_ Refer to the Highly Privileged Roles section at the top of this document for a reference list of roles considered highly privileged.
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ IA-2(1), IA-5c, IA-5g, IA-2(8)
- _MITRE ATT&CK TTP Mapping:_
- [T1566: Phishing](https://attack.mitre.org/techniques/T1566/)
- [T1566.001: Spearphishing Attachment](https://attack.mitre.org/techniques/T1566/001/)
- [T1566.002: Spearphishing Link](https://attack.mitre.org/techniques/T1566/002/)
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/)
#### MS.AAD.3.7v1
Managed devices SHOULD be required for authentication.
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ The security risk of an adversary authenticating to the tenant from their own device is reduced by requiring a managed device to authenticate. Managed devices are under the provisioning and control of the agency. [OMB-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf) states, "When authorizing users to access resources, agencies must consider at least one device-level signal alongside identity information about the authenticated user."
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-20b, IA-3
- _MITRE ATT&CK TTP Mapping:_
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/)
#### MS.AAD.3.8v1
Managed Devices SHOULD be required to register MFA.
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ Reduce risk of an adversary using stolen user credentials and then registering their own MFA device to access the tenant by requiring a managed device provisioned and controlled by the agency to perform registration actions. This prevents the adversary from using their own unmanaged device to perform the registration.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-20b, IA-3
- _MITRE ATT&CK TTP Mapping:_
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/)
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.005: Device Registration](https://attack.mitre.org/techniques/T1098/005/)
#### MS.AAD.3.9v1
Device code authentication SHOULD be blocked.
[](#key-terminology)
[](../../../docs/configuration/configuration.md#conditional-access-policy-exclusions)
- _Rationale:_ The device code authentication flow has been abused to compromise user accounts via phishing. Since most organizations using M365 don't need device code authentication, blocking it mitigates the risk.
- _Last modified:_ February 2025
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ CM-7
- _MITRE ATT&CK TTP Mapping:_
- [T1528: Steal Application Access Token](https://attack.mitre.org/techniques/T1528/)
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Accounts](https://attack.mitre.org/techniques/T1078/004/)
### Resources
- [What authentication and verification methods are available in Microsoft Entra ID?](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods)
- [Use additional context in Authenticator notifications - Authentication methods policy](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-additional-context#enable-additional-context-in-the-portal)
- [M-22-09 Federal Zero Trust Architecture Strategy](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf)
- [Configure Microsoft Entra hybrid join](https://learn.microsoft.com/en-us/entra/identity/devices/how-to-hybrid-join)
- [Microsoft Entra joined devices](https://learn.microsoft.com/en-us/entra/identity/devices/concept-directory-join)
- [Set up automatic enrollment for Windows devices (for Intune)](https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enroll)
- [Enable passkeys (FIDO2) for your organization](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2)
- [Storm-2372 conducts device code phishing campaign](https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/)
- [Microsoft 365 Device Code Phishing Cyber Attack – Demonstration, Analysis and Mitigation](https://github.com/cisagov/ScubaGear/issues/1599)
- [Block device code flow](https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies#block-device-code-flow)
### License Requirements
- Policies related to managed devices require Microsoft Intune.
### Implementation
#### MS.AAD.3.1v1 Instructions
1. Create a conditional access policy enforcing phishing-resistant MFA for all users. Configure the following policy settings in the new conditional access policy, per the values below:
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Access controls > Grant > Grant Access > Require authentication strength > Phishing-resistant MFA
#### MS.AAD.3.2v2 Instructions
There are a few different options to implement a conditional access policy that enforces MFA. Each option is described below, followed by our recommendation and the respective instructions for each option.
- **Option 1** - Create a custom authentication strength that includes the specific multifactor authentication methods supported by your organization and then create a policy that enforces your custom authentication strength.
- **Option 2** - Create a policy that enforces multifactor authentication (no specific MFA method).
- **Option 3** - Create a policy that enforces the built-in authentication strength named "Multifactor authentication" (no specific MFA method).
We recommend using a custom authentication strength because you can enforce the specific methods that offer the highest security. We recommend that you require the passwordless authentication strength Microsoft Authenticator (Phone Sign-in) in lieu of alternative MFA methods, since it removes passwords from the sign-in flow, reducing the exposure to credential compromise.
**Option 1**. [Follow the instructions at this link](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strength-advanced-options#create-a-custom-authentication-strength) to create a custom authentication strength. Create a conditional access policy that enforces your custom authentication. Configure the following policy settings in the new conditional access policy, per the values below:
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Access controls > Grant > Grant Access > Require authentication strength > YOUR_CUSTOM_AUTHENTICATION_STRENGTH
**Option 2**. Create a conditional access policy that enforces MFA but does not dictate a specific MFA method. Configure the following policy settings in the new conditional access policy, per the values below:
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Access controls > Grant > Grant Access > Require multifactor authentication
**Option 3**. Create a conditional access policy that enforces the built-in authentication strength named "Multifactor authentication" and does not dictate a specific MFA method. Configure the following policy settings in the new conditional access policy, per the values below:
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Access controls > Grant > Grant Access > Require authentication strength > Multifactor authentication
#### MS.AAD.3.3v2 Instructions
If Microsoft Authenticator is in use, configure Authenticator to display context information to users when they log in.
1. In **Microsoft Entra admin center**, click **Authentication methods > Microsoft Authenticator**.
2. Click the **Configure** tab.
3. For **Allow use of Microsoft Authenticator OTP** select *No*.
4. Under **Show application name in push and passwordless notifications** select **Status > Enabled** and **Target > Include > All users**.
5. Under **Show geographic location in push and passwordless notifications** select **Status > Enabled** and **Target > Include > All users**.
6. Select **Save**
#### MS.AAD.3.4v1 Instructions
1. Go through the process of [How to migrate MFA and SSPR policy settings to the Authentication methods policy for Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage).
2. Once ready to finish the migration, [set the **Manage Migration** option to **Migration Complete**](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage#finish-the-migration).
#### MS.AAD.3.5v2 Instructions
1. In **Microsoft Entra admin center**, click **Authentication methods**
2. Click on the **SMS**, **Voice Call**, and **Email OTP** authentication methods and disable each of them. Their statuses should be **Enabled > No** on the **Authentication methods > Policies** page.
#### MS.AAD.3.6v1 Instructions
1. Create a conditional access policy enforcing phishing-resistant MFA for highly privileged roles. Configure the following policy settings in the new conditional access policy, per the values below:
Users > Include > Select users and groups > Directory roles > select each of the roles listed in the Highly Privileged Roles section at the top of this document
Target resources > Include > All resources (formerly 'All cloud apps')
Access controls > Grant > Grant Access > Require authentication strength > Phishing-resistant MFA
#### MS.AAD.3.7v1 Instructions
1. Create a conditional access policy requiring a user's device to be either Microsoft Entra ID hybrid joined or compliant during authentication. Configure the following policy settings in the new conditional access policy, per the values below:
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Access controls > Grant > Grant Access > Require device to be marked as compliant and Require Microsoft Entra ID hybrid joined device > For multiple controls > Require one of the selected controls
#### MS.AAD.3.8v1 Instructions
1. Create a conditional access policy requiring a user to be on a managed device when registering for MFA. Configure the following policy settings in the new conditional access policy, per the values below:
Users > Include > All users
Target resources > User actions > Register security information
Access controls > Grant > Grant Access > Require device to be marked as compliant and Require Microsoft Entra ID hybrid joined device > For multiple controls > Require one of the selected controls
#### MS.AAD.3.9v1 Instructions
1. Create a Conditional Access policy to block device code flow
Users > Include > All users
Target resources > Include > All resources (formerly 'All cloud apps')
Conditions > Authentication Flows > Configure > Yes > Select Device code flow
Access controls > Grant > Block Access
## 4. Centralized Log Collection
This section provides policies to reduce security risks related to the lack of security logs, which hampers security visibility.
### Policies
#### MS.AAD.4.1v1
Security logs SHALL be sent to the agency's security operations center for monitoring.
[](#msaad41v1-instructions)
- _Rationale:_ The security risk of not having visibility into cyber attacks is reduced by collecting logs in the agency’s centralized security detection infrastructure. This makes security events available for auditing, query, and incident response.
- _Last modified:_ June 2023
- _Note:_ The following Microsoft Entra ID logs (configured in diagnostic settings), are required: `AuditLogs, SignInLogs, RiskyUsers, UserRiskEvents, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ADFSSignInLogs, RiskyServicePrincipals, ServicePrincipalRiskEvents, EnrichedOffice365AuditLogs, MicrosoftGraphActivityLogs`. If managed identities are used for Azure resources, also send the `ManagedIdentitySignInLogs` log type. If the Microsoft Entra ID Provisioning Service is used to provision users to software-as-a-service (SaaS) apps or other systems, also send the `ProvisioningLogs` log type.
- _Note:_ Agencies can benefit from security detection capabilities offered by the CISA Cloud Log Aggregation Warehouse (CLAW) system. Agencies are urged to send the logs to CLAW. Contact CISA at cyberliason@cisa.dhs.gov to request integration instructions.
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AU-4
- _MITRE ATT&CK TTP Mapping:_
- [T1562: Impair Defenses](https://attack.mitre.org/techniques/T1562/)
- [T1562.008: Disable or Modify Cloud Logs](https://attack.mitre.org/techniques/T1562/008/)
### Resources
- [Everything you wanted to know about Security and Audit Logging in Office 365](https://thecloudtechnologist.com/2021/10/15/everything-you-wanted-to-know-about-security-and-audit-logging-in-office-365/)
- [What are Microsoft Entra sign-in logs??](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins)
- [National Cybersecurity Protection System-Cloud Interface Reference Architecture Volume One: General Guidance](https://www.cisa.gov/sites/default/files/publications/NCPS%20Cloud%20Interface%20RA%20Volume%20One%20%282021-05-14%29.pdf)
### License Requirements
- An Azure subscription may be required to send logs to an external system, such as the agency's Security Information and Event Management (SIEM).
### Implementation
#### MS.AAD.4.1v1 Instructions
Follow the configuration instructions unique to the products and integration patterns at your organization to send the security logs to the security operations center for monitoring.
## 5. Application Registration and Consent
This section provides policies that help reduce security risk of malicious applications or service principals added to the tenant by non-privileged users. Malicious applications can perform many of the same operations as interactive users and can access data on behalf of compromised users. These policies apply to custom-developed applications and applications published by third-party vendors.
### Policies
#### MS.AAD.5.1v1
Only administrators SHALL be allowed to register applications.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ Application access for the tenant presents a heightened security risk compared to interactive user access because applications are typically not subject to critical security protections, such as MFA policies. Reduce risk of unauthorized users installing malicious applications into the tenant by ensuring that only specific privileged users can register applications.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6(10), CM-5
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.001: Additional Cloud Credentials](https://attack.mitre.org/techniques/T1098/001/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.5.2v1
User consent to applications SHALL be restricted.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ Restricting user consent for applications reduces risk of users giving insecure applications access to their data via [consent grant attacks](https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide).
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6(10), CM-5
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.001: Additional Cloud Credentials](https://attack.mitre.org/techniques/T1098/001/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.5.3v1
An admin consent workflow SHALL be configured for applications.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ Configuring an admin consent workflow reduces the risk of the previous policy by setting up a process for users to securely request access to applications necessary for business purposes. Administrators have the opportunity to review the permissions requested by new applications and approve or deny access based on a risk assessment.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ CM-4
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.001: Additional Cloud Credentials](https://attack.mitre.org/techniques/T1098/001/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.5.5v1
Application Password Addition SHOULD be blocked.
[](#key-terminology)
- _Rationale:_ Applications that use client secrets might store them in configuration files, hardcode them in scripts, or risk exposure in other ways. The complexities of secret management make client secrets susceptible to leaks and attractive to attackers. Blocking password addition forces the use of more secure certificate-based authentication.
- _Last modified:_ April 2026
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ IA-5
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.001: Additional Cloud Credentials](https://attack.mitre.org/techniques/T1098/001/)
- [T1528: Steal Application Access Token](https://attack.mitre.org/techniques/T1528/)
#### MS.AAD.5.6v1
Application password lifetime SHOULD be restricted to 180 days or less.
[](#key-terminology)
- _Rationale:_ Long-lived credentials increase the window of opportunity for attackers to exploit compromised secrets. Enforcing a maximum password lifetime of 180 days ensures regular credential rotation, reducing the impact of credential theft and improving overall security hygiene.
- _Last modified:_ April 2026
- _Note:_ Due to how Microsoft Entra ID evaluates the MaxLifetime restriction using "less than" (not "less than or equal to"), the portal setting must be configured to **181 days** to enforce the requirement of "180 days or less."
- _Note:_ This policy applies only if password credentials are permitted. Microsoft and CISA recommend blocking password addition entirely (MS.AAD.5.5v1) as the preferred approach.
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ IA-5, SC-12
- _MITRE ATT&CK TTP Mapping:_
- [T1552: Unsecured Credentials](https://attack.mitre.org/techniques/T1552/)
- [T1552.001: Credentials In Files](https://attack.mitre.org/techniques/T1552/001/)
#### MS.AAD.5.7v1
Application certificate lifetime SHOULD be restricted to 365 days or less.
[](#key-terminology)
- _Rationale:_ While certificates provide more secure authentication than passwords, long-lived certificates can still be compromised. Limiting certificate lifetime to 365 days reduces the risk of exploitation while balancing operational overhead. Regular certificate rotation is a security best practice that minimizes exposure from compromised keys.
- _Note:_ Due to how Microsoft Entra ID evaluates the MaxLifetime restriction using "less than" (not "less than or equal to"), the portal setting must be configured to **366 days** to enforce the requirement of "365 days or less."
- _Last modified:_ April 2026
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ SC-12, IA-5
- _MITRE ATT&CK TTP Mapping:_
- [T1649: Steal or Forge Authentication Certificates](https://attack.mitre.org/techniques/T1649/)
### Resources
- [Restrict Application Registration for Non-Privileged Users](https://www.trendmicro.com/cloudoneconformity/knowledge-base/azure/ActiveDirectory/users-can-register-applications.html)
- [Configure the admin consent workflow](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow)
- [Configure restrictions on how applications can be configured](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-app-management-policies)
- [Tutorial: Enforce secret and certificate standards using application management policies](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/tutorial-enforce-secret-standards)
- [Application Management Policies API Overview](https://learn.microsoft.com/en-us/graph/api/resources/applicationauthenticationmethodpolicy)
### License Requirements
- N/A
### Implementation
#### MS.AAD.5.1v1 Instructions
1. In **Microsoft Entra admin center**, select **Users**.
2. Select **User settings**.
3. For **Users can register applications**, select **No**.
4. Click **Save**.
#### MS.AAD.5.2v1 Instructions
There are a couple of configuration options to restrict user consent. Each option is described below, followed by its respective instructions.
- **Option 1** - Most restrictive - Do not allow user consent for applications. An administrator is required to consent for all applications. Users can submit requests to use an application via the admin consent workflow but they cannot perform the consent themselves.
- **Option 2** - More flexible - Allow users to consent to applications from Microsoft verified publishers that use low-risk permissions. When selecting this option, an administrator must configure a set of permissions considered low risk in the **Consent and permissions** > **Permission classifications** page in the Microsoft Entra admin center.
**Option 1**. Do not allow user consent.
1. In **Microsoft Entra admin center** select **Enterprise Applications**.
2. Under **Security**, select **Consent and permissions**. Then select **User Consent Settings**.
3. Under **User consent for applications**, select **Do not allow user consent**.
4. Click **Save**.
**Option 2**. Allow restricted user consent.
1. In **Microsoft Entra admin center** select **Enterprise apps**.
2. Under **Security**, select **Consent and permissions**. Then select **User Consent Settings**.
3. Under **User consent for applications**, select **Allow user consent for apps from verified publishers, for selected permissions**.
4. Click **Save**.
5. In the page navigation menu, select **Permission classifications**.
6. Click on the **Low** tab.
7. [Add a list of low risk application permissions that users will be able to consent to](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-permission-classifications). We recommend only including permissions that provide minimal access to a user's data. For a reference of permissions that are considered risky and should be avoided [go to this JSON file and examine the permissions listed](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/schemas/RiskyAppPermissions.json) in the **Delegated** sections under Microsoft Graph and other apps.
#### MS.AAD.5.3v1 Instructions
1. In **Microsoft Entra admin center** create a new Microsoft Entra ID Group that contains admin users responsible for reviewing and adjudicating application consent requests. Group members will be notified when users request consent for new applications.
2. Then in **Microsoft Entra admin center** under **Applications**, select **Enterprise Applications**.
3. Under **Security**, select **Consent and permissions**. Then select **Admin consent settings**.
4. Under **Admin consent requests** navigate to **Users can request admin consent to apps they are unable to consent to** and select **Yes**.
5. Under **Who can review admin consent requests**, select **+ Add groups** and select the group responsible for reviewing and adjudicating app requests (created in step one above).
6. Click **Save**.
#### MS.AAD.5.5v1 Instructions
1. In **Microsoft Entra admin center**, select **Enterprise apps**.
2. Under **Security**, select **Application policies**.
3. Select **Block password addition**.
4. Set status to **On**. Ensure **Applies to** is set to **All applications**.
5. Leave **Only apply to apps created after** blank. Setting a date allows apps created before that date to bypass this restriction.
6. Click **Save**.
#### MS.AAD.5.6v1 Instructions
1. In **Microsoft Entra admin center**, select **Enterprise apps**.
2. Under **Security**, select **Application policies**.
3. Select **Restrict max password lifetime**.
4. Set status to **On**. Set maximum lifetime to **181 days**. Ensure **Applies to** is set to **All applications**.
5. Leave **Only apply to apps created after** blank. Setting a date allows apps created before that date to bypass this restriction.
6. Click **Save**.
#### MS.AAD.5.7v1 Instructions
1. In **Microsoft Entra admin center**, select **Enterprise apps**.
2. Under **Security**, select **Application policies**.
3. Select **Restrict max certificate lifetime**.
4. Set status to **On**. Set maximum lifetime to **366 days**. Ensure **Applies to** is set to **All applications**.
5. Leave **Only apply to apps created after** blank. Setting a date allows apps created before that date to bypass this restriction.
6. Click **Save**.
## 6. Passwords
This section provides policies that reduce security risks associated with legacy password practices.
### Policies
#### MS.AAD.6.1v1
User passwords SHALL NOT expire.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ The National Institute of Standards and Technology (NIST), OMB, and Microsoft have published guidance indicating mandated periodic password changes make user accounts less secure. For example, OMB-22-09 states, "Password policies must not require use of special characters or regular rotation."
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ IA-5(1)
- _MITRE ATT&CK TTP Mapping:_
- None
### Resources
- [Password expiration requirements for users](https://learn.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide#password-expiration-requirements-for-users)
- [passwordValidityPeriodInDays property](https://learn.microsoft.com/en-us/graph/api/resources/domain?view=graph-rest-1.0#properties)
- [Eliminate bad passwords using Microsoft Entra Password Protection](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad)
- [NIST Special Publication 800-63B - Digital Identity Guidelines](https://pages.nist.gov/800-63-3/sp800-63b.html)
### License Requirements
- N/A
### Implementation
#### MS.AAD.6.1v1 Instructions
> **Note:** Tenants created after October 2021 have password expiration disabled by default (`passwordValidityPeriodInDays = null`), which Microsoft treats as equivalent to "never expire." Tenants created before October 2021, or any tenant where the policy was explicitly configured and then reverted, will show `2147483647` (INT_MAX). ScubaGear treats both values as compliant. The M365 admin center password expiration checkbox applies to all managed domains in the tenant. If a tenant has **multiple root domains**, use the PowerShell in Step 2 to audit all of them and remediate any that have a finite expiration period set.
1. Sign in to the [Microsoft 365 admin center](https://admin.microsoft.com) and [configure the **Password expiration policy** to **Set passwords to never expire**](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/set-password-expiration-policy?view=o365-worldwide#set-password-expiration-policy).
2. Optionally, verify and remediate all root domains via PowerShell. This is useful if any domain had a finite expiration configured explicitly. This uses `Invoke-MgGraphRequest`, which is included with the `Microsoft.Graph.Authentication` module already required by ScubaGear. To audit only, connect with `Domain.Read.All`; to also remediate, use `Domain.ReadWrite.All`.
```powershell
Connect-MgGraph -Scopes "Domain.ReadWrite.All" # or alternatively "Domain.Read.All" for determining which domains are in a non-compliant state.
$NonCompliantDomains = (Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/domains").value | Where-Object {
$_.isRoot -and $_.isVerified -and
$null -ne $_.passwordValidityPeriodInDays -and
$_.passwordValidityPeriodInDays -ne [int32]::MaxValue
}
Write-Host $NonCompliantDomains | Format-List
# Remediate each non-compliant domain
Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/domains/example.com" `
-Body @{ passwordValidityPeriodInDays = [int32]::MaxValue }
# Verify domain configurations
$AllDomains = (Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/domains").value | Where-Object {
$_.isRoot -and $_.isVerified
}
Write-Host "All current domain password expiration policies"
foreach ($Domain in $AllDomains) {
Write-Host "Domain passwordValidityPeriodInDays: $($Domain.id) $($Domain.passwordValidityPeriodInDays)"
}
```
## 7. Highly Privileged User Access
This section provides policies that help reduce security risks related to the usage of [highly privileged Microsoft Entra ID built-in roles](#highly-privileged-roles). Privileged administrative users have access to operations that can undermine the security of the tenant by changing configurations and security policies. Special protections are necessary to secure this level of access.
Some of the policy implementations in this section reference specific features of the Microsoft Entra ID Privileged Identity Management (PIM) service that provides Privileged Access Management (PAM) capabilities. As an alternative to Microsoft Entra ID PIM, third-party products and services with equivalent PAM capabilities can be leveraged.
### Policies
#### MS.AAD.7.1v1
A minimum of two users and a maximum of eight users SHALL be provisioned with the Global Administrator role.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ The Global Administrator role provides unfettered access to the tenant. Limiting the number of users with this level of access makes tenant compromise more challenging. Microsoft recommends fewer than five users in the Global Administrator role. However, additional user accounts, up to eight, may be necessary to support emergency access and some operational scenarios.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6(5)
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.7.2v1
Privileged users SHALL be provisioned with finer-grained roles instead of Global Administrator.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ Many privileged administrative users do not need unfettered access to the tenant to perform their duties. By assigning them to roles based on least privilege, the risks associated with having their accounts compromised are reduced.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-5
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
- [T1651: Cloud Administration Command](https://attack.mitre.org/techniques/T1651/)
- [T1136: Create Account](https://attack.mitre.org/techniques/T1136/)
- [T1136.003: Cloud Account](https://attack.mitre.org/techniques/T1136/003/)
#### MS.AAD.7.3v1
Privileged users SHALL be provisioned cloud-only accounts separate from an on-premises directory or other federated identity providers.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ By provisioning cloud-only Microsoft Entra ID user accounts to privileged users, the risks associated with a compromise of on-premises federation infrastructure are reduced. It is more challenging for the adversary to pivot from the compromised environment to the cloud with privileged access.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6(5)
- _MITRE ATT&CK TTP Mapping:_
- [T1556: Modify Authentication Process](https://attack.mitre.org/techniques/T1556/)
- [T1556.007: Hybrid Identity](https://attack.mitre.org/techniques/T1556/007/)
#### MS.AAD.7.4v1
Permanent active role assignments SHALL NOT be allowed for highly privileged roles.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
[](../../../docs/configuration/configuration.md#privileged-user-policy-exclusions)
- _Rationale:_ Instead of giving users permanent assignments to privileged roles, provisioning access just in time lessens exposure if those accounts become compromised. In Microsoft Entra ID PIM or an alternative PAM system, just in time access can be provisioned by assigning users to roles as eligible instead of perpetually active.
- _Last modified:_ June 2023
- _Note:_ Exceptions to this policy are:
- Emergency access accounts that need perpetual access to the tenant in the rare event of system degradation or other scenarios.
- Some types of service accounts that require a user account with privileged roles; since these accounts are used by software programs, they cannot perform role activation.
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-2
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.7.5v1
Provisioning users to highly privileged roles SHALL NOT occur outside of a PAM system.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ Provisioning users to privileged roles within a PAM system enables enforcement of numerous privileged access policies and monitoring. If privileged users are assigned directly to roles in the M365 admin center or via PowerShell outside of the context of a PAM system, a significant set of critical security capabilities are bypassed.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-2
- _MITRE ATT&CK TTP Mapping:_
- [T1651: Cloud Administration Command](https://attack.mitre.org/techniques/T1651/)
#### MS.AAD.7.6v1
Activation of the Global Administrator role SHALL require approval.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ Requiring approval for a user to activate Global Administrator, which provides unfettered access, makes it more challenging for an attacker to compromise the tenant with stolen credentials, and it provides visibility of activities indicating a compromise is taking place.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6(1)
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.7.7v1
Eligible and active highly privileged role assignments SHALL trigger an alert.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ Closely monitor assignment of the highest privileged roles for signs of compromise. Send assignment alerts to enable the security monitoring team to detect compromise attempts.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-2(1)
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.7.8v1
User activation of the Global Administrator role SHALL trigger an alert.
[](https://www.cisa.gov/news-events/directives/bod-25-01-implementation-guidance-implementing-secure-practices-cloud-services)
[](#key-terminology)
- _Rationale:_ Closely monitor activation of the Global Administrator role for signs of compromise. Send activation alerts to enable the security monitoring team to detect compromise attempts.
- _Last modified:_ June 2023
- _Note:_ It is recommended to prioritize user activation of Global Administrator as one of the most important events to monitor and respond to.
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6(9)
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.7.9v1
User activation of other highly privileged roles SHOULD trigger an alert.
[](#key-terminology)
- _Rationale:_ Closely monitor activation of high-risk roles for signs of compromise. Send activation alerts to enable the security monitoring team to detect compromise attempts. In some environments, activating privileged roles can generate a significant number of alerts.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6(9)
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
- [T1136: Create Account](https://attack.mitre.org/techniques/T1136/)
- [T1136.003: Cloud Account](https://attack.mitre.org/techniques/T1136/003/)
### Resources
- [Limit number of Global Administrators to less than 5](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices#5-limit-the-number-of-global-administrators-to-less-than-5)
- [Implement Privilege Access Management](https://learn.microsoft.com/en-us/azure/security/fundamentals/steps-secure-identity#implement-privilege-access-management)
- [Assign Microsoft Entra roles in Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-add-role-to-user)
- [Privileged Identity Management (PIM) for Groups](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/concept-pim-for-groups)
- [Approve or deny requests for Microsoft Entra roles in Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-approval-workflow)
- [Configure security alerts for Microsoft Entra roles in Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-configure-security-alerts)
### License Requirements
- Policies [MS.AAD.7.4v1](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/baselines/aad.md#msaad74v1), [MS.AAD.7.5v1](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/baselines/aad.md#msaad75v1), [MS.AAD.7.6v1](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/baselines/aad.md#msaad76v1), [MS.AAD.7.7v1](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/baselines/aad.md#msaad77v1), [MS.AAD.7.8v1](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/baselines/aad.md#msaad78v1), and [MS.AAD.7.9v1](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/baselines/aad.md#msaad79v1) require a Microsoft Entra ID P2 license; however, a third-party Privileged Access Management (PAM) solution may also be used to satisfy the requirements. If a third-party solution is used, then a P2 license is not required for the respective policies.
### Implementation
The following implementation instructions that reference the Microsoft Entra ID PIM service will vary if using a third-party PAM system instead.
#### MS.AAD.7.1v1 Instructions
When counting the number of users assigned to the Global Administrator role, count each user only once.
1. In **Microsoft Entra admin center** count the number of users assigned to the **Global Administrator** role. Count users that are assigned directly to the role and users assigned via group membership. If you have Microsoft Entra ID PIM, count both the **Eligible assignments** and **Active assignments**. If any of the groups assigned to Global Administrator are enrolled in PIM for Groups, also count the number of group members from the PIM for Groups portal **Eligible** assignments.
2. Validate that there are a total of two to eight users assigned to the Global Administrator role.
#### MS.AAD.7.2v1 Instructions
This policy is based on the ratio below:
`X = (Number of users assigned to the Global Administrator role) / (Number of users assigned to other highly privileged roles)`
1. Follow the instructions for policy MS.AAD.7.1v1 above to get a count of users assigned to the Global Administrator role.
2. Follow the instructions for policy MS.AAD.7.1v1 above but get a count of users assigned to the other highly privileged roles (not Global Administrator). If a user is assigned to both Global Administrator and other roles, only count that user for the Global Administrator assignment.
3. Divide the value from step 2 from the value from step 1 to calculate X. If X is less than or equal to 1 then the tenant is compliant with the policy.
#### MS.AAD.7.3v1 Instructions
1. Perform the steps below for each highly privileged role. We reference the Global Administrator role as an example.
2. Create a list of all the users assigned to the **Global Administrator** role. Include users that are assigned directly to the role and users assigned via group membership. If you have Microsoft Entra ID PIM, include both the **Eligible assignments** and **Active assignments**. If any of the groups assigned to Global Administrator are enrolled in PIM for Groups, also include group members from the PIM for Groups portal **Eligible** assignments.
3. For each highly privileged user in the list, execute the Powershell code below but replace the `username@somedomain.com` with the principal name of the user who is specific to your environment. You can get the data value from the **Principal name** field displayed in the Microsoft Entra ID portal.
```
Connect-MgGraph
Get-MgBetaUser -Filter "userPrincipalName eq 'username@somedomain.com'" | FL
```
6. Review the output field named **OnPremisesImmutableId**. If this field contains a data value, it means that the user is not cloud-only. If the user is not cloud-only, create a cloud-only account for that user, assign the user to their respective roles and then remove the account that is not cloud-only from Microsoft Entra ID.
#### MS.AAD.7.4v1 Instructions
1. In **Microsoft Entra admin center** select **Roles and admins**. Perform the steps below for each highly privileged role. We reference the Global Administrator role as an example.
2. Select the **Global Administrator** role.
3. Under **Manage**, select **Assignments** and click the **Active assignments** tab.
4. Verify there are no users or groups with a value of **Permanent** in the **End time** column. If there are any, recreate those assignments to have an expiration date using Microsoft Entra ID PIM or an alternative PAM system. If a group is identified and it is enrolled in PIM for Groups, see the exception cases below for details.
Exception cases:
- Emergency access accounts that require perpetual active assignment.
- Service accounts that require perpetual active assignment.
- If using PIM for Groups, a group that is enrolled in PIM is allowed to have a perpetual active assignment to a role because activation is handled by PIM for Groups.
#### MS.AAD.7.5v1 Instructions
1. Perform the steps below for each highly privileged role. We reference the Global Administrator role as an example.
2. In **Microsoft Entra admin center** select **Roles and Admins**.
3. Select the **Global Administrator** role.
4. Under **Manage**, select **Assignments** and click the **Active assignments** tab.
5. For each user or group listed, examine the value in the **Start time** column. If it contains a value of **-**, this indicates the respective user/group was assigned to that role outside of Microsoft Entra ID PIM. If the role was assigned outside of Microsoft Entra ID PIM, delete the assignment and recreate it using Microsoft Entra ID PIM.
#### MS.AAD.7.6v1 Instructions
1. In **Microsoft Entra admin center**, under **Identity Governance**, select **Privileged Identity Management (PIM)**, and then select **Microsoft Entra roles**.
2. Under **Manage**, select **Roles**.
1. Select the **Global Administrator** role in the list.
2. Click **Role settings**.
3. Click **Edit**.
4. Select the **Require approval to activate** option.
5. Click **Update**.
3. Review the list of groups that are actively assigned to the **Global Administrator** role. If any of the groups are enrolled in PIM for Groups, also apply the same configurations as steps 2-7 above to each PIM group's **Member** settings.
#### MS.AAD.7.7v1 Instructions
1. In **Microsoft Entra admin center**, under **Identity Governance**, select **Privileged Identity Management (PIM)**, and then select **Microsoft Entra roles**.
2. Under **Manage**, select **Roles**. Perform the steps below for each highly privileged role. We reference the Global Administrator role as an example:
1. Click the **Global Administrator** role.
2. Click **Role settings** and then click **Edit**.
3. Click the **Notifications** tab.
4. Under **Send notifications when members are assigned as eligible to this role**, in the **Role assignment alert > Additional recipients** textbox, enter the email address of the security monitoring mailbox configured to receive privileged role assignment alerts.
5. Under **Send notifications when members are assigned as active to this role**, in the **Role assignment alert > Additional recipients** textbox, enter the email address of the security monitoring mailbox configured to receive privileged role assignment alerts.
6. Click **Update**.
3. For each of the highly privileged roles, if they have any PIM groups actively assigned to them, apply the same configurations as steps 2-8 above to each PIM group's **Member** settings.
#### MS.AAD.7.8v1 Instructions
1. In **Microsoft Entra admin center**, under **Identity Governance**, select **Privileged Identity Management (PIM)**. Select **Microsoft Entra roles**.
2. Click the **Global Administrator** role.
3. Click **Role settings** then click **Edit**.
4. Click the **Notifications** tab.
5. Under **Send notifications when eligible members activate this role**, in the **Role activation alert** select the **Additional recipients** textbox and enter the email address of the security monitoring mailbox configured to receive Global Administrator activation alerts.
6. Click **Update**.
7. If the Global Administrator role has any PIM groups actively assigned to it, then also apply the same configurations per the steps above to each PIM group's **Member** settings.
#### MS.AAD.7.9v1 Instructions
1. Follow the same instructions as MS.AAD.7.8v1 for each of the highly privileged roles (other than Global Administrator) but enter a security monitoring mailbox different from the one used to monitor Global Administrator activations.
2. For each of the highly privileged roles, if they have any PIM groups actively assigned to them, then also apply the same configurations per step 1 to each PIM group's **Member** settings.
## 8. Guest User Access
This section provides policies that help reduce security risks related to integrating M365 guest users. A guest user is a specific type of external user who belongs to a separate organization but can access files, meetings, Teams, and other data in the target tenant. It is common to invite guest users to a tenant for cross-agency collaboration purposes.
### Policies
#### MS.AAD.8.1v1
Guest users SHOULD have limited or restricted access to Microsoft Entra ID directory objects.
[](#key-terminology)
- _Rationale:_ Limiting the amount of object information available to guest users in the tenant, reduces malicious reconnaissance exposure if a guest account is compromised or created by an adversary.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6
- _MITRE ATT&CK TTP Mapping:_
- [T1087: Account Discovery](https://attack.mitre.org/techniques/T1087/)
- [T1087.003: Email Account](https://attack.mitre.org/techniques/T1087/003/)
- [T1087.004: Cloud Account](https://attack.mitre.org/techniques/T1087/004/)
- [T1526: Cloud Service Discovery](https://attack.mitre.org/techniques/T1526/)
#### MS.AAD.8.2v1
Only users with the Guest Inviter role SHOULD be able to invite guest users.
[](#key-terminology)
- _Rationale:_ By only allowing an authorized group of individuals to invite external users to create accounts in the tenant, an agency can enforce a guest user account approval process, reducing the risk of unauthorized account creation.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-6(10)
- _MITRE ATT&CK TTP Mapping:_
- [T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)
- [T1098.003: Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003/)
#### MS.AAD.8.3v1
Guest invites SHOULD only be allowed to specific external domains that have been authorized by the agency for legitimate business purposes.
[](#msaad83v1-instructions)
- _Rationale:_ Limiting which domains can be invited to create guest accounts in the tenant helps reduce the risk of users from unauthorized external organizations getting access.
- _Last modified:_ June 2023
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-3
- _MITRE ATT&CK TTP Mapping:_
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.001: Default Accounts](https://attack.mitre.org/techniques/T1078/001/)
### Resources
- [Configure external collaboration settings for B2B in Microsoft Entra External ID](https://learn.microsoft.com/en-us/entra/external-id/external-collaboration-settings-configure)
- [Compare member and guest default permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions#compare-member-and-guest-default-permissions)
### License Requirements
- N/A
### Implementation
#### MS.AAD.8.1v1 Instructions
1. In **Microsoft Entra admin center** select **External Identities > External collaboration settings**.
2. Under **Guest user access**, select either **Guest users have limited access to properties and memberships of directory objects** or **Guest user access is restricted to properties and memberships of their own directory objects (most restrictive)**.
3. Click **Save**.
#### MS.AAD.8.2v1 Instructions
1. In **Microsoft Entra admin center** select **External Identities > External collaboration settings**.
2. Under **Guest invite settings**, select **Only users assigned to specific admin roles can invite guest users**.
3. Click **Save**.
#### MS.AAD.8.3v1 Instructions
1. In **Microsoft Entra admin center** select **External Identities > External collaboration settings**.
2. Under **Collaboration restrictions**, select **Allow invitations
only to the specified domains (most restrictive)**.
3. Select **Target domains** and enter the names of the external domains authorized by the agency for guest user access.
4. Click **Save**.
## 9. AI Security
This section provides policies that help reduce security risks related to the usage of AI Agents and automated services that interact with tenant resources.
### Policies
#### MS.AAD.9.1v1
Risky AI agents SHALL be blocked.
[](#key-terminology)
- _Rationale:_ AI agents may access tenant resources and can perform actions autonomously. Blocking agents that exhibit risky behaviors reduces the risk of unauthorized access and automated misuse of resources.
- _Last modified:_ March 2026
- _Note:_ This policy is not applicable to Government Community Cloud (GCC) High, and Department of Defense (DoD) tenants.
- _NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping:_ AC-3, AC-6, CM-7(4)
- _MITRE ATT&CK TTP Mapping:_
- [T1078: Valid Accounts](https://attack.mitre.org/techniques/T1078/)
- [T1078.004: Cloud Account](https://attack.mitre.org/techniques/T1078/004/)
### Resources
- [Block access by high-risk agent identities](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-agent-block-high-risk)
### License Requirements
- Requires a Microsoft Entra ID P2 license and either Microsoft Agent 365 or Microsoft 365 E7.
### Implementation
#### MS.AAD.9.1v1 Instructions
1. Create a conditional access policy blocking High Risk AI Agents. Configure the following policy settings in the new conditional access policy, per the values below:
Assignments > Users, agents (Preview) or workload identities > What does this policy apply to? > Agents (Preview) > Include > All agent identities (Preview)
Target resources > Include > All resources (formerly 'All cloud apps')
Conditions > Agent risk (Preview) > Configure > Yes > Configure agent risk levels needed for policy to be enforced > High
# Appendix A: Microsoft Entra ID hybrid Guidance
Most of this document does not focus on securing Microsoft Entra ID hybrid environments. CISA released a separate [Hybrid Identity Solutions Architecture](https://www.cisa.gov/sites/default/files/2023-03/csso-scuba-guidance_document-hybrid_identity_solutions_architecture-2023.03.22-final.pdf) document addressing the unique implementation requirements of Microsoft Entra ID hybrid infrastructure.
# Appendix B: Cross-tenant Access Guidance
Some of the conditional access policies contained in this security baseline, if implemented as described, will impact guest user access to a tenant. For example, the policies require users to perform MFA and originate from a managed device to gain access. These requirements are also enforced for guest users. For these policies to work effectively with guest users, both the home tenant (the one the guest user belongs to) and the resource tenant (the target tenant) may need to configure their Microsoft Entra ID cross-tenant access settings.
Microsoft’s [Authentication and Conditional Access for External ID](https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access) provides an understanding of how MFA and device claims are passed from the home tenant to the resource tenant. To configure the inbound and outbound cross-tenant access settings in Microsoft Entra External ID, refer to Microsoft’s [Overview: Cross-tenant access with Microsoft Entra External ID](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview).
**`TLP:CLEAR`**