Crypto-Agility & Post-Quantum Readiness Checklist
Two forces are about to make your cryptography move: TLS certificate lifetimes are shrinking toward ~47 days by 2029, and the post-quantum standards NIST finalised in August 2024 (ML-KEM, ML-DSA, SLH-DSA) will eventually have to replace today's algorithms. Both reward the same capability — crypto-agility: knowing where every algorithm, key and certificate lives, and being able to swap it without re-architecting. Work through a scored checklist across crypto inventory (CBOM), algorithm agility, certificate-lifetime reduction and automation, and PQC migration, and get a weighted 0-100 score with the gaps ranked so you start where it matters most. The near-term risk is harvest-now, decrypt-later: data captured today can be decrypted once quantum computers arrive, so long-lived secrets need protecting now. Nothing is uploaded and it runs entirely in your browser.
You cannot fully see or swap your cryptography, and PQC is unplanned. Harvest-now-decrypt-later means the clock is already running. Start with inventory.
Prioritised gaps
Highest-weight, lowest-scoring controls first — spend remediation effort here.
- Crypto inventory (CBOM) · unanswered
Build a CBOM: enumerate every algorithm, key length, certificate and TLS/SSH/VPN protocol in use, including libraries and embedded devices.
Reference: CycloneDX CBOM
- Crypto inventory (CBOM) · unanswered
Map key and certificate locations beyond the OS store — app trust stores, HSMs, appliances, SaaS and partner integrations.
- Crypto inventory (CBOM) · unanswered
Tag deprecated algorithms in the inventory and open retirement tickets; you cannot be agile about what you have not identified.
- Crypto inventory (CBOM) · unanswered
Ask critical vendors for their crypto/PQC roadmap and record it; third-party crypto is part of your attack surface.
- Algorithm agility · unanswered
Externalise algorithm/parameter choices into configuration or a crypto-provider abstraction so they can be changed without code changes.
- Algorithm agility · unanswered
Route cryptography through a shared library or service so an algorithm swap happens in one place, not across every app.
- Algorithm agility · unanswered
Prefer protocols/versions that negotiate algorithms (TLS 1.3) so clients and servers can adopt new suites without a flag day.
- Algorithm agility · unanswered
Run a drill: change a cipher suite or hash across a service end-to-end to prove agility exists in practice, not just on paper.
+ 8 more gaps in the full export.
Crypto inventory (CBOM) · weight 3
You cannot migrate what you cannot see. A cryptographic bill of materials (CBOM) records every algorithm, protocol, certificate and key across your estate — in code, libraries, certificates, hardware and third parties. Inventory carries the most weight because every later step depends on it.
You maintain a cryptographic inventory / CBOM covering algorithms, key sizes, certificates and protocols across the estate.
You know where every private key and certificate lives (apps, language trust stores, HSMs, appliances, third parties).
The inventory flags weak/legacy algorithms (e.g. RSA-1024, SHA-1, 3DES, RC4) for retirement.
You track the cryptography used by critical vendors and dependencies, not just your own code.
Algorithm agility · weight 3
How quickly you can swap an algorithm without re-architecting. Crypto-agility means algorithms and parameters are configuration, not hard-coded assumptions — so moving from one algorithm to another (or to a hybrid) is a change, not a rebuild.
Algorithms and key sizes are configuration-driven, not hard-coded into applications.
Applications call a central crypto library / service rather than each embedding their own primitives.
Protocols negotiate algorithms (e.g. TLS 1.3 cipher negotiation) so endpoints can migrate independently.
You have actually rehearsed swapping an algorithm or rotating to a new suite (not just assumed you can).
Certificate-lifetime reduction & automation · weight 2
Short-lived certificates and automation make any migration routine. The industry is moving toward a ~47-day maximum TLS certificate lifetime by 2029 (per the CA/Browser Forum ballot adopted in 2025); automation (ACME) is what makes that — and any future re-issuance — sustainable.
Certificate issuance and renewal are automated (e.g. ACME), not manual.
You are prepared for shorter certificate lifetimes (the move toward a ~47-day max TLS cert lifetime by 2029).
Expiries are monitored and alert before outage, with no reliance on a human remembering.
You could force a fleet-wide re-issuance (e.g. after a mass distrust) without a fire drill.
Post-quantum (PQC) migration · weight 2
Readiness for the standardised post-quantum algorithms. NIST finalised FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures) and FIPS 205 (SLH-DSA, signatures) in August 2024. The near-term driver is "harvest-now, decrypt-later": data captured today can be decrypted once a cryptographically relevant quantum computer exists, so long-lived secrets need protecting now.
Your team is aware of the finalised NIST PQC standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205).
You have identified long-lived secrets/data at risk from "harvest-now, decrypt-later" and prioritised them.
You are planning or piloting hybrid key exchange (classical + ML-KEM) for the most sensitive channels.
A PQC migration roadmap exists, sequenced off the crypto inventory, with owners and milestones.
Educational — general guidance, not legal/compliance advice. Heuristic self-assessment: the area weights are a transparent judgement framework, not a measurement or certification. This tool performs no scan, makes no network calls, and runs entirely in your browser — nothing is uploaded. Named standards (NIST FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, finalised August 2024; CycloneDX CBOM; ACME/RFC 8555; the CA/Browser Forum 2025 certificate-lifetime ballot) are referenced for orientation only.
What this checklist is
- A free, 100% in-browser scored checklist for crypto-agility and post-quantum readiness: answer across crypto inventory (CBOM), algorithm agility, certificate-lifetime reduction, and PQC migration, and get a weighted 0-100 score with prioritised gaps.
- Inventory carries the most weight: you cannot migrate what you cannot see. A cryptographic bill of materials (CBOM) records every algorithm, key, certificate and protocol across code, libraries, hardware and vendors.
- Crypto-agility means algorithms are configuration, not hard-coded — so swapping one (or moving to a hybrid) is a change, not a rebuild. The quickest proof is having actually rehearsed a swap.
- The industry is moving toward a ~47-day maximum TLS certificate lifetime by 2029 (CA/Browser Forum ballot adopted 2025); ACME automation is what makes that cadence — and any mass re-issuance — sustainable.
- NIST finalised the post-quantum standards in August 2024: ML-KEM (FIPS 203) for key exchange, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. "Harvest-now, decrypt-later" means long-lived secrets are at risk today.
Why this matters
For decades cryptographic choices could be made once and left alone. That era is ending. The CA/Browser Forum's 2025 ballot steps the maximum public-TLS certificate lifetime down toward roughly 47 days by 2029, which only works with automation; and NIST's August 2024 standards — FIPS 203 (ML-KEM) for key exchange, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures — begin a migration that will touch almost every system that uses public-key cryptography. The organisations that cope will be the ones that are crypto-agile.
Agility starts with visibility. A cryptographic bill of materials (CBOM) tells you where every algorithm, key, certificate and protocol lives — including in third-party libraries and vendor systems you do not control — so you can retire the weak ones and sequence a migration. Then the cryptography has to be changeable: configuration-driven, routed through a shared library or service, negotiated at the protocol layer, and actually rehearsed. Automation (ACME, short-lived certificates, expiry monitoring) makes a mass re-issuance routine. And the post-quantum plan — driven off the inventory, prioritising long-lived secrets exposed to harvest-now-decrypt-later, piloting hybrid key exchange — is where all of it points. This is an educational self-assessment, not a certification or legal advice; the dates and standards named are for orientation and should be checked against current requirements.
Frequently asked questions
What is crypto-agility?
Crypto-agility is the ability to change cryptographic algorithms, key sizes and protocols quickly and with minimal disruption. In practice it means algorithm choices are configuration-driven rather than hard-coded, applications call a central crypto library or service instead of each embedding their own primitives, and protocols negotiate algorithms (as TLS 1.3 does) so endpoints can migrate independently. The decisive test is whether you have actually rehearsed a swap — many organisations assume they are agile until a forced migration proves otherwise. Agility is what turns the eventual move to post-quantum algorithms, or an emergency retirement of a broken algorithm, into a routine change rather than a multi-year re-architecture.
What is a CBOM and why does inventory come first?
A cryptographic bill of materials (CBOM) is an inventory of every cryptographic asset in your estate — algorithms, key sizes, certificates, protocols and where each lives, across your own code, third-party libraries, hardware, appliances and vendor integrations. It comes first because every later step depends on it: you cannot retire weak algorithms (RSA-1024, SHA-1, 3DES, RC4), plan a certificate-lifetime reduction, or sequence a post-quantum migration if you do not know where your cryptography is. CycloneDX has extended the SBOM format to express a CBOM. Inventory is weighted highest in this checklist for exactly this reason.
What are the NIST post-quantum (PQC) standards and what is "harvest-now, decrypt-later"?
In August 2024 NIST finalised three post-quantum cryptographic standards: FIPS 203 (ML-KEM, a key-encapsulation mechanism for key exchange, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, a digital-signature algorithm based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, a stateless hash-based signature scheme based on SPHINCS+). These are designed to resist attack by a future cryptographically relevant quantum computer. "Harvest-now, decrypt-later" is the near-term driver: an adversary can capture encrypted traffic today and store it until quantum computers can break the classical key exchange that protected it. So any data whose confidentiality must last years — long-lived secrets, archived records — is effectively at risk now, which is why sensitive channels are the first candidates for hybrid key exchange (a classical algorithm combined with ML-KEM).
Why are certificate lifetimes getting shorter, and what is the ~47-day number?
In 2025 the CA/Browser Forum adopted a ballot that progressively reduces the maximum lifetime of public TLS certificates, reaching roughly 47 days by 2029 (down from the current 398 days, via staged reductions). Shorter lifetimes limit how long a mis-issued or compromised certificate stays trusted and force automation. The practical consequence is that manual renewal stops being viable: you need ACME or equivalent automation, centralised expiry monitoring that alerts on the renewal deadline, and the ability to force a fleet-wide re-issuance without a fire drill. That same automation is what makes a post-quantum migration — which is ultimately a very large re-issuance — sustainable. This is an educational self-assessment and not legal or compliance advice; verify the exact dates against the current CA/Browser Forum requirements for your situation.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.Educational — general guidance, not legal/compliance advice.