The Top 7 Reasons Defense Contractors Fail CMMC Assessments in 2026

The CMMC final rule has been in force for nearly eight months. Hundreds of defense contractors have now completed Level 2 third-party assessments, and the data is finally honest enough to be useful. The "we'll figure it out during the assessment" era is over.

After three decades in cybersecurity — most of it spent staring at gap assessments that looked great on paper and fell apart at the assessor's table — I can tell you that CMMC failures rarely come from exotic technical deficiencies. They come from the same seven categories, in roughly the same order, in nearly every failed assessment I've reviewed.

This article walks through those seven failure patterns, why they keep catching even well-resourced contractors, and what you can do in the next 30 to 90 days to close them.

Why Failure Patterns Look Almost Identical Across Contractors

Before getting into the list, it's worth understanding why these patterns repeat. A CMMC Level 2 assessment evaluates 110 NIST 800-171 Rev 2 controls (transitioning to Rev 3 over the coming cycle). On paper, every control matters equally. In practice, a small handful of controls fail far more often than the rest, for three reasons:

1. Some controls require continuous evidence, not just policy. A policy document satisfies almost nothing on its own — assessors need to see implementation across time, often spanning the prior 12 months.
2. Some controls cross organizational boundaries. Identity, logging, and configuration management all touch IT, security, HR, and procurement. Hand-off failures kill audits.
3. Some controls are easy to overestimate. Many contractors mark themselves as compliant because they have a tool deployed, without realizing the tool is not configured to the control's actual requirement.

Every one of the seven failures below sits in at least one of those traps.

Failure #1: Multi-Factor Authentication Gaps (3.5.3)

This is, by a comfortable margin, the most common reason contractors fail. NIST 800-171 control 3.5.3 requires MFA for all privileged accounts and for all network access by non-privileged accounts.

Where contractors go wrong:

• Service accounts and break-glass accounts are exempted from MFA without documented compensating controls.
• Legacy systems (older ERP modules, file servers, certain CAD environments) authenticate users without MFA, often because someone added an exception years ago and never revisited it.
• Cloud admin accounts are protected, but on-premises domain admin accounts still log in with just a password.
• MFA factors don't meet NIST SP 800-63B requirements — SMS-based MFA, in particular, is increasingly being flagged as insufficient for privileged access in CUI environments.

The fix is not subtle. Inventory every account with access to CUI or with elevated privileges. For each, document the MFA factor in use, the system enforcing it, and the date of last verification. If you cannot produce that list in under an hour, you are not ready.

Failure #2: Audit Log Gaps and Missing Review Evidence (3.3.x Family)

The 3.3 control family — audit and accountability — punishes contractors more often than any technical family except access control. The controls themselves seem straightforward: generate audit records, protect them, review them, retain them. The problem is the review and retention pieces.

Common failures:

• Logs are generated but never reviewed. Assessors will ask for evidence of review activity — a ticket, a signed log review form, a SIEM dashboard with annotated alerts. "We have a SIEM" is not evidence of review.
• Retention falls short of the 90-day minimum for security-relevant events, and almost no one can produce a 12-month archive on demand.
• Privileged user activity is not logged separately from regular user activity.
• Time synchronization (3.3.7) is missed entirely — logs from different systems don't share an authoritative time source, making forensic reconstruction impossible.

If your last documented log review is older than 30 days, fix that today. Add a recurring calendar item, assign an owner, and capture the review in writing — even a one-paragraph summary in a ticket counts. Assessors are not looking for elegance. They are looking for proof that the activity happened.

Failure #3: Configuration Management Drift (3.4.x Family)

Configuration management failures are the quiet killer. A contractor passes the policy review, passes the interview, and then loses points in technical testing because the documented baseline does not match what is actually running.

Typical drift patterns:

• Approved software lists are out of date. The list says approved software is X, Y, and Z, but workstation scans show A, B, and C also installed.
• No formal change control for security-relevant changes. Firewall rules get modified, GPOs get updated, and there is no ticket, approval, or rollback path documented.
• System inventories are incomplete. A laptop that connects to the CUI environment once a quarter is missing from the asset register entirely.
• Baseline configurations exist for endpoints but not for servers, network devices, or cloud workloads.

The fastest remediation here is a 30-day reconciliation sprint: pull a fresh inventory from your endpoint management platform, compare it against your asset register, and document every delta. If your environment is small enough, this is a weekend project. If it is large enough that this feels overwhelming, that itself is the finding.

Failure #4: Incomplete or Stale System Security Plan (SSP)

The System Security Plan is the single most important document in a CMMC assessment. It defines the boundary, the controls, the responsible parties, and the implementation details for every control. Assessors begin with the SSP and use it to plan every interview and every technical test.

The SSP failures I see most often:

• The SSP describes a system that no longer exists. It references retired servers, decommissioned applications, or an old cloud tenant.
• Control implementation statements are generic. "We use multi-factor authentication" is not an implementation statement. "All privileged accounts in tenant X use Microsoft Authenticator with number matching; all non-privileged network access uses Duo Push" is.
• Shared responsibility with cloud providers is not articulated. If you use Azure Government, AWS GovCloud, or Microsoft 365 GCC High, your SSP must clearly state which controls the provider satisfies, which you satisfy, and which are shared — with citations to the provider's compliance documentation.
• The boundary is fuzzy. A good SSP draws a hard line around the systems that store, process, or transmit CUI. A bad SSP describes "the company" and lets the assessor guess.

If you have not updated your SSP in the last 90 days, it is probably stale. Schedule a quarterly review with a named owner. Treat the SSP as a living document, not a deliverable.

Failure #5: Plan of Action and Milestones (POA&M) Misuse

Under the CMMC final rule, contractors can pass a Level 2 assessment with open POA&M items — but only for specified non-critical controls, only if the overall score is at least 88 out of 110, and only if every item is closed within 180 days. That last constraint is where contractors get into trouble.

POA&M failures fall into a few patterns:

• POA&M items linger past 180 days without closure. Some contractors discover during their assessment that an item they opened a year ago is still "in progress," which automatically disqualifies them.
• Critical controls show up on the POA&M. Certain controls — including the MFA, audit, and incident response controls discussed elsewhere in this article — cannot be on a POA&M at assessment time. If they are, the assessment fails outright.
• No supporting evidence for closure. A POA&M item marked complete needs a paper trail: configuration screenshots, ticket history, scan results, training rosters.
• The POA&M is a wish list, not a remediation plan. Every item needs a target date, an owner, a resource estimate, and a verification method. "Q3 2026 — IT will handle" is not a milestone.

If you do not have a monthly POA&M review meeting on the calendar with named owners and concrete deliverables, build one this week. For a deeper walkthrough on running these effectively, see our POA&M Management for CMMC guide.

Failure #6: FIPS-Validated Cryptography Not Actually Validated (3.13.11)

This one trips up sophisticated contractors more than any other on the list, because the failure is invisible until an assessor asks for the validation certificate.

Control 3.13.11 requires FIPS-validated cryptography to protect the confidentiality of CUI. The word that matters is "validated" — not "compliant," not "compatible," not "approved." Validated means the cryptographic module has a current FIPS 140-2 or 140-3 certificate from NIST's Cryptographic Module Validation Program (CMVP), and the contractor is using the module in its validated configuration.

Where contractors lose points:

• Using a product whose certificate has expired or moved to "historical" status. Many widely deployed VPN appliances and storage encryption products carry certificates that have lapsed.
• Using FIPS-validated software in a non-FIPS mode. Windows, for example, has a FIPS mode that must be explicitly enabled. Running Windows without FIPS mode means you are not using validated cryptography even if the underlying module is certified.
• Cloud-native encryption services without verified configuration. Azure Storage, AWS S3, and Google Cloud Storage all offer FIPS-validated encryption, but only when configured to use the appropriate endpoints. The default configuration is often not the validated configuration.
• TLS endpoints negotiating non-FIPS cipher suites. A web server that supports TLS 1.2 with FIPS-validated ciphers is fine — until it falls back to a non-validated cipher for a specific client.

Pull every cryptographic module in scope. Document the CMVP certificate number, the certificate status, and the configuration in use. If you cannot trace each module back to an active certificate at NIST, you have a finding.

Failure #7: Incident Response Plans That Have Never Been Tested

Control 3.6.3 requires incident response capability testing. Most contractors interpret this as "we have a written plan." That is half of the requirement. The other half — and the half that fails — is evidence of testing.

What assessors expect to see:

• An annual tabletop exercise, at minimum, with a written scenario, named participants, dated minutes, and lessons learned captured in writing.
• Plan updates that reflect the lessons learned. A tabletop that produces three findings and zero plan updates suggests the test was performative.
• Coordination with the DoD reporting pathway. Contractors handling CUI must report incidents to DC3 (DoD Cyber Crime Center) within 72 hours under DFARS 252.204-7012. If your plan does not name DC3 explicitly and describe how reports flow, you have a gap.
• Detection-to-response timing data, if available. Mean time to detect, mean time to respond, mean time to contain — even rough numbers — show maturity.

A two-hour tabletop with the IT lead, the CISO, the legal contact, and the executive sponsor closes most of this gap. For a complete walkthrough of what to include, see our Incident Response Plan for Defense Contractors guide.

What These Seven Failures Have in Common

Step back and look at the pattern. Every one of these failures is a documentation, process, or evidence problem — not a technology problem. Contractors who fail CMMC assessments almost always have the right tools deployed. What they lack is the ongoing operational discipline to produce evidence on demand.

That distinction matters for how you spend the next 90 days. If you treat CMMC as a tooling problem, you will buy software you do not need and still fail. If you treat it as an evidence-and-process problem, you will pass with the tooling you already have.

The three habits that separate contractors who pass from contractors who fail:

1. A controls calendar. Every recurring control activity — log reviews, vulnerability scans, training completions, POA&M reviews, configuration audits — has a named owner and a recurring date on a shared calendar.
2. An evidence repository. Every control activity produces a dated artifact, stored in a single location, indexed by control number. Assessors should be able to walk through your evidence library and find what they need in minutes, not days.
3. A quarterly internal review. Someone outside the day-to-day operations team pulls a random sample of controls each quarter and verifies that the documented activity actually happened. This is the single highest-leverage discipline a contractor can adopt.

How to Use This List in the Next 30 Days

If you are 12 months out from your assessment, you have time to address all seven failures methodically. If you are 6 months out, you need to prioritize. Here is the order I would tackle them:

Each of these gets a named owner, a target date, and a defined deliverable. Treat the list as a sprint plan, not a wish list.

Where Policy Foundations Fit

Most of the seven failures above are remediated through process changes, but each of them also requires written policies and procedures that reflect the new behavior. Policies that have not been updated since 2023 are almost certainly out of step with the post-final-rule reality.

The TalonPoint PolicyPack provides a complete, CMMC-aligned policy framework that covers all 110 NIST 800-171 controls, including dedicated policies for MFA enforcement, audit logging, configuration management, FIPS cryptography, POA&M management, and incident response testing. It is designed for defense contractors who need an audit-ready policy foundation without paying $40,000 for a consulting engagement to produce one. If your policies are stale, the PolicyPack is the fastest path to a defensible baseline.

The Bottom Line

CMMC assessment failures are not random and they are not unfair. The same seven failure patterns repeat across nearly every failed assessment. The contractors who pass are not smarter, better-funded, or technically more sophisticated than the ones who fail. They are simply more disciplined about producing evidence on a recurring schedule.

You almost certainly have most of the tooling you need. What you need to add — over the next 30, 60, or 90 days — is the discipline of evidence. Build the calendar. Name the owners. Stand up the repository. Run the quarterly review.

Do that, and the assessor's visit becomes a formality. Skip it, and you will be one of the contractors generating the data for next year's version of this article.

---

TalonPoint Security helps defense contractors prepare for CMMC Level 2 assessments through ready-to-deploy policy frameworks, audit-readiness tools, and gap remediation guidance. Explore the PolicyPack to see how we accelerate compliance for small and mid-sized contractors.