What is the difference between CMMC Level 1 and CMMC Level 2 for organizations pursuing DoD work?

Why This Matters for Security Teams

cmmc level 1 and Level 2 are not just different checklists. They reflect two very different risk profiles for DoD work. Level 1 is aimed at basic protection of Federal Contract Information, while Level 2 is designed for Controlled Unclassified Information and a much broader control set. That shift changes how organisations document evidence, assign ownership, and prove repeatability across systems, users, and non-human identities. NHI Mgmt Group’s research shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, which matters because CMMC evidence often fails when service accounts, API keys, and automation paths are overlooked.

The practical gap is rarely about whether controls exist on paper. It is about whether access is actually bounded, monitored, and revocable across the identities that do the real work. The Ultimate Guide to NHIs — What are Non-Human Identities explains why non-human identities are frequently the weakest link in governance, and NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control model many organisations use to structure that evidence. In practice, many security teams discover the Level 2 gap only after a supplier review exposes undocumented access paths and stale credentials.

How It Works in Practice

Level 1 is the starting point for contractors handling FCI. It focuses on basic safeguarding practices and is generally validated through self-assessment. Level 2 applies when CUI is in scope, and the organisation must show alignment to the 110 controls in NIST SP 800-171. That usually means more formal governance, stronger evidence collection, and in many cases third-party assessment by a C3PAO. The difference is not only control count. It is the maturity expected in how access is granted, reviewed, and removed.

For security teams, the easiest way to think about the split is by evidence depth:

• Level 1 asks whether basic cyber hygiene is in place for FCI protection.
• Level 2 asks whether the organisation can demonstrate repeatable protection of CUI across people, systems, and automation.
• Level 2 reviews often scrutinise identity lifecycle evidence, including service accounts, key rotation, privileged access, and offboarding.
• Both levels benefit from mapping technical controls to a central policy set so ownership is clear.

This is where NHIs become material. If a build pipeline, integration, or bot can reach CUI repositories, it becomes part of the compliance boundary whether or not a human directly touches it. The same logic applies to privileged scripts, CI/CD secrets, and machine-to-machine tokens. The Ultimate Guide to NHIs — What are Non-Human Identities is useful here because it frames the governance problem around lifecycle, visibility, and privilege rather than just account inventory. These controls tend to break down when organisations treat automation as outside the assessment scope because the assessor will still follow the data path back to the identity that accessed it.

Common Variations and Edge Cases

Tighter CMMC expectations often increase assessment effort, documentation burden, and remediation cost, so organisations have to balance speed against the need for defensible evidence. That tradeoff becomes most visible in mixed environments where some contracts involve only FCI while others bring CUI into the same identity plane.

A few edge cases regularly create confusion. First, not every contractor needs Level 2 for every program. The requirement depends on contract flowdown and the presence of CUI, not on company size. Second, a Level 1 environment can still have weak identity hygiene if service accounts, secrets, or vendor integrations are left unmanaged. Third, Level 2 does not mean every control is judged by the same proof standard. Current guidance suggests assessors will look for operational consistency, not just policy language, and that is especially true for accounts that never log in interactively.

In practice, many teams find that CMMC readiness work overlaps with broader NHI governance: inventorying machine identities, rotating secrets, enforcing least privilege, and removing orphaned access. That overlap is useful, but it should not be overstated as a universal standard for every environment. The exact control implementation will vary by architecture, contracting scope, and whether the organisation runs its own tooling or depends heavily on suppliers.

Related resources from NHI Mgmt Group

• What is the difference between Postgres RLS and application-level authorization for access control?
• What is the difference between PostgreSQL roles and row-level security in multi-tenant access control?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?