How to estimate the blast radius of a post-quantum migration
"How big is our post-quantum migration?" is the question every programme gets asked first, and the one most inventories cannot answer. A count of RSA findings is not a scope. The blast radius of a migration is everything that has to change, be tested or be coordinated when an algorithm is replaced: code, certificates, services, partners and teams.
Start from an inventory with provenance
You cannot size what you cannot locate. Each finding needs to say where it lives — file and line, certificate store or TLS endpoint — and what it is used for: signing, key exchange, encryption or hashing. Use case matters as much as algorithm: replacing an RSA signature (towards ML-DSA) and an RSA key transport (towards ML-KEM) are different projects with different dependencies.
Five steps to a defensible estimate
- Group by algorithm and use case. Separate classically broken cryptography (MD5, SHA-1, short RSA keys) from PQC migration candidates (RSA, ECDSA, ECDH, Ed25519) and from cryptography to retain (AES-256, SHA-256+).
- Map findings to owners. Turn file paths and endpoints into services and teams. The number of distinct files or services carrying critical and high findings is a better first measure of reach than the raw finding count.
- Find the choke points. A shared JWT signing key, an internal CA, a crypto wrapper library or a TLS terminator can account for dozens of findings. Changing one of them fixes many assets at once — or breaks many relying parties if done without coordination.
- Weight by migration complexity. A hash swap is not an asymmetric migration. CRYPTAGION's roadmap uses a simple per-asset heuristic — about 0.25 person-months where little changes, 1 for low complexity, 3 for medium, 8 for high — meant to be tuned with the customer, not used as a quote.
- Sequence in waves. Quick wins first, then high-priority medium-complexity work, then complex and deeply embedded systems, anchored to data lifetimes and your CRQC planning scenario.
A source inventory example
Our pinned pyca/cryptography demonstration separates 46 library-source detections from 1,746 test detections and 12 documentation-script detections. It does not estimate migration effort or establish production exposure. The review shows why source records must be connected to owners and operational context before sizing work.
Shrink the radius before you migrate
- Centralise cryptography behind a provider or service, so an algorithm change is a configuration change, not a code hunt. See crypto-agility explained.
- Stop it growing. A CI gate on new high-risk cryptography keeps the baseline from moving while you migrate — see CRYPTAGION in CI/CD.
- Track drift. Snapshot the inventory each release and diff it, so the estimate stays current.
Know what the estimate does not include
An estimate built from source code, certificates and TLS endpoints does not see compiled third-party binaries, firmware, HSM configuration or partners' systems. List them explicitly as open items, with an owner, rather than letting them disappear from the scope.
Size your own migration
We run CRYPTAGION on a representative repository in the call and show the reach, the waves and the effort — inside your perimeter.
Book a free discovery call →