CBOM for Government and Defense: Cryptographic Inventory for CNSA 2.0 Compliance

The Government Cryptographic Imperative

Government and defense organizations operate under the most demanding cryptographic requirements in the world. The convergence of mandatory CNSA 2.0 timelines, classified data protection obligations, adversary sophistication, and regulatory complexity creates an environment where cryptographic inventory is not a best practice — it is a national security requirement.

The challenge is immense:

• Mandatory compliance deadlines: CNSA 2.0 establishes non-negotiable timelines for quantum-safe migration
• Classified information: Data classified for 25-75 years faces certain HNDL exposure
• Supply chain depth: Defense industrial base (DIB) extends cryptographic dependencies across thousands of contractors
• Air-gapped networks: Critical systems may not have internet connectivity for automated discovery tools
• Legacy infrastructure: Systems built to previous cryptographic standards (Suite A, Suite B, CNSA 1.0) must be transitioned
• Adversary capability: Nation-state adversaries specifically target government communications for HNDL collection

A CBOM provides the foundational visibility required to execute quantum-safe migration across this complexity within mandated timelines.

CNSA 2.0: The Mandatory Timeline

CNSA 2.0 Requirements Summary

The NSA’s Commercial National Security Algorithm Suite 2.0 establishes mandatory post-quantum cryptography requirements for National Security Systems (NSS):

Use Case	Algorithm Required	Parameter Set	Mandatory Date
Software/firmware signing	ML-DSA	ML-DSA-87 (Level 5)	2025 (prefer PQC)
Key establishment (symmetric key transport)	ML-KEM	ML-KEM-1024 (Level 5)	2030 (prefer PQC)
Web/cloud authentication	ML-DSA	ML-DSA-87	2030 (prefer PQC)
Networking (VPN, router) key establishment	ML-KEM	ML-KEM-1024	2030 (prefer PQC)
Networking authentication	ML-DSA	ML-DSA-87	2033 (exclusively PQC)
Key establishment (all contexts)	ML-KEM	ML-KEM-1024	2033 (exclusively PQC)
OS/infrastructure signing	ML-DSA	ML-DSA-87	2035 (exclusively PQC)
All digital signatures	ML-DSA or SLH-DSA	Level 5	2035 (exclusively PQC)
Legacy equipment (no update possible)	N/A	Replacement required	2033

Critical CNSA 2.0 Observations

• Level 5 is mandatory — ML-KEM-1024 and ML-DSA-87, not the lower parameter sets
• “Prefer” vs. “Exclusively” — “prefer PQC” means hybrid is acceptable; “exclusively PQC” means classical must be removed
• 2025 is NOW — software and firmware signing should already prefer PQC
• Equipment that cannot be updated must be replaced by 2033 — no exceptions for legacy hardware
• SLH-DSA is accepted as an alternative to ML-DSA for software/firmware signing

What “National Security Systems” Means

CNSA 2.0 applies to systems processing classified or mission-critical information:

• Intelligence community systems (all classification levels)
• Department of Defense operational systems
• Nuclear command and control
• Critical infrastructure control systems (when designated NSS)
• Defense contractor systems processing classified information (CUI with specific markings may also be in scope)

However, agencies increasingly apply CNSA 2.0 principles to all federal systems as best practice, not just those formally designated NSS.

FedRAMP Cryptographic Requirements

Current FedRAMP Crypto Controls

FedRAMP (Federal Risk and Authorization Management Program) mandates specific cryptographic controls for cloud services serving federal agencies:

Control	Requirement	CBOM Relevance
SC-8	Transmission confidentiality and integrity	Inventory encryption for data in transit
SC-12	Cryptographic key establishment and management	Document all key management mechanisms
SC-13	Cryptographic protection (FIPS 140 validated)	Verify all crypto modules are FIPS validated
SC-17	Public key infrastructure certificates	Inventory all certificates and their algorithms
SC-28	Protection of information at rest	Inventory encryption for data at rest
IA-7	Cryptographic module authentication	Verify authentication mechanisms
CM-6	Configuration settings (including crypto configs)	Track all cryptographic configurations

FedRAMP and PQC

FedRAMP has not yet issued formal PQC requirements, but the trajectory is clear:

• NIST SP 800-131A Rev 2 will incorporate PQC algorithm recommendations
• FedRAMP High baselines will likely adopt CNSA 2.0 aligned requirements
• Cloud service providers seeking FedRAMP authorization should demonstrate PQC readiness
• Agencies are beginning to ask about PQC in FedRAMP authorization packages

Organizations preparing FedRAMP packages today should include CBOM-generated cryptographic inventory as evidence of proactive cryptographic management.

CMMC 2.0 and Cryptographic Intersection

CMMC Crypto-Relevant Practices

The Cybersecurity Maturity Model Certification (CMMC) 2.0 intersects with cryptographic requirements at multiple levels:

CMMC Level	Practice	Crypto Connection
Level 1	AC.L1-3.1.1 Limit system access	Authentication mechanisms use cryptography
Level 2	SC.L2-3.13.8 Encrypt CUI in transit	Specific encryption requirements for CUI
Level 2	SC.L2-3.13.11 FIPS-validated cryptography	Must use FIPS 140 validated modules
Level 2	SC.L2-3.13.16 Protect CUI at rest	Encryption at rest for CUI
Level 3	SC.L3-3.13.4e Crypto implementation	Enhanced cryptographic protections

CMMC + CNSA 2.0: The Convergence

Defense contractors handling CUI often also process classified information or support NSS-adjacent systems. The convergence means:

1. CMMC mandates FIPS-validated encryption for CUI
2. CNSA 2.0 mandates PQC for classified/NSS data
3. Contractors must maintain two parallel cryptographic regimes during transition
4. CBOM is essential for tracking which systems operate under which regime

DIB Supply Chain Implications

The Defense Industrial Base extends cryptographic requirements down the supply chain:

• Prime contractors must verify subcontractor cryptographic compliance
• CUI flowing between contractors must be encrypted per CMMC requirements
• Subcontractors handling classified data must meet CNSA 2.0 timelines
• CBOM provides supply chain cryptographic visibility — verifying that data exchange with partners uses appropriate algorithms

Air-Gapped CBOM Deployment

The Challenge of Classified Networks

Many government and defense systems operate on air-gapped networks (no internet connectivity). This creates specific challenges for CBOM deployment:

• Cannot use cloud-based discovery tools
• Software updates require physical media and security review
• Network scanning tools must be approved for the classification level
• Data cannot be exfiltrated (even CBOM results) without proper review

QCecuring CBOM Air-Gapped Architecture

QCecuring CBOM supports air-gapped deployment with:

On-Premises Deployment

• Fully self-contained deployment requiring no external connectivity
• All analysis engines, databases, and reporting run locally
• Updates delivered via approved physical media or cross-domain solutions

Classification-Level Appropriate Discovery

• Discovery agents approved for deployment on classified networks
• Passive network monitoring that does not generate traffic
• Static analysis tools that examine configurations without runtime access
• Results stored on the local classified network — never transmitted externally

Air-Gapped Discovery Methods

Method 1: Configuration Scanning (Passive)
  → Read crypto configurations from system files
  → Parse TLS/SSL configurations from web servers, databases
  → Extract algorithm settings from application configs
  → No network traffic generated

Method 2: Binary Analysis (Offline)
  → Static analysis of compiled binaries for crypto library usage
  → Identify linked crypto libraries and their versions
  → Detect hard-coded algorithms and key sizes
  → Works on any binary without execution

Method 3: Certificate Inventory (Passive)
  → Enumerate certificates from local stores
  → Parse certificate chains for algorithm information
  → Check validity, key sizes, and signature algorithms
  → No CA/OCSP connectivity required

Method 4: Network Capture Analysis (Passive)
  → Analyze previously captured (approved) network traffic
  → Extract negotiated TLS cipher suites from pcap files
  → Identify key exchange algorithms from handshake messages
  → Post-hoc analysis, no active scanning

Cross-Domain Considerations

When CBOM results need to move between classification levels:

• CBOM reports contain algorithm/protocol information only — no classified content
• Review processes verify reports do not contain sensitive system details
• Aggregated risk scores can inform unclassified planning without revealing classified architecture
• Cross-domain solution (CDS) policies must be established for regular CBOM data flow

NSA Quantum Readiness Guidance

NSA’s Stated Position

The NSA has been remarkably explicit about quantum readiness requirements:

• Quantum threat is real and imminent enough to mandate migration now
• HNDL is explicitly cited as justification for immediate action on key exchange
• No organization should wait for CRQCs to exist before migrating
• Crypto-agility is a national security imperative
• Algorithm selection is finalized — ML-KEM-1024 and ML-DSA-87 for NSS

NSA Guidance for Different Audiences

Audience	Key NSA Message	Action Required
NSS operators	CNSA 2.0 timelines are mandatory	Begin migration immediately
Government agencies (non-NSS)	Adopt PQC as quickly as possible	Plan migration, deploy hybrid
Defense contractors	Protect CUI with quantum-safe crypto	Assess HNDL exposure, upgrade
Critical infrastructure	Quantum threat affects you	Inventory crypto, plan migration
Commercial sector	Standards are ready, migrate now	Assess readiness, begin deployment

Connecting NSA Guidance to CBOM

NSA guidance repeatedly emphasizes the need to know what cryptography you have before you can migrate it. Specific statements from NSA cybersecurity advisories:

• “Organizations must identify all instances of quantum-vulnerable cryptography”
• “A complete inventory of cryptographic mechanisms is the essential first step”
• “Migration planning requires understanding the scope of quantum-vulnerable algorithms”

These statements directly describe the function of a CBOM. QCecuring CBOM operationalizes NSA’s guidance by providing the automated discovery and inventory capability that enables migration planning.

Federal Acquisition and PQC

Contract Requirements for PQC

Government procurement is beginning to incorporate PQC requirements:

Current FAR/DFARS Crypto Requirements

• DFARS 252.204-7012: Adequate security for CUI (includes encryption)
• FIPS 140-2/3 validation required for cryptographic modules
• Continuous monitoring of cryptographic configurations

Emerging PQC Procurement Language

• New contracts increasingly require PQC readiness assessment
• “Quantum-safe” or “post-quantum capable” appearing in technical requirements
• CNSA 2.0 alignment required for NSS-supporting contracts
• Crypto-agility clauses requiring algorithm update capability

What Contractors Must Prepare

Defense contractors and government IT service providers should:

1. Inventory their own cryptographic implementations using CBOM
2. Document PQC migration plans aligned with CNSA 2.0 timelines
3. Ensure crypto-agility in products delivered to government customers
4. Prepare for PQC compliance audits with evidence of algorithm readiness
5. Test PQC interoperability with government systems and standards

SBOM → CBOM: The Federal Supply Chain Evolution

Executive Order 14028 mandated SBOMs for software delivered to the federal government. The natural evolution includes CBOM:

SBOM (EO 14028):
  → What software components are in this product?
  → What vulnerabilities exist in those components?

CBOM (Emerging requirement):
  → What cryptographic algorithms does this product use?
  → Are those algorithms quantum-vulnerable?
  → What is the migration path to PQC?
  → Is the product crypto-agile?

Multiple government agencies are exploring CBOM requirements for procured software. Early adoption of CycloneDX CBOM format positions organizations ahead of formal mandates.

Implementation for Government Organizations

QCecuring CBOM Government Features

QCecuring CBOM provides government-specific capabilities:

CNSA 2.0 Compliance Dashboard

• Real-time view of organizational progress against each CNSA 2.0 milestone
• Per-system tracking: which systems have migrated to ML-KEM-1024, ML-DSA-87
• Timeline projections: at current pace, will mandatory deadlines be met?
• Exception tracking: systems that cannot be migrated and require replacement

FedRAMP Evidence Generation

• SC-12, SC-13, SC-17 control evidence automatically generated
• Cryptographic module FIPS validation status tracked per instance
• Certificate algorithm inventory for all public key infrastructure
• Key management mechanism documentation

CMMC Assessment Support

• SC.L2-3.13.8 / SC.L2-3.13.11 compliance verification
• FIPS-validated module usage confirmation
• CUI encryption adequacy assessment
• Evidence package for CMMC assessors

Air-Gapped Operations

• Fully on-premises deployment architecture
• No cloud dependency or external connectivity requirement
• Approved for deployment on classified networks (per agency ATO)
• Update mechanism via approved physical media

Deployment Approach for Federal Agencies

Phase 1: Unclassified Networks (Months 1-4)

Start with unclassified systems where deployment is less complex:

1. Deploy CBOM across .gov web services and public-facing infrastructure
2. Inventory encryption on cloud services (FedRAMP authorized CSPs)
3. Assess email encryption (S/MIME, TLS) across the agency
4. Map VPN and remote access cryptographic configurations
5. Generate initial SC-13 compliance report

Phase 2: CUI Systems (Months 4-8)

Extend to Controlled Unclassified Information systems:

1. Deploy CBOM on CUI-processing systems
2. Inventory CMMC-relevant cryptographic controls
3. Map contractor data exchange encryption
4. Assess CUI encryption at rest and in transit
5. Identify FIPS 140 validation gaps

Phase 3: Classified Networks (Months 8-16)

Deploy air-gapped CBOM on classified networks:

1. Security review and ATO for CBOM deployment on classified network
2. Deploy passive discovery mechanisms (config scanning, binary analysis)
3. Inventory algorithms on classified processing systems
4. Map CNSA 2.0 compliance status per system
5. Identify systems requiring replacement (cannot be upgraded)

Phase 4: CNSA 2.0 Migration Execution (Months 12-36)

Use CBOM data to execute migration:

1. Prioritize by CNSA 2.0 timeline (software signing first, then key establishment)
2. Deploy hybrid PQC on systems supporting ML-KEM-1024
3. Plan replacement of legacy systems that cannot support PQC
4. Track migration progress against CNSA 2.0 milestones
5. Report compliance status to authorizing officials

Cross-Agency Coordination

Federal PQC Migration Coordination

Quantum-safe migration for the federal government requires coordination across:

• NIST: Standards development and validation (FIPS 203/204/205, FIPS 140-3)
• NSA: Requirements definition (CNSA 2.0, algorithm selection)
• CISA: Vulnerability management and guidance dissemination
• OMB: Policy mandates and budget allocation
• GSA: Procurement vehicle updates (FedRAMP, acquisition guidance)
• Individual agencies: Implementation and compliance

CBOM provides the common measurement framework across agencies — enabling government-wide visibility into quantum migration progress.

Shared Services and PQC

Federal shared services (cloud.gov, Login.gov, MAX.gov) must migrate to PQC to protect all tenant agencies simultaneously. CBOM assessment of shared services identifies:

• Which shared services still use quantum-vulnerable key exchange
• What the timeline for shared service PQC migration is
• How individual agencies can mitigate risk while waiting for shared service upgrades

Key Takeaways

• CNSA 2.0 timelines are mandatory, not advisory — non-compliance for NSS is not an option
• 2025 is the first deadline — software and firmware signing should already prefer ML-DSA-87
• Level 5 (ML-KEM-1024, ML-DSA-87) is required for national security systems — lower parameter sets are insufficient
• Equipment that cannot be updated must be replaced by 2033 — begin replacement planning now for legacy hardware
• Air-gapped CBOM deployment is essential for classified networks where standard discovery tools cannot operate
• CMMC + CNSA 2.0 creates dual compliance requirements for defense contractors handling both CUI and classified data
• QCecuring CBOM supports air-gapped deployment with fully on-premises architecture and no external connectivity requirement
• Federal acquisition is evolving to include PQC requirements — contractors should prepare CBOM-based evidence of quantum readiness
• FedRAMP will incorporate PQC — cloud service providers should demonstrate PQC readiness in authorization packages now
• CBOM is the common measurement framework enabling government-wide visibility into quantum-safe migration progress
• NSA explicitly states that cryptographic inventory is the essential first step — CBOM operationalizes this guidance
• Start with unclassified, extend to CUI, then classified — phased approach manages complexity while building toward full coverage