CMMCComplianceDefenseData Security

CMMC Level 2 Compliance Through Data-Centric Security

June 4, 2026

The Cybersecurity Maturity Model Certification is the Department of Defense's answer to a supply chain that has been quietly hemorrhaging controlled unclassified information for a decade. Every defense contractor that handles CUI needs to certify at Level 2 or above by the phased deadline in 32 CFR Part 170. The difficulty is not that the requirements are ambiguous, they are explicit, but that most contractors have infrastructure built around perimeter controls, and Level 2 keeps asking questions that perimeter controls cannot answer.

What CMMC Level 2 Actually Requires

CMMC Level 2 codifies the 110 security practices in NIST SP 800-171 Rev. 3 and adds the process-maturity expectations that distinguish CMMC from the original DFARS 252.204-7012 self-attestation. The practices distribute across 14 families: Access Control (AC), Audit and Accountability (AU), Awareness and Training (AT), Configuration Management (CM), Identification and Authentication (IA), Incident Response (IR), Maintenance (MA), Media Protection (MP), Personnel Security (PS), Physical Protection (PE), Risk Assessment (RA), Security Assessment (CA), System and Communications Protection (SC), and System and Information Integrity (SI).

The phased implementation in 32 CFR Part 170 sets fixed timelines. Phase 1 begins on the rule's effective date with self-assessment for Level 1 and select Level 2 contracts. Phase 2 (one year later) requires C3PAO third-party assessment for most Level 2 contracts. Phase 3 (two years) extends third-party assessment to all CUI-handling contracts. Phase 4 (three years) reaches full implementation. Defense contractors that handle CUI and miss the relevant phase deadline lose contract eligibility.

The families where traditional perimeter architectures struggle hardest are AC, AU, IA, MP, and SC. These five families together account for 67 of the 110 practices, and they all require the security boundary to follow the data rather than the network.

The Practices Data-Centric Security Addresses Directly

Six families map cleanly to capabilities a data-centric architecture provides as a single primitive.

Access Control (22 practices) requires that CUI access be limited to authorized users, processes, and devices. Wrapping each CUI object with attribute-based access control (ABAC) at the policy enforcement point (PEP) satisfies AC.L2-3.1.1 through AC.L2-3.1.22, because every access decision is policy-evaluated at the data layer regardless of network position.

Audit and Accountability (9 practices) requires that audit records be created, retained, and analyzed. Merkle-tree lineage produces tamper-evident audit records bound to each object. The lineage record satisfies AU.L2-3.3.1 through AU.L2-3.3.9, because the audit record is a property of the data, not a property of a separate logging pipeline that an attacker could disable.

Identification and Authentication (11 practices) requires that users and devices be uniquely identified and authenticated before access. The PEP consumes the existing identity provider's authentication assertion as one input to the ABAC decision. IA.L2-3.5.1 through IA.L2-3.5.11 are satisfied through the integration, not through a parallel authentication system.

Media Protection (9 practices) requires that CUI on digital and physical media be protected, sanitized, and tracked. CUI wrapped in policy-bound encryption is protected at rest on any media; the wrapping key controls access independent of the medium. MP.L2-3.8.1 through MP.L2-3.8.9 are satisfied because the protection follows the object onto removable media, backup tapes, and external drives.

System and Communications Protection (16 practices) requires that information transmitted or received be protected and that security functions be separated from non-security functions. Post-quantum key encapsulation through ML-KEM-768 protects data in transit; the policy decision point (PDP) provides the architectural separation between identity (the IdP), policy (the PDP), and enforcement (the PEP). SC.L2-3.13.1 through SC.L2-3.13.16 fall within this separation.

Configuration Management (9 practices) covers establishing and maintaining baseline configurations and inventories. The policy-as-code approach produces version-controlled, reviewable, testable policies. CM.L2-3.4.1 through CM.L2-3.4.9 reduce to standard software engineering practice with the policy treated as the configuration artifact.

Across these six families, 76 of the 110 practices map to capabilities a single data-centric architecture provides.

The Practices Data-Centric Security Does Not Solve

Physical Protection (6 practices) covers facility access controls, monitoring, and visitor management. Architecture is irrelevant. The contractor still has to lock doors, log visitors, and protect printed CUI.

Personnel Security (2 practices) covers screening before access and reassignment or termination procedures. The HR process and the background check program satisfy these; the architecture has nothing to add.

Awareness and Training (3 practices) covers role-based training and insider-threat awareness. The contractor's training program is the control; the architecture provides the audit record showing who completed what but does not deliver the training itself.

Maintenance (6 practices) covers equipment maintenance procedures, including off-site maintenance and remote diagnostics. Some practices reduce when the data is policy-bound, because the maintainer cannot read CUI without policy attributes, but the practices governing the maintenance procedure itself are operational.

Incident Response (3 practices), Risk Assessment (3 practices), Security Assessment (4 practices), and System and Information Integrity (7 practices) overlap with the architecture but require additional operational programs that the architecture supports without replacing.

Be honest about the boundary. Data-centric security is not a CMMC Level 2 silver bullet. It is the architectural backbone that satisfies the majority of the technical practices and produces the evidence the assessor will ask for, while leaving the operational and personnel practices to the programs that already own them.

Evidence Collection for Auditors

CMMC assessments under the C3PAO framework rely heavily on artifacts: documented policies, configuration baselines, audit logs, training records, and assessment evidence. The artifacts that take the most effort to produce in a traditional architecture are the ones the data-centric architecture produces by default.

A cryptographically logged access trail for every CUI object is evidence the C3PAO cannot dispute. ABAC policies committed to version control are evidence of access control discipline. The Merkle-tree lineage record is evidence of audit and accountability. The ML-KEM key wrapping configuration is evidence of cryptographic protection. The PEP's request log demonstrates that authentication and authorization are evaluated at every access.

The evidence pack composes from artifacts the architecture already produces, not from artifacts a contractor has to assemble specifically for the audit. The cost of being audit-ready drops because the architecture's normal operation is the audit's evidence.

Where Lattix Fits in a CMMC Roadmap

A typical contractor's Level 2 readiness path with Lattix Technologies as the backbone follows three phases.

Phase 1 covers inventory and classification. Identify every system, share, and data flow that touches CUI. Wrap the highest-volume CUI repositories with policy-bound encryption first. Stand up the PDP integrated with the existing identity provider. Track which 76 practices clear at this phase against the C3PAO assessment criteria.

Phase 2 covers policy expansion. Extend ABAC policy coverage to mid-volume CUI flows, automated pipelines, and partner access paths. Document the policies in the System Security Plan (SSP) per 32 CFR Part 170. Conduct a self-assessment against the full 110 practices.

Phase 3 covers audit readiness. Engage a C3PAO for the third-party assessment. Pull the artifact pack from the architecture's normal logs. Address findings on the operational practices (PE, PS, AT, MA) that the architecture does not solve.

The architecture work compresses into Phase 1 and Phase 2. The phase deadlines in 32 CFR Part 170 are the gate. Contractors that begin the data-centric architecture now have time. Contractors that begin in Phase 4 do not.