Most small contractors do not fail a CMMC Level 2 assessment on exotic requirements. They fail on a short list of controls that are easy to misunderstand and easy to half-implement. Assessors reviewing more than 100 defense contractors keep finding the same gaps — and the top two, FIPS-validated cryptography and multi-factor authentication, get failed or partially failed more than any other requirement in the 110.
Here are the seven that catch small firms most often, with the control number, why it bites, and what to actually do about it. If you have no internal IT staff, read this as your remediation punch list.
1. FIPS-Validated Cryptography (3.13.11)
Why it fails: Firms confuse FIPS-validated with FIPS-capable. They check that the encryption algorithm is approved, but the requirement is that the cryptographic module itself is validated under the NIST program — and that it is actually running in FIPS mode. Plenty of companies buy FIPS-capable tools and never flip them into FIPS mode, which means they are non-compliant despite spending the money.
Fix: Inventory every place CUI is encrypted at rest and in transit. Confirm each tool uses a module with a NIST validation certificate, and verify FIPS mode is enabled, not just available. Document the certificate numbers in your SSP.
2. Multi-Factor Authentication (3.5.3)
Why it fails: MFA gets deployed selectively. The classic finding: MFA is enforced on email, but remote VPN access still allows password-only login, or domain controllers and on-premises systems are exempt. The control requires MFA everywhere CUI is processed, stored, or transmitted — every layer, including local and privileged access.
Fix: Map every authentication point that touches CUI: cloud apps, VPN, servers, admin accounts, on-prem systems. Enforce MFA on all of them. The most common gap is privileged and on-premises access, so start there.
3. Audit Logging and Review (3.3.1 and 3.3.2)
Why it fails: Logs exist, but nobody collects them centrally, retention is undefined, and no one reviews them. Small teams without a SIEM generate more log volume than they can read, so review quietly drops to the bottom of the list. An assessor wants to see that logs are aggregated, retained for a defined period, and actively reviewed — not just that logging is turned on.
Fix: Stand up centralized log collection (a SIEM or a managed service). Define a retention period and a documented review cadence, and keep evidence that reviews actually happen. For a small shop, a managed security provider is usually cheaper than building this in-house.
4. System Security Plan Maintenance (3.12.4)
Why it fails: The SSP was written once, often two years before the assessment, and never updated after a cloud migration or a new system went live. An SSP that does not match your current environment is one of the fastest ways to fail, because it tells the assessor your documentation cannot be trusted.
Fix: Treat the SSP as a living document, not a pre-assessment deliverable. Update it whenever your environment changes. Review it on a schedule and date every revision. No other piece of paperwork does more to pass or sink the assessment.
5. Risk Assessments (3.11.1)
Why it fails: Either the firm never formally ran one, or it ran an IT checklist and called it a risk assessment. The control wants documented threats, vulnerabilities, likelihood, impact, and how your controls address each — reviewed periodically.
Fix: Run a documented risk assessment that names real threats and vulnerabilities to your CUI, rates likelihood and impact, and maps controls to each risk. Schedule a periodic review so it stays current.
6. Configuration Management (3.4.1 and 3.4.2)
Why it fails: Small IT teams operate informally. There is no documented baseline configuration for systems, and changes get made without an authorization record. Assessors look for a defined baseline and evidence that changes are reviewed and approved.
Fix: Document baseline configurations for the systems in your CUI scope. Put a lightweight change-control process in place that records who approved each change and when. It does not need heavy tooling — it needs to be written down and followed.
7. Incident Response (3.6.1 and 3.6.2)
Why it fails: A plan exists on paper, but it has never been tested, staff do not know their roles, and the DoD reporting requirement is not wired in. The DFARS 252.204-7012 clause requires reporting a cyber incident to the DoD within 72 hours — a step many small contractors have never rehearsed.
Fix: Write an incident response plan that reflects your actual environment, then run a tabletop exercise so people know their roles. Integrate the 72-hour reporting path to the DoD Cyber Crime Center so it is a known procedure, not an improvisation during a real incident.
The Pattern Behind All Seven
Notice what these have in common: none are exotic. They fail because they require either a discipline small teams have not built (logging review, SSP maintenance, tabletop exercises) or a configuration detail that is easy to get 90% right and still fail (FIPS mode off, MFA missing on one access path). The firms without dedicated security staff fail most, because these controls reward operational consistency more than one-time spending.
Why This Hits Small SDVOSBs Hardest
A service-disabled veteran-owned shop bidding DoD work often runs lean — a few people, a cloud tenant, maybe an outsourced IT contractor who handles helpdesk, not security engineering. That is exactly the profile that gets surprised by these seven. The good news: every one of them is fixable without enterprise budgets if you start early. The bad news: trying to fix all seven in the 60 days before a C3PAO shows up is how firms blow past the November 10, 2026 deadline.
Work the list now, while a POA&M is still a planning tool and not a Hail Mary.