Quantum Academy
No product is unhackable in any sense a standards body recognizes: NIST’s glossary of security terms has no entry for the word. The top ratings that do exist are numbered levels, such as Security Level 4 in FIPS 140-3, the US federal standard for cryptographic modules, and EAL7, “Formally verified design and tested”, in the Common Criteria, the international scheme for evaluating security products. A vendor who calls a product unhackable usually means something narrower: a security proof under stated assumptions, a module validated against a standard, or an implementation tested by a lab. You can check each of those.
The quantum threat to public-key cryptography is real. NIST states that large-scale quantum computers, if built, “will be able to break many of the public-key cryptosystems currently in use”. NIST published its first post-quantum cryptography (PQC) standards on August 13, 2024.
How security claims are measured
When NIST states a security claim, it names a threat model, the assumptions the claim depends on, and the attacker’s resources, usually an amount of computation. A threat model is a description of who the attacker is and what they can reach. Here are the three parts for ML-KEM-768, the middle parameter set of ML-KEM (Kyber), which NIST standardized in FIPS 203 for establishing shared keys.
| Part of the claim | What NIST states for ML-KEM-768 |
|---|---|
| Threat model | The attacker can submit ciphertexts of their choice and see the results, a model called IND-CCA2 |
| Assumption | Module Learning with Errors, a lattice problem, is hard to solve for classical and quantum computers |
| Attacker’s resources | Security category 3: any successful attack needs computation comparable to or greater than a key search on a block cipher with a 192-bit key, such as AES-192, which has 2¹⁹² possible keys |
Even then, NIST words the result as a belief: ML-KEM is “believed to be secure, even against adversaries who possess a quantum computer.” A vendor who says “unhackable” has stated none of the three parts.
Common Criteria evaluations, defined in ISO/IEC 15408, have the same parts. The vendor’s security target states the threats and the assumptions, and evaluators weigh the attacker’s “expertise, resources, and motivation”. The scheme’s introduction is explicit that the fact a product has been evaluated “has meaning only in the context of the security properties that were evaluated and the evaluation methods that were used.”
Proof versus product
A proof applies to an algorithm or protocol as written. NIST writes in FIPS 203 itself that “conformance to this standard does not ensure that a particular implementation is secure”. A product adds four things that aren’t part of the proof:
- side channels, the physical signals a device gives off while it computes, such as timing and power use
- key handling, meaning how keys are generated, stored, backed up and destroyed
- authentication, the check that the other party is who it claims to be
- operations, such as configuration, patching and access control
In the KyberSlash research, published in 2025, ten researchers showed that several Kyber implementations, “including the official reference code”, leaked secret key information through a timing side channel: the time a division instruction took. They recovered secret keys within minutes for one variant and within a few hours for the other. Maintainers patched the code quickly, and the mathematics of ML-KEM was never in question.
What QKD proofs depend on
Quantum key distribution (QKD) is optical hardware that lets two endpoints establish a shared random key by sending single photons or very weak laser pulses. “Unhackable” turns up often in QKD marketing, and QKD vendors have a real basis for strong language. The authors of ETSI White Paper No. 27 (2018) describe QKD’s security as information-theoretic: it “can be proven based only on models of the local devices operated by legitimate users” and “does not require any assumptions on the resources available to an adversary”.
The condition is the phrase “models of the local devices”. A proof applies to devices that behave exactly as modeled. QKD systems also exchange ordinary messages over a classical channel, which the ETSI authors require to be authentic. The UK’s National Cyber Security Centre (NCSC) notes that “QKD protocols do not provide authentication”, so they must be deployed alongside cryptography that does.
In 2010, researchers reported in Nature Photonics that the detectors in two commercially available QKD systems “can be fully remote-controlled using specially tailored bright illumination”, which let an eavesdropper “tracelessly acquire the full secret key”. Researchers writing in Nature Communications in 2011 described an installed eavesdropper that obtained the entire key from a running QKD connection while “none of the parameters monitored by the legitimate parties indicate a security breach”.
The NSA states the consequence: “The actual security provided by a QKD system is not the theoretical unconditional security from the laws of physics (as modeled and often suggested), but rather the more limited security that can be achieved by hardware and engineering designs.”
Three questions to ask instead
Model and assumptions
Ask which threat model and assumptions the claim depends on. For a PQC product, expect the algorithm, parameter set and security category, such as ML-KEM-768 in category 3. For QKD, expect the protocol, the proof’s assumptions about the devices, and how the classical channel is authenticated. If the reply is a general reference to the laws of physics, ask what an attacker would have to do to obtain a key.
Proof, validation and testing
Ask who proved, validated or tested it. Each kind of evidence has a document you can check:
- A security proof is a published paper. Check which devices and channels its model includes.
- A module validation is a certificate from NIST’s Cryptographic Module Validation Program (CMVP). On each certificate you’ll find the module name, version, security level and tested configuration, and you can search the certificates yourself.
- A product evaluation is a Common Criteria certificate, listed on the Common Criteria portal with its certification report and security target. For QKD hardware, ask about evaluation against ISO/IEC 23837, published in 2023, or ETSI’s Common Criteria protection profile for QKD modules, which Germany’s Federal Office for Information Security (BSI) certified in January 2024.
Key store compromise
Ask what happens when a key store is compromised. A key store is anywhere a key exists in usable form, such as a hardware security module (HSM), a key management server or an encryptor’s memory. A vendor with a straight answer can tell you which keys an attacker would get, what data those keys protect, how you’d detect the compromise and how the keys would be replaced. With forward secrecy, where the system runs a fresh key exchange for every session, an attacker who steals a long-term key can’t decrypt sessions recorded earlier. In a QKD network, count the trusted nodes, the relays that pass a key from one link to the next. Each trusted node has the key in readable form. The NSA links trusted relays to “additional security risk from insider threats”.
Raising it with a vendor
Send the questions in writing before the meeting, framed as your organization’s requirement: “Our risk process requires us to record the assumptions behind each security claim we rely on. Could you send the threat model, any validation or evaluation certificates, and your procedure for a compromised key store?” You’re giving the vendor time to find the engineer who can answer.
“Category 3 under these assumptions, validated at FIPS 140-3 Level 2 in this configuration, and here’s what a compromised HSM would expose” is an answer you can record in a risk register. “We’ll come back to you on that” is fair too, so agree a date. If the datasheet also uses invented phrases such as “quantum-grade”, the four questions in A Field Guide to Misleading Quantum Marketing apply as well.
If reviewing vendor claims is a regular part of your work, PQC Vendor Governance and Supply Chain covers assessing vendor PQC readiness, contractual language for migration obligations and criticality tiering.
Before your next vendor call, write the three questions at the top of the datasheet, then look up any certificate number printed on it in the CMVP search or on the Common Criteria portal. Check that the version and configuration on the certificate match the product you’re buying.