CMMC and NIST SP 800-171: auditing Microsoft identity for defense contractors

If your company handles Controlled Unclassified Information for the Department of Defense, CMMC is no longer a distant concern. A large share of its requirements are identity requirements — who can access what, proven with what, and logged how. For most contractors, that means Entra ID and Microsoft 365.

The short version of the framework

The Department of Defense uses CMMC to verify that companies in the defense industrial base protect two kinds of government information: Federal Contract Information (FCI) and Controlled Unclassified Information (CUI).

The model has three levels. Level 1 covers basic safeguarding of FCI. Level 2 is where most contractors land: it aligns with the 110 security requirements of NIST SP 800-171, and applies when you handle CUI. Level 3 adds requirements drawn from NIST SP 800-172 for the most sensitive programs.

Why this is largely an identity problem

Look at how the 800-171 requirement families are weighted and the picture is clear. Access Control is by far the largest family. Add Identification and Authentication and Audit and Accountability, and a substantial portion of your assessment rests on how your directory is configured.

Access Control

The requirements here translate directly into questions you can answer from Entra ID:

• Least privilege — how many accounts hold administrative roles, and do they need them permanently? Standing privileged access is the classic finding.
• Separation of duties — are privileged and day-to-day accounts distinct, or does one person administer everything from their daily-driver login?
• Remote access control — conditional access policies governing where and from what device access is permitted.
• Session termination and lock — session lifetime and inactivity settings.
• Control of external connections — guest access, external sharing, federation with other tenants.

Identification and Authentication

This family is where multi-factor authentication lives, and it is unambiguous: MFA for privileged accounts and for network access is a requirement, not a recommendation. In practice, assessors find gaps not because MFA is absent but because it is partially applied — a conditional access policy with an exclusion group that quietly grew, a break-glass account nobody documented, a legacy protocol still enabled that bypasses the policy entirely.

The family also covers identifier management, password complexity and reuse, and the prohibition on shared accounts — every user uniquely identified.

Audit and Accountability

Can you determine who did what, and when? For Microsoft environments that means the unified audit log actually enabled, sign-in and directory audit logs retained for a useful period, and ideally exported somewhere that survives beyond the default retention window.

The self-assessment problem

Whether you self-assess or engage a third-party assessor, you have to produce a score and be able to defend it. Two things make that hard by hand:

• Volume. Verifying more than a hundred requirements manually, across a directory, a cloud tenant and a collaboration suite, is a multi-week exercise that goes stale the moment someone changes a policy.
• Repeatability. A score is only meaningful if you can reproduce it the same way next quarter. Manual assessment is not reproducible — two people checking the same environment reach different conclusions.

An automated, read-only configuration audit addresses both. It runs the same checks the same way every time, dates the result, and shows you the delta since the last run.

What an audit does and does not cover

To be direct about scope: a configuration audit gives you technical evidence for the identity, access and logging requirements. It does not address the many 800-171 requirements that are procedural — media protection, physical security, personnel screening, incident response planning, security awareness training. Those need policy and process work regardless of tooling.

What it does give you is a defensible technical baseline: every finding mapped to a recognised control reference, ranked by severity, with the remediation spelled out — and a report you can hand to an assessor rather than a set of portal screenshots.

Where to start

1. Run a read-only audit across Entra ID and Microsoft 365 to establish where you actually stand.
2. Fix the fundamentals first: MFA coverage including the paths that bypass it, privileged role count, delegation on the domain, audit log retention.
3. Map the findings to your requirement families with whoever owns your assessment.
4. Re-run on a schedule so the score is current when the assessment window arrives, not reconstructed afterwards.

Where the timeline stands in 2026

The 48 CFR DFARS acquisition rule took effect on 10 November 2025, beginning Phase 1: CMMC clauses (DFARS 252.204-7021) started appearing in new DoD contracts, initially on self-assessment for Levels 1 and 2, with results posted to SPRS. Phase 2 — mandatory third-party (C3PAO) Level 2 certification for contracts handling CUI — was scheduled for 10 November 2026, but the Department paused the transition in July 2026 pending a task-force review, and as of mid-September 2026 no replacement Phase 2 date had been published. The direction of travel is unchanged even if the pacing is: readiness work started now is not wasted.

The SPRS affirmation is a legal instrument

Because a CMMC status is a condition of award, the annual affirmation you post to SPRS is a statement to the government. A knowingly inaccurate one carries False Claims Act exposure — the reason the DOJ's Civil Cyber-Fraud Initiative exists. That raises the bar on the assessment behind it: the affirmation should rest on evidence of the 110 NIST SP 800-171 requirements actually being met, not on a hopeful self-scoring. An automated audit that shows the current state of each requirement, with its identifier and remediation, is what makes the affirmation defensible.