May 2026
PQC theatre — what's not post-quantum even when it claims to be.
Most 'post-quantum cryptography' product claims in May 2026 are theatre. Five patterns describe the vast majority of them. Each pattern below cites a public source — vendor blog, vendor doc, or industry write-up. We don't paraphrase; we link to what the vendor itself wrote.
This page is for buyers and engineers who need to verify a PQC claim before signing a contract or wiring a dependency. The four-question test at the bottom is the shortest path to separating real PQC from theatre.
Pattern 1
Hybrid TLS at the edge, classical key material everywhere underneath
The most common pattern. Looks like PQC. Isn't.
The customer-facing endpoint negotiates hybrid X25519+ML-KEM-768 in the TLS handshake. Inside the trust boundary the keys, secrets, signatures, and stored data are still RSA / ECDSA / Ed25519 / AES with classical key wrapping. A harvest-now-decrypt-later adversary has to break the TLS handshake to read traffic, but the key material at rest is unchanged — and that's what an attacker with a CRQC actually wants.
AWS Secrets Manager
Apr 14, 2026 launch announcement. Hybrid PQ-TLS via X25519MLKEM768 added to the Secrets Manager endpoint. The secrets stored under KMS keys remain wrapped with classical RSA / ECC.
source →Google Cloud KMS
Hybrid TLS for the KMS endpoint enabled. ML-KEM key encapsulation for software keys is in preview; ML-DSA / SLH-DSA signatures still preview as of April 2026 (vendor's own status page).
source →Cloudflare TLS posture
Public Cloudflare data shows 60%+ of human TLS traffic now hybrid ML-KEM at the handshake. Authentication signatures (the part that matters for forgery) remain mostly classical until ML-DSA-to-origin lands mid-2026.
source →How QNSP handles this
Transport security is necessary but not sufficient. If your auditor asks 'are these secrets quantum-safe in storage?' the honest answer for a hybrid-TLS-only deployment is no. QNSP's vault stores payload material under PQC envelope encryption (ML-KEM-768 by default, ML-KEM-1024 on the maximum tier) — the bytes on disk are quantum-safe, not just the bytes on the wire.
Pattern 2
Experimental flags / preview-grade APIs marketed as 'PQC support'
Vendor docs say 'not for production'. Sales decks don't.
PQC is named in the product brochure but the implementation lives behind an explicit experimental gate, with no SLA, no rollback story, and no commitment to API stability. A buyer reads the brochure and assumes the feature is available; the engineer who tries to use it discovers a beta toggle.
HashiCorp Vault Transit (ML-DSA)
Vault Enterprise 1.19 added ML-DSA in Transit, flagged experimental in the official PQC plans blog. The roadmap blog itself sets expectations: SLH-DSA next, all post-NIST-final, all opt-in.
source →GCP Cloud KMS signatures
ML-DSA / SLH-DSA signature support documented as 'preview' in Google's announcement. Software-key only at preview; HSM-backed PQC depends on Marvell LiquidSecurity firmware that is itself in MIP/IUT.
source →How QNSP handles this
QNSP ships PQC at the GA tier across vault, KMS, audit signing, edge TLS, and SDK activation. There is no 'PQC mode'; PQC is the default. Free-tier customers get ML-KEM-768 + ML-DSA-65; the strict / maximum / government crypto-policy tiers narrow the algorithm allow-list rather than enabling features that were previously off.
Pattern 3
Consultancy-as-PQC — services repackaged as a runtime
Discovery + roadmap + advisory. No keys, no signatures, no execution.
A vendor announces a 'quantum-safe partnership' or 'PQC readiness program'. The deliverable is a multi-quarter assessment, a Cryptographic Bill of Materials produced by manual review, and a roadmap document. None of it runs cryptography. None of it produces a new key, signs a new payload, or wraps a new secret. The customer pays seven figures for a Word doc.
Entrust + IBM partnership
Apr 29, 2026 announcement. Joint go-to-market for 'quantum-safe discovery and advisory'. The deliverable is assessment + roadmap; runtime crypto remains whatever the customer already had.
source →Palo Alto Networks + IBM
Earlier 2026 partnership for 'enterprise-wide quantum-safe readiness'. Same shape: assessment + roadmap + advisory.
source →QuSecure QuProtect R3
Positioned as a PQC orchestration / overlay layer; verify against the vendor's product surface whether the runtime executes KEM/signature/vault/audit operations or coordinates upstream systems that do.
source →How QNSP handles this
QNSP is a runtime, not a deck. The /api/sandbox/pqc-runtime endpoint runs a real ML-KEM-768 keygen + encap + decap on every request — anyone can curl it, no signup, no key. The Crypto Inventory (CBOM) service is automated discovery + readiness scoring, but the keys are real and the PQC operations are real.
Pattern 4
Sub-NIST parameter sets and non-finalist algorithms
Calling Kyber-512 'PQC ready' when NIST's recommended floor is 768.
Some vendors implement only the smallest parameter sets or non-finalist alternatives because they're cheaper to integrate. The marketing says 'post-quantum cryptography'. The implementation ships at security category 1 (~AES-128 equivalent) when the customer's threat model wants category 3 or 5.
Embedded / IoT vendors (industry-wide)
Multiple embedded PQC vendors ship Kyber-512 or non-NIST candidates in resource-constrained firmware. PQShield's UltraPQ is the legitimate exception — proven param sets in sub-5KB libraries, NIST-conformant.
source →How QNSP handles this
QNSP exposes 89 algorithm implementations across 14 PQC families (verified in packages/cryptography/src/providers/liboqs.ts). All three NIST-finalized algorithms in three security categories: ML-KEM-512/768/1024, ML-DSA-44/65/87, SLH-DSA in 8 variants. Customers who need category 5 (~AES-256-equivalent) get it; the government crypto-policy tier enforces it.
Pattern 5
'PQC HSM' that isn't FIPS 140-3 + PQC validated
Validation pending isn't validation.
HSM vendors ship firmware that includes ML-KEM and ML-DSA primitives, then market the HSM as 'FIPS 140-3 PQC-validated'. As of May 2026 no HSM has actually completed FIPS 140-3 validation with PQC algorithms in scope — they're all in MIP (Modules In Process) or IUT (Implementation Under Test). The validation that customers think they're buying does not yet exist.
Thales Luna v7.9 firmware
Firmware claims ML-KEM/ML-DSA support. FIPS 140-3 + PQC validation status: in NIST's MIP queue, not yet validated.
source →Entrust nShield v13.8
NIST CAVP-validated for the algorithms (algorithm conformance). FIPS 140-3 module validation including PQC: not yet. CAVP and CMVP are different programs.
source →How QNSP handles this
QNSP integrates with Thales Luna, Entrust nShield, AWS CloudHSM, and Azure HSM via PKCS#11. The QNSP marketing copy never claims customer's HSM is FIPS 140-3 + PQC validated — that's the HSM vendor's claim to make, when their CMVP submission completes. Until then the customer's posture is 'PQC operations executed by HSM with FIPS 140-2 / 140-3 validation pending PQC scope'. We won't put words in the HSM vendor's mouth.
The four-question test
A 90-second PQC vendor verification
Run these four questions against any vendor making a PQC claim. If the answer to any of them is the right column, the claim is theatre.
| Ask the vendor | Real PQC answer | PQC theatre answer |
|---|---|---|
| Where is the PQC actually executed — handshake only, or all the way through to the bytes on disk? | All the way through: TLS handshake + KEM-wrapped data keys + PQC signatures on long-lived assertions + PQC-signed audit chain. | TLS handshake only. The bytes underneath are still RSA / ECDSA / AES under classical wrap. |
| Is PQC behind an experimental flag, a preview gate, or part of the GA product? | GA. No flag, no preview enrollment, no SLA carve-out. PQC is the default; the strict tiers narrow the allow-list rather than enabling features. | Experimental / preview / opt-in beta toggle. Vendor's own docs say 'not for production'. |
| Does the PQC story include a runtime, or is it a deck? | A runtime. Real keys, real signatures, real wrap operations on customer payloads. Verifiable with curl and a test API key. | A discovery + roadmap engagement. The deliverable is a Word doc and a remediation plan that runs over multiple quarters. |
| Does the algorithm coverage include all three NIST finalists at all three security categories — and at least one HQC / hash-based fallback? | ML-KEM-512/768/1024, ML-DSA-44/65/87, SLH-DSA at all variants. HQC for cryptographic agility. Hash-based SLH-DSA as the conservative no-lattice-assumption fallback. | ML-KEM-512 only (the cheapest), or non-finalist candidates. No HQC. No hash-based signature option. |
Verify QNSP yourself
No signup, no API key, no waiting
The QNSP PQC sandbox at qnsp.cuilabs.io/#verify-sandbox runs a real ML-KEM-768 + ML-DSA-65 round-trip on every page request. The bytes you see are produced server-side by @noble/post-quantum 0.6.0; the conformance endpoint runs the NIST KAT vectors against every release. None of this is theatre — curl the endpoints, verify the bytes, then decide.