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

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 and Active Directory:

• 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 on-premises reality of defense contractors

Defense contractors are, as a group, more on-premises than the average tech company. Engineering workstations, file shares holding CUI, legacy applications — a great deal authenticates against on-premises Active Directory.

This creates a specific risk: cloud-focused assessment tooling reports on Entra ID and stops. Meanwhile the domain controllers governing access to the systems that actually hold CUI go unexamined. Unconstrained delegation, oversized Domain Admins membership, weak Kerberos configuration and service accounts with stale passwords are all directly relevant to Access Control and Identification requirements — and all invisible from a cloud-only view.

If you handle CUI, your on-premises directory is in scope. Audit it with the same rigour as the cloud.

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, on-premises Active Directory and Azure 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.