“Ensure all systems are cryptographically agile.”
Russell T. Vought
Director, U.S. Office of Management and Budget · M-26-15
CBOM in plain English
Modern systems embed cryptography across TLS, certificates, signatures, APIs, HSMs, identity, software, custody and blockchains. Most institutions still lack a reliable, machine-readable map of where it sits and what depends on it.
CBOM closes that visibility gap. EO 14412 requires CISA, coordinated with NIST, to publish minimum elements by March 19, 2027.4 Until then, treat CBOM as a cryptographic dependency map: assets linked to implementations, functions, owners and dependencies.
SBOM
What software do we have?Inventory packages, libraries, versions and software dependencies.
CBOM
What cryptography do we depend on?Inventory algorithms, keys, certificates, protocols and crypto dependencies.
Crypto agility
Can we change it safely?Replace algorithms and keys while preserving security and operations.
PQC migration
What must move?Prioritize quantum-vulnerable cryptography and execute the transition.
Inventory is not migration. A CBOM may reveal ECDSA, RSA or a TLS dependency; crypto agility asks whether it can be replaced without breaking identity, interoperability, hardware, validation or operations.
The definitions that matter — from U.S. government sources
For institutions, terminology should come from primary sources. Separate terms defined by Executive Order, OMB or NIST from requirements still being developed.
| Term | Authoritative federal meaning | Status | Why an institution should care |
|---|---|---|---|
| SBOM | Executive Order 14028 / NIST define a Software Bill of Materials as a formal record of software components and their supply-chain relationships.14 | Defined | It tells procurement and security teams what software components are present. It does not by itself map how cryptography is used. |
| Cryptographic system | OMB M-23-02 defines it as an active software or hardware implementation of cryptographic algorithms providing key establishment, encrypted connections, or digital-signature creation/validation.1 | Defined | This is the object federal agencies were required to inventory. It makes clear that inventory reaches beyond source code into hardware and operational systems. |
| CBOM | EO 14412 uses the term and requires CISA/NIST to publish minimum elements that enable automated assessment of cryptographic assets used by hardware or software.4 | Pending | Institutions should build machine-readable cryptographic evidence now, but should not claim that a final federal CBOM schema or mandatory format already exists. |
| Crypto agility | OMB M-26-15 operationalizes it; NIST defines the technical capability. M-26-15 describes cryptographic agility as an architectural principle that lets an organization switch algorithms with minimal disruption, and requires federal migration plans to include a cryptographic-agile architecture. NIST CSWP 39-upd1 defines the broader capability to replace and adapt cryptography while preserving security and ongoing operations.165 | In OMB M-26-15 | For federal agencies this is no longer merely a desirable design pattern: it is embedded in the required migration architecture. For private institutions, it is increasingly a procurement, resilience and third-party-risk requirement even when the same federal directive does not directly bind them. |
| Post-quantum cryptography (PQC) | EO 14412 defines PQC as cryptographic algorithms or methods designed to resist attack by both quantum and classical computers.4 | In EO 14412 | PQC is the destination. Crypto agility is the capability to reach that destination safely and to handle the next cryptographic transition after it. |
Legal-status distinction
EO 14412 sets federal policy; OMB M-26-15 implements it for civilian agencies. The same deadlines do not automatically bind every private institution. Private-sector relevance can arise through critical infrastructure, federal procurement, shared services, sector rules, customers and resilience requirements.416
The federal chain institutions should read in order: EO 14412 → OMB M-26-15 → NIST
Read U.S. post-quantum policy as a three-document chain: EO sets direction → OMB operationalizes it → NIST defines the technical capability.
June 22, 2026
1. Executive Order 14412
Sets policy and deadlines. Federal HVAs and high-impact systems must transition key establishment by 2030 and digital signatures by 2031; CISA/NIST must define CBOM minimum elements; Sector Risk Management Agencies must assist critical-infrastructure owners/operators; and the FAR Council is directed toward PQC procurement requirements.4
June 24, 2026
2. OMB Memorandum M-26-15
Turns policy into an operating plan. Agencies must submit a PQC Migration Plan within 120 days, run a phased migration through 2035, use automated cryptographic inventory, populate a central CBOM, coordinate third parties, and build cryptographic agility into architecture and procurement.16
June 29, 2026
3. NIST CSWP 39-upd1
Defines the engineering capability. NIST describes crypto agility as the capability to replace and adapt cryptography across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations.5
Why M-26-15 changes the framing
Crypto agility is explicitly part of the federal migration architecture.
- Phases 3–4 (2028–2031): after prioritized key-establishment and signature migration, agencies are told to ensure systems are cryptographically agile.
- Appendix A, Section 5: gives concrete architecture mechanisms — modern crypto libraries, configuration-driven algorithm selection, cipher-suite negotiation and agile KMS/HSM infrastructure.
- Appendix B: requires crypto-agile architecture in migration plans, PQC/agility provisions in vendor requirements, and crypto-agile/PQC-compatible systems.
The federal execution model is: discover → map → make replaceable → migrate.16
Four voices that frame the transition
What the people leading this shift are saying
“We encourage organizations to begin their transition to these standards immediately to ensure their data remains secure in the quantum era.”
Dustin Moody
NIST mathematician · Head of the PQC standardization project
“giving organizations deeper visibility into the cryptography they use, enabling them to assess their quantum readiness”
Michael Osborne
CTO, IBM Quantum Safe
“This is going to be a multi-year project. It's going to be 10 years easily.”
Jaime Gómez García
Global Head, Santander Quantum Threat Program · Chair, Europol Quantum Safe Financial Forum
The institutional “so what”
CBOM maps whether your institution can change cryptography without breaking a critical business function.
A critical cryptographic dependency that cannot be replaced cleanly becomes migration debt: hardware replacement, key or account migration, contract upgrades, vendor coordination, asset moves or downtime.
Where your institution should see itself
Banks & FMIs
Payments, clearing and settlement
Typical exposure: PKI, TLS, HSM/KMS, payment gateways, middleware, code signing, APIs, identity, counterparty certificates and settlement infrastructure.
So what: a migration can fail because one appliance, certificate hierarchy, vendor library or counterparty interface cannot support the replacement algorithm on time.
Custodians & wallet infrastructure
Authorization remains the control point
Typical exposure: threshold ECDSA, EdDSA or Schnorr, MPC protocols, HSMs, wallet policy engines, recovery, approvals and blockchain adapters.
So what: a blockchain becoming PQ-capable does not make custody PQ-safe if the asset can still be authorized through a classical signing path.
Stablecoin & RWA issuers
Issuer controls can remain classical
Typical exposure: mint, burn, freeze, pause, upgrade and treasury keys; transfer-agent workflows; custody; smart contracts; bridges; oracles and admin roles.
So what: the token may run on upgraded infrastructure while the issuer control plane that can create, freeze or redirect value remains dependent on classical cryptography.
Exchanges, brokers & trading venues
Many cryptographic domains meet in one workflow
Typical exposure: client authentication, API signing, custody, wallet infrastructure, TLS, FIX connectivity, withdrawal controls, key management and settlement.
So what: the migration path is determined by the least-agile dependency across the full trade-to-settlement chain, not by the strongest component in isolation.
Asset managers & tokenization platforms
Portfolio infrastructure inherits vendor crypto
Typical exposure: custodians, fund administrators, transfer agents, tokenization platforms, signing workflows, identity, data rooms and settlement counterparties.
So what: much of the cryptographic estate may sit outside your direct control, making vendor evidence, contractual upgrade paths and dependency ownership critical.
CISO, CTO, risk & procurement
“PQC-ready” is not enough evidence
Typical exposure: enterprise PKI, IAM, VPN, certificates, code signing, HSMs, SaaS, cloud services, firmware, third-party products and long-lived data.
So what: without a dependency-aware CBOM, you cannot credibly prioritize spend, challenge vendor claims, estimate migration cost or prove which critical paths remain exposed.
Where private institutions fit under EO 14412 and M-26-15
Not every bank is directly regulated by EO 14412. The relevant pathways are:
Direct federal mandate
Executive departments and agencies
EO 14412 and M-26-15 directly drive civilian federal agency inventory, planning and migration. M-26-15 excludes National Security Systems, which follow a separate national-security track.16
Critical-infrastructure pathway
Financial services and other critical sectors
EO 14412 requires Sector Risk Management Agencies to work with CISA to assist critical-infrastructure owners and operators with PQC migration plans. For the Financial Services Sector, the designated SRMA is the U.S. Department of the Treasury.417
Procurement pathway
Covered federal contractors and suppliers
EO 14412 directs the FAR Council to propose PQC/FIPS requirements for covered contractors. M-26-15 separately tells agency requirement owners to include PQC-readiness and cryptographic-agility provisions in vendor requirements.416
Sector / resilience pathway
Private financial institutions globally
Even where a U.S. federal directive does not directly bind an institution, sector bodies are converging on the same operating capability. NIST's NCCoE points financial-sector readers to FS-ISAC's crypto-agility work, and the G7 Cyber Expert Group has framed PQC migration and cryptographic agility as a coordinated financial-system transition.82021
Named institutions: this is already a financial-system problem, not a theoretical security topic
These names place the issue in the real financial system, using Federal Reserve and FS-ISAC sources.
U.S. GSIBs in the Federal Reserve supervisory program
JPMorgan ChaseBank of AmericaCitigroupGoldman SachsMorgan StanleyBNY MellonState StreetWells Fargo
The Federal Reserve identifies these eight firms as the largest and most complex U.S.-headquartered banking organizations in its GSIB supervisory program.18
Systemically important U.S. financial market utilities
DTCC / DTCDTCC / FICCDTCC / NSCCCHIPS / The Clearing HouseCLS BankCMEICE Clear CreditOCC
The Federal Reserve lists eight designated systemically important FMUs; DTC, FICC and NSCC are DTCC subsidiaries. Payment, clearing and settlement are continuity-sensitive migration surfaces.19
Institutions represented in FS-ISAC's financial-sector crypto-agility work
Wells FargoHSBCSantanderFidelity InvestmentsState StreetSwiftDeutsche BankJPMorgan ChaseMorgan StanleyU.S. BankUSAAAllyRBCScotiabankCIBCPrincipal Financial
FS-ISAC's financial-sector crypto-agility work includes contributors from major global institutions; NIST's NCCoE points readers to it as a sector resource.208
Scope note: these names show relevant institutional profiles; they do not mean EO 14412 directly imposes federal-agency deadlines on each firm. Applicability depends on the entity's federal, contractor, critical-infrastructure and regulatory role.
1 · Visibility
Where is the cryptography?Systems, keys, protocols, libraries, hardware and third parties.
2 · Criticality
What business function does it control?Payments, custody, issuance, identity, trading, settlement or recovery.
3 · Replaceability
How can it change?Configuration, software upgrade, key rotation, hardware replacement, contract upgrade or fork.
4 · Residual exposure
What remains classical?Fallback paths, legacy counterparties, recovery keys or immutable dependencies.
What a real CBOM lets an institution decide
| Institutional question | CBOM evidence required | Decision unlocked |
|---|---|---|
| Is our custody path actually PQ-ready? | Every signing primitive, MPC/HSM dependency, recovery path, wallet policy and classical fallback that can authorize value. | Know whether PQ protection is end-to-end or whether one legacy path can still bypass it. |
| Can we keep issuing or settling assets during migration? | Mint/burn/freeze/admin keys, treasury controls, settlement signatures, contracts, counterparties and upgrade mechanisms. | Sequence changes without interrupting issuance, transfer or settlement operations. |
| Which vendors become our migration bottleneck? | Product, version, crypto module, firmware/hardware dependency, algorithm support and contractual upgrade path. | Prioritize procurement, replacement, testing and vendor escalation before deadlines compress. |
| Does “the blockchain supports PQC” solve our risk? | Transaction authorization, custody, validators, smart contracts, bridges, recovery and governance mapped separately. | Distinguish a PQ feature from an end-to-end PQ-safe operating path. |
| Will migration require re-platforming? | Identity derivation, hard-coded algorithms, hardware limitations, immutable contracts, protocol rules and historical verification. | Estimate cost, coordination burden and whether migration is a key rotation, upgrade, re-issuance or architecture change. |
Why CBOM suddenly matters
CBOM matters because cryptographic transition is now an operating, procurement and policy problem—not a theoretical one. PQC is the clearest catalyst.
Quantum computers of sufficient scale are expected to threaten widely deployed public-key cryptography such as RSA and elliptic-curve systems. NIST finalized its first three primary post-quantum FIPS standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures and FIPS 205 (SLH-DSA) for digital signatures based on hash functions.6
The hard part is not choosing an algorithm. It is finding cryptography embedded across applications, devices, vendors and protocols—and understanding how each dependency is used.
How the CBOM journey developed
CBOM sits at the intersection of software supply-chain transparency, federal cryptographic inventory, PQC migration and crypto agility.
May 2021
SBOM becomes a major federal software-security concept
Executive Order 14028 accelerated federal attention on software supply-chain security and Software Bills of Materials. SBOM asks what software components are inside a product; it does not, by itself, provide a complete cryptographic inventory.
May 2022
NSM-10 establishes the post-quantum migration imperative
U.S. policy called for prioritizing the transition of vulnerable cryptographic systems toward quantum-resistant cryptography and directed work on inventories of deployed cryptographic systems.
November 18, 2022
OMB M-23-02 turns cryptographic inventory into an operational requirement
Federal agencies were directed to inventory active cryptographic systems, with prioritized inventories of quantum-vulnerable systems due by May 4, 2023 and annually thereafter under the memorandum.1
April 9, 2024
CycloneDX 1.6 introduces formal CBOM capability
CycloneDX announced CBOM support developed by IBM Research, giving the ecosystem an open machine-readable framework for representing cryptographic assets and dependencies.2
June 2024 → December 2025
CycloneDX becomes ECMA-424 and continues to evolve
Ecma International standardized CycloneDX as ECMA-424. The second edition, published in December 2025, specifies CycloneDX v1.7 and explicitly supports domain-specific modeling of cryptographic artefacts.3
April 17–18, 2025
NIST convenes a dedicated Crypto Agility Workshop
The program covered hardware, software, financial services, standards, enterprise environments and migration techniques. It also included a session on crypto-agility for blockchain protocols.7
June 22, 2026
Executive Order 14412 elevates CBOM
The order directs CISA, coordinated with NIST, to publish public guidance describing minimum CBOM elements within 270 days. Those elements must enable automated assessment of cryptographic assets used by hardware or software.4
June 24, 2026
OMB M-26-15 makes crypto agility operationalTwo days after EO 14412, OMB issued the implementing memorandum for civilian federal agencies. It requires agency migration plans within 120 days, phases migration through 2035, calls for automated cryptographic inventory feeding a central CBOM, and explicitly requires cryptographic-agile architecture and systems.16
June 29, 2026
NIST updates its crypto-agility guidance
NIST CSWP 39-upd1 defines crypto agility around the ability to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and operations.5
March 19, 2027
Expected deadline for federal minimum CBOM guidance
This is 270 days after EO 14412. Importantly, this deadline is about minimum CBOM elements — not a complete universal crypto-agility rulebook.
The policy direction is clear.
EO 14412 sets direction; OMB M-26-15 turns it into execution; NIST provides the technical definition and practices. Institutions should govern CBOM and crypto agility as one migration program.
What exactly goes inside a CBOM?
A useful CBOM should describe more than “RSA exists” or “ECDSA exists.” The inventory becomes operationally useful when it answers both what the cryptography is and how it is used.
Algorithms
Cryptographic primitives
Signature, key-establishment, encryption, hashing and related algorithms, including versions and parameters where relevant.
Keys
Key material and lifecycle
Key types, sizes, locations, ownership, rotation expectations, expiry and connections to HSMs, KMSs or custody systems.
Certificates
Certificates and trust chains
Certificate authorities, signing relationships, validity periods, public-key algorithms and dependencies on PKI infrastructure.
Protocols
Protocols and cipher suites
TLS, SSH, VPN, secure messaging, authentication and other protocols where cryptography is negotiated or fixed.
Implementations
Libraries, modules and hardware
Which crypto library, module, firmware component, HSM, accelerator or service actually implements the cryptography.
Dependencies
Where change propagates
Applications, services, APIs, identities or downstream systems that depend on a given cryptographic choice.
The federal minimum fields are not yet final. Institutions should distinguish between what an effective CBOM needs today and what forthcoming CISA/NIST guidance may require.
SBOM vs CBOM: the difference in one table
| Question | SBOM | CBOM |
|---|---|---|
| Primary purpose | Inventory software components | Inventory cryptographic assets and dependencies |
| Typical objects | Libraries, packages, versions, dependencies | Algorithms, keys, certificates, protocols, crypto libraries, parameters and relationships |
| Main risk lens | Software supply-chain and component vulnerability | Cryptographic vulnerability, policy compliance and migration readiness |
| PQC relevance | Can reveal components that may contain crypto | Directly maps quantum-vulnerable cryptography and migration dependencies |
| Core question | “What software is inside?” | “What cryptography do we depend on?” |
Who are the important players — and what does each one actually do?
Policy bodies, standards organizations, open-source projects and discovery tools play different roles.
| Player | Role | What it means for CBOM |
|---|---|---|
| White House / OMB | Federal policy and agency direction | Set national PQC policy through EO 14412 and translate it into agency execution through OMB M-26-15, including migration plans, automated inventory, central CBOM, vendor coordination and crypto-agile architecture.416 |
| CISA | Operational federal cybersecurity | EO 14412 directs CISA, coordinated with NIST, to issue public guidance on minimum CBOM elements. |
| NIST | Cryptographic standards and technical guidance | Standardizes PQC algorithms, publishes crypto-agility guidance and supports migration work through NIST and NCCoE programs. |
| NCCoE | Applied implementation collaboration | Works with industry collaborators on practical PQC migration and points users to discovery tools and CycloneDX CBOM guidance.8 |
| OWASP CycloneDX | Open BOM standard and community | Provides a machine-readable data model that supports cryptographic artefacts and CBOM use cases. |
| Ecma International / TC54 | International standardization | Standardizes CycloneDX as ECMA-424. |
| IBM Research | CBOM capability developer/contributor | Developed the CBOM functionality introduced into CycloneDX 1.6.2 |
| Discovery vendors and open-source tools | Find cryptography in real systems | Scan code, hosts, networks, certificates and infrastructure, then produce inventory data that can be represented in a CBOM. |
| Enterprises and public agencies | Risk owners and migration operators | Use inventory and dependency data to prioritize cryptographic risk, plan migration, procure compliant technology and demonstrate progress. |
CycloneDX explained properly
CycloneDX is a machine-readable BOM standard—not a scanner or commercial software company. It is community-driven under OWASP; IBM Research developed the CBOM functionality introduced in v1.6; and CycloneDX is standardized as ECMA-424.23
ECMA-424's December 2025 second edition defines CycloneDX v1.7 as a structured format for software and hardware components, services, dependencies, vulnerabilities, cryptographic artefacts, machine-learning models and other supply-chain information. It explicitly supports domain-specific modelling for cryptographic artefacts.3
CycloneDX governance is open and consensus-based, allowing community proposals—including domain-specific CBOM requirements.9
Does NIST require CycloneDX?
No. As of September 2, 2026, no federal rule says “all CBOMs must use CycloneDX.” What is true is that CycloneDX has strong institutional positioning: NIST's NCCoE PQC migration FAQ directs readers to CycloneDX's authoritative CBOM guide, while ECMA-424 provides formal standardization.8
Until CISA/NIST publishes the minimum elements, the required federal format remains unsettled.
Crypto agility: the capability that determines whether migration is controlled or disruptive
Crypto agility is the operational objective. CBOM shows what must change; crypto agility determines whether it can change safely and without disrupting critical services.
OMB M-26-15 · Federal execution language
For federal agencies, crypto agility is now an explicit migration requirement.
M-26-15 connects cryptographic inventory → central CBOM → crypto-agile architecture → PQC migration. Phases 3 and 4 call for cryptographically agile systems; Appendix B requires crypto-agile architecture in agency migration plans.16
The authoritative NIST meaning
NIST CSWP 39-upd1 defines crypto agility as the capability to replace and adapt cryptography across protocols, applications, software, hardware, firmware and infrastructure while preserving security and operations.5
Enterprise
Transition without major disruption
NIST describes enterprise crypto agility as the capacity to move rapidly away from vulnerable algorithms and adopt stronger ones without significant infrastructure changes or unnecessary disruption.12
Computing system
Stop vulnerable algorithms while the system keeps running
For a computing system, NIST focuses on adopting new algorithms and ending use of vulnerable ones without disrupting the running system.13
The key requirement is preserving security and operations. Crypto agility is an operational-resilience capability, not a feature checklist.
What crypto agility is — and what it is not
| Often mistaken for crypto agility | Why that is insufficient | What real agility requires |
|---|---|---|
| “Our library supports ML-DSA.” | Applications, identity, payload formats, HSMs or counterparties may still reject it. | End-to-end ability to deploy, negotiate or coordinate the new primitive across the dependent system. |
| “Our HSM vendor has a PQ roadmap.” | A future hardware feature does not prove that policies, MPC, recovery, APIs or applications can migrate. | Verified migration path across hardware, software, authorization, recovery and operations. |
| “We have a CBOM.” | Visibility can reveal that a dependency is immovable. | Mechanisms to replace algorithms, rotate keys, manage coexistence, test, roll back and retire the vulnerable path. |
| “We can run classical + PQ signatures.” | Hybrid operation can be useful, but it may preserve a classical bypass or create compatibility and performance problems. | A governed transition state with explicit security policy, expiry conditions and no unintended fallback. |
| “The blockchain/network will upgrade.” | Custody, addresses, smart contracts, validators, bridges or historical verification may remain tied to the old primitive. | Layer-by-layer transition covering every path that can authorize, validate or recover assets. |
The institutional “so what” for crypto agility
Crypto agility determines your time-to-safety.
The real metric is how quickly a vulnerable primitive can be removed from every critical path without breaking the business.
Time
How fast can we replace it?Weeks, months or a multi-year re-platforming program?
Continuity
Can services stay live?Can payments, custody, settlement and customer access continue through transition?
Dependency
Who can block us?HSM vendor, cloud provider, counterparty, protocol, wallet, contract or hardware lifecycle?
Control
Can the old path be retired?A migration is incomplete if a classical fallback can still authorize the same asset or action.
CBOM and crypto agility must be assessed together
| State | What it means | Institutional consequence |
|---|---|---|
| Low CBOM visibility + low agility | You do not know all dependencies and cannot change them predictably. | Blind and trapped — highest migration and outage risk. |
| High CBOM visibility + low agility | You can see the vulnerable dependencies, but many are hard-coded, vendor-locked or operationally immovable. | Known migration debt — the problem is visible but still expensive. |
| Low CBOM visibility + high agility mechanisms | Some systems can rotate cryptography, but the organization cannot prove coverage or prioritize the highest-risk dependencies. | Unproven readiness — capability exists, assurance does not. |
| High CBOM visibility + high agility | Dependencies are known, replaceability is tested, transition states are governed and vulnerable paths can be retired. | Controlled migration — the target operating state. |
Why this has regulatory and procurement relevance now
EO 14412 sets federal migration policy; OMB M-26-15 operationalizes crypto agility through agency architecture, vendor requirements and system ownership; NIST provides the technical definition and practices.4165
Institutional consequence: CBOM answers “where are we exposed?”; crypto agility answers “can we migrate without breaking a critical service?” Procurement should test replaceability, coexistence, rollback and retirement—not merely PQC support.
Who owns crypto agility inside the institution?
M-26-15's role model maps cleanly to private institutions:
CIO / CISO
Prioritization, risk acceptance and resource allocation. This is an enterprise risk program, not a cryptography-lab side project.
Procurement / Requirement Owner
Put PQC-readiness and crypto-agility provisions into vendor requirements, contracts and renewal criteria.
CFO / Finance
Fund the multi-year migration, hardware refresh, vendor replacement, testing and contingency capacity.
PQC / Cryptographic Migration Lead
Own the enterprise inventory, sequencing, cross-business coordination and executive reporting.
Security Architect / Technical Lead
Design the crypto-agile architecture, select algorithms, test interoperability and integrate with identity, ZTA, KMS/HSM and applications.
Application & System Owners
Actually remove hard-coded cryptography, upgrade components, test fallbacks and prove that each critical path can change without disruption.
Seven questions that reveal whether you are actually crypto-agile
- Can every critical cryptographic primitive be mapped to an accountable system owner and business function?
- Can the algorithm or key type be changed through configuration, policy or an upgrade path rather than a full redesign?
- Can old and new cryptography coexist safely during a controlled migration window?
- Can the vulnerable algorithm be completely disabled after migration, including fallback, recovery and emergency paths?
- Can HSMs, MPC systems, wallets, APIs, counterparties and protocol dependencies support the new primitive on the same timeline?
- Can the institution test, observe, audit and — where safe — roll back the migration without losing service continuity?
- Can the same migration mechanism be reused for the next cryptographic transition, rather than rebuilt for every algorithm change?
NIST explicitly presents CSWP 39-upd1 as a starting point for developing environment-specific, actionable mechanisms.10 In other words, crypto agility is not achieved by adopting one product or one algorithm. It has to be engineered into the institution's protocols, applications, hardware, governance, vendor contracts and operating model.
How CBOM and crypto agility fit into post-quantum migration
CBOM shows what exists; crypto agility enables safe replacement; PQC supplies the replacement algorithms.
DiscoverFind cryptography
LocateMap systems
ClassifyAssess risk
DependMap impact
PrioritizeSequence work
MigrateReplace safely
MonitorStay current
Discovery must become a dependency-aware inventory: what the cryptography protects, where it runs, who controls it, whether it can change and what must move with it.
EO 14412 explicitly requires minimum elements that support automated assessment of cryptographic assets used by hardware or software.4 CBOM is not meant to remain a static spreadsheet.
Why blockchain makes CBOM harder
Blockchain makes CBOM harder because cryptography is embedded in protocol rules, identity models and permanent state.
A conventional CBOM might correctly report:
“This system uses ECDSA over secp256k1.”
For migration, that is not enough. You need to know what ECDSA controls and what replacing it requires.
| Blockchain surface | CBOM must understand | Migration question |
|---|---|---|
| Transaction authorization | Signature scheme, verification path, encoding, gas/fee assumptions | Can a new signature type be accepted without breaking transaction processing? |
| Address derivation | How public keys become account identifiers | Does changing the key require changing the address or moving assets? |
| Consensus / validators | Validator signatures, certificates, aggregation and peer authentication | Can validator cryptography change without a consensus upgrade or coordinated fork? |
| Smart contracts | Signature verification, precompiles, hard-coded curves, immutable logic | Can applications verify PQ signatures, and are deployed contracts upgradeable? |
| Custody / MPC / HSM | Signing primitives, key shares, policy engines, recovery and approval paths | Can the authorization architecture change without replacing custody infrastructure? |
| Bridges / interoperability | Validator sets, light clients, message authentication and external chain assumptions | Does one classical dependency keep the cross-chain path quantum-vulnerable? |
| Historical verification | Old signatures, proofs, blocks and archival rules | How will the network verify pre-migration history after algorithms change? |
| Recovery / governance | Admin keys, upgrade keys, recovery keys and emergency controls | Can a classical fallback bypass the new PQ protection? |
This is why blockchain requires more than “cryptographic asset inventory.” It requires protocol-level cryptographic dependency and migration intelligence.
NIST's April 2025 Crypto Agility Workshop included a dedicated blockchain session highlighting persistence, immutability, historical validity and coordinated protocol transition.15 It is not a binding rule, but it confirms blockchain needs dedicated migration treatment.
What a Blockchain CBOM / Crypto-Agility Profile should add
A blockchain-aware profile should add function, immutability, upgrade path and migration dependency so cryptographic migration surfaces can be described consistently and machine-readably.
Function
What does the cryptography control?
Transaction signing, validator identity, address derivation, smart-contract verification, bridge authorization, custody, privacy, recovery or governance.
Layer
Where is it enforced?
Client, wallet, HSM, smart contract, precompile, execution layer, consensus layer, P2P layer, bridge or off-chain service.
Mutability
Can it be upgraded?
Configuration change, software update, contract upgrade, governance vote, hard fork, address migration or impossible without replacing the component.
Fallback
Can classical crypto bypass it?
A PQ verifier is not a complete control if a legacy ECDSA or EdDSA path can still authorize the same critical action.
Compatibility
What breaks when it changes?
Signature encoding, transaction size, gas model, hardware support, RPC interfaces, indexing, custody workflows, wallets or downstream contracts.
Migration
What is the actual transition mechanism?
Dual-signature window, key rotation, account abstraction, new precompile, hard fork, validator epoch transition, proof migration or re-issuance.
That turns CBOM into a map of cryptographic migration debt: where change is easy, coordinated, identity-changing, or requires a fork or asset migration.
What happens next?
CBOM is moving into procurement, audit, software lifecycle and migration programs. For institutions, cryptographic inventory becomes a capital-planning and resilience input: what to upgrade, replace, remediate or coordinate.
| Period | What to watch | Why it matters |
|---|---|---|
| Now → March 2027 | CISA/NIST minimum CBOM elements; vendor alignment; more machine-readable discovery | Defines the federal baseline and may influence procurement and enterprise tooling. |
| 2027–2030 | PQC pilots, crypto-agility architecture, migration prioritization, procurement requirements | Inventory begins turning into funded migration work. |
| 2030–2031 | EO 14412 federal migration and procurement milestones | Quantum-safe requirements move closer to contractual and operational enforcement in covered contexts. |
| Through 2035 | Broader transition of vulnerable public-key cryptography | Legacy systems, long-lived assets and protocol-level dependencies become the hardest tail of migration. |
For institutions, the immediate practical question is not “Which CBOM product should we buy?” It is:
- Do we have complete cryptographic visibility?
- Can we map cryptography to business and protocol functions?
- Can we automatically identify vulnerable or non-compliant cryptography?
- Do we know which dependencies make migration difficult?
- Can algorithms and keys be changed without re-platforming?
- Can we prove progress continuously rather than through one-off inventory exercises?
Outcomes by stakeholder
A strong CBOM gives every institutional team the cryptographic evidence it needs—not just security engineering.
| Stakeholder | What they need to know | What CBOM should give them |
|---|---|---|
| Board / Risk Committee | Where could cryptographic migration interrupt critical services or create material operational risk? | A ranked map of critical cryptographic dependencies, owners, migration difficulty and residual exposure. |
| CISO / Security Architecture | Where are vulnerable algorithms and which dependencies prevent replacement? | Machine-readable inventory tied to system, implementation, criticality, owner and remediation path. |
| CTO / Engineering | Which changes are configuration work versus architecture changes? | Replaceability, compatibility, test requirements, API impacts, hardware constraints and migration mechanism. |
| Custody / Digital Assets | Can value still be authorized through a classical path? | End-to-end signing and recovery map across wallets, MPC, HSM, chain, contracts and governance. |
| Issuer / Product | Can minting, burning, transfer, freeze and settlement continue during migration? | Control-path mapping plus sequencing for issuer keys, treasury, contracts, custody and counterparties. |
| Compliance / Audit | Can the institution demonstrate what crypto it uses and what is being remediated? | Evidence that is repeatable, attributable, versioned and capable of supporting automated assessment. |
| Procurement / Vendor Risk | Which products create lock-in or a future forced replacement? | Vendor-specific algorithm support, firmware/hardware constraints, upgrade commitments and fallback exposure. |
Six questions an institution should be able to answer now
- Which production systems and third parties still depend on quantum-vulnerable public-key cryptography?
- Which of those cryptographic dependencies control payments, custody, issuance, identity, trading, settlement, recovery or governance?
- Which dependencies can be replaced by configuration or key rotation — and which require new hardware, software, contracts, addresses or protocols?
- Where does a classical fallback remain capable of authorizing the same critical action?
- Which vendor or counterparty is the slowest dependency in the migration path?
- Can the institution prove this continuously from machine-readable evidence rather than a one-off spreadsheet?
If you cannot answer these questions, the gap is not the PQ algorithm.
It is insufficient cryptographic visibility and migration intelligence.
EternaX institutional migration paths
From CBOM findings to the right migration path
CBOM identifies exposure; crypto agility tests replaceability. EternaX addresses four institutional migration paths.
01 · Stablecoins & Tokenization
Protect issuer and asset-control authority
For stablecoins, tokenized funds and RWAs, EternaX adds PQ-safe controls around mint/burn, compliance, permits, vault governance and custody while preserving the existing tokenization stack.
So what: protect the control plane without reissuing the asset simply because cryptography changes.
Relevant institutional profiles
CirclePaxosRippleJPMorgan / KinexysBlackRock / BUIDLFranklin TempletonOndoBNY MellonDTCC
Explore Stablecoins & Tokenization →
02 · Custody & MPC
Add PQ authorization without replacing custody
For MPC, HSM and smart-account custody, EternaX introduces an independent post-quantum authorization boundary around existing institutional workflows.
So what: migrate the authorization layer while keeping the custodian, assets and operating model in place.
Relevant institutional profiles
FireblocksBitGoCopperAnchorage DigitalZodia CustodyHex TrustSafeThalesUtimaco
Explore Custody & MPC →
03 · PQ-Native Settlement
Start new long-duration rails inside a PQ-native boundary
For programmes that require post-quantum authorization, consensus, privacy and future algorithm rotation in one infrastructure boundary, EternaX provides PQ-native institutional settlement.
So what: avoid embedding new long-lived assets and liquidity into infrastructure that already carries migration debt.
Relevant institutional profiles
DTCCJPMorganCitiHSBCBNY MellonState StreetCirclePaxosBlackRock
Explore PQ-Native Settlement →
04 · Hyperledger Besu
Make institutional Besu infrastructure migration-ready
For existing or planned Besu networks, EternaX provides PQ tokenization controls, privacy protection, custody authorization and a deeper PQ-safe ledger path where required.
So what: keep the institutional EVM operating model while removing the cryptographic bottlenecks that make future migration difficult.
Relevant programmes & profiles
DTCC AppChainSWIFTFnalityCitiProject AgoramBridgeHSBCStandard CharteredBNP Paribas
Explore Hyperledger Besu →
What an institutional readiness engagement should produce
Exposure mapWhere classical cryptography remains.
Agility gapWhat cannot be changed safely today.
Migration pathCustody, tokenization, Besu or PQ-native.
Priority planWhat to protect now vs. later.
Institution names above illustrate relevant institutional profiles or public programmes; they do not imply EternaX customer relationships.
Research authors
About the authors
Paarrthhh Birla
Co-Founder
Ex-Polygon (VP Growth Office); Head of Partnerships, Subspace Protocol; Digital assets strategy at EYP, Advised Visa and State Street; MBA, CPA.
Dariia Porechna
Co-Founder
Cryptographer and distributed systems architect; Head of Protocol, Subspace; Research Engineer, Wolfram|Alpha. Co-author, SILMARILS.
Dr. Chen Feng
Chief Scientist
Assoc. Prof. at University of British Columbia; PhD (Toronto); 100+ peer-reviewed papers; Quantum communications, blockchain, TEE privacy. Co-author, SILMARILS.
Frequently asked questions
CBOM FAQ
What is a CBOM?
A Cryptographic Bill of Materials (CBOM) is a structured inventory of cryptographic assets and dependencies used by hardware or software. It can describe algorithms, keys, certificates, protocols, libraries, parameters and relationships so an organization can identify cryptographic risk and plan migration.
What is the difference between SBOM and CBOM?
An SBOM inventories software components such as packages and libraries. A CBOM inventories cryptography and its dependencies. SBOM answers “what software is inside?” while CBOM answers “what cryptography do we depend on?”
Why is CBOM important for post-quantum cryptography?
Post-quantum migration cannot be planned reliably without knowing where quantum-vulnerable cryptography exists. CBOM provides the inventory layer needed to discover, classify and prioritize cryptographic dependencies before replacing them with PQC.
Does M-26-15 connect CBOM and crypto agility?
Yes. Appendix A says automated cryptographic inventory should populate a central CBOM to provide a real-time view of cryptographic posture. The same appendix then defines cryptographic agility and gives architecture mechanisms, while Appendix B requires a plan for a cryptographic-agile architecture. The memo therefore treats visibility and replaceability as connected parts of one migration program.16
Is CBOM mandatory?
There is no single universal rule requiring every organization to produce a CBOM in one format. However, U.S. federal policy already requires cryptographic inventories in defined contexts, and EO 14412 directs CISA and NIST to publish minimum CBOM elements. Procurement and sector-specific requirements can make CBOM capabilities increasingly important even where the term itself is not mandated.
What does Executive Order 14412 require for CBOM?
EO 14412, signed June 22, 2026, directs the Secretary of Homeland Security through CISA, in coordination with NIST, to release public guidance within 270 days describing the agencies' considered view on minimum CBOM elements. Those elements must enable automated assessment of cryptographic assets used by hardware or software.4
What is OMB Memorandum M-26-15, and why is it important?
M-26-15, Execution of the Migration to Post-Quantum Cryptography, was issued June 24, 2026 to implement EO 14412 for civilian federal agencies. It requires a PQC Migration Plan within 120 days, phases migration through 2035, makes automated cryptographic inventory and central CBOM part of execution, and explicitly requires cryptographic-agile architecture and systems.16
What happens on March 19, 2027?
March 19, 2027 is 270 days after EO 14412. It is therefore the deadline implied by the order for CISA/NIST public guidance on minimum CBOM elements. It is not a deadline for a complete universal crypto-agility framework.
What is CycloneDX?
CycloneDX is an open, machine-readable Bill of Materials standard under the OWASP community. It can represent software, hardware, services, cryptographic artefacts and other supply-chain information. CycloneDX is standardized internationally as ECMA-424.3
Is CycloneDX itself a CBOM scanner?
No. CycloneDX is primarily a data model and exchange standard. Discovery products and open-source tools scan systems or code; their findings can then be represented in a CycloneDX CBOM.
Did IBM invent CBOM?
IBM Research developed the CBOM capability introduced into CycloneDX 1.6. CycloneDX explicitly credits IBM Research for developing that CBOM functionality.2 The broader idea of cryptographic inventory is also driven by government policy, standards work and industry migration needs, so it is more accurate to distinguish the CycloneDX CBOM implementation from the broader concept.
Does NIST require CycloneDX for CBOM?
No. As of September 2, 2026, no federal mandate says that CBOM must use CycloneDX. NIST's NCCoE PQC migration material points users to CycloneDX's authoritative CBOM guide, but that is not the same as mandating one format.8
Is there a NIST-approved CBOM scanner?
There is no general NIST certification category equivalent to “approved CBOM scanner.” NCCoE lists collaborator and discovery tools, but listing a tool is not the same as CMVP/FIPS validation or federal certification.
What is crypto agility?
NIST defines crypto agility as the capabilities needed to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. For an enterprise, NIST further frames it as the capacity to move rapidly away from vulnerable algorithms and adopt stronger ones without major infrastructure change or unnecessary disruption.512
Is crypto agility legally required?
For civilian federal agencies executing M-26-15, crypto agility is explicitly part of the required migration architecture. The memorandum says Phase 3 and Phase 4 should ensure all systems are cryptographically agile and requires migration plans to include a cryptographic-agile architecture. It is not a universal statutory duty imposed on every private company. Private institutions can become affected through critical-infrastructure coordination, federal procurement/contracting, FedRAMP/shared-service dependencies, sector rules and customer/vendor requirements.164
Is CBOM the same as crypto agility?
No. CBOM is the evidence and inventory problem; crypto agility is the transition-capability problem. An institution can know exactly where ECDSA, RSA or a certificate profile is used and still be non-agile if changing it requires new hardware, new identities, contract upgrades, counterparty coordination or downtime. The strongest readiness program measures both visibility and replaceability.
Does CBOM apply to blockchain?
Yes. Blockchain systems contain cryptographic algorithms in transaction authorization, consensus, addresses, custody, smart contracts, bridges and other components. The key challenge is that those cryptographic choices can be protocol-critical and persistent.
Why does blockchain need a special CBOM profile?
A normal CBOM can identify an algorithm. A blockchain profile should also describe what that algorithm controls, which layer enforces it, whether a classical fallback remains, whether changing the key changes the address, and whether migration requires an application upgrade, validator transition, hard fork or asset move.
Has NIST discussed blockchain crypto agility?
Yes at the research and stakeholder level. NIST's April 2025 Crypto Agility Workshop included a presentation titled “Crypto-agility for Blockchain Protocols.” That does not establish a binding blockchain standard, but it demonstrates that blockchain migration is a recognized topic within crypto-agility work.7
What are the NIST post-quantum standards most relevant to migration?
NIST finalized FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures and FIPS 205 (SLH-DSA) for digital signatures in August 2024. Additional standards, including FIPS 206 for FN-DSA, remain part of the continuing PQC standardization program.6
Which financial institutions are already treating crypto agility as a sector issue?
FS-ISAC's financial-sector crypto-agility work includes contributors from institutions such as Wells Fargo, HSBC, Santander, Fidelity Investments, State Street, Swift, Deutsche Bank, JPMorgan Chase, Morgan Stanley, U.S. Bank, RBC and others. Separately, the Federal Reserve's U.S. GSIB program includes JPMorgan Chase, Bank of America, Citigroup, Goldman Sachs, Morgan Stanley, BNY Mellon, State Street and Wells Fargo. These names show that cryptographic migration is already a systemic-finance issue; they do not imply that EO 14412 directly imposes federal-agency deadlines on each private firm.1820
What should an institution do now?
Build or validate cryptographic inventory now; map every high-risk dependency to the business function it controls; identify owners, vendors, hardware and fallback paths; classify replaceability; test PQC support; and create a funded migration sequence. For custody, tokenization and blockchain, separately map transaction authorization, admin/recovery controls, consensus, contracts and bridges so a single classical path cannot be mistaken for end-to-end PQ readiness.
Primary sources
Sources & further reading
- OMB M-23-02 — Migrating to Post-Quantum Cryptography. November 18, 2022.
- CycloneDX v1.6 Released — Cryptographic Bill of Materials. April 9, 2024.
- ECMA-424 — CycloneDX Bill of Materials specification. Ecma International.
- Executive Order 14412 — Securing the Nation Against Advanced Cryptographic Attacks. June 22, 2026.
- NIST CSWP 39-upd1 — Considerations for Achieving Crypto Agility: Strategies and Practices. Updated June 29, 2026.
- NIST — Approval of FIPS 203, FIPS 204 and FIPS 205 for Post-Quantum Cryptography. August 13, 2024.
- NIST Crypto Agility Workshop. April 17–18, 2025.
- NIST NCCoE — Migration to Post-Quantum Cryptography FAQ and collaborator tools.
- CycloneDX Governance.
- NIST — Considerations for Achieving Crypto Agility.
- NIST CSRC Glossary — Crypto Agility. Source: CSWP 39-upd1.
- NIST CSRC Glossary — Crypto Agility for an Enterprise. Source: CSWP 39-upd1.
- NIST CSRC Glossary — Crypto Agility for a Computing System. Source: CSWP 39-upd1.
- NIST CSRC Glossary — Software Bill of Materials. Definition sourced from Executive Order 14028 and NIST publications.
- NIST Crypto Agility Workshop — Crypto-agility for Blockchain Protocols. April 18, 2025.
- OMB M-26-15 — Execution of the Migration to Post-Quantum Cryptography. June 24, 2026.
- CISA — Sector Risk Management Agencies. Financial Services Sector: U.S. Department of the Treasury.
- Federal Reserve Board — Global Systemically Important Banks. Eight U.S. GSIBs as of February 2026.
- Federal Reserve Board — Designated Financial Market Utilities.
- FS-ISAC — Post Quantum Cryptography: Building Cryptographic Agility in the Financial Sector.
- G7 Cyber Expert Group — Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector. January 2026.
- NIST — What Is Post-Quantum Cryptography?. Updated February 27, 2026.
- FS-ISAC — Jaime Gomez Garcia: Prep for Quantum Like It’s Basic Cyber Hygiene — Because It Is. 2026.
Editorial note: Definitions and mandate statements are anchored to primary U.S. government sources wherever available. This guide distinguishes EO 14412, OMB M-26-15 agency requirements, NIST technical guidance, critical-infrastructure coordination, and proposed procurement rules. Named private institutions are shown to help readers recognize their place in the financial-system migration ecosystem; their inclusion is not a claim that EO 14412 directly imposes federal-agency deadlines on each firm.