Post-Quantum Scan — where the cryptography a quantum computer opens lives

In everyday life

First the list of doors, then the locksmith.

Imagine changing every lock in an old building. Nobody starts by buying locks: they walk the building with a clipboard, noting each door, what kind of lock it has and what it guards. Some doors are hidden behind others.

Cryptography is the same, with one twist: many "doors" aren’t in your code. They are in dependencies (the libraries and SDKs your system uses) and in server configuration. Without a sweep, nobody knows what needs to migrate.

The system’s floor plan with each lock found. In red, those a quantum computer opens; in gray, those that already resist.

The sum that sets the order

Secrecy plus migration, against the clock.

In 2015 Michele Mosca proposed a three-number sum that became the industry’s yardstick. X: how many years the data must stay secret. Y: how many years you need to migrate. Z: how many years until a quantum computer able to break the lock exists.

If X + Y exceeds Z, the data is already exposed today, even though the quantum computer doesn’t exist yet. In practice: a signed contract that must stay valid for 20 years is already late under any estimate; a login token valid for an hour only has to be migrated before the day the machine switches on.

When secrecy plus migration fit before the quantum computer arrives, there is slack. When they go past it, the data is already exposed.

Why now

Record now, decrypt later.

Whoever wants your data doesn’t need to wait for the quantum computer to act. They just record today’s traffic encrypted with RSA or elliptic curves and keep it. The day the machine exists, they open everything at once, backwards.

That is why urgency isn’t about who uses the data today: it’s about who will need it to stay secret 10 or 20 years from now. Financial data, contracts, health records and intellectual property are first in line.

Traffic recorded today is stored until the day it can be opened. That day’s date is an estimate.

How the scan works

Sweep, map, classify, plan.

Code and configuration. An automated sweep of code and server settings: where RSA, ECDSA and ECDH are used, which TLS versions and ciphers are enabled, which certificates and keys exist.

Dependencies. The whole tree of libraries, cloud SDKs and integrations: for each, the version, the algorithm it uses and whether a version with the new lock exists.

Classification. Each finding gets the secrecy horizon of the data it protects, its exposure (internet, internal network, isolated) and the effort to replace it.

Plan. The migration order to NIST’s new locks (ML-KEM, ML-DSA, SLH-DSA), with hybrid mode where compatibility requires it. A report the security lead takes to the board.

The scan’s four steps, from code to plan.

Deadlines that already exist

Recommendation became a calendar.

NIST published the first three new-lock standards in August 2024. Since then, governments have turned recommendation into dates: the US federal government targets 2030 for key exchange and 2031 for authentication; US national security systems require resistant algorithms in new purchases from 2027; the European Union, critical infrastructure by 2030 and full transition by 2035; the G7 roadmap for finance, critical systems between 2030 and 2032.

Brazil has no equivalent date yet, but whoever supplies global banks, the US government or European supply chains will be pulled along by their deadlines.

Dates published through mid-2026. They have been revised, usually earlier.

Where to use it

Data that must last.

Makes sense

Banks, fintechs and insurers: contracts, transactions and data that must stay valid for a decade or more.
Health: records that follow the patient for life.
Regulated suppliers: anyone selling to governments, global banks or European supply chains.

Can wait

Ephemeral data: sessions and minute-long tokens go in the plan, but not at the top.
System about to be retired: if it goes before the deadline, the effort goes to its replacement.
Symmetric cryptography only: AES-256 and good password hashes already resist; the scan confirms and moves on.

Three words from this page

Cryptographic inventory

The list of where cryptography lives in the system, of what kind, and what it protects.

Record now, decrypt later

Recording encrypted traffic today to decrypt it once the quantum computer exists.

Hybrid mode

Using the old and new locks at the same time during migration, so as not to break whoever hasn’t updated.

Limits

Where this could be wrong.

The quantum computer’s date is an estimate

Nobody knows the year. Public estimates range from the end of this decade into the 2030s, and they move. That is why the specimen lets you change it.

The scan finds what is visible

Code, configuration and declared dependencies. Cryptography inside closed hardware or third-party services shows up as a black box to investigate.

The secrecy horizon is a business decision

Mosca’s X doesn’t come from the code: someone has to say how long each piece of data matters.

Regulatory deadlines move

The dates cited are those published through mid-2026 and keep being brought forward.

Does your cryptography survive a quantum computer?

The scan is the first step: knowing exactly what needs to migrate, in what order, and what it costs. The free 24-hour assessment shows where to start.

Request the assessment Talk to Stickybit