Conditional Access Policy Design for DFARS 252.204-7012

Conditional Access is the enforcement plane for most of the identity and access controls in NIST SP 800-171 r2 and, by extension, the DFARS 252.204-7012 clause that requires its implementation. It is where MFA actually gets demanded, where untrusted devices actually get blocked, and where the audit trail for “we limit access to authorized users” lives. Done well, a Conditional Access design covers most of the AC, IA, and SC families in a way an assessor can examine in twenty minutes. Done badly, it leaves silent gaps and brittle exclusions that fail under review.

This post is a design pattern, not a click-through guide. It assumes the reader is familiar with Conditional Access mechanics in Entra ID and is responsible for hardening a Microsoft 365 tenant against the DFARS 7012 / NIST 800-171 / CMMC Level 2 control set.

The Controls Conditional Access Actually Maps To

From NIST SP 800-171 r2, the practices that Conditional Access most directly supports:

• 3.1.1 / 3.1.2 — Limit system access to authorized users / Limit system access to the types of transactions and functions that authorized users are permitted to execute. Conditional Access scopes app access to specified user populations and enforces session controls.

• 3.1.12 / 3.1.13 — Monitor and control remote access sessions / Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. Conditional Access requires MFA, blocks legacy authentication that cannot enforce modern crypto, and logs every session decision.

• 3.1.16 / 3.1.17 / 3.1.18 — Authorize wireless access / Protect wireless access using authentication and encryption / Control connection of mobile devices. Conditional Access enforces compliant device and named-location requirements that operationalize these.

• 3.1.20 — Verify and control/limit connections to and use of external systems. Conditional Access policies for guest access and external collaboration tools enforce this.

• 3.5.3 — Use multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. The Conditional Access MFA grant is the implementation.

Several Audit and Accountability (AU) practices also rely on the Conditional Access sign-in logs as their evidence source.

The Baseline Policy Set

A defensible baseline for a CUI-handling tenant typically contains the following policies. Each is named for the practice it most directly supports.

1. Require MFA for All Users (CA-001)

Assignments: All users; All cloud apps; All client app types. Grants: Require multifactor authentication. Exclusions: Break-glass accounts (two minimum, documented), service principals where MFA cannot apply (use authentication policies instead). This satisfies 3.5.3 at the broadest scope.

2. Block Legacy Authentication (CA-002)

Assignments: All users; All cloud apps; Client app type “Other clients” (which captures POP, IMAP, SMTP basic auth, EAS basic). Grants: Block. Microsoft has been deprecating basic auth for years, but legacy clients still surface in tenant audit logs. A blocking policy makes the absence enforceable rather than aspirational.

3. Require Compliant Device for CUI Apps (CA-003)

Assignments: Users in a “CUI Users” group; Apps that handle CUI (SharePoint, OneDrive, Exchange, Teams, plus any CUI-resident SaaS surfaced through Entra app proxy or enterprise app registration). Grants: Require device to be marked as compliant (Intune) AND require multifactor authentication. This is the core control for the 3.1.18 device control practice and aligns with Intune Compliance Baselines for Protecting CUI on Managed Devices.

4. Block Access from Untrusted Locations (CA-004)

Assignments: All users (or CUI Users group, depending on risk tolerance); All cloud apps; Locations: any location, excluding named “trusted” locations and U.S. territory IPs where applicable. Grants: Block. For organizations that operate exclusively in the U.S., excluding non-U.S. locations is straightforward and significantly reduces brute-force surface area. Use sparingly. Overbroad geo-blocks can create operational friction.

5. Require MFA for Admins on Every Sign-In (CA-005)

Assignments: Built-in directory role memberships (Global Admin, Security Admin, Exchange Admin, etc.); All cloud apps; Session: Sign-in frequency 1 hour, persistent browser session disabled. Grants: Require MFA, require compliant device. Privileged identity gets the strongest controls. Use Privileged Identity Management for just-in-time elevation rather than standing assignments where feasible.

6. Session Controls on Browser Sessions (CA-006)

Assignments: CUI Users; CUI apps; Conditions: Device platform = all, Client apps = Browser. Grants: Require app-enforced restrictions (for SharePoint/Exchange) OR Conditional Access App Control session policy (via Defender for Cloud Apps) for finer-grained download/copy/print control on unmanaged browsers. This is one of the places where Defender for Cloud Apps integration pays off. Particularly for occasional access from non-corporate devices that must be allowed but constrained.

7. Risk-Based Policies (CA-007, CA-008)

With Entra ID P2, sign-in risk and user risk policies add a behavioral dimension. Recommended: block high sign-in risk; require password change on high user risk (after MFA verification). These complement rather than replace the deterministic baseline above.

Exclusions: Managing Them Without Losing the Audit Trail

Every Conditional Access policy in production has at least one exclusion. Break-glass accounts are the obvious one. Service principals, on-premises synchronization accounts, and emergency access roles often follow. The discipline that survives an assessor walk-through:

• Maintain a single Entra security group named “CA Exclusion – Break Glass” with two named accounts. Document the accounts and rotation schedule in the SSP.
• Do not exclude individual users from policies. Use groups, and document the group’s purpose. An assessor reviewing exclusions wants to see a documented basis for each one.
• Audit Conditional Access policy changes via the Entra audit log. Pipe to a SIEM or to Sentinel with a workbook that alerts on policy changes. Policy drift is one of the most common findings in assessor evidence reviews.
• Test policy changes via the “What If” tool and via Conditional Access policy report-only mode before enabling. Document the test result in a change record.

Break-Glass Account Design

Two break-glass accounts, no fewer. Configure with:

• Long, randomly generated passphrases (40+ characters), stored in a sealed envelope in a physical safe with documented retrieval procedure.
• FIDO2 hardware key as a backup credential where MFA is technically required by policy on the break-glass exclusion (the exclusion bypasses standard MFA policies but the account is still subject to authentication policy).
• Excluded from all Conditional Access policies that could fail closed.
• Sign-in alerts in Defender for Cloud Apps or Sentinel that page on any use.
• Quarterly tested. A break-glass account that has not been logged into in 18 months may have been disabled by an unrelated cleanup script.

Named Locations: When They Help and When They Don’t

Named locations work well for:

• Geo-fencing access to U.S. territory for tenants whose workforce is U.S.-based.
• Marking known corporate IP ranges as trusted to suppress MFA prompt frequency for low-risk sessions.
• Logging access from anomalous geographies even when not blocked.

Named locations work poorly as the primary access control because consumer VPNs trivially route around them. They are a defense-in-depth signal, not a primary boundary. Pair them with compliant device requirements.

Evidence the Assessor Will Examine

For each of the Conditional Access policies above, expect the assessor to ask for:

• The policy export (JSON or screenshot) showing assignments, conditions, grants.
• The Conditional Access sign-in log entries demonstrating the policy enforced.
• The user/group membership justifying the assignment scope.
• The exclusion group membership and the documented basis for each excluded principal.
• The SSP section describing the policy.

Keep an exported configuration baseline in a controlled repository. When configuration drifts, the diff is the audit evidence.

What To Do Next

• Audit existing Conditional Access policies for legacy basic-auth allowances, unscoped exclusions, and undocumented break-glass accounts.
• Implement the baseline policy set in report-only mode, validate against the What If tool, then promote.
• Align Conditional Access with the Intune compliance baselines that satisfy the device-compliance grants.
• Pair Conditional Access with Microsoft Purview labeling for download-control session policies, and ensure the tenant decision (commercial vs. GCC High) supports the policies you need. The tenant decision is covered in Migrating to Microsoft GCC High.