Every post-quantum migration plan begins with the same problem: nobody knows what they are running. Not through carelessness, but because cryptographic choices accumulate over a decade across teams, acquisitions, vendors, and appliances nobody has logged into since 2019.
Here is a practical order of operations.
1. Start outside-in
Begin with internet-facing services. Not because internal systems do not matter, but because external assessment needs no agents, no credentials, and no change control — so it can start today rather than after a quarter of planning.
It also matches the attacker's view. Anything an external scan finds is something an adversary can find, and traffic to those endpoints is what is being recorded for harvest now, decrypt later.
Expect surprises. The forgotten VPN appliance, an acquired company's marketing site, a staging environment never taken down — these turn up in essentially every estate.
2. Capture what is negotiated, not what is configured
A configuration file says what a server can do. It does not say what it does.
Servers commonly support a hybrid post-quantum group but still prefer a classical one, in which case ordinary clients receive no protection. Others accept weak cipher suites when a client offers nothing else, despite never selecting them in practice — static-RSA suites with no forward secrecy turn up on major, otherwise well-run sites.
Inventory what is actually negotiated on the wire.
3. Classify by retroactive decryptability
Sort findings by whether they can be attacked retroactively. This single distinction does more for prioritisation than any generic severity score:
- Key exchange — retroactively decryptable. Urgent.
- No forward secrecy — worst case; one key opens every recorded session.
- Certificate signatures — not retroactively forgeable. Report, do not panic.
- Symmetric algorithms — largely fine at 256-bit.
4. Then work inward
Once the external picture is stable, extend to internal service-to-service traffic, data at rest, code signing, and HSMs. This is slower and needs access, which is precisely why it should not block starting.
5. Make it repeatable
A point-in-time inventory is stale within a deployment cycle. What matters is a CBOM that regenerates, so posture is tracked rather than re-discovered.
Measurable progress is also what turns a migration from an open-ended engineering project into something reportable to a board or a regulator.