There's a comforting moment in every post-quantum project. The library is updated, the key exchange says ML-KEM-768, the ticket is closed. Done.

Except it isn't. You've replaced one lock. You haven't checked the windows, the seal on the letters, or whether anyone kept an inventory of the other locks.

People in the industry have started calling this the difference between PQC migration and PQC transformation. Migration swaps algorithms. Transformation swaps algorithms and rebuilds the verification, visibility and trust around them. Most vendors stop at the first one.

Migration is the algorithm. Transformation is everything around it.

Migration is necessary and we're not dismissing it. RSA and ECC will fall to a cryptographically relevant quantum computer, and NIST's FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) are the replacements. If you haven't started, start.

But an algorithm is a component, not a security posture. A quantum-safe key exchange protects the confidentiality of a message. It says nothing about whether the message is genuine, whether the token that authorised the request was forged, or whether the certificate at the other end of the connection was minted by someone who broke ECDSA last year.

Transformation asks four questions instead of one: Is it confidential? Is it verifiable? Do I know where all my cryptography lives? And who do I ultimately trust?

Encryption doesn't stop a man-in-the-middle. Verification does.

Harvest Now, Decrypt Later is about confidentiality: an attacker records ciphertext today and reads it when the hardware catches up. ML-KEM closes that door. We wrote about it before, and it's still the most urgent problem for anyone holding data with a long shelf life.

But the same quantum computer that breaks RSA encryption also breaks RSA and ECDSA signatures. That is a different attack with a different consequence. Instead of reading your data later, the attacker impersonates you now. Think about what in a typical stack is protected only by a classical signature:

Access tokens and JWTs — forge one and you don't need to steal a password.
TLS certificates — a forged certificate is a man-in-the-middle with a valid padlock.
Code and firmware signing — a forged signature ships malware as an official update.
Webhooks, API responses and audit logs — the integrity of everything downstream.

If you upgraded the encryption and left signatures on ECDSA, you've sealed the envelope and left the wax stamp forgeable. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) exist for exactly this side of the problem. A real transformation protects both sides.

You can't migrate what you can't see

Ask a CISO where RSA is used in their organisation and the honest answer is "more places than we know". It's in JWT headers, SSH keys, cloud KMS keys, PDF signatures, container registries, vendor SDKs, and that internal tool from 2017.

This is why every serious PQC roadmap — the EU's coordinated roadmap from June 2025 included — puts inventory before migration. The first milestone isn't "be quantum-safe". It's "know your crypto estate": which algorithms, which key sizes, which systems, which data lifetimes. Without it, you'll migrate the visible 60% and get breached through the 40% nobody listed.

Cryptographic inventory isn't glamorous. It's also the step that decides whether a transformation is real or cosmetic.

What a full transformation looks like

Put together, four layers — each one is necessary, none is sufficient on its own:

Confidentiality — ML-KEM key encapsulation wrapping AES-256-GCM for data at rest and in transit. This is the HNDL defence.
Verification — ML-DSA or SLH-DSA signatures on tokens, documents, artefacts and messages, so tampering and impersonation fail even against a quantum adversary.
Trust anchors — keys generated from real quantum entropy, issued and verified by infrastructure under a jurisdiction you can rely on. Zero-trust means every layer is post-quantum, not just the transport.
Inventory — a live view of which algorithms, keys and systems are in play, so the migration is measurable and nothing is missed.

Where QuantumAPI stands — honestly

Here is what is in production today. QuantumAPI encrypts and decrypts with ML-KEM-512/768/1024 wrapping AES-256-GCM, and signs and verifies with ML-DSA-44/65/87 and SLH-DSA. QuantumID issues access tokens that carry an ML-DSA-65 proof alongside the classical signature, so PQC-aware clients can verify both. QuantumVault stores secrets, keys and certificates under the same ML-KEM hybrid encryption, and its transit engine signs with ML-DSA. Keys are seeded from real quantum hardware, with automatic fallback. Everything runs on European infrastructure, under EU jurisdiction, charged by usage — never per user.

And here is what is not shipped yet. A cryptographic inventory dashboard, so you can see your algorithm estate at a glance, is on our roadmap and not in the product. Signed API responses are planned, not live. We'd rather tell you that than put a tick in a table.

If you're planning a post-quantum project, plan a transformation, not a migration. Start with both sides — encryption and verification — and demand an inventory from whoever you work with. You can try the encryption and signing endpoints on the free plan today at quantumapi.eu, and the documentation at docs.quantumapi.eu shows exactly what each algorithm does.