CBOM and Compliance: Mapping Cryptographic Inventory to NIST CSF 2.0 and SP 800-53

CMMC Phase 1 self-attestation became enforceable on November 10, 2025.^{[32 CFR Part 170]} Any DoD contractor that cannot document which cryptographic algorithms are running in scope systems—and demonstrate they meet SP 800-171 control requirements—faces audit exposure right now, with third-party C3PAO assessments beginning November 10, 2026. The foundational artifact that makes that documentation possible is a Cryptographic Bill of Materials (CBOM). The problem is that neither NIST CSF 2.0 nor SP 800-53 uses the term "CBOM," leaving compliance officers to construct the mapping themselves. This article does that work.

What a CBOM Is and Why Compliance Frameworks Haven't Adopted the Term Yet

A CBOM is a structured inventory of every cryptographic asset in a system: algorithms, key lengths, protocol versions, certificate chains, and the software components that implement them. It is a specialised extension of the Software Bill of Materials (SBOM) concept, focused exclusively on cryptographic dependencies. The relationship between CBOM and SBOM, including CISA's guidance on both, is documented separately on this site. The relevant point here is that CISA has referenced CBOM in its supply chain guidance, but neither NIST CSF 2.0 nor SP 800-53 Rev. 5 or Rev. 5.2.0 uses the term in a normative context.^{[NIST SP 800-53 Rev. 5][NIST CSF 2.0]}

That silence is not an exemption. It means compliance officers must perform the mapping themselves, connecting CBOM outputs to the control language that auditors and assessors will actually test against. The sections below make that mapping explicit and traceable.

The SP 800-53 Controls That Implicitly Require Cryptographic Inventory

SP 800-53 Rev. 5 contains 1,108 controls across 20 families, distributed across baselines of 125 controls (Low), 325 controls (Moderate), and 421 controls (High).^{[NIST SP 800-53 Rev. 5]} Four control families create de facto requirements for knowing what cryptography you are running and where.

SC — System and Communications Protection

SC-8 (Transmission Confidentiality and Integrity) and SC-28 (Protection of Information at Rest) require that systems protect data using cryptographic mechanisms.^{[NIST SP 800-53 Rev. 5]} An assessor testing SC-8 will ask which algorithms and protocol versions are in use. Without a CBOM, that question cannot be answered consistently across a distributed system. SC-12 (Cryptographic Key Establishment and Management) further requires documentation of key management procedures, which presupposes knowledge of what keys exist and under which algorithm families they operate.

SA — System and Services Acquisition

SP 800-53 Rev. 5.2.0, released August 27, 2025, introduced new controls and enhancements specifically targeting software supply chain integrity: SA-24 (Software Provenance), SI-02(07) (Flaw Remediation — Automated Patch Management), and SA-15(13) (Development Process, Standards, and Tools — Criticism Analysis).^{[NIST SP 800-53 Rev. 5.2.0]} SA-24 in particular requires organisations to track the provenance of software components, which directly implicates cryptographic libraries and their versions. A CBOM that records which cryptographic library implements which algorithm, at which version, in which system component, satisfies the evidentiary requirement SA-24 creates without a CBOM ever being named.

SR — Supply Chain Risk Management

SR-3 (Supply Chain Controls and Processes) and SR-11 (Component Authenticity) require that organisations manage risks arising from third-party components.^{[NIST SP 800-53 Rev. 5]} Cryptographic libraries sourced from open-source repositories or commercial vendors are third-party components. SR-3 assessment procedures under SP 800-53A will test whether the organisation has documented those dependencies. A CBOM is the natural artifact that satisfies this documentation requirement.

SI — System and Information Integrity

SI-2 (Flaw Remediation) requires that organisations identify, report, and correct information system flaws. Deprecated cryptographic algorithms—RSA-1024, SHA-1, DES—are documented flaws under NIST IR 8547's deprecation schedule.^{[NIST IR 8547 (Initial Public Draft)]} The 2030 and 2035 deprecation deadlines in IR 8547 mean that SI-2 compliance now has a cryptographic dimension that did not exist at the same scale two years ago. Without a CBOM, an organisation cannot know which instances of deprecated algorithms require remediation.

Mapping CBOM Outputs to NIST CSF 2.0 Functions and Subcategories

NIST CSF 2.0 organises its guidance across 6 functions and 102 subcategories.^{[NIST CSF 2.0]} Three functions are directly served by CBOM outputs. The mapping below uses CSF 2.0 subcategory identifiers as published; the CSF 2.0 reference tool maps these subcategories to SP 800-53 controls, confirming the linkage.^{[NIST CSF 2.0 Reference Tool]}

Note: This mapping reflects the CSF 2.0–to–SP 800-53 informative references as published in the NIST CSF 2.0 reference tool. NIST CSWP 48, which addresses PQC-specific CSF guidance, was released as an Initial Public Draft in September 2025 and does not yet provide explicit CBOM-to-subcategory mappings.^{[NIST CSWP 48 (Initial Public Draft)]} Where CSWP 48 is silent, this table draws on the base CSF 2.0 subcategory language and its informative SP 800-53 references.

CMMC 2.0 and the Cryptographic Documentation Problem Contractors Must Solve Before November 2026

CMMC Level 2 aligns to 110 practice requirements across 14 domains derived from NIST SP 800-171.^{[32 CFR Part 170]} SP 800-171 is itself derived from the SP 800-53 Moderate baseline, which means the SC, SA, SR, and SI control families discussed above are all represented in CMMC scope, translated into practice requirements. The forthcoming revision aligns CMMC Level 2 to SP 800-171 Rev. 3, which maps to 97 requirements across 17 domains.^{[NIST SP 800-171 Rev. 3]}

The practical problem for contractors is this: CMMC assessors conducting C3PAO assessments from November 10, 2026 will test practices such as SC.3.177 (Use of FIPS-validated cryptography) and will ask for evidence. That evidence must show which algorithms are implemented, in which systems, validated to which standard. A CBOM is the only structured artifact that can answer those questions at scale across a multi-system environment. Contractors currently have no standard template mandated by the CMMC Accreditation Body for this evidence, which means any well-structured CBOM that maps to assessed practices will be defensible documentation by default.

Finance and procurement teams should note: a contractor that cannot produce this documentation during a C3PAO assessment risks a finding that blocks contract award or renewal. The cost differential between proactive cryptographic documentation and reactive remediation under audit pressure is material and quantifiable.

Generating a Compliance-Grade CBOM: Required Fields, Formats, and Audit Linkage

A CBOM intended for compliance use—as distinct from a developer-focused dependency scan—must contain fields that map directly to control assessment criteria. At minimum, a compliance-grade CBOM entry should record: the algorithm identifier (e.g., RSA-2048, AES-128-CBC, TLS 1.2), the key length or parameter set, the protocol version where applicable, the implementation location (system component, service name, network segment), the cryptographic library name and version, the library's provenance (vendor, open-source repository, hash), and the current compliance status against applicable baselines (FIPS-validated, deprecated, migration-pending).

Machine-readable format matters for integration with SP 800-53 assessment procedures. CycloneDX 1.6 introduced a dedicated cryptoProperties component type that supports algorithm, keyLength, and implementationType fields.^{[CycloneDX 1.6 Specification]} OSCAL (Open Security Controls Assessment Language), maintained by NIST, provides a structured format for expressing system security plans and assessment results that can reference CBOM data as supporting artifacts within component definitions.^{[NIST OSCAL]} IBM's CBOMkit toolchain, now under the Linux Foundation, generates CycloneDX-compatible CBOM output and represents one available open-source option for organisations beginning this process.

When connecting CBOM outputs to SP 800-53A Rev. 5 assessment procedures, the relevant linkage is the examine-interview-test triad. For SC-8, an assessor examines configuration documentation and tests system behaviour. A CBOM entry that records TLS 1.2 with RC4 cipher suites in a production service is precisely the kind of documentation artefact the examine step is designed to surface. Providing it proactively, tied to a remediation timeline, is materially stronger than waiting for an assessor to discover it.

A Phased Roadmap: From CBOM Generation to CSF 2.0 Profile

The operational sequence for converting a CBOM into a compliance artifact is straightforward, though execution requires deliberate resourcing.

Phase 1 — Generate the CBOM. Use automated discovery tooling to scan in-scope systems and produce a machine-readable inventory in CycloneDX or a compatible format. Manual review is required for systems that do not yield to automated scanning (hardware security modules, legacy OT systems, embedded firmware).

Phase 2 — Map to SP 800-53 controls and CSF 2.0 subcategories. Use the mapping table in this article as a starting point. Annotate each CBOM entry with the control identifiers it serves as evidence for. This creates a traceable evidence chain from cryptographic asset to compliance control.

Phase 3 — Score against baseline. Assess each CBOM entry against the applicable SP 800-53 baseline (Low, Moderate, or High). Flag entries that represent control gaps: deprecated algorithms, unvalidated implementations, missing key management documentation. Risk-score gaps by data sensitivity and system criticality.

Phase 4 — Prioritise PQC migration. Entries that involve asymmetric algorithms (RSA, ECDH, ECDSA) and serve long-lived data or high-value authentication functions are the highest migration priority under IR 8547's 2030 deprecation schedule. Sequence migration work against that timeline, not against an arbitrary internal roadmap.

Phase 5 — Maintain the CBOM as a continuous monitoring artifact. SP 800-53 CA-7 (Continuous Monitoring) requires ongoing assessment of security controls.^{[NIST SP 800-53 Rev. 5]} A CBOM that is generated once and never updated does not satisfy CA-7. Integrate CBOM refresh into change management procedures so that new software deployments, library updates, and configuration changes trigger a CBOM update cycle.

As a concrete next action: download and review the SP 800-53 Rev. 5.2.0 control text for SA-24, SR-3, and SI-2 at csrc.nist.gov/projects/risk-management/sp800-53-controls, then cross-reference each control's assessment procedures in SP 800-53A Rev. 5 to identify precisely what evidence your next assessor will request. That gap analysis is the input your CBOM generation effort needs to prioritise correctly.

Key Takeaways

• Neither NIST CSF 2.0 nor SP 800-53 Rev. 5 or 5.2.0 uses the term "CBOM" in a normative context — compliance officers must construct the mapping themselves.
• SP 800-53 Rev. 5.2.0 (August 2025) introduced SA-24, SI-02(07), and SA-15(13), which create de facto cryptographic provenance documentation requirements without naming CBOM as the mechanism.
• Four SP 800-53 control families — SC, SA, SR, and SI — collectively require the kind of cryptographic visibility that only a structured CBOM provides at scale.
• CSF 2.0 subcategories ID.AM-02, GV.SC-06, PR.DS-01, and PR.DS-02 are directly satisfied by CBOM outputs; the CSF 2.0 reference tool confirms the linkage to SP 800-53 controls.
• CMMC Phase 2 C3PAO assessments begin November 10, 2026. Contractors without structured cryptographic documentation face findings against SC.3.177 and related practices with no standard template available to fall back on.
• NIST CSWP 48 (Initial Public Draft, September 2025) does not yet provide explicit CBOM-to-subcategory mappings; where it is silent, practitioners must rely on the base CSF 2.0 informative references.
• A compliance-grade CBOM must be maintained as a continuous monitoring artifact under CA-7, not treated as a point-in-time assessment deliverable.

Related Reading

On this site:

• Cryptographic Bill of Materials: practitioner architecture guide
• NIST IR 8547 algorithm deprecation deadlines explained for compliance officers
• PQC readiness self-assessment checklist mapped to compliance frameworks

Primary sources:

• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems
• NIST Cybersecurity Framework 2.0 — official documentation and reference tool
• NIST CSWP 48 Initial Public Draft — Migration to Post-Quantum Cryptography Standards

This article draws on primary documentation from NIST SP 800-53 Rev. 5 and Rev. 5.2.0, NIST CSF 2.0 and its reference tool, NIST CSWP 48 (Initial Public Draft, September 2025), NIST IR 8547 (Initial Public Draft), NIST SP 800-171 Rev. 3, 32 CFR Part 170 (CMMC final rule), the CycloneDX 1.6 specification, and NIST OSCAL documentation. All claims verified against official sources as of April 2026.