CMMC and DoD Zero Trust Architecture: where the gap analysis actually breaks
Geert WarmenbolApril 29, 2026
Key takeaways
CMMC Level 2 and DoD Zero Trust Architecture v2.0 do not map cleanly. CMMC asks whether controls exist. ZTA asks whether those controls enforce least privilege continuously. Passing one does not satisfy the other.
SC.L2-3.13.11 (FIPS-validated cryptography) is one of the most commonly misimplemented controls. Contractors who use FIPS-validated products but leave SMB signing disabled or permit TLS 1.0 fallback are failing the control despite passing the product checkbox.
Network segmentation failures are the most common reason CUI environments fail technical validation during C3PAO assessments. A flat network with a hardened perimeter still allows lateral movement across every CUI system after a single endpoint compromise.
MFA bypass through push notification fatigue is now a documented attack path against defense contractor environments. MFA implementation without conditional access policies based on device posture and location does not satisfy ZTA User pillar requirements.
C3PAO assessors look for evidence artifacts, not policy documents. Screenshots, configuration exports, log samples, and scan results are what survives a CMMC assessment. A signed SSP that describes correct controls does not substitute for evidence that they are running.
Continuous monitoring is not a SIEM subscription. It is automated alerting tied to specific CMMC control deviations. Contractors who collect logs without thresholds and response workflows are not doing continuous monitoring under CMMC requirements.
TL;DR
Defense contractors with mature security tooling keep failing CMMC assessments because tool deployment and control implementation are not the same thing. Zero Trust Architecture introduces seven pillars that overlap imperfectly with CMMC's 14 control families, and the gaps live in that overlap. This covers where the misalignment causes real assessment failures, what C3PAOs are actually looking for, and which technical misconfigurations survive inside environments that look compliant from the outside.
The contractor who had all the right tools and failed anyway
A logistics company supporting DoD contracts came to us after a C3PAO pre-assessment review returned 23 findings. They had Palo Alto firewalls, Azure Sentinel for SIEM, CrowdStrike Falcon on every endpoint. Their security budget was significant. The CISO's framing going in: 'We are already zero trust. We just need to document it properly.' The documentation was not the problem. What the pre-assessment found was a flat internal network where CUI systems shared broadcast domains with general corporate workstations. SMB signing was not enforced. TLS 1.0 was still permitted on two legacy applications that touched CUI. The EDR was deployed but the incident response procedure it was supposed to trigger was a six-page document that had never been tabletop tested. Every tool was real. The implementation gaps were also real.
The framing 'we are zero trust' meant they had acquired zero trust products. ZTA is not a product state. It is an architectural condition where no implicit trust is granted based on network location or asset ownership. Their network architecture granted exactly that kind of implicit trust to anything inside the perimeter.
Why CMMC and ZTA do not map to each other cleanly
CMMC Level 2 is built on NIST SP 800-171, which defines 110 security requirements across 14 control families. The assessment methodology from NIST 800-171A then specifies examination, interview, and testing objectives for each requirement. DoD Zero Trust Architecture v2.0 organizes security capability across seven pillars: Users, Devices, Networks, Applications and Workloads, Data, Visibility and Analytics, and Automation and Orchestration. These two frameworks do not share a common taxonomy. A CMMC control like AC.L2-3.1.3, which addresses CUI flow control, maps loosely to the Networks pillar, the Data pillar, and the Applications pillar simultaneously. No single ZTA pillar implementation satisfies it completely, and implementing controls pillar-by-pillar without referencing the CMMC control mapping produces gaps by default. The organizations that implement ZTA tooling without running that tooling against NIST 800-171 control objectives end up with architectures that satisfy ZTA marketing language but fail CMMC evidence requirements.
Example
The Data pillar failure is the most structurally consistent. Organizations implement SC.L2-3.13.11 by deploying a FIPS-validated encryption product, check the box, and move on. What the control actually requires is that FIPS-validated cryptography is used wherever CUI is transmitted or stored, configured correctly, and not undermined by fallback paths. A system that supports AES-256 over HTTPS but also permits unencrypted SMB traffic on the same network segment is not satisfying SC.L2-3.13.11 regardless of what the product configuration says.
NIST 800-171A testing objectives for SC.L2-3.13.11 include examining system configurations, testing network traffic to verify encryption is applied, and interviewing personnel to confirm they understand where FIPS-validated cryptography is and is not in use. A C3PAO using the full 800-171A methodology will not accept a product deployment checklist as evidence. They will look for network capture samples and configuration exports.
What the assessments show across defense contractor environments
Assessment base: Patterns observed across CMMC-focused gap assessments conducted by Vulnox, covering defense contractors in logistics, aerospace, manufacturing, and professional services.
Flat networks inside ZTA-branded architectures
The most consistently recurring technical finding is internal network architecture that does not segment CUI environments from general corporate infrastructure. Contractors have next-generation firewalls at the perimeter and micro-segmentation on paper in the SSP. The actual VLAN configuration shows CUI servers on the same broadcast domain as HR workstations and guest Wi-Fi access points. When we ask how lateral movement is restricted after an endpoint compromise, the answer is typically 'CrowdStrike would catch it.' EDR catches behavioral anomalies after execution. It does not prevent lateral movement in a flat network before execution completes.
AC.L2-3.1.3 and SC.L2-3.13.6 both require controlling CUI flow. A flat network cannot satisfy these controls regardless of what the perimeter looks like. C3PAO assessors who run internal network scans during technical validation will find the flat architecture. This is not a documentation gap that can be resolved by updating the SSP.
FIPS cryptography deployed but not enforced at the protocol level
Across assessments where contractors claimed SC.L2-3.13.11 compliance, a recurring finding is TLS configuration that permits protocol downgrade. The server supports TLS 1.3 and is running a FIPS-validated implementation. The same server also accepts TLS 1.0 connections from legacy application integrations that were never updated. The FIPS-validated product is installed. The actual encryption applied to some CUI traffic is TLS 1.0 with export-grade cipher suites, which is exploitable via downgrade attack. The contractor's configuration review never tested this path because the testing script only confirmed that TLS 1.3 was available.
SC.L2-3.13.11 compliance requires that FIPS-validated cryptography is applied consistently, not that a FIPS-validated product is present. Any fallback path to non-FIPS cryptography represents a control failure. Nmap ssl-enum-ciphers against all CUI-adjacent services will surface this in minutes. Most contractors have not run it.
Incident response plans that describe the right process but have never run it
The IR procedure documentation in CMMC assessments is generally adequate. Organizations have written playbooks that reference IR.L2-3.6.1 and IR.L2-3.6.2, describe escalation paths, assign roles, and specify reporting timelines. What those documents do not reflect is that the playbook has never been executed. No tabletop exercise. No simulated incident. No validation that the tools involved actually integrate with each other in the way the playbook assumes. In two assessments, the playbook referenced a SIEM integration that had been deprecated when the SIEM was upgraded. The playbook was updated; the integration was not.
C3PAO assessors conducting interviews with technical personnel can identify this gap quickly. If the staff responsible for executing the IR plan cannot describe what they would do in the first 30 minutes of a detected incident without reading from the document, the control does not pass interview-based validation under NIST 800-171A methodology.
MFA deployed without conditional access creates a false sense of control
Every assessment involving Microsoft or Okta environments shows MFA enabled for all users. The MFA deployment is real and counts toward IA.L2-3.5.3. What the ZTA User pillar requires, and what the CMMC Identification and Authentication family implies when read against ZTA requirements, is that access decisions incorporate more than a second factor. Push notification MFA without device compliance checks or location-based conditional access policies allows an attacker who has compromised a user's registered device to authenticate to CUI systems from any network. We have documented this attack path in contractor environments where the security posture was described as mature.
The CMMC control is satisfied by MFA deployment. The ZTA security objective is not. Organizations that are pursuing CMMC certification while also representing their architecture as zero trust need to close this gap explicitly, because a C3PAO assessment will pass the MFA control while a DoD technical review focused on ZTA posture will flag the conditional access gap.
Better tooling correlates with worse documentation gaps, not better ones
Common belief
Organizations with mature security tooling produce better CMMC evidence packages because they have more data to work with. The assumption is that a Splunk deployment plus a Qualys scanner plus CrowdStrike gives you everything a C3PAO needs.
What we found
Contractors who engaged with us after investing heavily in security tooling required more remediation work on evidence package development than contractors who had simpler environments but had been building toward CMMC deliberately. The tools were not the blocker. The gap between what the tools were doing and what the documentation said they were doing was.
What we consistently find is the opposite. Organizations with advanced tooling have invested their attention in tool configuration and operational use. The compliance documentation layer, the SSP sections that map each tool to a specific CMMC control, the evidence artifacts that demonstrate the tool is operating as the SSP describes, has been neglected because the tools feel like the answer. Organizations with simpler security environments who have been working toward CMMC for two years sometimes produce better evidence packages because they have had to manually document everything rather than assuming the tool output would speak for itself. A Splunk dashboard showing security events is not CMMC evidence. A Splunk dashboard with an annotation showing it captures specific log sources required by AU.L2-3.3.1 and AU.L2-3.3.2, tied back to the SSP, with alert configurations documented, is CMMC evidence.
The ZTA pillars where CMMC assessments consistently find undocumented gaps
Visibility and Analytics pillar
This pillar requires that security monitoring provides continuous visibility into CUI data flows, user behavior, and system state. CMMC's AU control family covers audit logging. The gap is between audit log collection and actionable visibility. Organizations configure logging on CUI systems, send logs to a SIEM, and consider the AU controls satisfied. The SIEM has no alerts configured for the specific conditions CMMC assessors look for: unauthorized access attempts to CUI, failed authentication spikes, bulk data transfers from CUI repositories. The logs exist. The monitoring does not.
Automation and Orchestration pillar
This is the ZTA pillar most organizations have not started. CMMC does not have a direct control family mapping to automation and orchestration, which creates the illusion that it does not matter for compliance. What it actually means is that organizations rely on manual processes for compliance validation: manual patch verification, manual access review, manual configuration audits. Each manual process is a place where compliance drift accumulates between audit cycles. By the time the next C3PAO assessment arrives, the gap between the SSP and the actual environment has grown substantially.
Applications and Workloads pillar
Contractors who have moved CUI workloads to cloud environments assume the cloud provider's FedRAMP authorization covers their application layer. FedRAMP authorizes the infrastructure. The application running on that infrastructure is the contractor's responsibility. API authentication configurations, session management settings, and input validation controls in custom or vendor-supplied applications handling CUI are not covered by FedRAMP authorization. They are covered by CMMC control families that the contractor must validate independently.
Where CMMC and ZTA enforcement are heading
By 2027, DoD program offices will begin requiring evidence of ZTA pillar implementation as a separate deliverable from CMMC certification, creating a two-track compliance burden for contractors on high-value acquisition programs.
The DoD Zero Trust Strategy published in 2022 set a target for department-wide ZTA implementation by 2027. Program offices responsible for sensitive acquisition programs are already incorporating ZTA requirements into contract language that goes beyond CMMC control language. The divergence between CMMC certification and ZTA compliance posture is well understood internally at DoD. A formal evidence requirement is the predictable next step.
Confidence: mediumIf no new DoD contract solicitations published in 2026 or 2027 include a ZTA pillar evidence requirement separate from CMMC certification, the timeline is wrong.A publicly attributed breach of a CMMC-certified defense contractor will occur within 24 months, with the entry point traced to a ZTA gap that CMMC controls did not cover, specifically in the Applications and Workloads or Devices pillar.
CMMC Level 2 certification validates control implementation against a static snapshot. The ZTA gaps described above, particularly in application layer security and device compliance verification, are structural and widely present. Adversaries targeting the defense industrial base are not constrained by what CMMC assesses. The combination of a certified contractor with exploitable ZTA gaps and sophisticated nation-state adversaries who are specifically targeting defense contractor CUI makes this outcome structurally predictable.
Confidence: highIf no publicly attributed breach of a CMMC Level 2 certified contractor with a confirmed ZTA-related entry point appears in open source reporting by the end of 2027, the prediction was wrong.
CMMC certification is solving the wrong problem
CMMC Level 2 certification tells you that a contractor had the right controls documented and evidenced on the day a C3PAO assessed them. It does not tell you that those controls are operating correctly today, next month, or after the next system change. The three-year certification cycle is incompatible with the rate at which contractor environments actually change. New cloud integrations, personnel turnover, software updates that alter security configurations, subcontractor additions: all of these can introduce gaps that were not present at certification and will not be caught until the next assessment. The security community is split on whether continuous monitoring requirements adequately address this, and that is a real debate worth having. My position is that they do not, because the continuous monitoring requirements in CMMC are defined at a level of generality that allows organizations to satisfy them with log collection alone. The organizations that are actually maintaining compliance between certifications are doing something beyond the minimum requirement.
Counterargument
The counterargument is that CMMC represents a substantial improvement over self-attestation and that raising the floor for the entire defense industrial base is worth the imperfection of a three-year cycle. That argument is correct about the direction of travel. It does not address the gap between certification state and current security state, which is where real incidents will originate.
One technical action this week
Run Nmap ssl-enum-ciphers against every internet-facing and CUI-adjacent service in your environment. The command is straightforward: nmap -sV --script ssl-enum-ciphers -p 443,445,3389 against your CUI system IP ranges. Any result showing a cipher suite rated as weak, any system accepting TLS 1.0 or 1.1, any SMB service without signing required: those are SC.L2-3.13.11 failures that will surface in a C3PAO technical assessment. You will find something. Most environments do. The value of finding it this week instead of during the assessment is that you control the timeline for remediation.
Further Reading
Gap Analysis
DoD zero trust gap analysisDigital Footprint
digital footprint analysisCMMC 2.0 levels explained: which tier applies to your DoD contract and what it actually requires
CMMC and DoD Zero Trust Architecture gap analysis and where contractors consistently fall shortNational Vulnerability Database NIST
NIST National Vulnerability DatabaseNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkCompliance Gap Analysis Guide
compliance gap analysis guide
Frequently Asked Questions
How does CMMC Level 2 map to DoD Zero Trust Architecture?
CMMC Level 2 and DoD ZTA v2.0 do not share a common taxonomy. CMMC's 110 controls across 14 families overlap imperfectly with ZTA's seven pillars. A single CMMC control like AC.L2-3.1.3 maps to the Networks, Data, and Applications pillars simultaneously. Implementing ZTA pillar by pillar without cross-referencing NIST 800-171 control objectives produces gaps by default. Contractors need a control-to-pillar mapping exercise before claiming ZTA satisfies CMMC requirements.
What does SC.L2-3.13.11 actually require beyond deploying a FIPS-validated product?
SC.L2-3.13.11 requires FIPS-validated cryptography wherever CUI is transmitted or stored, configured correctly, with no fallback paths to non-FIPS cryptography. Deploying a FIPS-validated product that also permits TLS 1.0 connections or unencrypted SMB traffic fails the control. C3PAO assessors using 800-171A testing objectives will examine network traffic and configuration exports, not just product deployment records.
What evidence artifacts do C3PAO assessors actually require for CMMC Level 2?
C3PAO assessors conducting 800-171A-structured assessments look for examination artifacts (configuration exports, system screenshots, log samples, scan results), interview validation (technical staff who can describe control operation without reading from documents), and testing results (active validation that controls are functioning). A signed SSP describing correct controls does not substitute for evidence they are running. Documentation gaps in organizations with advanced tooling are common because staff assume tool output speaks for itself.
Why is MFA alone insufficient for CMMC ZTA User pillar compliance?
MFA satisfies IA.L2-3.5.3 for CMMC certification. The ZTA User pillar requires that access decisions incorporate device compliance posture and contextual signals beyond a second authentication factor. Push notification MFA without conditional access policies based on device health and location allows an attacker with a compromised registered device to authenticate to CUI systems from any network. CMMC passes MFA as a control. ZTA compliance requires the additional layer.
How often does a CMMC Level 2 assessment need to happen?
CMMC Level 2 requires a C3PAO third-party assessment every three years. DCMA retains the authority to conduct compliance reviews at any time regardless of certification status. The three-year cycle does not account for the rate at which contractor environments change through software updates, cloud integrations, personnel turnover, and new subcontractor relationships. Organizations maintaining compliance between certifications are doing continuous monitoring that exceeds the minimum CMMC requirement.
What network segmentation is required to pass CMMC Level 2 technical validation?
AC.L2-3.1.3 and SC.L2-3.13.6 require that CUI data flows are controlled and that CUI systems are isolated from general corporate networks. In practice, C3PAO assessors running internal network scans will identify flat architectures where CUI systems share broadcast domains with non-CUI workstations. VLAN segmentation of CUI environments is the minimum implementation. Micro-segmentation described in the SSP but not reflected in actual VLAN configuration does not pass technical validation.
What is the difference between log collection and continuous monitoring under CMMC?
CMMC continuous monitoring requires automated tracking of CUI data flows, detection of unauthorized access attempts, and alerting on control deviations. Log collection satisfies the data gathering requirement of AU control families but not the monitoring requirement if no alerts, dashboards, or response workflows are tied to specific CMMC control conditions. A SIEM deployment without configured alerts for the events CMMC assessors look for is log storage, not continuous monitoring.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.