In five steps: find all your cryptography, rank it by risk, move the most exposed parts to hybrid post-quantum algorithms first, then to the NIST standards ML-KEM and ML-DSA, and keep checking so it does not come back. For most organisations this is a multi-year programme, which is why it starts with an inventory rather than a rewrite.
1. Inventory your cryptography
You cannot migrate what you cannot see. RSA and elliptic curves appear in far more places than your own code:
- libraries and dependencies,
- TLS settings and certificates on every endpoint,
- SSH keys, VPNs and internal service-to-service connections,
- cloud key-management services, databases and message queues,
- signed tokens (JWT), code signing and firmware.
The result should be a machine-readable inventory, ideally a CBOM, not a spreadsheet that is out of date the week it is finished.
2. Rank it by exposure
Not all RSA is equal. RSA on a public login endpoint protecting long-lived customer data matters far more than RSA in a test fixture. Rank each finding by where it runs, what it protects, and how long that data must stay secret. Start with what an attacker could be recording today — see harvest now, decrypt later.
3. Go hybrid first
A hybrid combines a classical algorithm with a post-quantum one, so security never rests on the new algorithm alone. For key exchange, the usual choice is X25519 with ML-KEM-768, already the default in major browsers. Hybrid mode lets you move now without betting everything on algorithms that have had less real-world scrutiny than RSA.
4. Move to the NIST standards
- Key exchange and encryption: ML-KEM (FIPS 203). See What is ML-KEM?
- Signatures: ML-DSA (FIPS 204), or SLH-DSA (FIPS 205) where a conservative, hash-based scheme is preferred.
- Symmetric encryption and hashing: use AES-256 and SHA-256 or stronger.
Design for crypto-agility: keep algorithm choices in configuration, not scattered through code, so the next change is a setting rather than another migration.
5. Keep checking
New code and new dependencies bring RSA back. Scan continuously, fail a build when newly introduced quantum-vulnerable cryptography appears, and keep evidence of progress for auditors.
How long does it take?
It depends on the size of the estate. A single application can move in weeks; a large organisation with many systems and suppliers typically needs years. NIST's draft guidance proposes deprecating RSA and elliptic curves at today's common strength after 2030 and disallowing them after 2035, so the planning needs to start well before then.
How Qopanza helps
Qopanza does each step: it discovers the quantum-vulnerable cryptography across your code, dependencies, TLS endpoints and cloud accounts, ranks it by exposure, turns it into a migration plan you can approve and track, provides ML-KEM, ML-DSA and SLH-DSA (including hybrid mode) through an API and SDKs in nine languages, gates CI on new findings, and exports a CycloneDX CBOM and audit evidence. Book a demo or start at qopanza.com.