Is AES Quantum-Safe? What to Keep, What to Replace, and QNSI's Required Design

The short answer - and the expensive wrong conclusion

Evidence boundary: any present-tense QNSI product wording below describes source-declared contracts, architecture targets, or vendor-run artifacts-not independently observed production behavior. Conformance artifacts prove only their stated algorithm scope. End-to-end production execution is NOT VERIFIED.

Yes, AES-256 is quantum-safe. Grover's algorithm - the only quantum attack that touches symmetric ciphers - delivers a quadratic speedup, which halves the security level in bits. AES-256 keeps roughly 128 bits of post-quantum margin, which no adversary is brute-forcing. AES-128 drops to a marginal ~64 bits and should be retired for long-lived data. So far, so reassuring.

The expensive mistake is the conclusion teams draw next: “we use AES-256, so we are fine.” A quantum attacker never touches your cipher. They break the RSA or elliptic-curve key transport that delivered the AES key - Shor's algorithm breaks that math outright, at any key length - and your strong cipher then opens with its own key, exactly as designed. QNSI's required design keeps AES-256 for bulk encryption only after genuine PQC key establishment or wrapping. End-to-end Vault, Storage, and transport execution remains NOT VERIFIED.

The 60-second threat model

Two quantum algorithms, two completely different outcomes. Grover speeds up brute-force search against symmetric primitives - AES, SHA-2 - by a square root; doubling the key length restores the margin, which is why AES-256 stays on every post-quantum recommendation list, CNSA 2.0 included.

Shor is categorically different: it efficiently solves the factoring and discrete-log problems underneath RSA, Diffie-Hellman/ECDH, and ECDSA. No key length rescues them. And because of harvest-now-decrypt-later, the deadline is not the arrival of a quantum computer - adversaries record your encrypted handshakes today and unwind them retroactively, so data with a multi-year confidentiality horizon is already inside the risk window.

• Keep: AES-256-GCM for bulk encryption and SHA-384/SHA-512 for hashing - both retain comfortable post-quantum margins.
• Replace: RSA/ECDH key transport with ML-KEM (FIPS 203, finalized August 2024); RSA/ECDSA signatures with ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). FN-DSA remains draft.
• Regulators already assume this split: US EO 14412 (June 2026), CNSA 2.0 (new national-security systems from January 2027), DORA, PCI DSS 4.0, MAS TRM, and PDPA all point the same direction.

QNSI's required AES and PQC split

This split requires fleet-wide changes to storage, secrets, key management, and transport. QNSI source defines the target, but complete deployment execution remains NOT VERIFIED.

The required design uses AES-256-GCM only under genuine PQC-established or wrapped keys for Storage, search, and Vault, with PQC-native transport. The KMS source catalog contains 87 PQC algorithms - 24 KEMs and 63 signatures across 13 families - but catalog presence does not prove end-to-end execution.

The unexecuted snippet below illustrates the intended SDK contract; route reachability and cryptographic execution remain NOT VERIFIED:

import { QnsiClient } from "@heossihq/qnsi";

const client = new QnsiClient({ apiKey: process.env.QNSI_API_KEY });

// Source-linked call shape; PQC envelope execution is NOT VERIFIED.
await client.storage.putObject("contracts", "msa-2026.pdf", {
  data: fileBytes,
  contentType: "application/pdf",
});

// Plaintext handling and PQC envelope execution are NOT VERIFIED.
const [bytes] = await client.storage.getObject("contracts", "msa-2026.pdf");

Your migration list, mapped to QNSI features

Each step below maps to source contracts or architecture targets. Complete deployment execution remains NOT VERIFIED:

1. Find RSA, ECDH, and ECDSA dependencies through QNSI's source-defined 11 cloud-vendor connector families and 36 inventory source types, then export CycloneDX. Complete connector execution and estate coverage remain deployment-specific.
2. Keep AES-256 for bulk data only after genuine PQC key establishment or wrapping. Vault and Storage migration plus existing-DEK rewrap remain incomplete and NOT VERIFIED.
3. Replace key transport - mint ML-KEM keys in QNSI KMS and govern them with rotation policies, BYOK import, capability-gated BYOHSM connectors (8 implementations), and the current escrow route, which is not threshold recovery and is not presented as available. Named hardware remains unavailable until its qualification evidence passes.
4. Plan what must change - QNSI's migration control plane maps discovered assets to policy-selected targets, governed execution modes, approvals, cutover confirmation, reconciliation, and evidence. Cryptographic transformation remains subject to the capability of the selected source and destination provider.
5. Enforcement target - policy source pins allowed algorithms and defines audit/evidence contracts. Complete operation coverage, event ingestion, pack provenance, and deployment behavior remain NOT VERIFIED.

Start now

Use independent evidence-not a successful response-to evaluate whether AES keys are genuinely PQC-established or wrapped. The QNSI workspace exposes evaluation surfaces, but Storage envelope execution remains NOT VERIFIED.

Scoping a fleet-wide migration? Talk to a QNSI architect at /contact - bring your longest-lived data and we will map the keep/replace split against it.