Post-Quantum Cryptography, Explained for Enterprises

What post-quantum cryptography is

Post-quantum cryptography — often shortened to PQC — is a family of encryption and digital-signature algorithms designed to remain secure even against an adversary equipped with a large-scale quantum computer. It runs on the ordinary classical hardware you already operate: laptops, servers, network appliances, and cloud instances. What makes it "post-quantum" is not the machine it runs on, but the mathematics it rests on. Each algorithm is built from a computational problem that neither classical nor quantum computers are known to solve efficiently.

That distinction matters because the cryptography protecting almost every enterprise system today was not built with quantum computers in mind. When you connect to a website over HTTPS, sign a software release, authenticate to a VPN, or encrypt a database backup, you rely on public-key cryptography — most commonly RSA and elliptic-curve cryptography (ECC). Those two algorithm families secure the key exchanges and digital signatures that underpin the modern internet. They are also precisely the algorithms a sufficiently powerful quantum computer is expected to break. Post-quantum cryptography exists to replace them before that happens.

It helps to be clear about scope from the outset. PQC is concerned almost entirely with public-key cryptography: the mechanisms two parties use to agree on a shared secret, and the mechanisms used to prove authenticity through signatures. The symmetric algorithms that do the bulk encryption of data — most notably AES — are affected very differently and, as we will see, remain secure with only a modest adjustment. So when security teams talk about a PQC migration, they are overwhelmingly talking about replacing key-exchange and signature algorithms, not tearing out the entire cryptographic stack.

Post-quantum cryptography is sometimes confused with quantum cryptography, such as quantum key distribution (QKD). They are not the same thing. QKD uses quantum physics — typically photons over specialized fiber or free-space links — to distribute keys, and requires dedicated hardware. PQC uses conventional software and math, deploys over the networks and devices you already have, and is the approach standards bodies and governments have chosen for the general migration. This article is about PQC.

How quantum computers break today's cryptography

To understand why the migration is necessary, it helps to understand exactly what a quantum computer changes and what it does not. The threat is specific, not universal, and getting the specifics right is what separates a sound migration plan from panic.

Shor's algorithm versus RSA and ECC

The security of RSA rests on the difficulty of factoring very large numbers into their prime components. The security of elliptic-curve cryptography rests on a related problem, the elliptic-curve discrete logarithm. For a classical computer, both problems are effectively intractable at the key sizes in use: factoring a 2048-bit RSA modulus with today's best classical methods would take longer than the age of the universe. That intractability is the entire foundation of their security.

In 1994, mathematician Peter Shor published an algorithm that solves both problems efficiently on a quantum computer. Shor's algorithm does not merely speed factoring up a little; it transforms it from an exponentially hard problem into a tractable one. A quantum computer with enough stable, error-corrected qubits running Shor's algorithm could recover an RSA or ECC private key from its public key in a practical amount of time. When that becomes possible, RSA and ECC do not become weaker — they become broken. Signatures could be forged, key exchanges could be decrypted, and the trust anchors of the internet would no longer hold.

The machine capable of this is often called a cryptographically relevant quantum computer (CRQC). One does not exist today. Current quantum processors have far too few reliable qubits, and error correction remains an immense engineering challenge. No credible authority claims RSA-2048 can be broken right now. But the trajectory of investment and progress is real, and — crucially — nobody can offer a firm date. Security planning has to treat the CRQC as a matter of "when," not "if," and plan against an uncertain timeline rather than a comfortable one.

Grover's algorithm and symmetric keys

There is a second quantum algorithm worth understanding, because it is frequently misunderstood. Grover's algorithm provides a general speedup for searching an unstructured space — including brute-forcing a symmetric key. But its advantage is only quadratic, not exponential. In practical terms, Grover's algorithm reduces the effective security of a symmetric key by roughly half its bits: a 128-bit key offers about 64 bits of security against an ideal quantum search, while a 256-bit key offers about 128 bits. Because 128 bits of security remains comfortably beyond reach, AES-256 stays secure against quantum attack. Grover's algorithm does not represent the same category of threat that Shor's algorithm poses to public-key cryptography, and no amount of quantum progress changes that asymmetry.

Harvest now, decrypt later: why long-lived data is already at risk

The most common objection to acting on the quantum threat is intuitive: if no quantum computer can break RSA today, why not wait until one is closer? The answer is a threat model known as harvest now, decrypt later (sometimes called "store now, decrypt later" or retrospective decryption), and it is the single most important reason enterprises cannot afford to defer.

The premise is straightforward. An adversary does not need a quantum computer today to benefit from one tomorrow. They only need to capture encrypted data today and keep it. Nation-state actors and well-resourced groups are widely assessed to be recording encrypted traffic and exfiltrating encrypted archives now, with the expectation of decrypting them once a cryptographically relevant quantum computer becomes available. The ciphertext sits patiently in storage; the key that protects it will one day be recoverable.

This reframes the deadline entirely. The question is not "when will a quantum computer exist?" It is "how long does this data need to stay confidential?" Any information whose sensitivity outlives the arrival of a CRQC is effectively at risk the moment it crosses a network in a form protected only by classical public-key cryptography. Consider how long real enterprise data must remain secret:

• Health records and genetic data — sensitive for a patient's entire lifetime, and often beyond.
• Financial and trade secrets — intellectual property, deal terms, and strategic plans that hold value for decades.
• Government and defense information — routinely classified with multi-decade protection requirements.
• Personal identifiers — a Social Security number or biometric template cannot simply be rotated when it leaks.
• Long-lived credentials and keys — root keys and certificates whose compromise unravels everything they anchor.

A useful way to reason about the urgency is sometimes called Mosca's inequality, after cryptographer Michele Mosca. It uses three variables. Let X be the number of years your data must remain confidential — its secrecy lifetime or "shelf life." Let Y be the number of years it will take your organization to migrate its systems to post-quantum cryptography. And let Z be the number of years until a cryptographically relevant quantum computer exists that can break your current cryptography. The inequality is simple: if X + Y > Z, you have a problem. In plain terms, if the time your data needs to stay secret, added to the time it takes you to protect it, exceeds the time until the threat arrives, then some of your data will be exposed before you finish defending it.

Mosca's inequality, worked through

Consider a concrete, deliberately conservative example. Suppose a healthcare organization holds patient records that must stay confidential for 25 years (X = 25). Suppose, realistically for a large regulated enterprise, that a full cryptographic migration will take 7 years from a standing start (Y = 7). And suppose — generously to the "wait and see" camp — that a cryptographically relevant quantum computer is 15 years away (Z = 15). Plugging in: X + Y = 25 + 7 = 32, which is greater than Z = 15. The organization is exposed by 17 years. In fact, even if the quantum computer never arrived until year 32, the data harvested in years 1 through 7 — before migration completed — would still be readable the moment it did. The only variable an enterprise fully controls is Y, its own migration time, and the only way to shrink the exposure is to start earlier.

What makes the inequality sobering is how much uncertainty lives in Z. No one can measure it precisely, and an adversary will not announce the moment their capability crosses the threshold. Prudent planning therefore treats Z as smaller and less certain than optimism would suggest, and treats Y — which is knowable and controllable — as the lever. For a large enterprise, migration alone can take many years. That single fact means the practical deadline for protecting long-lived data has, for many organizations, already passed. Harvest now, decrypt later is not a future problem you can schedule; it is a present one you can only mitigate going forward.

The NIST post-quantum standards

For years the barrier to acting was the absence of vetted, standardized algorithms. That barrier is gone. In 2016 the U.S. National Institute of Standards and Technology (NIST) launched a public, multi-round competition to select post-quantum algorithms, drawing submissions and cryptanalysis from researchers worldwide. In August 2024, NIST published the first finalized standards. They are the foundation on which enterprise PQC migration now builds, and every serious plan should be anchored to them.

FIPS 203 — ML-KEM (key encapsulation)

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), standardized as FIPS 203, is the post-quantum replacement for the key exchange that establishes a shared secret between two parties. It derives from the algorithm previously known as CRYSTALS-Kyber and is based on the hardness of structured lattice problems, which are not known to be efficiently solvable by quantum computers. A key-encapsulation mechanism, or KEM, is the modern way to think about key establishment: one party encapsulates a fresh secret to the other's public key, and only the holder of the private key can decapsulate it. ML-KEM is specified at three parameter sets — ML-KEM-512, ML-KEM-768, and ML-KEM-1024 — with ML-KEM-1024 offering the highest security level and the natural choice for high-assurance, long-lived protection.

FIPS 204 — ML-DSA (primary signatures)

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardized as FIPS 204, is the primary post-quantum digital-signature scheme. It derives from CRYSTALS-Dilithium and, like ML-KEM, rests on lattice problems. Signatures are what let a recipient verify that a message, certificate, firmware image, or software release genuinely came from its claimed source and was not altered. ML-DSA is the default recommendation for most signature use cases, and its strongest parameter set, ML-DSA-87, is the appropriate selection where the highest assurance is required.

FIPS 205 — SLH-DSA (conservative signatures)

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), standardized as FIPS 205, is a second signature standard built on a deliberately different mathematical foundation. Derived from SPHINCS+, it relies only on the security of hash functions rather than on lattice problems. Its signatures are larger and signing is slower than ML-DSA, but it offers valuable diversity: if a future weakness were ever found in lattice-based schemes, hash-based signatures would be unaffected. SLH-DSA is well suited to scenarios where signatures are infrequent but must remain trustworthy for a very long time — firmware signing and root certificates being classic examples.

Two points are worth emphasizing about these standards. First, they are the product of years of open, adversarial cryptanalysis — not vendor claims. That public scrutiny is what gives an enterprise the confidence to build on them. Second, they are algorithms, not products. A standard tells you which mathematics to use; it does not migrate your systems, update your libraries, or reissue your certificates. That work is the migration, and it is where most of the effort actually lives.

Lattice-based cryptography, intuitively

Two of the three NIST standards — ML-KEM and ML-DSA — are built on structured lattice problems, so it is worth developing some intuition for why lattices are believed to resist quantum attack. You do not need the underlying algebra to make sound decisions, but a working mental model helps explain why these algorithms replace RSA and ECC rather than merely reinforcing them.

Picture a regular grid of points extending in every direction — in two dimensions it looks like graph paper, but the real constructions live in hundreds of dimensions. A lattice is exactly that: the set of all points you can reach by taking whole-number steps along a fixed set of basis vectors. Two famous hard problems live in this structure. The shortest vector problem asks you to find the lattice point closest to the origin (other than the origin itself), and the closest vector problem asks, given an arbitrary point in space that is near — but not exactly on — the lattice, which lattice point is nearest. In two or three dimensions these look easy. In hundreds of dimensions, with a deliberately awkward basis, they become staggeringly hard: the number of candidate directions explodes, and there is no shortcut that reliably finds the answer.

The security of lattice cryptography rests on a related, more practical problem called Learning With Errors (LWE), and its efficient "module" and "ring" variants that ML-KEM and ML-DSA actually use. The intuition behind LWE is approachable. Imagine a system of linear equations where each equation has been nudged by a small, random error. Without the errors, a first-year linear-algebra technique would solve the system instantly. With small errors deliberately added, recovering the original secret becomes intractable — the noise hides the solution among an astronomical number of near-misses. Encryption hides a message inside that noise; decryption, using the private key, is the one path that can separate signal from error.

This also explains a practical trade-off enterprises will notice during migration. Lattice-based keys, ciphertexts, and signatures are larger than their RSA and ECC equivalents — often by a factor of several. That is the price of the added dimensionality and noise that provide security. It rarely matters for throughput, but it does affect handshake sizes, certificate sizes, and any protocol with tight length assumptions, which is why testing under production-like conditions is part of a responsible rollout. SLH-DSA (FIPS 205) takes a different route entirely: rather than lattices, it builds signatures purely from hash functions, trading larger, slower signatures for a security argument that depends on nothing more than the collision resistance of a hash — a deliberately conservative hedge against any future surprise in lattice cryptanalysis.

Hybrid schemes: classical and post-quantum together

Post-quantum algorithms are new. They have survived intense analysis, but they have not accumulated the decades of real-world scrutiny that RSA and ECC have. Deploying a brand-new algorithm alone means betting everything on the possibility that no unforeseen classical weakness will ever be discovered in it. Many organizations, and much of the standards community, are unwilling to take that bet during the transition. The answer is the hybrid approach.

A hybrid key exchange runs a well-understood classical algorithm and a post-quantum algorithm side by side, then combines their outputs so that the resulting shared secret is protected by both. The most widely deployed construction pairs X25519 — a fast, mature elliptic-curve Diffie-Hellman function — with ML-KEM. An attacker would have to break both schemes to recover the secret. If ML-KEM ever proved to have a flaw, the classical X25519 layer would still protect against a classical attacker; and if a quantum computer defeated X25519, the ML-KEM layer would still hold. This construction has already been rolled out at scale across major browsers, TLS libraries, and cloud services, which is a strong signal of its practicality.

Hybrid deployment does carry costs worth planning for. Post-quantum keys and ciphertexts are larger than their classical counterparts, which increases handshake sizes and can affect systems with tight packet-size assumptions. Running two algorithms adds a small amount of computation. For most enterprise workloads these costs are negligible, but they are real enough that testing under production-like conditions is part of any responsible rollout. The upside is decisive: hybrid lets you gain post-quantum protection today without giving up the battle-tested security guarantees you already depend on.

What post-quantum means for TLS and PKI

Most enterprise cryptography is not written by hand; it is delivered through two pervasive systems — TLS, which secures connections, and the public-key infrastructure (PKI) of certificates that establishes trust. Understanding how PQC lands in each is what turns a general awareness of the threat into an actionable plan, because these are the systems where the migration is felt.

Key exchange versus authentication in TLS

A TLS handshake does two cryptographic jobs, and they face the quantum threat on very different timelines. The first is key exchange: the client and server agree on a shared symmetric key that will encrypt the session. The second is authentication: the server (and sometimes the client) proves its identity with a certificate and a signature. The key exchange is the urgent one, because it is exactly what harvest now, decrypt later targets — an adversary who records a handshake today can, with a future quantum computer, recover the session key and read the whole conversation retroactively. This is why hybrid key exchange combining X25519 with ML-KEM has been the first post-quantum feature deployed at scale in browsers and TLS libraries: it protects the confidentiality of today's traffic against tomorrow's decryption.

Authentication is genuinely less time-critical, though not unimportant. A signature only needs to be unforgeable at the moment of the handshake; an attacker cannot usefully forge a certificate for a connection that already happened. That means the quantum threat to TLS authentication becomes acute only as a cryptographically relevant quantum computer approaches, not in retrospect. This asymmetry gives enterprises a rational sequencing principle: prioritize post-quantum confidentiality (key exchange) now, and phase in post-quantum authentication (signatures) as the ecosystem of certificate authorities, browsers, and libraries matures around ML-DSA and SLH-DSA.

Certificates, chains, and the size problem

PKI is where the larger sizes of post-quantum signatures become a concrete engineering concern rather than an abstraction. A certificate chain typically contains several signatures — the end-entity certificate, one or more intermediates, and often signed timestamps or transparency proofs. Replacing each classical signature with a substantially larger ML-DSA or SLH-DSA signature multiplies the bytes that must travel in every handshake. Protocols and middleboxes that assumed compact certificates can behave unexpectedly when chains grow, and some legacy systems impose hard limits that post-quantum certificates can exceed. None of this is a blocker, but all of it is a reason to inventory and test rather than assume a drop-in replacement.

Long-lived trust anchors deserve special attention. A root certificate authority may be trusted for decades, which places it squarely in the harvest-now, decrypt-later reasoning for signatures: a root whose signing key could eventually be forged undermines everything beneath it. This is a natural home for SLH-DSA, whose hash-based construction offers a conservative, long-horizon guarantee for infrequently used but extremely high-value signing operations such as root and firmware signing. Code signing more broadly — where a signature may need to remain trustworthy for the entire supported life of a device or software release — follows the same logic.

AES-256 and symmetric considerations

Amid the urgency around public-key cryptography, it is easy to over-rotate and assume everything must change. It should not. As covered above, symmetric encryption — the algorithms that actually encrypt the bulk of your data — is affected by quantum computing only through Grover's algorithm, whose quadratic speedup merely halves effective key strength. AES-256 therefore retains roughly 128 bits of security against a quantum adversary, which is far beyond any practical attack. It does not need to be replaced.

The practical guidance is simple and worth stating plainly:

• Use 256-bit symmetric keys where you want a comfortable quantum margin. AES-256 is the conservative, quantum-resistant default for data at rest and in transit.
• Prefer authenticated encryption such as AES-256 in GCM mode, which protects both confidentiality and integrity.
• Keep hash functions strong. SHA-256 and SHA-3 remain appropriate; as with symmetric keys, larger outputs preserve margin against Grover-style search.

The reason symmetric algorithms get so little attention in a PQC migration is precisely that they need so little change. This is good news: the hardest and most disruptive part of the transition is confined to key exchange and signatures, while the encryption doing the heavy lifting on your data is already essentially quantum-ready with the right key sizes.

A practical enterprise migration roadmap

A PQC migration is a multi-year program, not a patch. But it is a tractable one when approached in the right order. The following four phases reflect the sequence most standards bodies and mature security teams recommend, and each phase produces value on its own rather than deferring all benefit to the end.

1. Build a cryptographic inventory

You cannot migrate what you cannot see. The foundational step — and the one most organizations underestimate — is a complete inventory of where and how cryptography is used across the enterprise. That means cataloguing the algorithms, key sizes, and protocols in your applications, TLS endpoints, VPNs, code-signing pipelines, hardware security modules, databases, and, critically, your third-party and vendor dependencies. Cryptography is often embedded deep inside libraries and products where teams have never had to look. A thorough inventory turns an abstract threat into a concrete, prioritizable list of systems.

2. Prioritize long-lived and high-value data

Not everything migrates at once, and not everything is equally urgent. Because harvest now, decrypt later targets confidentiality that must survive for years, the highest priority is data with a long secrecy lifetime that traverses networks an adversary could be recording. Rank systems by two questions: how long must this data stay confidential, and how exposed is it in transit or in retained storage? Health data, financial records, intellectual property, and long-lived keys and credentials typically rise to the top. Short-lived, low-sensitivity data can follow later. This prioritization is where the abstract Mosca calculation becomes an actual project plan.

3. Roll out hybrid post-quantum cryptography

With priorities set, begin deploying post-quantum protection — favoring the hybrid constructions discussed above, such as X25519 combined with ML-KEM for key exchange, and adopting ML-DSA and, where appropriate, SLH-DSA for signatures, certificates, and code signing. Start where you control both ends of a connection and can test safely, then expand. Validate performance and interoperability under production-like load, since larger keys and ciphertexts occasionally surface assumptions buried in older systems. Hybrid rollout is what actually closes the harvest-now-decrypt-later window for the data you have prioritized.

4. Build crypto-agility

The final goal is not simply to swap RSA for ML-KEM and declare victory. It is crypto-agility: the ability to change cryptographic algorithms again, quickly and with minimal disruption, whenever the need arises. The current transition is painful for many organizations precisely because cryptographic choices were hardwired into applications and infrastructure decades ago. Building agility means abstracting cryptography behind well-defined interfaces, centralizing algorithm and key management, and treating "which algorithm" as a configuration decision rather than a code rewrite. An enterprise that emerges from this migration with genuine crypto-agility will handle the next transition — and there will be a next one — as routine maintenance rather than a crisis.

In practice, crypto-agility is less a single feature than a set of engineering patterns worth naming explicitly:

• Abstraction over direct calls. Application code should request "encrypt this" or "sign this" from a cryptographic service or library interface, never name a specific algorithm inline. When the algorithm is a parameter rather than a hardcoded call, changing it later does not require touching business logic.
• Algorithm identifiers in the data. Ciphertexts, signatures, and stored keys should carry a machine-readable label of the algorithm and parameters that produced them. This lets systems decrypt or verify old data with the old algorithm while producing new data with the new one — the essence of a graceful transition rather than a flag-day cutover.
• Centralized policy. Which algorithms are approved, and at which parameter sets, should be governed in one place — a policy that key-management systems and services consult — rather than rediscovered independently in every codebase. Centralization is what makes an org-wide change a configuration update.
• A maintained cryptographic inventory. The inventory built in phase one is not a one-time artifact. Kept current, it becomes the map you use to scope the next migration in days rather than months.
• Negotiation and fallback. Protocols that can negotiate algorithms between endpoints, and fall back safely, let a fleet migrate incrementally without breaking interoperability with systems that have not yet moved.

These patterns pay for themselves immediately, because the hybrid rollout in phase three is itself an exercise in agility: supporting two algorithms at once and labeling which produced what is exactly the muscle you will use again. An organization that treats this migration as a chance to build durable agility turns a forced, expensive project into a lasting capability.

Common migration pitfalls

Enterprises that stumble on PQC migration rarely do so because the cryptography is wrong. They stumble on the operational realities around it. A handful of pitfalls recur often enough to be worth flagging in advance, because each is far cheaper to avoid than to remediate.

Treating the inventory as optional

The single most common failure is starting to deploy before knowing what exists. Teams migrate the systems they can see — public web endpoints — while quantum-vulnerable cryptography quietly persists in internal service-to-service traffic, backup encryption, database TDE, message queues, and embedded devices. A migration that skips a rigorous inventory delivers a false sense of completion. The systems you never catalogued are exactly the ones that surface as gaps years later.

Forgetting the vendor and supply-chain surface

Much of an enterprise's cryptography is not its own. It lives inside purchased software, SaaS platforms, hardware security modules, and network appliances. If those vendors have not moved to post-quantum algorithms, parts of your estate cannot be migrated no matter how agile your own code is. Building vendor readiness into procurement — asking for a PQC roadmap and contractual commitments — is part of the work, and it takes lead time that only starts counting once you ask.

Ignoring performance and size until production

Larger keys, ciphertexts, and signatures are usually harmless, but "usually" is not "always." Constrained devices, high-connection-rate services, and protocols with rigid length assumptions can behave badly under post-quantum sizes. Discovering this in a load test is a tuning exercise; discovering it in production during an incident is not. Validate under realistic conditions before broad rollout.

Confusing "installed" with "in use"

Adding a post-quantum-capable library to a system does not mean traffic is actually using it. Negotiation can silently fall back to classical algorithms, feature flags can remain off, and legacy endpoints can pin old suites. Verification — measuring what algorithms real connections negotiate — is the only way to know the protection you deployed is the protection you are getting.

Neglecting long-lived stored data

Migrating cryptography going forward protects new data, but archives encrypted under classical algorithms remain exactly as exposed as the day they were written. For data that must stay confidential for decades, re-encrypting or re-protecting existing stores — not just securing new writes — is part of closing the harvest-now, decrypt-later window rather than merely narrowing it.

Common misconceptions

Because the topic mixes real cryptography with a great deal of marketing, several persistent myths get in the way of good decisions. Clearing them up is part of planning well.

"No quantum computer can break RSA yet, so there's nothing to do."

This ignores harvest now, decrypt later. The relevant clock is your data's required secrecy lifetime plus your migration time, not the arrival date of a quantum computer. For long-lived data, waiting for a CRQC to appear means acting too late by definition.

"We'll just wait for a firm timeline before starting."

There will be no reliable early warning. Progress in quantum computing is not linear or publicly telegraphed, and an adversary's capability will not be announced. Because migration itself takes years, an organization that starts only once a CRQC is confirmed has already lost the race for any data that needed protecting in the interim.

"Post-quantum cryptography needs a quantum computer to run."

It does not. PQC algorithms run on ordinary classical hardware — the servers, laptops, and cloud instances you already operate. That is what makes broad deployment feasible. The confusion usually stems from conflating PQC with quantum key distribution, which is a different, hardware-dependent approach.

"Quantum computing breaks all encryption, including AES."

No. Shor's algorithm breaks public-key cryptography; Grover's algorithm only halves symmetric-key strength. AES-256 remains secure. The migration is overwhelmingly about key exchange and signatures, not about replacing your bulk data encryption.

"Once we adopt ML-KEM, we're finished."

Adopting the NIST standards is essential, but the durable goal is crypto-agility. Algorithms evolve, and parameters can change as cryptanalysis advances. An organization that hardwires ML-KEM as rigidly as it once hardwired RSA has simply set up the next painful migration. The point is to make algorithm changes routine.

How Deflected helps

Understanding post-quantum cryptography is one thing; executing a migration across a real enterprise is another. Deflected treats PQC not as a checkbox but as a program with a defined start, a prioritized sequence, and a durable end state in crypto-agility. Two parts of our platform bear most directly on the quantum threat.

Our Quantum-Safe Migration service maps directly onto the four-phase roadmap above: it starts with a cryptographic inventory, prioritizes the data most exposed to retrospective decryption, deploys hybrid post-quantum key exchange and NIST-standard signatures, and finishes by building the agility to change algorithms again without re-architecting systems. It is a services engagement, scoped and quoted per environment, so the plan reflects your actual estate rather than a generic template.

Underneath the services, post-quantum cryptography is simply how the Deflected platform protects everything it touches by default. Every byte that flows through Deflected is secured with hybrid X25519 + ML-KEM key exchange, ML-KEM-1024 and ML-DSA-87 at the strongest parameter sets, SLH-DSA where hash-based signatures fit best, and AES-256 for symmetric encryption at rest and in transit. You can read the full breakdown of our encryption approach on the platform overview, and see how it fits our broader posture on the security page. The principle is consistent: the data your customers entrust to you should be protected not only against today's attackers, but against the cryptographic threats of the coming decade.

Frequently asked questions

The takeaway

Post-quantum cryptography is no longer speculative. The threat is well understood: Shor's algorithm breaks the RSA and ECC that secure nearly every enterprise system, while Grover's algorithm leaves AES-256 comfortably intact. The timeline is uncertain, but the harvest-now-decrypt-later threat removes the option of waiting for certainty — for any data with a long secrecy lifetime, the exposure is already real. And the tools are ready: NIST has finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), with hybrid constructions like X25519 + ML-KEM offering a safe path through the transition.

What remains is execution. An enterprise that inventories its cryptography, prioritizes its most exposed long-lived data, rolls out hybrid post-quantum protection, and builds genuine crypto-agility will not only close the quantum window — it will be positioned to handle whatever comes after it as routine. The migration is a multi-year effort, which is exactly why the right time to start is now.