The short answer
Yes, AES is quantum-safe — with one important caveat about key length. AES-256 retains roughly 128 bits of effective security against a quantum adversary, which is well beyond any feasible attack. AES-128 drops to about 64 bits of effective security, which is marginal and should be phased out for long-lived data. The reason is Grover's algorithm: against symmetric ciphers and hash functions it provides only a quadratic speedup, effectively halving the security level in bits — not breaking it outright.
The trap is what people conclude from this. "We use AES-256, so we're fine" is the single most common — and most dangerous — misconception in post-quantum readiness. Your bulk encryption is almost certainly the part of your stack that is least exposed. The part that breaks is how you exchange the AES key in the first place, and how you sign and authenticate. That is asymmetric cryptography, and it does not survive a sufficiently large quantum computer.
Two different quantum algorithms, two completely different effects
Most confusion about quantum risk comes from conflating two distinct algorithms that attack two distinct kinds of cryptography. They are not interchangeable, and the difference is the entire story.
Grover's algorithm speeds up brute-force search. Against a symmetric primitive — AES, ChaCha20, SHA-2 — the best it can do is square-root the search space. That is why doubling your key length restores your margin: AES-256 against Grover is comparable to AES-128 against a classical attacker, which nobody is worried about.
Shor's algorithm is categorically different. It does not brute-force anything. It efficiently solves the integer-factorization and discrete-logarithm problems that RSA, Diffie-Hellman / ECDH, and ECDSA / RSA signatures are built on. A cryptographically-relevant quantum computer (CRQC) running Shor would not weaken these schemes — it would break them. There is no key length that saves RSA or elliptic-curve cryptography from Shor; the underlying hard problem simply stops being hard.
- Grover → symmetric (AES, hashes): quadratic speedup, mitigated by larger keys. AES-256 stays safe.
- Shor → asymmetric (RSA, ECDH, ECDSA): efficient break, no key length rescues it. This is the real threat.
- Net: the quantum threat is primarily to KEY EXCHANGE and SIGNATURES, not to bulk symmetric encryption.
So where does your data actually break?
Picture a typical TLS session or an encrypted file at rest. The payload is encrypted with a symmetric cipher — usually AES-256-GCM. That symmetric key is itself negotiated using an asymmetric key-exchange (ECDH in modern TLS) and the parties authenticate each other with signatures (ECDSA or RSA). The AES layer is the strong link. The key-exchange and signature layers are the ones Shor dismantles.
An adversary with a CRQC does not need to attack your AES-256 ciphertext directly. They recover the session key by breaking the ECDH handshake that established it, and then the AES layer opens with the correct key — exactly as designed. Your strong symmetric encryption protects nothing once the key that fed it has been recovered through the broken asymmetric exchange.
Harvest now, decrypt later: why the deadline is already here
There is a common objection: "a CRQC doesn't exist yet, so this is a future problem." For confidentiality, that reasoning is wrong, and the reason has a name — harvest now, decrypt later (HNDL).
An adversary can record your encrypted traffic today, store it cheaply, and wait. The moment a CRQC capable of running Shor at the necessary scale exists, every captured ECDH/RSA handshake can be unwound retroactively and the AES keys recovered. Data you transmit this year with classical key exchange is therefore already at risk if its confidentiality needs to outlast the arrival of a CRQC.
The practical question is not "is a quantum computer here?" It is "how long does this data need to stay secret?" For financial records, health data, defense communications, long-lived credentials, and anything under multi-decade regulatory retention, the answer routinely exceeds any reasonable CRQC timeline. That is the data you migrate first.
What the standards bodies have actually finalized
The migration path is no longer speculative. NIST finalized the first set of post-quantum standards in August 2024, and they are the algorithms you should be planning around — stated precisely, without overclaiming what is and isn't final.
These cover exactly the two functions Shor threatens: key establishment (a KEM) and digital signatures. They do not replace AES; AES-256 remains a recommended symmetric cipher in the post-quantum era.
- FIPS 203 — ML-KEM (the key-encapsulation mechanism, derived from Kyber). Finalized August 2024. This replaces classical key exchange.
- FIPS 204 — ML-DSA (lattice-based signatures, derived from Dilithium). Finalized August 2024.
- FIPS 205 — SLH-DSA (stateless hash-based signatures, derived from SPHINCS+). Finalized August 2024.
- FIPS 206 — FN-DSA (Falcon-based signatures). Draft pending, not yet finalized.
- HQC — selected by NIST in March 2025 as a backup KEM based on a different hard problem, but not yet a finalized FIPS standard.
What to actually do
The fix follows directly from the threat. You do not rip out AES. You replace the vulnerable asymmetric layers and, where appropriate, run them alongside the classical ones during transition.
The recommended approach for key exchange is hybrid: combine a classical primitive (such as X25519) with a post-quantum KEM (ML-KEM) so the session is secure as long as either component holds. Hybrid protects you against both a future CRQC and any undiscovered weakness in the still-young PQC implementations — you are strictly no worse off than today, and quantum-safe on top.
- Inventory your cryptography first. You cannot migrate what you cannot see — find every use of RSA, ECDH, and ECDSA across services, certificates, and protocols.
- Migrate key exchange to hybrid ML-KEM (e.g. X25519 + ML-KEM-768). This is the highest-priority change because of HNDL.
- Migrate signatures to ML-DSA or SLH-DSA where long-term verifiability matters (firmware signing, document signing, code signing).
- Keep AES-256-GCM for bulk encryption and SHA-384/SHA-512 for hashing — they remain safe.
- Retire AES-128 for any data with a long confidentiality lifetime; standardize on AES-256.
Why "just swap a library" understates the work
The algorithms are the easy part. The hard part is operational: discovering every cryptographic dependency, choosing the right algorithm per data class and regulatory regime, rotating keys without downtime, proving to auditors that the new implementations are correct, and maintaining a defensible inventory as standards evolve.
This is where most teams stall. A single ML-KEM call is a few lines of code; a fleet-wide, audit-ready, policy-governed migration across dozens of services is a platform problem. That gap is the reason a managed PQC platform exists.
How QNSP delivers post-quantum key exchange
QNSP is the flagship post-quantum cryptography platform from CUI Labs (CUI LABS PTE. LTD., Singapore). It is built to close the operational gap above — not just to expose PQC primitives, but to make a real, auditable migration practical.
On algorithm breadth, QNSP supports 90 PQC algorithms across 14 families — 27 KEMs and 63 signatures — so you can match the exact algorithm to the data class and compliance regime rather than being locked to a single curve. Key exchange uses ML-KEM (FIPS 203) and can be run in hybrid mode; signatures use ML-DSA (FIPS 204) and SLH-DSA (FIPS 205).
Correctness is not asserted, it is shown. QNSP runs a dual-provider architecture: a native-C engine (liboqs) as the primary production provider and a pure-JavaScript reference (@noble/post-quantum) as an independent cross-verification secondary. Two implementations of different lineage independently producing the same result is the practical defense against a single-library bug becoming a silent cryptographic failure.
Governing the migration, not just running the math
Algorithm choice should be a policy, not a per-developer decision. QNSP exposes crypto-policy tiers — default, strict, maximum, and government — that constrain which algorithms a tenant may use, so a regulated workload can be locked to, for example, FIPS-finalized algorithms only, enforced centrally rather than by code review.
To answer "where is RSA still in use?", QNSP generates a CBOM (Cryptographic Bill of Materials) — an inventory of your cryptographic assets that turns migration from guesswork into a tracked checklist. Combined with managed KMS, a PQC-encrypted vault, and audit trails, it gives the evidence an auditor actually asks for.
You can evaluate all of this without a commitment: QNSP has a free-forever tier (10 GB storage, 50,000 API calls, 20 KMS keys, 25 vault secrets) and SDKs across five languages, so engineers can run real post-quantum operations against the same production engine before any procurement conversation.
Where QNSP fits in the market
The PQC vendor landscape spans pure research and advisory firms, hardware and HSM-centric vendors, and cloud-provider key services. QNSP's differentiator is being a full managed platform — KMS, vault, encrypted storage and search, crypto policy, and CBOM — paired with broad algorithm coverage and publicly verifiable conformance evidence, rather than a single primitive or a consulting engagement.
If you are comparing options, the honest move is to check the evidence yourself. QNSP maintains side-by-side comparison pages and a public conformance harness so the claims here can be checked against vendor positioning directly.
- vs PQShield (/compare/pqshield) — IP/hardware and library focus vs QNSP's full managed platform.
- vs QuSecure (/compare/qusecure) — orchestration positioning vs QNSP's algorithm breadth plus published conformance.
- vs AWS KMS (/compare/aws-kms) — cloud key service vs a dedicated PQC platform with CBOM and crypto-policy governance.
Bottom line
AES-256 is quantum-safe; AES-128 is marginal for long-lived data. Grover only halves symmetric security in bits, which a 256-bit key absorbs comfortably. The real, immediate exposure is key exchange and signatures — RSA, ECDH, and ECDSA — which Shor's algorithm breaks outright, and which harvest-now-decrypt-later puts on the clock today, not in some indefinite future.
The correct response is to keep your strong symmetric encryption and replace the asymmetric layers with hybrid ML-KEM for key exchange and ML-DSA / SLH-DSA for signatures, governed by policy and backed by a cryptographic inventory. That is precisely what QNSP, the flagship PQC platform from CUI Labs, is built to deliver — with conformance evidence you can verify rather than take on faith.