CMMC 2.0 makes identity evidence the real test for defense contractors

At a glance

What this is: This is a technical guide on CMMC 2.0 that argues identity verification, access control, and auditability are the practical proof points defense contractors must demonstrate, especially across legacy and privileged access paths.

Why it matters: It matters because IAM, PAM, and NHI teams supporting defense contractors now have to prove controls operate in practice, not just exist on paper, across user access, remote paths, and machine-driven workflows.

By the numbers:

• Only 4% of contractors were actually prepared for formal assessment while 75% believed they were compliant.
• For Level 2 compliance, all 110 requirements across these 14 domains must be implemented, documented in a System Security Plan (SSP), and verifiable by an assessor.
• Level 1 applies to organizations that handle Federal Contract Information (FCI), and approximately 63% of DIB contractors fall into this category.

👉 Read Secret Double Octopus' CMMC 2.0 identity and compliance guide

Context

CMMC 2.0 is a proof problem as much as a compliance problem. For defense contractors, the standard now asks whether every identity path to Federal Contract Information and Controlled Unclassified Information is controlled, logged, and demonstrable under assessment, which changes the role of identity from a policy topic to an audit boundary.

That shift matters because the weak point is rarely the well-managed cloud stack already covered by SSO. The operational risk sits in legacy systems, shared accounts, remote access, and privileged workflows where authentication, access scope, and logging are inconsistent enough to fail an assessor even when the policy says otherwise.

Key questions

Q: What fails in CMMC assessments when identity controls are only documented and not enforced?

A: When identity controls exist only on paper, assessors cannot verify that access was actually limited, authenticated, and logged. In CMMC environments, that usually shows up as weak evidence for MFA, shared accounts, inconsistent remote access control, or missing audit trails. The result is a compliance gap that is operational, not cosmetic.

Q: Why do shared accounts create more CMMC risk than many teams expect?

A: Shared accounts remove accountability, which means you cannot prove who accessed CUI, who changed a system, or who triggered a risky event. That makes incident scoping, audit evidence, and control verification far harder. In CMMC terms, shared access undermines both assessment confidence and defensive containment.

Q: How do security teams know whether MFA is strong enough for CMMC 2.0?

A: MFA is strong enough when it is enforced for the required access paths, documented in the SSP, and technically resistant to replay where the control calls for it. For CMMC, the real test is not whether MFA exists somewhere in the environment. It is whether the authenticated path to sensitive systems can be proven.

Q: Who is accountable when a contractor cannot prove identity controls during a CMMC assessment?

A: The organisation pursuing the contract is accountable, because CMMC is about verified compliance at the contractor level, not delegated assurance. The accountable teams are usually IAM, PAM, security operations, and compliance working together. If the evidence chain is incomplete, the bid eligibility risk sits with the contractor, not the assessor.

Technical breakdown

Why identity evidence matters more than policy in CMMC 2.0

CMMC 2.0 is built on verifiable control operation, not policy intent. In practice, that means assessors want evidence that access is uniquely assigned, authentication is enforced, and logs can prove who touched what, when, and from where. Identity becomes the connective tissue between access control, authentication, and auditability. If an organisation cannot prove those three things across every in-scope system, the control may exist in theory but not in assessment reality. This is especially true where legacy technology, shop-floor endpoints, and remote access paths bypass modern IAM patterns.

Practical implication: map every in-scope identity path to an evidence source before assessment prep begins.

Why shared accounts and remote access are assessment liabilities

Shared credentials break accountability because they collapse multiple operators into one identity, which means neither attribution nor containment can be demonstrated. Remote access introduces another layer of proof burden: the contractor must show that sessions are controlled, monitored, and routed through managed access points. In CMMC terms, this is not just about whether MFA is enabled. It is about whether the access path itself is technically constrained enough to withstand audit scrutiny. That includes VPN, RDP, SSH, and any privileged workflow that reaches CUI or supporting systems.

Practical implication: remove shared access from any path that could touch CUI or critical administrative functions.

How auditability turns identity events into compliance evidence

Audit and accountability controls make the rest of the programme testable. Login events, configuration changes, account creation and deletion, and access to sensitive data must be logged with enough detail to reconstruct activity during an incident or assessment. Equally important, those logs must be protected from tampering. Without protected audit trails, an attacker can erase evidence and a contractor cannot show control effectiveness. This is why identity and logging cannot be managed as separate workstreams in CMMC environments.

Practical implication: validate that identity events are centralised, retained, and tamper-resistant before an assessor asks for proof.

NHI Mgmt Group analysis

Identity evidence, not just identity policy, is the new compliance boundary. CMMC 2.0 rewards what can be demonstrated under assessment, which means user-level proof of authentication, access control, and auditability matters more than written intent. In defence contracting, the control is not real unless it is visible, attributable, and repeatable across every system that touches FCI or CUI. Practitioners should treat evidence generation as part of the control itself.

Legacy access paths are where CMMC programmes most often break down. SSO-covered cloud applications usually look better on paper than the operational reality of shop-floor workstations, VPN, RDP, SSH, and shared privileged workflows. That is where identity assurance becomes inconsistent, and where assessment findings are most likely to cluster. The lesson is that programme scope must follow the actual access path, not the preferred architecture diagram. Practitioners should prioritise the paths that cannot be explained cleanly to an assessor.

Auditability is the control that turns access decisions into defensible evidence. The article’s emphasis on logging reflects a broader governance reality: if login, privilege, and configuration events are not captured and protected, access controls cannot be verified after the fact. This aligns directly with NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev. 5 expectations for access and audit controls. Practitioners should treat log integrity as a compliance prerequisite, not an operational nice-to-have.

The identity triad of authentication, access control, and audit accountability is where assessment outcomes are decided. CMMC does not treat these as separate hygiene items; together they define whether a contractor can prove a controlled environment. The practical consequence is that IAM, PAM, and logging teams need one shared evidence model. Practitioners should align control ownership across those teams before an assessor forces the issue.

Verified compliance is accelerating a wider shift from declarative IAM to evidentiary IAM. Defence is often the leading indicator for other regulated environments, because the standard forces organisations to prove control behaviour rather than claim coverage. That pushes identity programmes toward stronger telemetry, tighter lifecycle discipline, and fewer exceptions in remote and privileged access. Practitioners should expect this evidence-first model to spread beyond defence supply chains.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 52 NHI Breaches Analysis shows how weak lifecycle discipline turns access into breach persistence.

What this signals

Identity evidence will become a stronger procurement filter across regulated supply chains. As programmes like CMMC normalise proof-based assurance, contractors will need to show not only that access exists, but that it is bounded, attributable, and reviewable. That has direct consequences for any team managing a mix of human, machine, and privileged access, because the weakest identity path now determines the credibility of the whole control set.

The next maturity jump is not another policy layer. It is tighter linkage between identity events, audit records, and contract scope, so that access to sensitive data can be explained quickly and consistently under assessment.

Credential and access lifecycle discipline will increasingly decide whether identity controls are auditable at all. In environments that mix remote users, privileged admins, and non-human identities, stale access and unclear ownership create evidence gaps that no spreadsheet can close. Teams should expect greater pressure to prove who owns each credential, when it was last reviewed, and whether it still maps to the work being done.

For practitioners

• Inventory every identity path to CUI and FCI. Trace cloud, legacy, remote, and shop-floor access paths end to end, then classify each one by whether it can be authenticated, controlled, and logged with assessor-ready evidence.
• Eliminate shared accounts on sensitive access paths. Replace shared logins with uniquely attributable identities for VPN, RDP, SSH, and administrative workflows so that access can be traced to a single accountable user.
• Prove MFA enforcement, not just deployment. Capture technical evidence that MFA is required for privileged and remote access, then verify that legacy systems and cloud services use a replay-resistant method where CMMC requires it.
• Centralise and protect identity audit logs. Send authentication, account, and privilege events to a log platform that preserves integrity, supports review, and can reconstruct a session for assessment or incident response.
• Build the SSP from control evidence upward. Document how each in-scope identity control operates in practice, then map it to the evidence an assessor would request so the SSP reflects reality rather than aspiration.

Key takeaways

• CMMC 2.0 turns identity into an evidence problem, not just a policy problem, because contractors must prove access, authentication, and logging operate in practice.
• The biggest assessment failures are likely to come from shared accounts, remote access paths, and legacy systems where identity controls are inconsistent or hard to verify.
• Teams that cannot connect SSP documentation to real identity evidence will struggle to demonstrate compliance, regardless of how strong the written policy looks.

Key terms

• CMMC 2.0: The Cybersecurity Maturity Model Certification version that requires defence contractors to prove cybersecurity controls rather than merely claim them. It aligns contractor practices to NIST-based requirements and uses assessment evidence to determine whether access, authentication, and logging are actually operating in scope.
• System Security Plan: A System Security Plan is the documentation record that explains how security controls are implemented, managed, and evidenced in an environment. For CMMC, it must describe what exists, where it applies, and how the organisation can prove the control is real during assessment.
• Audit and Accountability: Audit and Accountability is the discipline of capturing and protecting event records so activity can be reconstructed later. In CMMC programmes, it turns identity actions such as logins, account changes, and access to sensitive data into proof that the control environment is operating as intended.
• Shared Account: A shared account is a single login used by multiple people, which destroys user-level attribution and weakens incident scoping. In regulated environments, it creates a governance failure because the organisation can no longer reliably show who performed a sensitive action or accessed protected information.

What's in the full article

Secret Double Octopus' full blog post covers the operational detail this post intentionally leaves for the source:

• How its identity approach maps to CMMC identity, access, and audit expectations across legacy and remote paths
• Specific implementation detail for privileged access, login enforcement, and evidence capture in assessment-ready environments
• The source article's full breakdown of CMMC levels, control domains, and how contractors should scope in-scope systems
• Practical discussion of where MFA, shared accounts, and audit logs become assessment blockers in real deployments

👉 The full Secret Double Octopus post expands on identity controls, audit evidence, and CMMC readiness details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.