Crypto-Agility and CBOM: Getting Ready for Post-Quantum

Crypto-agility is the ability to replace cryptographic algorithms, keys and certificates in a system quickly, without rebuilding it and without harming security or operations. NIST defines it as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. A CBOM (cryptographic bill of materials) is the inventory that tells you where those algorithms are used. Together they are the base for moving to post-quantum cryptography.

Why agility matters now

In August 2024 NIST finalized its first three post-quantum standards: FIPS 203 (ML-KEM, for establishing keys), and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), both for digital signatures. NIST's post-quantum project page gives 2035 as the target for removing quantum-vulnerable algorithms from its standards, with high-risk systems moving much earlier. The transition is the subject of NIST IR 8547, which was still an initial public draft (published 12 November 2024) on the NIST page we read. That draft page does not state the dates.

The set of standards is still growing. In March 2025 NIST selected HQC as a second key-encapsulation algorithm (a way to deliver a key safely) after ML-KEM, and said a final version is expected in approximately two years. NIST's post-quantum page, last updated on 5 August 2026, says the Falcon signature algorithm (to be named FN-DSA) was selected for standardization and that work is underway, without giving a date. We could not confirm whether the FN-DSA draft, FIPS 206, has been published. Algorithm choices will keep changing, which is why agility is needed.

What NIST says about crypto-agility

NIST published CSWP 39, "Considerations for Achieving Crypto Agility: Strategies and Practices", on 19 December 2025. An updated version, CSWP 39upd1, was released as final on 29 June 2026 and supersedes the first. NIST's abstract says it surveys current approaches, discusses challenges and trade-offs, describes operational mechanisms, and identifies areas that need more work. Its keywords include cryptographic API and cryptographic risk management.

In practice, agility is a design habit and not a product. The habits below are our own summary of common engineering practice, not NIST requirements:

• Do not hard-code algorithms: read the algorithm name and key size from configuration, not from code scattered across programs
• Use one shared crypto library or service: so that one update changes many applications
• Automate certificate and key changes: see Encryption key management and Certificate lifecycle management
• Test with larger sizes: post-quantum keys and signatures are generally larger than RSA and ECC ones, so check the limits in protocols, devices and databases
• Ask vendors for an update path: can the product get new algorithms through a software or firmware update, or only by replacing hardware?

What a CBOM is

A CBOM is an inventory of cryptographic assets such as algorithms, keys and certificates, together with the software that depends on them. It is like an SBOM (software bill of materials, the parts list of a piece of software, see SBOM and software supply chain security), but for cryptography. The CycloneDX standard added CBOM in version 1.6, announced by OWASP on 9 April 2024. CycloneDX describes it as a way to discover, manage and report on cryptographic assets for a quantum-safe future.

A CBOM answers questions such as which systems still use RSA or ECC (public-key cryptography that a future quantum computer could break), which key sizes are in use, who owns each item, and how long the protected data must stay secret. Without those answers, a migration cannot be planned or sized.

A practical way to build one is:

• Set the scope and owners: start with internet-facing systems and long-lived data
• Discover: scan source code, network traffic, certificate stores, key stores and vendor products
• Record: for each item note the algorithm, key size, location, owner, vendor and how long the data must stay secret
• Prioritize: handle long-secrecy data and devices that are hard to update first
• Keep it current: regenerate it at each build or release, and review it on a schedule

What CISA says

CISA's quantum page urges organizations to begin preparing now, because future quantum computers could break widely used public-key encryption and signatures. It takes an inventory-first approach. US federal civilian agencies must keep a current inventory of IT that is vulnerable to quantum decryption, and CISA supports automated cryptographic discovery and inventory tools. It also maintains a list of product categories that support, or plan to support, the post-quantum standards. These are US federal requirements, but the idea of starting with an inventory applies to any organization.

How this connects to your other work

Agility builds on work many teams already do: automated certificates, keys held in a KMS or HSM, and software inventories. If you have not yet read why the quantum risk matters, start with What is PQC?.

Common mistakes

• Waiting for the standards to settle before starting: the inventory and the agility work do not depend on the final list of algorithms
• Treating the move to PQC as a one-time project: the set of algorithms is still changing, as HQC and FN-DSA show
• Building the CBOM once and never updating it: it goes out of date at the next release
• Inventorying only your own code: libraries, appliances, SaaS products and embedded devices also hold cryptography
• Swapping algorithms without testing sizes and speed: larger keys and signatures can break protocol limits and slow systems down
• Assuming the vendor will handle it: without a written roadmap and dates, there is no commitment

Start today

• Pick a pilot scope: for example all TLS endpoints and VPNs, so the first inventory stays small
• Run a first inventory: record algorithms, key sizes, owners and data lifetime in a spreadsheet if you have no tool yet
• Stop hard-coding algorithms in new code: read them from configuration
• Add an update-path question to purchasing checklists: ask how the product gets new algorithms
• Read the sources: NIST CSWP 39upd1 and the CISA quantum page, listed below

To see where your cryptography and identity controls stand today, try the self-assessment.

Scope and accuracy

The sources were read on 27 October 2026. We read the NIST abstract pages, not the full text of CSWP 39upd1, so this article does not describe its contents beyond the abstract. NIST's schedule for HQC, FN-DSA and NIST IR 8547 can change, so confirm on csrc.nist.gov before planning. The CISA page names the US federal requirements and is not a requirement for other organizations. This article is general information and not legal or compliance advice.

References and further reading

• NIST CSWP 39upd1: Considerations for Achieving Crypto Agility: the NIST white paper page (final, June 2026)
• NIST Post-Quantum Cryptography project: overall status of the PQC standards
• FIPS 203: ML-KEM: the key-establishment standard
• NIST IR 8547 (initial public draft): the planned transition away from quantum-vulnerable algorithms
• NIST: HQC selected as a 4th-round algorithm: announcement of March 2025 and the expected timeline
• CISA: Quantum: CISA's post-quantum guidance and resources
• CycloneDX: Cryptography Bill of Materials (CBOM): what a CBOM records
• OWASP: CycloneDX v1.6 released: the announcement that introduced CBOM (April 2024)