For most of the defense industrial base, the Cybersecurity Maturity Model Certification has lived in a comfortable middle distance for years — real enough to worry about, far enough off to defer. That distance is closing. As the certification requirement phases into Department of Defense solicitations, a contractor's ability to win or keep work that involves controlled unclassified information increasingly depends on holding the right level of certification at award. The organizations treating this as a paperwork exercise to complete the quarter before they need it are the ones that will discover, too late, that certification is a program that takes many months and cannot be sprinted.

This is a readiness guide, not a legal one. The regulatory specifics — exact phase-in dates, the precise interaction between the program rule and the acquisition clause — are moving and worth confirming against current DoD guidance before you make decisions on them. What follows is the part that doesn't move: what certification actually requires, the decisions that determine whether it costs tens of thousands of dollars or hundreds, and the mistakes that turn a six-month effort into an eighteen-month one.

What CMMC 2.0 actually requires

CMMC 2.0 organizes requirements into three levels, tied to the sensitivity of the information a contractor handles.

Level 1 applies to contractors handling only Federal Contract Information — non-public information provided by or generated for the government under a contract, but not the more sensitive controlled unclassified information. It covers a set of basic safeguarding practices drawn from existing federal acquisition requirements and is met through an annual self-assessment. For a small supplier handling no CUI, this is the whole obligation.

Level 2 is where most of the meaningful defense industrial base lives, and it is the one to plan around. It aligns to the security requirements in NIST Special Publication 800-171 — the well-known set of 110 controls for protecting CUI in non-federal systems. For the majority of contracts involving CUI, Level 2 requires a third-party assessment conducted by an accredited assessor organization, not a self-attestation. That third-party requirement is the single biggest change in posture from the prior self-reported regime, because it means the assessment is adversarial: someone whose job is to find gaps will look at your evidence.

Level 3 applies to the highest-priority programs and adds a subset of the enhanced requirements in NIST SP 800-172 on top of the Level 2 baseline, with a government-led assessment. Comparatively few contractors will need it, and those who do generally already know.

The practical takeaway is that the center of gravity for the defense industrial base is Level 2 and the 110 controls of NIST 800-171. If your contracts involve CUI, that is the bar, and a third party will hold you to it.

The timeline, honestly

Here is where things actually stand. The contract rule that carries CMMC into federal acquisition took effect in late 2025, and the requirement is rolling out in phases. The current phase leans on Level 1 and Level 2 self-assessment; the phase in which a third-party (C3PAO) assessment becomes the standard for most CUI contracts was scheduled for late 2026 but has since been paused while the program undergoes a review, leaving the exact date the third-party requirement takes hold genuinely uncertain. Confirm the current phase and dates against official guidance before making timing decisions on them.

That uncertainty is real, and it is also a trap. The phased — now partly paused — rollout governs when certification is required; it does nothing to change how long certification takes, and contractors routinely confuse the two. A pause in the requirement is not a reason to pause the work: the direction is settled even where the timing isn't, and the effort doesn't shrink for having been deferred.

A realistic Level 2 effort — from an honest gap assessment, through remediation of the findings, evidence collection, and a third-party assessment — runs the better part of a year for an organization starting from a typical position, and longer if the remediation surfaces architectural problems rather than policy gaps. Assessor capacity is finite, and as demand concentrates around the phase-in, scheduling an assessment becomes its own bottleneck. The contractor who starts when the requirement lands in a solicitation they want to bid on has already lost. The one who is ready before the requirement forces it can treat certification as a competitive advantage — a qualification competitors don't yet hold.

Scope is the decision that sets the cost

Before any control gets implemented, one decision determines whether certification is expensive or ruinous: the scope of the CUI environment. Every system, network, and person that stores, processes, or transmits CUI is in scope for the 110 controls. Every system that doesn't, isn't. The single highest-leverage move in a readiness program is to make that in-scope boundary as small as defensibly possible.

The contractors who struggle are the ones whose CUI is smeared across the whole enterprise — email, shared drives, engineering workstations, the general corporate network — because that makes the entire enterprise the assessment boundary, and 110 controls across an entire company is a very large project. The contractors who move fast build an enclave: a deliberately bounded environment, often a purpose-built cloud tenancy or a segmented set of systems, where all CUI work happens, isolated from the rest of the business. The 110 controls apply to the enclave. The corporate network, kept genuinely free of CUI, stays out of scope.

Enclave scoping is not a trick to evade requirements; it is the correct architecture. Concentrating regulated data in a controlled boundary is what data protection is supposed to look like, and it happens to shrink the assessment surface dramatically. The organizations that get this right often spend more time on the discipline of keeping CUI inside the boundary — data handling policy, user training, technical controls that prevent CUI from leaking onto out-of-scope systems — than on any individual control. That discipline is the real work.

The artifacts that carry the assessment

A CMMC assessment is an evidence exercise. The controls matter, but what the assessor evaluates is whether you can demonstrate the controls are implemented and operating. Three artifacts anchor that.

The System Security Plan describes how each of the 110 controls is met in your specific environment — not a generic template, but an accurate description of your actual systems, boundaries, and implementations. A vague or aspirational SSP is the fastest way to fail, because the assessor tests reality against it, and every gap between what the SSP claims and what the environment does is a finding.

The Plan of Action and Milestones tracks the controls not yet fully met, with owners and target dates. Under the current rules, certain controls must be fully implemented with no POA&M permitted, while others may be addressed through a time-bound plan up to a conditional threshold — the specifics of which controls allow a POA&M and for how long are exactly the kind of detail to confirm against current guidance, because they change the remediation strategy. What does not change is that a POA&M is a plan to close a gap, not a place to park one indefinitely.

The SPRS score — the self-assessed 800-171 score reported to the government's supplier risk system — is where many contractors have already made a quiet mistake. Scores were self-reported for years under a lighter regime, and plenty of them were optimistic. A third-party assessment that contradicts a previously reported high score is an uncomfortable conversation with real consequences. If your reported score was generous, the readiness program is also a chance to make the record honest before an assessor makes it honest for you.

Where readiness programs actually stall

Three failure points account for most of the delay between "we started" and "we're certified."

The first is shared responsibility confusion in the cloud. Moving the CUI enclave to a compliant cloud environment does not inherit the controls automatically. The cloud provider is responsible for some controls, the customer for others, and the boundary between them is precisely defined in the provider's shared-responsibility documentation — which contractors routinely fail to read. Assuming the platform "handles compliance" leaves a set of customer-responsibility controls unimplemented, and those gaps surface at assessment. The provider's certification covers the provider's half; your half is still yours.

The second is managed service providers who aren't in scope of their own promises. Many small contractors outsource IT to an MSP and assume the MSP's practices satisfy the requirements. If the MSP touches CUI or the systems that hold it, the MSP is inside the assessment boundary, and its practices are your findings. An MSP that cannot produce evidence of how it meets the relevant controls is a liability, not a solution. The readiness program has to bring the MSP into scope explicitly or restructure so it stays out.

The third is treating policy as implementation. Writing a password policy is not implementing multi-factor authentication. Documenting an incident-response plan is not the same as having logging that would let you execute it. Assessors test operation, not intention, and the gap between a well-written policy binder and a control that actually functions is where confident organizations get surprised. Every control needs an implementation and evidence that it runs, not a document that says it should.

What to do in the next 90 days

If certification is on the horizon and the program hasn't started, the fastest path to a defensible position is narrow and specific.

First, define the CUI boundary. Map where controlled unclassified information actually lives today — not where policy says it should live, but where it is. That map almost always reveals CUI in places it shouldn't be, and cleaning that up is both a scoping win and a genuine risk reduction.

Second, run an honest gap assessment against the 110 controls for the scoped environment. Not a self-flattering one — the point is to find the gaps before an assessor does. The output is a prioritized remediation list and a realistic SSP that describes the current state, not the desired one.

Third, triage the remediation into what must be fully implemented before assessment and what can defensibly sit on a POA&M, and sequence the work accordingly. Architectural gaps — segmentation, identity, logging — take longest and should start first; policy and documentation gaps close faster and can follow.

Fourth, book the assessment realistically, accounting for assessor availability, and work backward from that date. A readiness program without a target assessment date drifts; one anchored to a booked assessment stays honest about its timeline.

The bottom line

CMMC 2.0 is not, at its core, a novel security standard — Level 2 is NIST 800-171, a control set the defense industrial base has nominally been subject to for years. What changed is that the certification is becoming a condition of the contract and the assessment is becoming adversarial, which turns a long-ignored obligation into a gating requirement with a real assessor on the other side. The contractors who treat it as a slow-moving architecture and data-governance project — scope the CUI tightly, build the enclave, make the SSP honest, and start early enough that assessor scheduling isn't a crisis — will clear it and treat certification as a moat. The ones who treat it as a compliance sprint to run when a solicitation forces it will find that the one thing certification cannot be is rushed.

CMMC readiness begins with an honest gap assessment against those 110 controls — the fastest way to see where you actually stand before an assessor does it for you. ComplianceScan runs an automated compliance gap analysis to produce that baseline and the prioritized remediation list to work from.

---

Part of a series on enterprise cybersecurity architecture. This guide is general information, not compliance or legal advice — confirm current CMMC requirements against official DoD guidance and a qualified assessor before relying on them.