The No-Hype PQC Guide
What Security Leaders
Actually Need to Know
Quantum cryptanalysis is a well-established mathematical approach and poses a future threat due to the lack of programmable, scalable quantum computers. Sharing and collaborating with unprotected data and AI systems ingesting unencrypted enterprise data are a present threat. Post-quantum migration is not only about upgrading cryptography. It’s about reducing the amount of sensitive data already exposed in applications, SaaS platforms, documents, and AI pipelines and workflows today.
June 2026
Author
Karim Eldefrawy
Co-founder & CTO, Confidencial.io
25+ years in cybersecurity and cryptography. 100+ published scientific works. Latest Forbes piece on Post Quantum "Harvest Now, Read Now: The Immediate Overlooked Risk Beneath The PQC Discussion."
Introduction
Most post-quantum cryptography discussions focus on a future problem: how to protect encrypted data once large enough quantum computers can break today’s public-key cryptography using established algorithms, e.g., Shor’s algorithm.
But many organizations are overlooking the more immediate issue. Sensitive enterprise data is already broadly exposed inside documents, SaaS platforms, collaboration tools, and AI workflows — often in readable plaintext once perimeter defenses fail.
Performing quantum cryptanalysis at scale is a future threat. Sharing and collaboration tools and AI pipelines ingesting unencrypted enterprise data is a present one.
This guide is designed for security leaders who already understand the conceptual quantum risk and now need practical guidance on what to do, in what order, and under what timeline.
The goal is not to predict the exact quantum timeline. It is to help organizations reduce exposure while building toward long-term cryptographic agility.
Before we dive into details, we have to acknowledge that post-quantum cryptographic schemes are relatively new and some in the community voice legitimate concerns over that. The NIST FIPS-203 standard itself acknowledges in its abstract that there is no well-established definitive mathematical proof of security and that “At present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.” The words “at present” and "believed" are deliberately chosen. This is not unique to the PQC schemes, though. Even classical cryptographic schemes that are as factoring (e.g., RSA) and discrete logarithm (e.g., ECDSA, ECIES) have security that also relies on hardness assumptions and beliefs of these underlying mathematical problems. The difference is that, for factoring and discrete logarithms, we have decades of cryptoanalysis that have strengthened collective confidence in their classical security (not quantum, though, because Shor's algorithm can break them). A reasonable hedge against the recency and the lack of decades of cryptoanalysis on such quantum-safe assumptions and schemes is to combine them with classical ones in what are called hybrid schemes. The idea is that, even in the short term, the classical scheme may protect the data if the quantum scheme is weakened, but this approach falls short in the long term, as the classical scheme could eventually be broken if the encrypted data is harvested.
CHAPTER 1: Timeline
Stop Waiting for Permission to Act
Post-quantum cryptography timelines: when do organizations actually need to act?
An answer that is pegged to quantum hardware timelines is ill-informed and shortsighted - cryptographically relevant quantum computers arriving somewhere between 2030 and 2035. That framing is both accurate and nearly irrelevant to the decision security leaders face today.
The decision isn't about when to finish migration. It's about when to start planning and executing it. Infrastructure-layer PQC migration (TLS updates, PKI overhauls, HSM upgrades) will probably take 5 to 10 years in most enterprise environments. If you start when the threat becomes undeniable, you won't finish in time.
Two developments in early 2026 made this question harder to ignore. In March, Google accelerated its internal PQC migration deadline to 2029, citing advances in quantum hardware and error correction. Days later, Caltech researchers published findings suggesting that Shor's algorithm could be executed with roughly 10,000 physical qubits — a dramatic reduction from prior estimates requiring millions. Their analysis puts 256-bit elliptic-curve key-breaking at 10 days with 26,000 qubits. Over two decades, qubit requirements for cryptographically relevant factoring have dropped by roughly 10,000x. The community’s experience with cryptanalysis is that once a scheme or primitive is significantly weakened and dramatic reductions in required resources begin to occur, they continue in subsequent years (maybe at a slower rate, but they will continue). It would not be surprising if additional speedups and resource reductions occur over the next 24 months, rendering Google’s timeline prescient.
The US government has previously established migration targets pushing federal systems toward post-quantum readiness by 2035. Auditors are beginning to ask for documented PQC plans by 2026–2027. There are reports as of May 2026 that the US government will soon issue new executive orders to further speed up the PQC adoption timelines.
Content-layer data protection (encrypting the data itself, not just the transmission pipe or underlying storage) can be deployed immediately and doesn't require waiting for infrastructure migration to complete.
Inside the enterprise, encryption becomes your last line of defense. Outside the enterprise, it becomes your first and only line of defense.
Is harvest-now-decrypt-later a real threat or vendor hype?
It's very real. But the framing undersells the actual problem.
Nation-state actors targeting long-lifecycle secrets, such as classified intelligence, IP with 20-year relevance, and M&A deal data, pose a genuine concern. Google explicitly named "store-now-decrypt-later" as a present threat in its 2029 announcement.
But what the harvest-now-decrypt-later narrative misses: most enterprise unstructured data is not even encrypted. Adversaries don't need to harvest and wait. They can harvest and read immediately. Sensitive data sitting in documents, SaaS platforms, collaboration tools, and AI workflows is already readable to anyone who gets through the perimeter. No quantum computer required.
The real issue is not only that quantum systems will be capable of breaking current classical encryption schemes. It is how much sensitive enterprise data is already exposed once it reaches applications and AI workflows today, and how much more will be exposed once more AI is adopted in the coming years. PQC migration is becoming inseparable from data-layer security.
"It's not 'harvest now, decrypt later.' It's harvest now, read now. Why wait for quantum computers? If you get in today, you can already see everything."
CHAPTER 2: Migration
Don't Upgrade What You Haven't Mapped
PQC migration: what to upgrade first and in what order
Start with what you can inventory, not what you can upgrade. The most common and costly mistake is jumping to remediation before knowing what you have. You can't prioritize what you haven't mapped.
The right sequence:
-
Understand your data,
-
Map your cryptographic dependencies,
-
Analyze the algorithms in use, then
-
Prioritize based on sensitivity and exposure window.
Asymmetric encryption and key exchange (RSA and ECDH and ECIES) and weak symmetric primitives (SHA-1 and AES-128) are the most urgent to replace — it's what quantum attacks will break first. Strong symmetric encryption (AES-256) is considered quantum-resistant at current 256-bit key lengths.
What is a Crypto Bill of Materials (CBOM), and why does it matter for PQC?
A CBOM (Crypto Bill of Materials) is an inventory of every cryptographic dependency in your environment: algorithms in use in software, where they're used, what they protect, and what would break if they were compromised or replaced. Think of it as a software BOM, but for cryptography. Without a CBOM, PQC migration planning is guesswork. It's the foundational first step before any meaningful remediation work can begin.
Should organizations upgrade TLS or PKI first?
We argue for PKI first, in most cases, and start using more encryption. For many enterprises, it's the more complex long-term migration challenge. PKI certificates have longer validity windows, touch more systems, and have slower replacement cycles. A certificate infrastructure that isn't crypto-agile will become a bottleneck for everything else. Hybrid TLS approaches — running classical and post-quantum key encapsulation in parallel — are already available and are a reasonable interim step while PKI migration is underway.
The more important point: TLS secures data in transit. It does not inherently protect the content itself once it is received, processed, copied, stored, or consumed by applications and AI systems. When organizations say "our data is encrypted," the right follow-up question is: encrypted where, to whom, with what schemes, and secure until when?
What is crypto agility, and why does it matter for post-quantum migration?
Crypto agility is the ability to update cryptographic schemes and algorithms across your environment without having to rebuild everything that depends on them. Systems with crypto agility can, for example, transition from RSA-KEM to ML-KEM without re-architecting dependent applications. Systems without it will require full rewrites or will be left behind. Every new system deployed today should be built with algorithm flexibility as a non-negotiable requirement, not bolted on later.
"Crypto inventory is foundational. Without it, you're guessing. The first step is knowing what data you have and how it's protected. Everything else depends on that."
CHAPTER 3: Performance
The Present-Day Risk Hidden in Your AI Stack
Does post-quantum cryptography affect performance and compatibility?
For some algorithms, yes — there's a real performance cost, and it's not uniform. ML-KEM (the NIST-standardized key encapsulation mechanism) has strong performance characteristics and has been designed with practical deployment in mind. ML-DSA has larger signature sizes compared to ECDSA and RSA, which can increase bandwidth requirements in high-volume environments. For most enterprise applications involving humans, the performance delta will be imperceptible to such end users. Industrial and cyber-physical systems, high-frequency trading, real-time communications, and other constrained environments with limited compute warrant careful benchmarking before committing to a migration path.
Will AI systems make data exposure worse during PQC migration?
Yes. This is the most under-appreciated risk in the current conversation. AI copilots, assistants, and agents do not merely transport data. They ingest it, summarize it, transform it, correlate it, and act on it across systems and clouds. If the content in the data layer remains broadly visible in plaintext, AI amplifies not just productivity but exposure: more access paths, more machine identities, more derived outputs, more places where sensitive information can leak.
In March 2026, an AI agent at Meta answered an internal engineering question with instructions that exposed sensitive data to engineers internally for roughly two hours, triggering a major security alert. No attacker was involved. The data was simply readable, and the AI gave instructions that revealed it to unauthorized users.
Quantum cryptanalysis is a future threat. AI pipelines ingesting unencrypted data is a present and very real one. Data-layer protection — selective encryption applied at the content level, is the control that addresses both simultaneously.
Will HSMs support post-quantum cryptography standards?
Major HSM vendors are actively adding PQC support. As of NIST's 2024 finalized standards, Thales, Entrust, AWS CloudHSM, and others have published PQC roadmaps or early support. For HSMs that require hardware replacement rather than firmware updates, that lead time needs to factor into migration planning now. Content-layer encryption does not depend on HSM readiness and can deploy independently of infrastructure migration timelines.
CHAPTER 4: Vendor Skepticism
How to Read Vendor Claims Without Getting Burned
What does "quantum-safe" actually mean, and how to spot PQC-washing
"Quantum-safe," "quantum-ready," "quantum-resistant," and "post-quantum" are used interchangeably in vendor marketing. They do not mean the same thing.
Quantum-safe:
-
Quantum-safe should mean: algorithms resistant to attacks from both classical and quantum computers, aligned with NIST's finalized PQC standards. The best source is NTST’s own PQC page.
-
A great reference is the NSA PQC FAQ, especially the part about other advanced cryptographic schemes:
-
"Q: What algorithms should I use for other areas of cryptography (e.g., Blockchain, Private Information Retrieval, Identity Based Encryption)?
-
A: NSA wants to know about potential use cases for any of the innovative cryptography listed below (or other similar cryptographic innovation). CNSSP 15 mandates using public standards, while allowing exceptions for additional NSA-approved options when needed. Neither NSA nor NIST has produced standards for these areas, and NSA has not issued any general approval for using these technologies on NSS.
Many of these topics involve novel security properties requiring further scrutiny. NSS owners should consult NSA before using any cryptography that CNSA 1.0 or CNSA 2.0 and other published guidance do not specify. In particular, the following have no generally approved solutions:-
Distributed ledgers or blockchain
-
Private information retrieval (PIR)
-
Private set intersection (PSI)
-
Identity-based encryption (IBE)
-
Attribute-based encryption (ABE)
-
Homomorphic encryption (HE)
-
Group signatures
-
Ring signatures
-
Searchable encryption
-
Threshold signatures
-
-
-
Quantum-ready:
-
Quantum-ready often means: we have a plan, or we can theoretically update our software when standards are finalized.
The tells of PQC-washing: vague claims with no algorithm specifics; "ready" language with no published roadmap; protection that only applies to data in transit; no answer to what happens when data leaves the system. Vendors doing real work will name the algorithm, show where in the stack it's applied, and be honest about what's shipping versus what's still in progress.
Five questions to ask every vendor claiming post-quantum security
1
How is the data protected? Which algorithm, which implementations and libraries?
2
When is it protected? In transit only? At rest? At the content layer?
3
Who is it protected for? Does protection persist when data moves outside your environment?
4
How will PQC be enabled? Firmware update? API change? Full re-architecture?
5
How will PQC keys themselves be protected? Is the root of protection tied to a Hardware Security Module (HSM) or Cloud Key Management Systems (KMS)?
What are the NIST post-quantum cryptography standards?
NIST finalized three post-quantum cryptographic standards in August 2024:
-
ML-KEM (FIPS 203) — Key encapsulation, replacing RSA/ECDH for key exchange
-
ML-DSA (FIPS 204) — Digital signatures, general purpose
-
SLH-DSA (FIPS 205) — Hash-based signatures, conservative alternative
The NIST PQC standardization process is is still ongoing with additional schemes being considered here.
If a vendor claims quantum-safe status without referencing all of these NIST standards, ask why.
"Quantum is a proxy for a much bigger issue: most data is not properly secured. The problem is not future decryption. The problem is present-day exposure."
CHAPTER 5: Vendor Skepticism
What Compliance Actually Requires Right Now
Post-quantum cryptography compliance: what regulations and auditors currently require.
Requirements depend on the sector. As of May 2026:
-
Federal / Defense: Active planning is effectively required. NSA's CNSA 2.0 sets specific timelines, with some systems required to support PQC algorithms by 2027. There are recent indications of upcoming new acceleration by USGOV of timelines.
-
Financial Services: No hard mandates yet, but the SEC, OCC, and FFIEC have all signaled interest. International jurisdictions are moving faster. Quantum risk is appearing in operational resilience frameworks. There are recent indications of upcoming new acceleration by USGOV of timelines that may affect this sector.
-
Healthcare / HIPAA: No specific PQC requirement, but underlying data protection obligations apply — and quantum risk to PHI is entering compliance conversations.
-
Legal / Professional Services: Bar ethics rules require reasonable data security. What "reasonable" means when harvest-now adversaries are active is evolving — firms advising regulated clients are increasingly held to those sectors' standards.
What will auditors expect from organizations on PQC readiness?
In the near term (next 12-18 months), auditors will begin to expect three things: documented awareness that post-quantum risk exists, an assessment of where exposure sits, and a migration roadmap — even if migration is years away. Organizations that have done nothing, have no documented inventory, and cannot articulate a plan are starting to get flagged. Within 2–3 years, as NIST standards become embedded in sector-specific regulatory guidance, expectations will tighten considerably.
What is the minimum viable PQC posture for a security team right now?
NIST finalized three post-quantum cryptographic standards in August 2024.
-
Document that you have assessed and understand the risk. A basic PQC risk assessment is better than silence.
-
Build your crypto inventory (CBOM). Know what algorithms are in use, where, and what they protect.
-
Identify high-sensitivity, long-lifecycle data. Anything that needs to remain confidential for 5+ years is already inside the harvest-now window. Encrypt it at the data layer now — do not wait for infrastructure migration.
-
Have a migration roadmap. It does not have to be finished. It has to exist and be actionable.
"You do not have a quantum problem. You have a data protection problem. Security that does not follow the data is ineffective once the data moves or can be copied at scale."
The right executive question is not only "how do we migrate to PQC?" It's also: where is our sensitive data readable today, and how do we reduce that exposure at the content layer itself?
The quantum threat is accelerating. The 10,000-qubit research, Google's 2029 deadline, and the US government's 2035 mandate are converging signals that the cryptanalytic horizon is approaching faster than most enterprise risk models assumed. But before adversaries can decrypt your data later, they may already be able to read it now.
Data-level protection—selective encryption applied at the content level within documents, other containers, and databases—is the control that closes the present-day exposure gap and puts you in a position to complete the infrastructure migration on a realistic timeline. It can be deployed today. It does not require waiting for other providers and parties to upgrade their cryptography, systems, and networks.
Like what you're reading?
Complete the form to download your own copy.