Why do CMMC assessors care so much about identity configuration evidence?

Why assessors want configuration evidence, not just a claimed capability

CMMC assessors are not trying to infer intent from the platform’s feature set. They want evidence that the identity control was configured, enabled, and used in a way that leaves an auditable trail. For access governance questions, that makes the difference between “the environment could do it” and “the control actually operated during the assessment period.”

That is why assessor review often starts with the identity lifecycle: how accounts were issued, whether access was approved, whether MFA was applied consistently, and whether dormant or stale access was handled according to policy. Those are operating facts, not vendor assurances, and they are what demonstrate control execution.

In practice, configuration evidence is also how an assessor tests scope. If an organisation says MFA is required, the supporting artifacts should show where that rule is enforced, which populations it covers, and what happens for exceptions. If an account is disabled or removed, the record should show the action and timing, not just the current end state.

What good evidence looks like in an identity review

A credible evidence set is usually a small chain of artifacts that line up with one another. Policy says what should happen, configuration shows how the system is set up, and operational records show that the setup was used. When those three disagree, the assessor follows the contradiction, because that is where control failure usually hides.

Useful examples include account provisioning records, MFA enforcement settings, access review outputs, exception logs, deprovisioning records, and screenshots or exports that show the relevant control state. The important part is not the file format, it is the traceability from requirement to configuration to operating outcome.

For that reason, mature identity evidence often reads better than a static screenshot because it shows time, ownership, and change. A control that can only be demonstrated by a live admin login is much harder to defend than one that can be backed by a report, a workflow record, or a configuration export tied to the assessment window.

How assessors separate platform capability from operating effectiveness

The distinction matters because many platforms can support strong identity controls without the organisation actually using them. A system may have MFA available, conditional access features, lifecycle workflows, or deprovisioning options, yet still fail assessment if those features are not deployed consistently or if exceptions are unmanaged.

Assessors therefore look for proof of enforcement, coverage, and exception handling. If a control is only present for certain users, environments, or workflows, the evidence should make that boundary explicit. If stale accounts are allowed for administrative convenience, the assessor will expect the exception path, compensating control, and approval trail to be visible.

That same logic explains why inherited platform capability does not equal compliance. Capability is potential; compliance is documented operation over time. In identity-heavy assessments, the evidence trail is what converts a security claim into something testable.

Risk and Threat Considerations

Weak identity evidence creates a specific risk: controls may exist on paper while dormant accounts, inconsistent MFA enforcement, or undocumented exceptions continue to expand the attack surface. When assessors cannot verify the operating state, they have to assume the control could fail under pressure or be bypassed in practice.

Failure mechanism: The organisation treats platform features as proof, but the real control state is not observable, so gaps in provisioning, MFA enforcement, deprovisioning, or exception management remain hidden.

Impact: Attackers and auditors both benefit from that blind spot, because stale access and uneven enforcement are exactly the conditions that turn identity configuration into unauthorized access risk.

Practitioner Guidance

What to verify: Build the evidence set around the control question, not around the tool. If the control is MFA, show where it is enforced, who is covered, and how exceptions are approved and reviewed. If the control is lifecycle, show joiner, mover, leaver records and the timestamps that prove stale access was removed.

Common mistake: Teams often present screenshots from the admin console and assume that proves operation. It usually does not, unless the screenshot is tied to change records, exports, or workflow evidence that demonstrates the control existed during the period under review and was actually applied.

What good looks like: An assessor can trace each identity control from requirement to configuration to operational evidence without guesswork. The record set is consistent, time-bound, and specific enough that a reviewer can see not only that the control exists, but that it is being run as intended.

Practitioner takeaway: In CMMC reviews, identity evidence is persuasive when it proves control operation over time, not when it merely proves the platform has the feature.

Related resources from NHI Mgmt Group

• Why do assessors care so much about evidence in CMMC Level 2 reviews?
• Why do insurers care so much about control evidence instead of policy questionnaires?
• Why do boards care so much about identity misuse and credential abuse?
• Why do audit teams care so much about repeatable evidence and training dates during an observation period?