Using Microsoft Entra Conditional Access to Enforce 800-171 Access Controls
Author: Leonard Esere, Senior Cloud Security Architect
Date: April 2026
Organization: Aeolitech
Abstract
Microsoft Entra Conditional Access (CA) is the policy enforcement engine at the center of every credible CMMC Level 2 identity architecture. It evaluates contextual signals—user identity, device compliance state, network location, application sensitivity, real-time risk scores—and enforces access decisions before a session is established. For defense contractors operating in Microsoft 365 GCC High or Azure Government, a well-designed Conditional Access policy stack directly satisfies the majority of NIST SP 800-171 Rev 2 Access Control (AC) and Identification and Authentication (IA) requirements, including the 22 AC controls and 11 IA controls that CMMC assessors scrutinize most closely. This whitepaper maps each relevant Conditional Access capability to its NIST 800-171 control number, provides production-ready policy JSON examples, covers Privileged Identity Management (PIM) integration, break-glass account management, session control design, and documents the most common audit findings that lead to CMMC assessment failures.
Table of Contents
1. Conditional Access Fundamentals
2. Mapping CA Policies to NIST 800-171 Access Control Family (3.1.1–3.1.22)
3. MFA Enforcement: Satisfying IA.L2-3.5.3
4. Device Compliance: Mapping to SI.L2-3.14.x
5. Session Controls and Continuous Access Evaluation
6. Identity Protection Signals and Risk-Based Access
7. Named Locations for External Access Control (3.1.20)
8. PIM Integration for Administrative Accounts (3.1.5, 3.1.6)
9. Policy JSON Reference
10. Break-Glass Account Management
11. Common CMMC Audit Findings
12. About the Author
13. References
1. Conditional Access Fundamentals
Microsoft Entra Conditional Access is Microsoft's implementation of a Zero Trust Policy Decision Point (PDP). Every access request to Microsoft 365, Azure, and third-party SaaS applications integrated with Entra ID passes through the CA engine, which evaluates a set of signals and applies a configured access control decision.
The CA evaluation model:
`
IF [Assignments: Who + What + Where]
THEN [Grant/Block/Session Controls]
`
- Who: Users, groups, service principals, workload identities, guest accounts
- What: Cloud applications (All Cloud Apps, Office 365, Azure Management Portal, specific apps)
- Where/Conditions: Device platforms, locations (named locations, countries), client apps, device filter, identity protection risk level, authentication context
- Grant Controls: Block access, require MFA, require compliant device, require Hybrid Entra ID Join, require approved client app, require authentication strength
- Session Controls: App-enforced restrictions, Conditional Access App Control (MCAS proxy), sign-in frequency, persistent browser session, continuous access evaluation, disable resilience defaults
Licensing requirements:
- Conditional Access (basic policies): Entra ID P1 (included in M365 E3 GCC High, Business Premium)
- Risk-based CA policies: Entra ID P2 (included in M365 E5 GCC High)
- Continuous Access Evaluation: Entra ID P1 or P2
- Conditional Access App Control (MCAS integration): Microsoft Defender for Cloud Apps licensing
In GCC High environments, Entra ID Government provides the same Conditional Access feature set as Entra ID commercial, with the restriction that all traffic and data remains within the Azure Government boundary.
Policy evaluation order: All CA policies are evaluated independently for each access request. The most restrictive applicable policy wins—if any policy blocks access, the request is denied regardless of other policies that might grant it. This "all yes, any no" model means policy conflicts and overlaps require careful testing.
2. Mapping CA Policies to NIST 800-171 Access Control Family (3.1.1–3.1.22)
The NIST SP 800-171 Rev 2 Access Control family contains 22 requirements. Conditional Access directly implements or supports the majority of them:
| Control | Requirement Text | CA Implementation |
|---|---|---|
| 3.1.1 | Limit system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems) | CA policy: Require compliant device OR Hybrid Join; block unregistered devices |
| 3.1.2 | Limit system access to the types of transactions and functions that authorized users are permitted to execute | CA + Azure RBAC + App Roles; CA surfaces the entry point, RBAC enforces within applications |
| 3.1.3 | Control the flow of CUI in accordance with approved authorizations | CA Information Protection policies + Purview DLP; CA enforces entry, Purview enforces data flow |
| 3.1.4 | Separate the duties of individuals to reduce the risk of malevolent activity | PIM separate accounts + CA requiring distinct credential activation |
| 3.1.5 | Employ the principle of least privilege, including for specific security functions and privileged accounts | PIM eligible-only assignments + CA policy targeting admin roles requiring PIM elevation |
| 3.1.6 | Use non-privileged accounts or roles when accessing non-security functions | PIM separate standard vs. admin accounts; CA different policy stacks for each |
| 3.1.7 | Prevent non-privileged users from executing privileged functions and capture execution in audit logs | CA App Control + Azure PIM activation logs in Entra audit log |
| 3.1.8 | Limit unsuccessful logon attempts | Entra ID Smart Lockout (30-second lockout after 10 failed attempts by default; configurable) |
| 3.1.9 | Provide privacy and security notices consistent with CUI rules | Entra ID Terms of Use policy (CA grant control) |
| 3.1.10 | Use session lock with pattern-hiding displays after a period of inactivity | CA Session Control: sign-in frequency + Intune device compliance (screen lock requirement) |
| 3.1.11 | Terminate (automatically) a user session after a defined condition | CA Session Control: sign-in frequency (1-hour for high-sensitivity apps, 8-hour for standard) |
| 3.1.12 | Monitor and control remote access sessions | CA: require compliant device + named location + Conditional Access App Control proxy |
| 3.1.13 | Employ cryptographic mechanisms to protect the confidentiality of remote access sessions | TLS 1.2+ enforced at Azure Application Gateway; CA blocks legacy auth (no TLS for NTLM/Basic) |
| 3.1.14 | Route remote access via managed access control points | CA: require Compliant Device (Intune-managed); no unmanaged device access to CUI apps |
| 3.1.15 | Authorize remote execution of privileged commands and access to security-relevant information via remote access only for documented operational needs | CA: Named Location block for admin roles (only from specific on-prem IPs or Azure Bastion) |
| 3.1.16 | Authorize wireless access prior to allowing such connections | CA: Device compliance policy enforces Wi-Fi security requirements via Intune (EAP-TLS) |
| 3.1.17 | Protect wireless access using authentication and encryption | Intune compliance policy: require Wi-Fi profile; CA gates on device compliance |
| 3.1.18 | Control connection of mobile devices | CA: Device filter blocking non-compliant mobiles; Intune App Protection Policies |
| 3.1.19 | Encrypt CUI on mobile devices | Intune device compliance: require device encryption; CA blocks non-compliant devices |
| 3.1.20 | Verify and control connections to external systems | CA: Named Locations block unauthorized countries; block unrecognized external tenants |
| 3.1.21 | Limit use of portable storage devices on external systems | Intune: block USB storage via Device Restrictions profile; CA gates device compliance |
| 3.1.22 | Control CUI posted or processed on publicly accessible information systems | Purview DLP (not CA directly); CA + App Control prevent upload to non-approved cloud apps |
3. MFA Enforcement: Satisfying IA.L2-3.5.3
Control text: "Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts."
This is one of the most commonly deficient controls in CMMC assessments. The requirement is unambiguous: MFA is required for all privileged account access (local and network) and for all non-privileged account network access. A CA policy requiring MFA only for specific applications or specific user groups does not satisfy this control.
Policy: Require MFA for All Users (Baseline)
`json
{
"displayName": "CMMC-IA-3.5.3-RequireMFA-AllUsers",
"state": "enabled",
"conditions": {
"users": {
"includeUsers": ["All"],
"excludeUsers": [
"
"
],
"excludeGroups": []
},
"applications": {
"includeApplications": ["All"]
},
"clientAppTypes": ["all"]
},
"grantControls": {
"operator": "OR",
"builtInControls": ["mfa"]
}
}
`
MFA strength considerations for CMMC: Standard Entra MFA satisfies the literal text of 3.5.3. However, NIST SP 800-63B (Authentication and Lifecycle Management) and emerging DoD guidance increasingly favor phishing-resistant MFA (FIDO2 security keys or Windows Hello for Business) over TOTP/push notification-based MFA, which is vulnerable to real-time phishing and MFA fatigue attacks. For privileged accounts, phishing-resistant MFA should be required as a stronger implementation.
Policy: Require Phishing-Resistant MFA for Privileged Roles
`json
{
"displayName": "CMMC-IA-3.5.3-PhishingResistantMFA-Admins",
"state": "enabled",
"conditions": {
"users": {
"includeRoles": [
"62e90394-69f5-4237-9190-012177145e10",
"e8611ab8-c189-46e8-94e1-60213ab1f814",
"194ae4cb-b126-40b2-bd5b-6091b380977d"
]
},
"applications": {
"includeApplications": ["All"]
}
},
"grantControls": {
"operator": "OR",
"authenticationStrength": {
"id": "00000000-0000-0000-0000-000000000004"
}
}
}
`
Note: Role IDs above are Global Administrator, Privileged Role Administrator, and Security Administrator. The authenticationStrength ID 00000000-0000-0000-0000-000000000004 corresponds to Phishing-Resistant MFA (FIDO2/Windows Hello). Verify current GUIDs in your GCC High tenant.
4. Device Compliance: Mapping to SI.L2-3.14.x
The System and Information Integrity (SI) family includes requirements that devices maintain malware protections, apply security updates, and run verified software configurations. Conditional Access enforces these requirements by blocking access from non-compliant devices.
The gate mechanism: Intune compliance policies define what "compliant" means for each device platform. CA policies then require device compliance as a grant control. Only Intune-enrolled, policy-compliant devices receive the compliance token that CA checks.
Windows device compliance policy (Intune) for CMMC:
`
BitLocker: Required
Secure Boot: Required
Code Integrity: Required
Minimum OS version: 10.0.22621 (Windows 11 22H2)
Microsoft Defender Antivirus: Required
Microsoft Defender Antivirus Real-time protection: Required
Firewall: Required
Antispyware: Required
Antivirus: Required
`
CA Policy: Require Compliant Device for CUI Applications
`json
{
"displayName": "CMMC-SI-3.14-RequireCompliantDevice-CUIApps",
"state": "enabled",
"conditions": {
"users": {
"includeUsers": ["All"],
"excludeUsers": [
"
"
]
},
"applications": {
"includeApplications": [
"00000003-0000-0ff1-ce00-000000000000",
"00000002-0000-0ff1-ce00-000000000000",
"2793995e-0a7d-40d7-bd35-6968ba142197"
]
},
"platforms": {
"includePlatforms": ["all"]
}
},
"grantControls": {
"operator": "AND",
"builtInControls": ["compliantDevice", "mfa"]
}
}
`
Application IDs above are Office 365 SharePoint Online, Exchange Online, and Azure Management Portal. Replace with the correct application object IDs from your GCC High tenant.
Control mappings:
- 3.14.1 (Identify, report, and correct information and information system flaws) → Intune compliance: minimum OS version; Defender real-time protection
- 3.14.2 (Provide protection from malicious code at appropriate locations) → Intune compliance: Microsoft Defender Antivirus required + real-time protection enabled
- 3.14.4 (Update malicious code protection mechanisms when new releases are available) → Intune compliance: Defender signature version check; automatic update policy
- 3.14.6 (Monitor organizational systems to detect attacks and indicators of potential attacks) → Defender for Endpoint integration feeds alerts to Sentinel; device health attestation required for compliance
5. Session Controls and Continuous Access Evaluation
Session controls extend CA enforcement into active authenticated sessions—not just at initial sign-in. This is critical for CMMC because 3.1.10 and 3.1.11 require session lock and session termination behaviors.
Sign-in Frequency: Controls how often a user must reauthenticate for a given application. Entra ID defaults to a rolling 90-day persistent session—far too permissive for CUI workloads.
Recommended sign-in frequency settings by application sensitivity:
| Application | Sign-in Frequency |
|---|---|
| Azure Management Portal | 1 hour |
| SharePoint/OneDrive (CUI libraries) | 4 hours |
| Exchange Online | 8 hours |
| Teams | 8 hours |
| Non-CUI SaaS applications | 1 day |
Continuous Access Evaluation (CAE): CAE is a significant enhancement over static token-based access. With CAE, Entra ID and Microsoft services (Exchange Online, SharePoint, Teams, Graph API) maintain a near-real-time communication channel. When a risk signal occurs—user account disabled, password changed, high-risk sign-in detected, risky user flagged by Identity Protection—the service immediately revokes the active session rather than waiting for the token to expire.
CAE satisfies the spirit of 3.1.11 (terminate session after defined condition) more thoroughly than sign-in frequency alone, because it handles out-of-band risk signals in near real-time.
CA Policy: Session Controls for CUI Applications
`json
{
"displayName": "CMMC-AC-3.1.11-SessionControls-CUIApps",
"state": "enabled",
"conditions": {
"users": {
"includeUsers": ["All"],
"excludeUsers": ["
},
"applications": {
"includeApplications": [
"00000003-0000-0ff1-ce00-000000000000",
"00000002-0000-0ff1-ce00-000000000000"
]
}
},
"sessionControls": {
"signInFrequency": {
"value": 4,
"type": "hours",
"isEnabled": true
},
"persistentBrowser": {
"mode": "never",
"isEnabled": true
},
"continuousAccessEvaluation": {
"mode": "strictEnforcement"
}
}
}
`
App Control (Conditional Access App Control / MCAS Proxy): For unmanaged or personal devices that require limited access (e.g., a vendor who needs to read a document but should not be able to download or print it), Conditional Access can route the session through Microsoft Defender for Cloud Apps as a reverse proxy. The proxy enforces:
- Block download to unmanaged devices
- Block copy/paste of sensitive content
- Block printing
- Session activity logging with file activity detail
This satisfies 3.1.12 (monitor and control remote access sessions) and provides compensating controls for BYOD or third-party access scenarios.
6. Identity Protection Signals and Risk-Based Access
Microsoft Entra ID Protection (requires P2 licensing) continuously analyzes sign-in behavior and user risk using Microsoft's threat intelligence, which processes trillions of signals daily across commercial and government tenants.
Sign-in risk signals include:
- Atypical travel (sign-in from location A and location B within impossible travel time)
- Anonymous IP address (Tor exit nodes, known VPN services)
- Malware-linked IP address
- Unfamiliar sign-in properties (new device, new location, new browser)
- Password spray patterns
- Token theft indicators
User risk signals include:
- Leaked credentials (found in dark web breach databases)
- Confirmed compromised sign-ins
- User flagged by Microsoft intelligence
Risk-based CA policies:
`json
// Block sign-in when sign-in risk is High
{
"displayName": "CMMC-IA-RiskBasedAccess-BlockHighRisk",
"state": "enabled",
"conditions": {
"users": {
"includeUsers": ["All"],
"excludeUsers": ["
},
"applications": {
"includeApplications": ["All"]
},
"signInRiskLevels": ["high"]
},
"grantControls": {
"operator": "OR",
"builtInControls": ["block"]
}
}
`
`json
// Require MFA re-challenge when sign-in risk is Medium
{
"displayName": "CMMC-IA-RiskBasedAccess-MFAMediumRisk",
"state": "enabled",
"conditions": {
"users": {
"includeUsers": ["All"],
"excludeUsers": ["
},
"applications": {
"includeApplications": ["All"]
},
"signInRiskLevels": ["medium"]
},
"grantControls": {
"operator": "OR",
"builtInControls": ["mfa"]
}
}
`
Forensic retention: All Entra ID sign-in logs and Identity Protection risk events must be forwarded to Microsoft Sentinel (or a Log Analytics workspace) and retained for a minimum of 90 days (active) and 1 year (archived). Entra ID's native portal only retains 30 days of sign-in logs by default—a common CMMC finding.
7. Named Locations for External Access Control (3.1.20)
Control text (3.1.20): "Verify and control/limit connections to external systems."
Named Locations in Entra ID define IP address ranges or countries/regions that are associated with specific trust levels. They enable CA policies to make access decisions based on network context.
Use cases for CMMC:
1. Corporate network trust: Define on-premises network egress IPs as a "Trusted Corporate Network" named location. Require stronger MFA or block certain actions from outside this location.
2. Block unauthorized countries: Define an allowed countries location (US only for most DIB contractors) and block access attempts from all other countries. This satisfies 3.1.20 by limiting access to verified, controlled network contexts.
3. Restrict admin access to known locations: Global Administrators should only be able to perform administrative actions from specific IP ranges (e.g., the corporate network, a management VPN, or specific Azure Bastion egress IPs). Block admin role activation from foreign countries or unknown networks.
Named Location: US Only (Country Filter)
In the Entra portal (entra.microsoft.com → Protection → Conditional Access → Named Locations):
- Create a Countries location named "Allowed Countries - US Only"
- Select United States, include unknown countries: No
- Use this in CA policies as "not this location" → Block
CA Policy: Block Access from Non-US Locations
`json
{
"displayName": "CMMC-AC-3.1.20-BlockNonUSAccess",
"state": "enabled",
"conditions": {
"users": {
"includeUsers": ["All"],
"excludeUsers": ["
},
"applications": {
"includeApplications": ["All"]
},
"locations": {
"includeLocations": ["All"],
"excludeLocations": [
"
"AllTrusted"
]
}
},
"grantControls": {
"operator": "OR",
"builtInControls": ["block"]
}
}
`
Note: Test this policy thoroughly in Report-Only mode before enabling. Contractor staff traveling internationally will be blocked. A process for temporary exceptions (justification-based MFA + admin approval) should be documented in your SSP.
8. PIM Integration for Administrative Accounts (3.1.5, 3.1.6)
Control 3.1.5: "Employ the principle of least privilege, including for specific security functions and privileged accounts."
Control 3.1.6: "Use non-privileged accounts or roles when accessing non-security functions."
Microsoft Entra Privileged Identity Management (PIM) directly addresses both controls. PIM converts permanent Active role assignments into time-bound Eligible assignments—administrators must explicitly activate their privileged role, providing justification and completing MFA, before elevated access is granted.
Account structure for CMMC compliance:
Every privileged user should maintain two separate accounts:
- Standard account (
alice.smith@contoso.onmicrosoft.us) — used for day-to-day work (email, Teams, web browsing) - Admin account (
alice.smith-admin@contoso.onmicrosoft.us) — used only for administrative tasks; has no mail license; activates roles via PIM only when needed
PIM role settings for Global Administrator:
`
Maximum activation duration: 4 hours
Require justification on activation: Yes
Require ticket information on activation: Yes (ServiceNow ticket number)
Require Multi-Factor Authentication on activation: Yes (Phishing-Resistant)
Require approval to activate: Yes (requires second admin approval)
Notification when eligible role is activated: Email to SOC distribution list
Periodic access reviews: Quarterly (90 days), reviewer = Security Admin
`
PIM role settings for lower-privilege admin roles (Security Reader, Compliance Admin):
`
Maximum activation duration: 8 hours
Require justification: Yes
Require MFA: Yes (standard MFA acceptable)
Require approval: No
Notification: Email to role owner
Access reviews: Bi-annual (180 days)
`
Entra ID audit log for PIM: Every PIM activation, approval, denial, and deactivation is recorded in the Entra ID audit log with: principal, role, justification, start time, end time, approver. These logs must be forwarded to Sentinel and retained for at least 90 days (active) + 1 year (archived) per CMMC AU requirements.
CA Policy: Require Elevation for Azure Portal Access
`json
{
"displayName": "CMMC-AC-3.1.5-RequirePIMElevation-AzurePortal",
"state": "enabled",
"conditions": {
"users": {
"includeRoles": [
"62e90394-69f5-4237-9190-012177145e10",
"e8611ab8-c189-46e8-94e1-60213ab1f814"
]
},
"applications": {
"includeApplications": [
"797f4846-ba00-4fd7-ba43-dac1f8f63013"
]
}
},
"grantControls": {
"operator": "AND",
"builtInControls": [
"mfa",
"compliantDevice"
]
},
"sessionControls": {
"signInFrequency": {
"value": 1,
"type": "hours",
"isEnabled": true
}
}
}
`
Application ID 797f4846-ba00-4fd7-ba43-dac1f8f63013 is the Azure Management portal. In GCC High, verify the correct application ID in your tenant.
9. Policy JSON Reference
Complete recommended CA policy stack for CMMC Level 2 (GCC High):
| Policy Name | Purpose | State |
|---|---|---|
| CMMC-BlockLegacyAuth | Block all legacy authentication clients (NTLM, Basic Auth, IMAP, POP3) | Enabled |
| CMMC-IA-3.5.3-RequireMFA-AllUsers | MFA for all users on all cloud apps | Enabled |
| CMMC-IA-PhishingResistantMFA-Admins | Phishing-resistant MFA for privileged roles | Enabled |
| CMMC-SI-3.14-RequireCompliantDevice-CUIApps | Compliant device for M365 and Azure | Enabled |
| CMMC-AC-3.1.20-BlockNonUSAccess | Block sign-ins from non-US countries | Enabled |
| CMMC-AC-3.1.8-SmartLockout | Smart lockout (enforced by default, documented) | Enforced by platform |
| CMMC-AC-3.1.11-SessionControls-CUIApps | Sign-in frequency + no persistent browser for CUI apps | Enabled |
| CMMC-IA-RiskBasedAccess-BlockHighRisk | Block high-risk sign-ins | Enabled |
| CMMC-IA-RiskBasedAccess-MFAMediumRisk | Require MFA for medium-risk sign-ins | Enabled |
| CMMC-AC-3.1.9-TermsOfUse | Require Terms of Use acceptance | Enabled |
| CMMC-AC-GuestAccess-Block | Block all guest/external B2B collaboration (or restrict to approved tenants) | Enabled |
Block Legacy Authentication (highest priority):
`json
{
"displayName": "CMMC-BlockLegacyAuthentication",
"state": "enabled",
"conditions": {
"users": {
"includeUsers": ["All"]
},
"applications": {
"includeApplications": ["All"]
},
"clientAppTypes": [
"exchangeActiveSync",
"other"
]
},
"grantControls": {
"operator": "OR",
"builtInControls": ["block"]
}
}
`
Terms of Use (3.1.9 privacy and security notice):
Terms of Use in Entra ID displays a PDF document to users at login. The document should contain the organization's CUI acceptable use policy, notice of monitoring, and system use notification required by NIST 800-171 3.1.9. Users must accept before accessing M365 resources. Acceptance is logged in the Entra ID audit log.
10. Break-Glass Account Management
Break-glass (emergency access) accounts exist to prevent lockout from the Entra ID tenant if all regular administrator accounts are compromised or inaccessible. CMMC assessors will examine break-glass accounts because improper configuration is both a compliance gap and a security risk.
CMMC-compliant break-glass account requirements:
| Requirement | Implementation |
|---|---|
| Excluded from all CA policies | List both accounts in every CA policy's user exclusion |
| Cloud-only identity | Not synced from on-premises AD; not subject to AD password policies |
| No named individual | Shared accounts tied to a role, not a person; breakglass1@contoso.onmicrosoft.us |
| Strong, random password | 64+ character random string; not stored in any password manager |
| FIDO2 hardware key | YubiKey or equivalent; not an authenticator app |
| Offline credential storage | Sealed envelope in physical safe; dual-person integrity (two people needed to access) |
| Sign-in monitoring | Sentinel alert rule: any sign-in from break-glass account triggers immediate P1 alert to SOC and ISSO |
| Periodic verification | Monthly automated test of credential validity (without actually signing in); documented in SOC runbook |
| No licensed applications | No email, Teams, or SharePoint licenses; accounts exist only for Entra/Azure admin access |
Sentinel alert for break-glass sign-in:
`kql
// KQL query for Sentinel Analytics Rule: Break-Glass Account Sign-In
SigninLogs
| where UserPrincipalName in (
"breakglass1@contoso.onmicrosoft.us",
"breakglass2@contoso.onmicrosoft.us"
)
| project TimeGenerated, UserPrincipalName, IPAddress, Location, ResultType, ResultDescription
| order by TimeGenerated desc
`
Automation Rule: When this alert fires, immediately email ISSO, security manager, and Contracting Officer's Representative (COR) with sign-in details. Any use of break-glass accounts outside a declared incident or maintenance window should trigger an investigation.
11. Common CMMC Audit Findings Related to Conditional Access
Based on patterns observed in C3PAO assessments and NIST SP 800-171 DoD assessments, these are the most frequently cited CA-related deficiencies:
Finding 1: Legacy authentication not blocked
Control: 3.1.1, 3.5.3
Organizations that have enabled MFA but have not blocked legacy authentication protocols (Basic Auth, NTLM) effectively have no MFA protection—attackers bypass MFA entirely by using clients that don't invoke the CA engine. Remediation: Deploy the CMMC-BlockLegacyAuthentication policy immediately, after confirming no legitimate business processes depend on legacy clients.
Finding 2: MFA policy excludes specific applications or has excessive exclusions
Control: 3.5.3
MFA policies scoped to "All Cloud Apps" with exception lists that include critical applications (e.g., "exclude Salesforce" or "exclude legacy app") create gaps. Every exclusion must be documented with a compensating control and business justification in the SSP.
Finding 3: Audit log retention below 90 days in Entra ID
Control: 3.3.1, 3.3.2
Entra ID's default sign-in log retention is 30 days (P2) or 7 days (P1 or no license). Without a Sentinel workspace or Log Analytics workspace connected via diagnostic settings, logs are purged before CMMC's de facto 90-day retention requirement is met. Remediation: Configure Entra ID diagnostic settings to forward all sign-in, audit, and Identity Protection logs to a Sentinel workspace with 90+ day retention.
Finding 4: Break-glass accounts not excluded from CA policies
Control: 3.1.1, 3.1.5
Some organizations configure CA policies to include "All Users" with no exclusions for break-glass accounts. If an incident requires break-glass use and the account is subject to a Compliant Device or Named Location policy, the break-glass will fail. This is a P1 operational risk and an assessor finding.
Finding 5: No session controls on administrative portals
Control: 3.1.10, 3.1.11
Azure Management Portal and Entra Admin Center sessions with no sign-in frequency control can persist for the default 90-day rolling token lifetime. A compromised administrator session token could be used by an attacker for days before detection. Remediation: Set sign-in frequency to 1 hour for Azure Management Portal and Entra Admin Center.
Finding 6: PIM exists but permanent Global Admin assignments remain
Control: 3.1.5
Organizations that deploy PIM but leave one or more accounts with permanent Active Global Administrator assignments (rather than Eligible) do not satisfy 3.1.5 least privilege. Every privileged role—including Global Administrator—must be Eligible only. The only exceptions are break-glass accounts (by design) and service principals that require persistent elevated access for automated tasks.
Finding 7: Separate privileged accounts not enforced
Control: 3.1.6
Administrators using their standard user accounts to activate Global Admin in PIM—rather than a dedicated admin account—means email, web browsing, and administrative functions share one credential context. If the standard account is phished, the attacker can immediately activate Global Admin. Separate admin accounts (with no email/Teams licenses) are required.
Finding 8: No SSP documentation for CA policies
Control: 3.1.1, general SSP requirements
C3PAO assessors require that every CA policy be documented in the System Security Plan with: policy name, conditions, grant controls, session controls, exclusions, the specific 800-171 control(s) it satisfies, and the date last reviewed. Many organizations have functional CA policies but no corresponding SSP documentation, resulting in a POA&M finding.
About the Author
Leonard Esere is a Senior Cloud Security Architect at Aeolitech specializing in Zero Trust architecture, Microsoft identity security, and CMMC assessment preparation for DIB contractors. He has supported accreditation activities at Los Alamos National Laboratory (LANL), contributed to MITRE ATT&CK-based threat modeling for DoD program offices, and holds active DoD clearance credentials. His CMMC work spans both Level 2 and Level 3 assessment preparation across manufacturing, aerospace, and research sectors. Leonard holds CISSP, Microsoft Certified: Identity and Access Administrator Associate (SC-300), and Microsoft Security Operations Analyst (SC-200) certifications.
References
1. Microsoft. Entra Conditional Access Overview. https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
2. Microsoft. Privileged Identity Management. https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
3. Microsoft. Entra ID Protection. https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection
4. Microsoft. Continuous Access Evaluation. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
5. Microsoft. Named Locations in Entra Conditional Access. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-assignment-network
6. NIST. Special Publication 800-171 Rev. 2: Access Control Family. https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final
7. NIST. Special Publication 800-63B: Digital Identity Guidelines – Authentication and Lifecycle Management. https://csrc.nist.gov/publications/detail/sp/800-63b/final
8. CMMC Accreditation Body. CMMC Assessment Process (CAP) v2.0. https://cyberab.org/
9. DoD. DFARS 252.204-7012. https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting
10. Microsoft TechCommunity. Copilot for Security and NIST 800-171: Access Control. https://techcommunity.microsoft.com/blog/publicsectorblog/microsoft-copilot-for-security-and-nist-800-171-access-control/4075263
11. Totem Technologies. Microsoft 365 Conditional Access and CMMC. https://www.totem.tech/microsoft-365-conditional-access-and-cmmc/
12. Microsoft. Conditional Access: Upcoming Enforcement Changes. https://techcommunity.microsoft.com/blog/microsoft-entra-blog/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/4488925
Call to Action
Aeolitech provides Conditional Access architecture design, policy implementation, PIM configuration, and CMMC-readiness assessments for organizations operating in Microsoft 365 GCC High and Azure Government. Our team has direct C3PAO-engagement experience and can provide pre-assessment gap analysis against all 110 NIST SP 800-171 controls, with a specific focus on the CA policy stack, PIM configuration, and audit log pipeline that assessors examine most closely. Contact us for a Conditional Access Health Check—a two-day engagement that reviews your entire CA policy stack, tests policy coverage, and produces a written gap report with prioritized remediation actions.
© 2026 Aeolitech. All rights reserved. Policy JSON examples are provided as reference implementations. Test all Conditional Access policies in Report-Only mode before enabling in production. Review Microsoft Learn documentation for current GCC High-specific guidance before deployment.