Your encrypted API traffic may be unreadable today.That doesn’t mean it will stay that way.
“Harvest now, decrypt later” describes a real quantum-security concern: adversaries can capture encrypted data today and potentially decrypt it years from now when cryptographically relevant quantum computers become available. Marin Ivezic, founder of Applied Quantum and a former Fortune Global 500 CISO, argues that organizations with long-lived sensitive data should treat this as a risk worth preparing for now.
Here’s the direct answer to what that means: post-quantum cryptography (PQC) is a new class of encryption and signature standards designed to resist attacks from future quantum computers. It matters for API security because nearly every API calls ,a login token, a payment request, an encrypted payload depends on classical public-key cryptography that a powerful quantum computer could break. That gap is why “we’ll deal with it later” is quietly becoming security’s most expensive sentence.
What "Harvest Now, Decrypt Later" Actually Means for APIs
Every API call your business makes a payment authorization, a health record lookup, a partner data sync is protected today by encryption built on math problems that are hard for ordinary computers to solve. A sufficiently powerful quantum computer would solve them easily.
The catch is that an attacker doesn’t need that computer today. They just need to record your encrypted API traffic now and store it. This is a harvest-now-decrypt-later (HNDL) attack: data intercepted today can be decrypted retroactively once quantum computing catches up (Dubey & Varshney, 2026)
For data with a short shelf life, that’s a non-issue. For anything that needs to stay confidential for five, ten, or twenty years, medical records, trade secrets, government data, long-term financial agreements ,it’s a live risk right now, not a future one.
Cryptographer Michele Mosca put a number on that urgency back in 2015: if X (how long your data must stay confidential) plus Y (how long your migration takes) is greater than Z (years until a quantum computer can break today’s encryption), you’re already exposed (Mosca, 2015)
Run the math on a typical API: a healthcare or financial API often needs 10+ years of confidentiality, and enterprise crypto migrations routinely take 5-7 years. Even a conservative 15-year estimate for Z leaves almost no margin which is exactly why “wait and see” stops being a strategy for anything with a long confidentiality window.
The Standards Are Already Finished
This isn’t a hypothetical waiting on research. NIST finalized its first three post-quantum cryptography standards in August 2024, establishing module-lattice-based key encapsulation and digital signature schemes as the foundation for structured migration in government and commercial systems (NIST, via Wikipedia summary, 2024). The three that matter most for API infrastructure:
ML-KEM (FIPS 203) Securing the Connection
A key encapsulation mechanism that replaces RSA and ECDH for establishing encrypted connections is the part of TLS that protects your API traffic in transit (NIST FIPS 203)
ML-DSA (FIPS 204) Securing the Tokens
A digital signature standard that replaces ECDSA and RSA for signing tokens and certificates directly relevant to how your API gateway validates JWTs and OAuth tokens (NIST FIPS 204)
SLH-DSA (FIPS 205) The Backup Plan
A more conservative, hash-based signature scheme held in reserve in case weaknesses are ever found in the newer lattice-based math (NIST FIPS 205)
What the Data Actually Shows
Most articles on this topic cite the standards and stop there. A June 2026 internet-scale measurement study scanned 32,011 live domains across banking, government, defense, cloud, and other sectors specifically to check quantum readiness and the results complicate the “it’s basically handled” narrative:
- 15.70% of domains, concentrated in banking and government, still run on TLS 1.2, a protocol that cannot support modern hybrid post-quantum key exchange at all (Dubey & Varshney, 2026).
- 49.3% of domains now support hybrid post-quantum key exchange (like ML-KEM-768 paired with X25519), while 50.7% still rely on classical-only key exchange a near coin-flip split (Dubey & Varshney, 2026).
- The most important finding for API teams: the study observed 0% adoption of hybrid post-quantum certificates across the entire dataset, meaning certificate-based authentication the layer that underlies API trust and token validation remains completely classical and exposed to future forgery (Dubey & Varshney, 2026).
- Sector-level risk is uneven: BFSI, government, defense, telecom, energy, and legal sectors were all rated high-to-very-high quantum risk, while cloud/CDN, social media, and search sectors were rated low risk due to faster hybrid adoption (Dubey & Varshney, 2026).
Separately, researchers studying how developers actually work with these new algorithms found that despite NIST’s timeline to deprecate classical schemes like RSA and ECDSA by 2035, real-world PQC adoption is slowed by limited developer expertise and inconsistent API documentation a genuine implementation bottleneck, not just a scheduling one (Rathnaikage et al., 2026)
Why Your JWTs and OAuth Tokens Are a Bigger Problem Than Your TLS
Most conversations about quantum risk jump straight to encryption. But API access control has its own exposure. A typical flow where an identity provider issues a JWT, a client sends it, and the API gateway validates its signature using a public key depends entirely on public-key cryptography that quantum computing would undermine. An attacker who can derive a private key from a public one could, in principle, forge valid tokens and impersonate legitimate users, not just eavesdrop on traffic. The certificate-forgery risk flagged above isn’t theoretical; it’s the exact mechanism a compromised signature scheme would enable.
This is a useful distinction to hold onto: encryption is vulnerable to retroactive attacks (harvest now, decrypt later), while signatures are only vulnerable to future forgery; they can’t be faked after the fact. That means key exchange deserves migration priority, but token-signing infrastructure still needs a plan, just on a slightly longer runway.
The three layers matter separately because each defends against a different failure mode: hybrid key exchange protects the session in transit, hybrid signatures stop a forged token even if classical signing is eventually broken, and PQC-derived encryption keeps stored payloads safe from the harvest-now-decrypt-later threat described above.
The Part of Your Stack That's Already Ahead of You
Here’s the twist most internal PQC conversations miss: parts of the internet’s edge have moved faster than most enterprises realize. The hybrid X25519+ML-KEM-768 mechanism is now the default in major browsers including Chrome, Firefox, Safari, and Edge, and is supported in widely used libraries such as OpenSSL 3.5+, Go 1.24+, and Node.js, while Cloudflare and AWS CloudFront have already deployed hybrid post-quantum key exchange across their infrastructure (Dubey & Varshney, 2026).
The gap isn’t the public internet, it’s everything behind it. The hop between your CDN and your origin servers, your internal service mesh, your third-party API integrations, and your identity provider are all still running classical cryptography in most organizations, and almost nobody has a complete inventory of where.
A Realistic Starting Point, Not a Five-Year Program
Security teams researching quantum readiness consistently land on the same first three moves:
Build a cryptographic inventory.
Find every place your APIs, gateways, certificates, and third-party SDKs rely on public-key cryptography. Most organizations discover this list is far longer, and far less documented, than expected.
Move to hybrid cryptography first.
Run post-quantum algorithms alongside classical ones (like ML-KEM paired with X25519) so you gain quantum resistance without losing the fallback protection of proven algorithms.
Ask vendors directly.
Your HSM vendor, certificate authority, and API gateway provider should have a concrete PQC roadmap not a vague assurance. Crypto-agility is now a legitimate line item in vendor security questionnaires.
The Step Before the Migration: Knowing What You're Migrating
Here’s the quiet problem behind that first step. You cannot inventory cryptography on an API you don’t know exists. Most enterprises carry shadow APIs, deprecated endpoints, and partner integrations that never made it into a formal registry and those are exactly the ones still running old TLS configurations and unmanaged certificates.
This is where API discovery tooling stops being a nice-to-have and becomes a prerequisite. Platforms like Prophaze continuously map every API across an environment documented or not, internal, external, or AI-generated and keep that inventory current as the architecture evolves.
For a quantum-readiness program, that living inventory is the foundation everything else sits on: you can’t apply hybrid cryptography, flag weak signature algorithms, or prioritize migration by risk if half your API surface is invisible to begin with. Pairing continuous discovery with runtime API posture management turns “we think we found everything” into an ongoing, verified answer.
Quantum-safe APIs won’t happen through a single upgrade they’ll happen through the same unglamorous discipline that got most enterprises through the SHA-1 and RSA-1024 retirements: find where you’re exposed, build in the ability to swap algorithms without rearchitecting everything, and start now, while the timeline is still yours to control.
If your team is still working from an incomplete API inventory, that’s the place to start not the cryptography itself. See how Prophaze’s continuous API discovery gives you a real-time, verified map of your API surface before you build a migration plan on top of it.
Frequently Asked Questions (FAQ)
1. Is post-quantum API security only relevant once quantum computers exist?
No. The harvest-now-decrypt-later threat means data intercepted today can be decrypted later, so long-lived sensitive data is already at risk.
2. Do post-quantum algorithms slow down APIs?
Somewhat. ML-KEM keys and ML-DSA signatures are larger than their classical equivalents, which adds latency and payload size a real factor to budget for in high-throughput API design, though most implementations remain workable with tuning.
3. Should we migrate encryption or authentication first?
Encryption and key exchange generally come first, since it’s the piece exposed to retroactive decryption. Signature-based authentication (JWTs, OAuth, certificates) can’t be forged after the fact, so it can follow on a slightly longer timeline but current data shows certificate infrastructure hasn’t started moving at all, so it shouldn’t be ignored.
4. What's the single most useful first step?
A cryptographic inventory. You can’t migrate what you haven’t found, and most enterprises don’t yet know where all their APIs and services depend on vulnerable cryptography.
