How do teams know whether a subcontractor needs Level 1 or Level 2 CMMC?

Why This Matters for Security Teams

Subcontractor CMMC scoping is not a paperwork exercise. If the team misreads the information flow, it can place a supplier in the wrong assessment path, create contractual noncompliance, or expose Controlled Unclassified Information through an under-scoped relationship. The practical test is whether the subcontractor will handle Federal Contract Information or CUI, not whether the prime contractor already holds a higher certification. That distinction matters because CMMC obligations are tied to safeguarding requirements, evidence, and flowdown terms.

Security teams often overlook how quickly “limited” collaboration becomes real data access through shared drives, ticketing systems, build pipelines, or support channels. NHI Mgmt Group research shows that 92% of organisations expose NHIs to third parties, which is a useful reminder that supplier access often extends far beyond named users. For governance teams, this is the point where CMMC scoping intersects with identity and secrets management, because subcontractor access is usually mediated by service accounts, API keys, or other NHIs rather than only human logins. The control baseline should be anchored in the Ultimate Guide to NHIs and the underlying access expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, many security teams discover the wrong CMMC level only after the subcontractor has already been issued credentials or accepted deliverables containing controlled data.

How It Works in Practice

Determining whether a subcontractor needs Level 1 or Level 2 starts with data classification, then moves to contract language, then to access design. If the subcontractor only processes FCI, Level 1 is generally the starting point. If the subcontractor will store, process, or transmit CUI, Level 2 is usually required, and the team must confirm whether the relationship also triggers a certified assessment path, a supplier-specific flowdown clause, or both. The operational mistake is treating “no direct government contact” as a shortcut to lower requirements. CMMC follows the data, not the org chart.

Teams should document the decision in writing and map it to actual systems. That includes file shares, SaaS collaboration tools, support tickets, source repositories, and any automation used to exchange data. The same discipline applies to access credentials: if the subcontractor uses service accounts or tokens, those identities need the same scoping clarity as human users. NHIMG’s Ultimate Guide to NHIs is relevant here because supplier access commonly persists through machine identities long after the business contact changes. For control design, NIST’s baseline expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls help translate the classification decision into access restriction, auditability, and credential lifecycle requirements.

• Confirm whether the subcontractor will receive FCI, CUI, or both.
• Read the prime contract and subcontract clauses together, not separately.
• Write down the handling decision and who approved it.
• Limit access to the minimum systems needed for the work.
• Review whether automation, API keys, or service accounts expand the scope.

These controls tend to break down when CUI is embedded in mixed datasets, shared repositories, or outsourced engineering environments because the boundary between “incidental” and “in scope” access becomes operationally blurred.

Common Variations and Edge Cases

Tighter subcontractor scoping often increases administrative overhead, requiring organisations to balance faster onboarding against clearer data boundaries. That tradeoff is especially visible when a subcontractor performs both commercial and defence work, because one team may only see sanitized data while another has access to controlled files or production systems. Current guidance suggests the safer assumption is that a subcontractor needs the higher level whenever CUI handling cannot be excluded in writing, but there is no universal standard for every mixed-use arrangement.

Edge cases also appear when the subcontractor uses hosted development tools, managed support platforms, or shared integration accounts. In those environments, the question is not only “what data is visible?” but also “what identities can retrieve it?” That is where NHI governance becomes part of CMMC scoping, especially if credentials are reused across projects or not removed at contract end. The risk is not theoretical: NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why supplier termination should be treated as a security control, not an HR task.

For teams seeking a control reference, Ultimate Guide to NHIs supports the identity lifecycle angle, while NIST SP 800-53 Rev 5 Security and Privacy Controls supports access control and audit expectations. In practice, the hardest cases are subcontractors embedded in shared engineering pipelines where the data category changes faster than the contract language does.

Related resources from NHI Mgmt Group

• How do security teams know whether AI audit logging is sufficient for CMMC?
• How do security teams know whether mTLS needs a redesign?
• How can security teams know whether org-level policies really cover new cloud services?
• How do teams know whether a CMMC change is significant?