Post-Quantum Encryption and What It Means for VPNs

What is post-quantum VPN encryption, and why does it matter?

Post-quantum VPN encryption refers to a newer generation of cryptographic algorithms — specifically, key-exchange and digital-signature algorithms — designed to remain secure even if an attacker eventually has access to a sufficiently powerful quantum computer. It's a response to a very specific, well-understood mathematical problem: the classical algorithms that VPNs (and nearly everything else encrypted on the internet, including HTTPS) currently use to establish a shared secret between two parties rely on math problems, like factoring large numbers or computing discrete logarithms on an elliptic curve, that are computationally infeasible for a normal computer to solve in any practical amount of time, but that a large enough quantum computer running the right algorithm could, in theory, solve efficiently.

It's worth being precise about what this does and doesn't mean before going further, because the topic attracts both dismissive skepticism and overheated marketing in roughly equal measure. No quantum computer that exists today, publicly or otherwise as far as is verifiable, is capable of breaking the encryption protecting a real VPN connection. This isn't a threat that's actively being exploited against ordinary VPN users right now. What makes post-quantum cryptography a live concern anyway, rather than a purely academic one, is a separate strategy called "harvest now, decrypt later," covered in detail further down this guide — the short version is that an adversary doesn't need a working quantum computer today to benefit from one eventually, as long as they're willing to record and store encrypted traffic now.

Post-quantum VPN encryption, in practice, doesn't mean throwing out everything a VPN currently does. It means adding a new, quantum-resistant algorithm to the part of the connection that's actually vulnerable — the initial key exchange — typically run alongside, not instead of, the classical algorithm that's already there. Understanding why that specific layer is the vulnerable one, and not the encryption of your actual traffic, is the key to understanding this whole topic without getting lost in either hype or dismissal.

How could a quantum computer actually break the encryption a VPN uses today?

A modern VPN connection relies on two distinct cryptographic jobs, and quantum computers threaten them very differently. The first job is key exchange: your device and the VPN server need to agree on a shared secret key over a network that an eavesdropper can watch, without ever transmitting that secret directly. This is handled by algorithms like Diffie-Hellman, elliptic-curve Diffie-Hellman (ECDH), or RSA key transport — our guide on perfect forward secrecy covers how the ephemeral version of this exchange works in more detail. The second job is encrypting the actual traffic once that shared key exists, typically using a symmetric cipher like AES-256 or ChaCha20.

These two jobs have very different relationships to quantum computing, because they rely on different kinds of math, and that difference is the single most important thing to understand about this entire topic:

• Key exchange is the seriously vulnerable part. Diffie-Hellman, ECDH, and RSA all rely on math problems — the discrete logarithm problem and integer factorization, respectively — that a quantum computer running Shor's algorithm could solve efficiently, given enough stable quantum bits (qubits) and enough error correction to run the algorithm reliably. Shor's algorithm, published by mathematician Peter Shor in 1994, isn't a hypothetical or speculative piece of math — it's a proven algorithm that would break these specific problems if run on hardware capable of executing it at the necessary scale. That hardware doesn't exist yet, and estimates for when (or whether) it will vary widely, but the algorithm itself isn't in question.
• Symmetric encryption is much less affected. AES-256, the cipher that actually encrypts your traffic once a key is established, isn't vulnerable to Shor's algorithm at all — it relies on a completely different kind of mathematical structure. The relevant quantum algorithm here is Grover's algorithm, which provides a quadratic speedup for brute-force key searches rather than breaking the cipher's structure outright. In practice, Grover's algorithm roughly halves a symmetric key's effective security strength against a quantum attacker — meaning AES-256 behaves, at worst, like a 128-bit key against a quantum brute-force attempt, which is still considered comfortably secure by current standards. This is precisely why security researchers already consider AES-256 "quantum-resistant enough" without any modification, while AES-128 is a meaningfully closer call.

The practical upshot of this asymmetry: the part of your VPN connection that's genuinely at risk from a future quantum computer isn't the encryption protecting your Netflix session or your emails in transit — it's the handshake that established the key protecting that session in the first place. That's exactly why "post-quantum VPN encryption" specifically targets the key-exchange step rather than replacing AES-256 with something else entirely, a distinction covered in more detail a bit further down.

How far away is a quantum computer that could actually do this?

Genuinely uncertain, and anyone stating a confident specific year is overselling their certainty. Building a quantum computer capable of running Shor's algorithm against real-world key sizes requires not just many qubits, but many stable, error-corrected, logical qubits — a bar that's dramatically higher than the "quantum computer" headlines about record qubit counts usually imply, because today's quantum hardware is still dominated by noise and error rates that make long, precise computations like Shor's algorithm unreliable at meaningful scale. Estimates from cryptographers and standards bodies have historically ranged anywhere from roughly a decade to several decades out, and those estimates have shifted over time as the underlying hardware research has progressed — sometimes accelerating expectations, sometimes tempering them. This guide isn't going to invent a specific date, because no one can currently state one with confidence, and any article that does should be read skeptically.

What matters for a practical decision isn't pinning down an exact year — it's recognizing that the uncertainty itself is the reason to start planning now rather than later, for a specific reason covered next.

What is "harvest now, decrypt later," and why does it make quantum risk urgent today?

"Harvest now, decrypt later" describes an attack strategy where an adversary doesn't try to break encryption in real time at all. Instead, they capture and store large volumes of encrypted traffic today — something that requires no quantum computer, no cryptographic breakthrough, and no special access beyond the ability to observe or intercept network traffic somewhere along its path — and simply wait. The bet is that at some point in the future, whether that's five years or twenty-five, a capability will exist (a working quantum computer, most prominently) that can retroactively decrypt at least some meaningful fraction of what was recorded.

This is what turns quantum computing from a distant, seemingly irrelevant threat into a present-tense decision for anyone whose data could still matter years from now. The math is straightforward and slightly unsettling once you sit with it: if your VPN traffic today is protected only by classical key exchange, and that traffic is recorded by an adversary capable of large-scale interception, then the question of whether it stays private isn't just "is today's encryption strong enough" — it's "will today's encryption still be strong enough in fifteen or twenty years," which is a materially different and harder question to answer with confidence.

Whether this matters to you personally depends heavily on how long your data needs to stay confidential. A lot of everyday browsing genuinely doesn't have a meaningful multi-decade confidentiality requirement — nobody is going to care in 2046 which streaming catalog you were accessing tonight. But plenty of traffic does carry that kind of long horizon: journalists communicating with sources whose safety depends on confidentiality holding indefinitely, medical or legal communications, government and corporate correspondence, intellectual property, or simply anyone who'd rather not gamble on their entire browsing history someday becoming exposed regardless of how unlikely that feels today. The realistic guidance isn't "everyone must panic now" — it's "the people and organizations with genuinely long confidentiality horizons are the ones who should be thinking about this today, and everyone else benefits from providers building it in as a matter of course, without needing to personally weigh the tradeoff."

It's also worth being honest about the scale required to actually carry out this attack against ordinary internet users. Recording and storing meaningful volumes of encrypted internet traffic at scale, and doing so for years while waiting on hardware that may or may not materialize on any particular timeline, is realistically the domain of well-resourced state-level actors rather than opportunistic criminals — which doesn't make the risk zero for anyone, but does mean it scales with how plausible a target you are for that specific kind of patient, well-funded adversary, not with how sensitive your traffic merely feels to you personally.

What exactly are "post-quantum" algorithms, and how are they different from what's used today?

Post-quantum cryptography isn't a single algorithm or a simple upgrade to existing ones — it's a family of newer algorithms built on entirely different mathematical foundations than RSA and elliptic-curve cryptography, chosen specifically because those foundations aren't known to be efficiently solvable even by Shor's algorithm or anything like it. The most prominent category used for key exchange is lattice-based cryptography, which relies on problems involving high-dimensional mathematical lattices that remain hard even for a quantum computer, as far as current cryptanalysis can determine. Other post-quantum approaches exist too, including hash-based and code-based schemes, each with different tradeoffs in key size, computational cost, and how long they've been studied.

Because "which math problem is actually quantum-resistant" isn't something any single research group or company can credibly decide unilaterally, the U.S. National Institute of Standards and Technology (NIST) ran a multi-year, public, adversarial standardization process — researchers worldwide submitted candidate algorithms, and other researchers spent years actively trying to break them, with weaker candidates eliminated along the way. This is the same basic model that produced AES itself decades ago, and it's the reason post-quantum standards carry real credibility rather than being one vendor's unverified claim about their own math.

That process concluded with NIST finalizing its first formal post-quantum standards:

• ML-KEM (FIPS 203), based on the CRYSTALS-Kyber algorithm, is the standard for key encapsulation — the mechanism used to establish a shared secret, and the piece most directly relevant to VPN key exchange.
• ML-DSA (FIPS 204), based on CRYSTALS-Dilithium, is the standard for digital signatures, used for authentication rather than key exchange itself.
• SLH-DSA (FIPS 205), based on SPHINCS+, is an alternative, hash-based signature standard, included partly as a structurally different backup in case future cryptanalysis finds a weakness in the lattice-based approach that both ML-KEM and ML-DSA share.

For VPN purposes, ML-KEM (Kyber) is the one that matters most directly, since key encapsulation is functionally the post-quantum equivalent of the Diffie-Hellman key exchange a VPN handshake already performs. When you see a VPN protocol or provider mention "Kyber" or "ML-KEM" specifically, that's what they're referring to — a standardized, publicly vetted algorithm for the exact job classical ECDH currently does, just built on different underlying math.

Does having a "backup" algorithm like SLH-DSA actually matter?

Yes, and it reflects a real, openly discussed concern within the cryptography community rather than excessive caution. Lattice-based cryptography is newer and less battle-tested than the decades of scrutiny RSA and elliptic-curve cryptography have accumulated — it's considered strong based on the current state of research, but "current state of research" is doing real work in that sentence. Having a structurally different backup standard, based on hash functions rather than lattices, means that if some future cryptanalytic breakthrough did find a weakness specific to lattice-based math, the field wouldn't be starting from zero. This kind of deliberate diversity is itself a sign of a maturing, honestly self-critical standardization process rather than a reason to distrust post-quantum cryptography generally.

Does post-quantum encryption replace AES-256, or work alongside it?

Alongside it, not instead of it — this is one of the most commonly misunderstood parts of the topic, including in some marketing copy that isn't always careful about the distinction. As covered earlier, AES-256 isn't meaningfully threatened by known quantum algorithms; Grover's algorithm only halves its effective strength, leaving it comfortably secure. There's no need to replace AES-256 with something else to make it quantum-resistant, and no mainstream post-quantum VPN implementation does that.

What actually changes is the key-exchange step that happens before AES-256 (or ChaCha20) ever starts encrypting traffic. A post-quantum-enabled VPN connection typically runs a hybrid key exchange: it performs the classical ECDH exchange it already would have performed, and separately performs a post-quantum key exchange (typically ML-KEM/Kyber) at the same time, then combines both results into the final session key. This hybrid approach is deliberate and conservative — it means the connection is secure as long as either the classical algorithm or the post-quantum algorithm remains unbroken, rather than betting everything on the newer, less-tested post-quantum math alone. If a subtle flaw were ever found in a specific post-quantum algorithm (a real possibility for a comparatively young field), the classical component still provides the security guarantee it always has; and if a quantum computer eventually breaks the classical component, the post-quantum component picks up the slack instead.

The practical mental model, then: post-quantum VPN encryption adds a second, independent lock to the key-exchange door, without touching the vault (your actual encrypted traffic) behind it. AES-256 keeps doing exactly what it's always done; the post-quantum layer is specifically about making sure the key protecting that traffic can't be retroactively derived by a future quantum computer via a broken classical handshake.

Which VPN protocols support post-quantum key exchange today?

Support here is uneven and still actively evolving, which is normal for a standard that only finalized in 2024 — this is a genuinely fast-moving area of the industry rather than a settled one, and any specific claim about "who supports what" is liable to age quickly. A few general, more durable patterns are worth understanding regardless of exactly which provider has shipped what by the time you're reading this:

• WireGuard does not include post-quantum key exchange in its core protocol specification, which was deliberately kept minimal and hasn't been revised to add it directly. Instead, post-quantum protection for WireGuard connections has generally come from separate, additional layers built on top of the base protocol — independent open-source projects like Rosenpass, for example, add a post-quantum pre-shared key negotiation step that runs alongside WireGuard's existing classical handshake, rather than modifying WireGuard itself. Providers that want post-quantum WireGuard connections have generally had to build or adopt this kind of additional layer rather than getting it from WireGuard out of the box.
• OpenVPN and other TLS-based protocols can adopt post-quantum key exchange through updates to the underlying TLS library and cipher suite negotiation, since TLS 1.3 already has a defined mechanism for hybrid key exchange. Support depends on which TLS implementation a provider's OpenVPN deployment is built on, and whether that implementation has been updated to include ML-KEM alongside classical ECDHE.
• IKEv2/IPsec has a similar story — hybrid post-quantum support is possible within the protocol's existing negotiation framework, but depends on whether a given implementation has actually added it, rather than being a property of the protocol itself.
• Browser-facing TLS (HTTPS), for comparison, moved on this earlier than most VPN protocols — major browsers and cloud providers began rolling out hybrid post-quantum key exchange (X25519 combined with Kyber) for standard HTTPS connections starting in 2023, ahead of NIST's final standard being published. This gives a useful reference point: the broader internet's TLS infrastructure has had a head start on VPN-specific protocols in actually deploying this at scale.

The overall picture: post-quantum key exchange for VPNs is real, standardized, and increasingly implementable, but it isn't yet a default, universal feature the way, say, AES-256 or even WireGuard support has become. Whether a specific VPN connection you're using has it depends on the specific protocol, the specific app, and sometimes the specific platform (desktop apps often get new cryptographic features before mobile apps do, for practical development-priority reasons) — which is exactly why checking a provider's own technical documentation, rather than assuming based on the protocol name alone, matters here.

Are there downsides to post-quantum VPN encryption, like slower speeds or bigger overhead?

Some, though they're modest by current standards and generally not something a typical user would notice in everyday use. The tradeoffs worth knowing about fall into two categories: data size and computational cost.

• Larger keys and ciphertext. Lattice-based algorithms like ML-KEM produce meaningfully larger public keys and ciphertexts than classical elliptic-curve Diffie-Hellman does — where a classical ECDH public key might be on the order of 32 bytes, an ML-KEM public key runs to roughly a kilobyte or more, depending on the specific parameter set chosen. For a single VPN handshake, that difference is negligible in absolute terms — a few extra kilobytes exchanged once per connection (or once per rekey interval) is nothing compared to the megabytes of ordinary traffic a VPN session moves. It becomes a more relevant engineering consideration at large scale, where a VPN provider running enormous numbers of simultaneous connections has to account for the added bandwidth and packet-handling overhead across its whole infrastructure, but this is a provider-side scaling question rather than something an individual user's connection would perceptibly feel.
• Extra computation during the handshake. Generating and processing a post-quantum key exchange takes more CPU time than the equivalent classical operation, since the underlying lattice math is more computationally involved than elliptic-curve arithmetic. On modern phone and laptop hardware, this shows up as a small, generally imperceptible amount of extra time during the initial handshake — not a sustained cost applied to every packet of ongoing traffic, since (as covered earlier) the actual traffic encryption still runs through the same AES-256 or ChaCha20 cipher it always did, untouched by any of this. Where it could matter more is on older, lower-powered devices, or in scenarios with very frequent rekeying, where the handshake cost is paid over and over — though even there, the overhead is small relative to the computational headroom on essentially any device sold in the last several years.
• Protocol and implementation immaturity. This is arguably the more meaningful practical downside today, and it's an engineering-maturity concern rather than a cryptographic one: because hybrid post-quantum key exchange is still relatively new in VPN-specific implementations, there's simply less real-world deployment history and fewer years of production hardening behind it compared to classical ECDH, which has been deployed at internet scale for well over a decade. This isn't a reason to avoid it, but it's a reasonable factor behind why some providers are rolling it out gradually, on newer app versions and one platform at a time, rather than flipping it on everywhere at once.

None of these tradeoffs come close to outweighing the benefit for the threat post-quantum key exchange is designed to address — a few extra kilobytes and a small amount of handshake computation is a genuinely reasonable price for closing the "harvest now, decrypt later" gap described earlier. They're worth knowing mainly so that "post-quantum support" doesn't get evaluated as a purely one-sided upgrade with no engineering tradeoffs at all; understanding the actual tradeoffs is part of reading a provider's technical claims with the right level of informed skepticism, the same principle covered throughout this guide.

Do any VPN providers actually offer post-quantum encryption right now?

Some do, in some form, on some platforms — the honest and most durable answer is that this is a genuinely active area of development across the industry rather than a settled feature list, and exactly which provider supports exactly what, on exactly which app and protocol, is the kind of detail that changes with app updates rather than staying fixed. Rather than asserting a specific snapshot of "provider X supports Y" that risks being stale by the time you read it, the more useful approach is knowing what to actually check for yourself, covered in the next section.

What's fair to say in general terms: the direction of travel across the consumer VPN industry is toward adding hybrid post-quantum key exchange as an option, usually rolled out first on newer protocol implementations and flagship desktop apps, with broader platform coverage following over time. This mirrors how most meaningful cryptographic upgrades have historically spread through the VPN industry — WireGuard adoption itself followed a similar pattern of gradual rollout rather than an instant, uniform switch. A provider actively working on and documenting post-quantum support is a genuinely positive signal about its broader cryptographic seriousness; a provider that's silent on the topic entirely isn't necessarily behind, but it does mean you'd need to dig into its technical documentation, or contact support directly, to find out where it actually stands rather than assuming either way.

Is "quantum-resistant VPN" marketing hype, or a real feature worth caring about?

Both things can be true at once, and separating them is worth the effort. The underlying cryptography — NIST-standardized post-quantum key exchange algorithms, hybrid classical-plus-post-quantum handshakes — is real, rigorously vetted, and addresses a genuine, well-understood risk. That part isn't hype. Where hype creeps in is in how the feature sometimes gets marketed: vague claims of "quantum-proof" or "unbreakable even by quantum computers" security, without specifying which algorithm is actually in use, which part of the connection it protects, or which apps and platforms it applies to, are exactly the kind of imprecise language that should raise skepticism rather than confidence.

A few markers that distinguish a substantive claim from a marketing flourish:

• Specificity about the algorithm. A provider that names the actual algorithm in use — ML-KEM, Kyber, or an equivalent — is making a checkable, falsifiable claim. Vague language like "quantum-safe technology" with no algorithm named is much harder to verify and more likely to be marketing shorthand than a precise technical description.
• Clarity about scope. Does the claim apply to all apps and platforms, or just one? To all supported protocols, or just one? A provider being specific and honest about partial rollout is a better sign than a broad, unqualified claim that turns out to only apply narrowly once you dig in.
• Hybrid, not standalone. As covered above, the responsible, currently-recommended implementation is hybrid — classical plus post-quantum together, not post-quantum key exchange alone. A provider that's replaced its classical key exchange entirely with an unproven post-quantum-only scheme, rather than layering it on top, is taking on more risk than the field's current consensus recommends.
• No claim of absolute, permanent security. Post-quantum cryptography, like all cryptography, is based on current best understanding of what's computationally hard — not a mathematically provable, permanent guarantee against every conceivable future attack, quantum or otherwise. Absolute language ("impossible to break," "unbreakable forever") is a red flag regardless of which cryptographic technology it's attached to.

None of this means the underlying feature isn't worth having — it clearly is, for exactly the "harvest now, decrypt later" reasons covered earlier. It means reading the specific claim carefully rather than taking a headline phrase like "quantum-resistant" at face value, the same way you'd want to read any other security claim on this site or anywhere else.

How urgent is the quantum threat, really — should I switch VPNs today because of it?

For most everyday VPN users, this isn't a reason to urgently switch providers today, and treating it that way would be overselling the near-term risk. No quantum computer capable of breaking real-world VPN key exchange exists, credible timelines for one remain genuinely uncertain and likely measured in years to decades at minimum, and most everyday browsing doesn't carry a confidentiality requirement that stretches that far into the future anyway.

Where this genuinely does matter more urgently is for a narrower set of people and use cases with long confidentiality horizons — the same audience that already tends to think carefully about jurisdiction, no-logs policies, and independent audits when picking a provider, covered in our guide on choosing a VPN for privacy. Journalists protecting sources, activists and dissidents whose safety could depend on communications staying confidential indefinitely, people handling legally or medically sensitive information, and organizations protecting long-lived intellectual property or state secrets are the clearest cases where "harvest now, decrypt later" isn't a theoretical concern but a live one worth factoring into a provider decision today.

For everyone else, a more measured framing holds up better: post-quantum support is a genuinely good signal about a provider's engineering seriousness and willingness to invest in cryptography ahead of an actual emergency, worth treating as a positive factor among several when comparing providers — similar to how an independent security audit or a transparent logging policy functions as a positive signal rather than a strict requirement. It doesn't need to be the single deciding factor for a typical user, but a provider actively building toward it, and documenting that work honestly, is doing something that reflects well on how it'll likely handle the next cryptographic transition too, whatever that turns out to be.

What should I actually look for when a VPN provider claims to be "quantum-safe"?

A short, practical checklist, roughly in order of how much verification effort each step requires:

1. Look for a named algorithm, not just a slogan. ML-KEM or Kyber specifically named in a provider's technical documentation or blog post is a stronger, more checkable claim than "quantum-resistant encryption" alone.
2. Check whether it's hybrid. Confirm the post-quantum algorithm runs alongside classical key exchange rather than replacing it outright — this is the current best-practice approach and should be described that way if the provider is being precise.
3. Check platform and protocol scope. Confirm whether the feature applies to the specific app and protocol you actually use, since post-quantum rollout is commonly partial (desktop-first, one protocol first) rather than universal across a provider's full product line.
4. Look for independent scrutiny. A provider that's had its post-quantum implementation specifically covered in an independent security audit, rather than only self-reported, gives you a third-party check on whether the implementation actually does what it claims — the same principle that applies to logging-policy audits generally.
5. Watch the provider's pace of updates over time. Because this is a genuinely fast-evolving area, a provider that publishes periodic, dated updates about its post-quantum rollout progress is demonstrating an ongoing commitment rather than a one-time press release designed to generate headlines and then go quiet.

If a provider's documentation can't answer these questions with any specificity, that's useful information too — it suggests the feature, if it exists at all, may be earlier-stage or narrower in scope than the marketing language implies.

How does post-quantum VPN encryption relate to perfect forward secrecy?

They're closely related but distinct properties that both matter for the same underlying "harvest now, decrypt later" threat, and it's worth being precise about the difference — our dedicated guide on perfect forward secrecy covers the first property in much more depth, but the short version here is useful for seeing how the two fit together.

Perfect forward secrecy protects against a stolen long-term key being used to retroactively decrypt past sessions — it does this by generating a fresh, disposable session key for every connection through an ephemeral classical Diffie-Hellman exchange, so that even if a server's long-term key is later stolen, that theft doesn't unlock previously recorded sessions. Critically, though, forward secrecy on its own assumes the underlying classical Diffie-Hellman math itself stays hard to break — it protects against key theft, not against someone solving the ephemeral exchange's math directly.

That's exactly the gap post-quantum cryptography closes. A sufficiently powerful future quantum computer wouldn't need to steal any key at all to break a classically forward-secret connection retroactively — it could, in theory, derive the ephemeral session key directly from the publicly exchanged classical Diffie-Hellman values and recorded ciphertext, using Shor's algorithm, without ever touching a long-term key. Forward secrecy alone provides zero protection against that specific attack, because it was never designed to address it — it was designed for a different threat (key theft), which it still handles well.

Post-quantum key exchange, layered into that same ephemeral, forward-secret handshake, is what closes this remaining gap: even if a future quantum computer could break the classical half of a hybrid ephemeral exchange, the post-quantum half remains unbroken (assuming the post-quantum algorithm itself holds up), so the resulting session key stays secure either way. The two properties, working together, are what actually delivers robust protection against "harvest now, decrypt later" specifically: forward secrecy handles the key-theft scenario, and post-quantum key exchange handles the quantum-computer-breaks-the-math scenario, and a genuinely well-designed modern VPN connection aims for both simultaneously rather than treating either as sufficient on its own.

Practical takeaway

Post-quantum VPN encryption is a real, standards-backed response to a specific, well-understood future risk — not a distant curiosity and not an urgent five-alarm emergency for most everyday users either. The core mechanics are straightforward once separated from the marketing noise: your VPN's symmetric encryption (AES-256) was never seriously threatened by known quantum algorithms; the actual vulnerability sits in classical key exchange, which a sufficiently powerful future quantum computer could in theory break directly; and the practical fix is a hybrid handshake that runs a NIST-standardized post-quantum algorithm like ML-KEM alongside the classical exchange a VPN already performs, rather than replacing anything.

What makes this worth acting on before a quantum computer capable of the attack actually exists is "harvest now, decrypt later" — encrypted traffic recorded today can, in principle, sit in storage for years and become readable retroactively the moment the hardware catches up, which means the decision to protect against it has to be made well ahead of the actual threat materializing, not after. For most users, this is a reasonable factor to weigh among several when comparing providers, not a reason to urgently switch today; for anyone with a genuinely long confidentiality horizon — journalists, activists, and others covered in more depth in our guide on VPNs for journalists — it deserves more direct, immediate attention. Either way, the useful skill is reading a "quantum-resistant" claim carefully: look for a named algorithm, confirm it's hybrid rather than standalone, check which apps and platforms it actually covers, and treat vague, absolute marketing language with the same skepticism you'd apply to any other unverified security claim.