The Post-Quantum Encryption Stack, Explained

A post-quantum encryption stack is not a single algorithm you switch on. It is a deliberately layered arrangement of cryptographic primitives, chosen so that no one component — and no one mathematical assumption — is the only thing standing between an attacker and your data. This article documents Deflected's active encryption stack in full: the seven components that protect every byte moving through the platform, why each was selected, and how they reinforce one another. Every algorithm name and standard here is exact, and none of it is aspirational — it is the default posture across the platform, described in detail on our platform overview and security pages.

Defense in depth, applied to cryptography

Security engineers have long understood defense in depth: you do not rely on a single wall, you build overlapping layers so the failure of any one control does not become the failure of the whole system. Cryptography is usually treated as the exception. For decades, a typical connection leaned on essentially one public-key algorithm to establish trust, and if that algorithm were broken, everything protected by it would fall at once. In a world where a future quantum computer could, in principle, break the classical public-key algorithms that secure most of the internet, that single-wall model is no longer prudent.

The response is to apply defense in depth to the cryptography itself. Rather than betting everything on one primitive, a modern stack composes several — each doing a distinct job, each resting on a different hardness assumption, and several deliberately duplicated so that two independent things would have to break at once for security to fail. That is the philosophy behind Deflected's encryption stack, which separates into three functional concerns:

• Confidentiality — keeping data unreadable to anyone without the key. This is the job of the symmetric cipher, and of the key-establishment mechanisms that get a shared key to both parties in the first place.
• Authenticity and integrity — proving that data came from who it claims to and has not been altered. This is the job of digital signatures and authenticated encryption.
• Resilience over time — ensuring that a compromise tomorrow does not retroactively expose what was protected today, and that the whole scheme can evolve as the threat landscape does. This is the job of hybrid constructions, ephemeral keys, and crypto-agility.

A useful mental model is that public-key cryptography is how two parties who have never met agree on a secret; symmetric cryptography is how they then use that secret to protect a large volume of data efficiently; and signatures are how each party proves who it is along the way. The quantum threat lands hardest on the first of those three. Understanding which parts of the stack are exposed to quantum attack, and which are not, is the key to reading the rest of this article. We take the components in the order they tend to matter during a connection: establishing keys, proving identity, and then bulk-encrypting data.

The threat model the stack is built against

Every design decision below answers to a specific adversary. That adversary is assumed to be able to observe and record all network traffic; to store what it captures indefinitely at low cost; to compromise a long-term private key at some future point; and, eventually, to operate a cryptographically relevant quantum computer capable of running Shor's algorithm at scale. Crucially, these capabilities are not simultaneous — the recording happens now, and the decryption capability arrives later. A stack that is secure only against an adversary who must attack in real time is not secure against one who is patient. This is the distinction that separates a genuinely forward-looking design from one that merely swaps in a new algorithm name.

Two principles follow from taking that adversary seriously. First, no component may be a single point of cryptographic failure: if breaking one algorithm — even a brand-new one — is enough to unlock everything, the design has failed the defense-in-depth test regardless of how strong that algorithm looks today. Second, the compromise of any long-term secret must have a strictly bounded blast radius: it may allow impersonation going forward, but it must not retroactively expose data that was already protected. These two principles — assumption diversity and bounded blast radius — recur throughout the stack, and they are the reason it has seven components rather than three.

ML-KEM-1024 — post-quantum key encapsulation

The first job in almost any secure exchange is agreeing on a shared secret key between two parties who may never have communicated before. Historically this was done with algorithms like RSA or elliptic-curve Diffie–Hellman, whose security rests on the difficulty of integer factorization or the discrete logarithm problem. Those are precisely the problems that Shor's algorithm, running on a sufficiently large quantum computer, solves efficiently. A cryptographically relevant quantum computer would render classical public-key key exchange readable. The replacement for that role is a post-quantum key encapsulation mechanism, or KEM.

What a KEM actually does

A KEM is a specific, disciplined way to establish a shared secret. It has three operations. Key generation produces a public/private key pair. Encapsulation takes the recipient's public key and outputs two things: a ciphertext to send, and a shared secret to keep. Decapsulation takes that ciphertext and the private key and recovers the same shared secret. The sender never has to transmit the secret itself — only the ciphertext, from which only the holder of the private key can derive the secret. That derived secret then seeds the symmetric encryption that protects the actual data. KEMs are a cleaner abstraction than older public-key encryption for this purpose, which is why the post-quantum standards are built around them.

The encapsulation and decapsulation flow, step by step

It is worth tracing the flow concretely, because it explains several of ML-KEM's design choices. Suppose a client wants to establish a key with a server whose ML-KEM-1024 public key it already holds:

1. The client runs encapsulation against the server's public key. Internally, this samples fresh randomness, uses it together with the public key to produce a lattice-based ciphertext, and derives a shared secret by hashing that randomness and the ciphertext together. The client keeps the shared secret and transmits only the ciphertext.
2. The server runs decapsulation using its private key. It decrypts the ciphertext to recover the client's randomness, then re-derives the same shared secret by the same hashing step. Because both sides fed the same inputs into the same key-derivation function, they now hold an identical secret without it ever having crossed the wire.
3. That shared secret is never used to encrypt data directly. It is passed through a key-derivation function to produce the actual symmetric session keys, keeping the KEM output structurally separated from the bulk cipher.

A subtle but important detail is how ML-KEM handles a malicious ciphertext. An attacker could try to exploit how a system reacts to invalid ciphertexts to learn about the private key — a chosen-ciphertext attack. ML-KEM defends against this with the Fujisaki–Okamoto transform: during decapsulation it re-encrypts the recovered message and checks that it matches the ciphertext it was given, and if the check fails it returns a deterministic pseudo-random secret rather than an error, so an attacker learns nothing from the system's behavior. This is what makes ML-KEM secure under the strong IND-CCA2 notion rather than merely against passive eavesdroppers — the kind of hardening that distinguishes a standardized primitive from a textbook one.

ML-KEM and its lineage

Deflected uses ML-KEM-1024, the Module-Lattice-Based Key-Encapsulation Mechanism standardized by NIST as FIPS 203. ML-KEM was formerly known as CRYSTALS-Kyber, the name it carried through the multi-year NIST post-quantum cryptography competition before it was selected and formalized. Its security rests on the hardness of the Module Learning With Errors problem — a lattice problem for which no efficient algorithm is known on either classical or quantum computers. This is a fundamentally different foundation than factorization or discrete logs, and critically, it is not one that Shor's algorithm addresses.

The -1024 designation refers to the highest of ML-KEM's three parameter sets. FIPS 203 defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024, in increasing order of security margin. ML-KEM-1024 targets NIST's Category 5, the strongest level, corresponding to a 256-bit quantum security level — resistance comparable to a 256-bit key against the best known attacks, including quantum ones. Deflected selects the highest parameter set rather than the lighter options because the platform protects long-lived, high-value data, where the cost of a larger key is trivial against the value of a wider margin.

ML-DSA-87 — post-quantum digital signatures

Establishing a shared key keeps data confidential, but confidentiality alone does not tell you who you are talking to, or whether a message arrived intact. That is the domain of digital signatures. A signature lets a recipient verify two properties at once: integrity, that the signed content has not been modified, and authenticity, that it was produced by the holder of a specific private key. Signatures underpin identity, code and update verification, certificate chains, and the authentication step of a key exchange — without them, an attacker could quietly interpose themselves in the middle of an otherwise-encrypted conversation.

Classical signature schemes such as RSA and ECDSA fall to the same quantum threat as classical key exchange, because they too rely on factorization or discrete logarithms. Deflected's post-quantum signature primitive is ML-DSA-87, the Module-Lattice-Based Digital Signature Algorithm standardized as FIPS 204. Like ML-KEM, it comes from the CRYSTALS family — its former name was CRYSTALS-Dilithium — and it is built on the same lattice foundations, drawing security from Module-LWE and a related short-vector problem. Reusing the same well-studied mathematical family for both key encapsulation and signatures is itself a design virtue: it concentrates cryptanalytic scrutiny on a smaller set of assumptions that the whole community examines continuously.

The -87 suffix denotes the highest-security parameter set defined in FIPS 204, corresponding to NIST security Category 5. ML-DSA is specified at three levels — ML-DSA-44, ML-DSA-65, and ML-DSA-87 — and, consistent with its choice of ML-KEM-1024, Deflected runs the strongest. ML-DSA-87 signs the artifacts that bind the platform's trust together: the authentication messages inside key exchanges, the integrity attestations on stored records, and the provenance of internal components. Because it is a lattice scheme rather than a factorization- or discrete-log-based one, its signatures are designed to remain unforgeable even against a quantum adversary — closing the authenticity gap that would otherwise let an attacker impersonate a trusted party or tamper with data undetected.

How signing and verification actually work

ML-DSA follows the "Fiat–Shamir with aborts" pattern. To sign, the signer hashes the message together with a commitment derived from fresh randomness and its private key, producing a challenge, then computes a response that ties the private key to that specific challenge. The "with aborts" part is a rejection-sampling step: if the candidate signature would leak information about the private key — if its values stray outside a safe range — the signer discards it and retries with new randomness. This is what prevents the signature from becoming a slow leak of the secret over many uses.

To verify, the recipient recomputes the challenge from the public key, the message, and the signature, and checks two things: that the algebraic relation between them holds, and that the response's magnitudes fall within the permitted bounds. If both pass, the signature is accepted; if the message was altered by even one bit, the recomputed challenge no longer matches and verification fails. The verifier needs only the public key and the message — never the private key — which is why signatures can be checked by anyone while only the key-holder can produce them. This verification step is what a party runs to confirm it is really talking to the intended peer during a handshake, and what a storage layer runs to confirm a record has not been tampered with since it was written.

SLH-DSA — a conservative hash-based backup

ML-DSA is efficient and well-analyzed, but it belongs to the lattice family — the same family as ML-KEM. Concentrating scrutiny is good, but concentrating risk is not: if a structural weakness were ever discovered in lattice-based cryptography, a stack that used lattices for everything would be uncomfortably exposed. This is why the stack includes a second, deliberately different signature scheme whose security rests on an entirely separate assumption.

That scheme is SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm, standardized as FIPS 205. It was formerly known as SPHINCS+. Its security does not depend on lattices, factorization, or discrete logarithms at all — it depends only on the properties of cryptographic hash functions, specifically their collision and preimage resistance. Hash functions are among the most battle-tested primitives in all of cryptography, studied for decades and relied upon everywhere, and their resistance to quantum attack is well understood and modest in impact. A signature scheme whose only assumption is "the underlying hash function is secure" is about as conservative a foundation as exists.

Why "stateless" matters

Early hash-based signature schemes were stateful: the signer had to track which one-time keys had already been used, and reusing one would catastrophically break security. Managing that state reliably across distributed systems, backups, and failovers is notoriously error-prone. SLH-DSA is stateless — it removes that requirement entirely, which is what makes it safe to deploy at scale without a fragile bookkeeping layer. The trade-off is that its signatures are larger and slower to produce than ML-DSA's, which is exactly why it serves as a backup and high-assurance option rather than the everyday default.

AES-256-GCM — the symmetric core

Public-key operations are relatively expensive, so they are used sparingly — to establish a shared secret and to prove identity. The heavy lifting of actually encrypting data, whether it is sitting in storage or streaming across a network, is done by a symmetric cipher, which uses the same key to encrypt and decrypt and is orders of magnitude faster. Deflected uses AES-256-GCM for symmetric encryption of data both at rest and in transit.

AES-256 is the Advanced Encryption Standard with a 256-bit key. The GCM — Galois/Counter Mode — is what makes it an authenticated cipher: it produces not only ciphertext but an authentication tag that lets the recipient verify the data was not tampered with, combining confidentiality and integrity in a single, efficient operation. This is why authenticated encryption modes like GCM are the modern default; encryption without integrity protection has historically been a rich source of real-world attacks.

How GCM authenticates as well as encrypts

GCM does two jobs in one pass. The counter half turns AES into a stream cipher: it encrypts a sequence of counter values and XORs the result with the plaintext, which is fast and parallelizable. The Galois half computes a message authentication code over the ciphertext — and over any associated data, such as headers that must be authenticated but not encrypted — using multiplication in a finite field, producing the authentication tag. On the receiving side the tag is recomputed and compared before the plaintext is released; if it does not match, the data is rejected outright rather than returned, so tampered or forged ciphertext never reaches the application. This is authenticated encryption with associated data (AEAD), and it closes off the padding-oracle and bit-flipping attacks that plagued older encrypt-only modes.

GCM has one non-negotiable rule: a given key must never reuse the same nonce (the counter's starting value). Nonce reuse is catastrophic — it can expose the authentication key and leak plaintext relationships — so the stack treats nonce management as a first-class concern. This is one of several places where the security of a well-studied primitive depends entirely on disciplined key and parameter management around it, a theme the key-lifecycle section returns to.

Why symmetric cryptography survives the quantum era

The most important and most misunderstood point about the quantum threat is that it does not apply equally to all cryptography. The dramatic break — Shor's algorithm — is specific to the structured mathematics of classical public-key schemes. Symmetric ciphers like AES have no such structure to exploit. The relevant quantum attack against them is Grover's algorithm, which speeds up brute-force search, but only quadratically. A quadratic speedup effectively halves the security level: against a 256-bit key, Grover's algorithm reduces the effective strength to roughly 128 bits.

A 128-bit effective security level is still comfortably beyond the reach of any conceivable brute-force attack, quantum or classical, and Grover's algorithm is difficult to parallelize efficiently, which further blunts its practical impact. The consequence is straightforward: well-chosen symmetric encryption with a large key does not need to be replaced for the post-quantum era. Choosing AES-256 rather than AES-128 is precisely what buys that margin, keeping the symmetric core quantum-resistant. This is why the migration challenge is overwhelmingly about public-key cryptography, and why the symmetric layer of the stack can remain a known, trusted quantity.

The contrast with Shor's algorithm is worth stating precisely, because conflating the two is the most common source of confusion about quantum risk. Shor's algorithm is an exponential speedup that dismantles the structured math underlying RSA and elliptic curves — it does not merely weaken those schemes, it renders them broken. Grover's algorithm is a quadratic speedup against unstructured search, and quadratic is a manageable factor, defeated simply by doubling the key length. In short, symmetric cryptography faces a headwind the industry has already accounted for by standardizing on 256-bit keys, while public-key cryptography faces a break that required inventing entirely new families of algorithms — the lattice and hash-based schemes that make up the rest of this stack.

Hybrid X25519 + ML-KEM key exchange

ML-KEM-1024 is a strong, standardized, quantum-resistant KEM. But it is also, in the long arc of cryptography, relatively new. Classical algorithms like elliptic-curve Diffie–Hellman have absorbed decades of intense cryptanalysis; lattice schemes have received enormous scrutiny during and since the NIST process, but less total elapsed time. Prudence says you should not have to bet everything on the newest scheme being flawless. The answer is a hybrid key exchange.

How a hybrid construction works

In a hybrid key exchange, both parties run two independent key-establishment algorithms in the same handshake — here, the classical X25519 elliptic-curve Diffie–Hellman and the post-quantum ML-KEM — and each produces its own shared secret. The two secrets are then combined through a key-derivation function into the single session key that actually protects the data. The essential property is this: an attacker must break both algorithms to recover the session key. Breaking only one is not enough, because the final key depends on both inputs.

The combiner: why the KDF is the load-bearing part

The security of a hybrid scheme lives in how the two secrets are combined, and this is more delicate than simply gluing them together. The two shared secrets — one from the X25519 exchange, one from the ML-KEM decapsulation — are concatenated and fed into a key-derivation function, typically an HKDF built on a hash function, which mixes them and stretches the result into the session keys the protocol needs. A well-designed combiner has a provable property: the output is secure as long as at least one of the inputs is secure. That is the mathematical guarantee behind the "belt and suspenders" claim — it is not merely that two algorithms are present, but that the combiner cannot be short-circuited by compromising just one of them.

The combiner also folds in transcript context so the derived keys are bound to this specific handshake and cannot be transplanted to another. Because a careless construction can quietly undermine the whole guarantee, hybrid deployments follow published combiner constructions rather than improvising — the combiner, not either algorithm alone, is the load-bearing part of the exchange.

That gives the construction a valuable "belt and suspenders" character. If a future quantum computer defeats X25519, ML-KEM still protects the session. If an unforeseen weakness were ever found in ML-KEM, the well-understood classical security of X25519 still protects it against today's non-quantum attackers. Security holds as long as either component holds. This is why hybrid deployment is the transitional posture recommended by most standards bodies and security agencies as organizations move to post-quantum cryptography. Deflected's hybrid X25519 + ML-KEM exchange is the front door of the stack: it is where confidentiality begins, and it is designed so that no single cryptographic surprise can open it.

Perfect forward secrecy via ephemeral keys

Establishing a strong session key is necessary but not sufficient. A further question is what happens if a long-term private key is compromised in the future. If every past session had been protected by that same long-term key, an attacker who eventually obtained it — and who had been recording traffic all along — could decrypt the entire history at once. Perfect forward secrecy, or PFS, is the property that prevents this, and it is a core part of the stack.

PFS is achieved with ephemeral keys: for each session, the parties generate fresh, short-lived key material used only for that exchange and then discarded. The long-term keys are used to authenticate the exchange — to prove identity — but not to derive the session secret directly. Because the ephemeral keys are destroyed when the session ends, there is nothing left for a future attacker to recover. Compromising a long-term key going forward does not unlock a single past session, because the secrets that protected those sessions no longer exist anywhere.

In Deflected's stack, the hybrid X25519 + ML-KEM exchange is run in ephemeral mode, so forward secrecy is preserved across both the classical and the post-quantum component. This matters acutely in the harvest-now, decrypt-later threat model: an adversary recording encrypted traffic today, hoping to decrypt it after a future key compromise or a future quantum computer, finds that each recorded session was sealed with keys that were thrown away the moment it ended. Forward secrecy turns "record everything and wait" from a patient strategy into a dead end.

Zero-knowledge proof architecture

The final component is less about moving data securely and more about a design principle for handling it: proving something is true without revealing the underlying data that makes it true. This is the province of zero-knowledge proofs. A zero-knowledge proof lets one party convince another that a statement holds — that a value falls within a permitted range, that a record satisfies a policy, that a credential is valid — while disclosing nothing beyond the truth of the statement itself.

Within the platform's design, this architecture supports verification workflows that would otherwise require exposing sensitive material: properties of data can be checked, and policy compliance attested, without the verifying component ever seeing the raw data behind the claim. Where encryption keeps data unreadable to outsiders, zero-knowledge techniques minimize how much even the system's own components must learn to do their jobs. It is data-minimization elevated to a cryptographic guarantee — you cannot leak what you were never required to reveal — complementing the confidentiality and authenticity layers rather than replacing them.

Where the stack lives: the handshake and the transport

Cryptographic primitives do not protect anything on their own; they protect data because a protocol orchestrates them at the right moments. For data in transit, that protocol is the transport-layer handshake — the negotiation that happens before any application data flows. Mapping the stack onto that handshake shows how the pieces fit together in practice, and where the post-quantum components slot into an architecture the industry already understands.

A handshake proceeds, in broad strokes, in three phases. In the negotiation phase, the two parties agree on which algorithms they will use; a hybrid deployment advertises the combined X25519 + ML-KEM group so that both the classical and the post-quantum exchange run together. In the key-establishment phase, they carry out that exchange: ephemeral X25519 keys are exchanged, an ML-KEM encapsulation and decapsulation are performed, and the two resulting secrets are run through the combiner described above to produce the handshake and application keys. In the authentication phase, each party presents a certificate and a signature — this is where ML-DSA-87, or SLH-DSA in higher-assurance contexts, proves identity so that neither side is talking to an impostor. Only once all of this completes does AES-256-GCM begin protecting the actual application data.

The important architectural point is that post-quantum cryptography does not require a new kind of protocol. It slots into the same handshake structure that has protected the web for years — the same phases, the same certificate model, the same record layer — changing only which algorithms occupy each slot. That continuity is deliberate: it is what lets hybrid key exchange be rolled out incrementally, one endpoint at a time, while remaining interoperable with peers that have not yet upgraded.

Data at rest follows the same logic

For data at rest, there is no live counterparty, but the pattern is analogous. A data-encryption key protects the records themselves with AES-256-GCM, and that key is itself wrapped — encrypted — by a higher-level key that is guarded more tightly and rotated on its own schedule. This envelope encryption arrangement means rotating the outer key does not require re-encrypting every record, only re-wrapping the data-encryption keys. Integrity attestations signed with ML-DSA-87 let the storage layer detect tampering, so at-rest data inherits the same confidentiality-plus-authenticity guarantee that GCM provides in transit.

How it all composes: quantum-secured by default

Read individually, each component solves one problem. The point of the stack is how they compose. Walk a single protected interaction from start to finish and the layering becomes concrete:

1. Two parties open a session and run the hybrid X25519 + ML-KEM-1024 key exchange in ephemeral mode. Two independent shared secrets — one classical, one post-quantum — are derived and combined into a single session key. Breaking either algorithm alone yields nothing, and the ephemeral keys guarantee forward secrecy.
2. The exchange is authenticated with post-quantum signatures — ML-DSA-87 as the everyday scheme, with SLH-DSA available as a hash-based, assumption-independent alternative — so each side proves its identity and no attacker can silently interpose.
3. The session key seeds AES-256-GCM, which encrypts the actual data with authenticated symmetric encryption at full speed, protecting both confidentiality and integrity for everything at rest and in transit.
4. Where the workflow only needs to verify a property rather than see the data, zero-knowledge techniques let that verification happen without exposing the underlying record.

No single point in that chain is a single point of failure. The key exchange survives the loss of either of its two algorithms; the signature layer spans two unrelated mathematical families; the symmetric core is already quantum-resistant by virtue of its key size; and past sessions are sealed by discarded ephemeral keys. This is what "quantum-secured by default" means in practice: not one clever algorithm, but a stack in which the assumptions are diversified and duplicated so surviving a surprise does not depend on any one of them being perfect. And because it is the default rather than an opt-in tier, there is no configuration in which data quietly falls back to classical-only protection.

Crypto-agility and the migration path

Standards evolve, parameters get revised, and new attacks occasionally shift the ground. A stack that is hard-wired to specific algorithms becomes a liability the moment any of that happens. The property that guards against it is crypto-agility: the ability to change cryptographic algorithms and parameters without re-architecting the systems that depend on them.

Crypto-agility is a design discipline more than a single feature. It means isolating algorithm choices behind clean interfaces, so a component asks for "authenticated encryption" or "a key exchange" rather than naming a specific primitive it can never let go of. It means maintaining a live inventory of everywhere cryptography is used — often the hardest part, because most organizations genuinely do not know where all their cryptography lives. And it means being able to introduce a new algorithm, run it in hybrid alongside the old one, and retire the old one on a schedule rather than in a panic. The hybrid key exchange in this stack is itself an expression of crypto-agility.

For organizations that need to bring their own systems to this posture, the migration is a structured engagement rather than a flip of a switch. It starts with discovering and inventorying existing cryptography, prioritizing the long-lived and high-value data most exposed to harvest-now, decrypt-later, and then rolling out post-quantum and hybrid schemes in phases with alignment to NIST FIPS 203, 204, and 205. That is precisely the scope of our Quantum-Safe Migration service, and it is the practical bridge between the stack described here and an enterprise's own estate.

Key lifecycle, rotation, and separation of duties

A stack of strong algorithms is only as trustworthy as the keys that drive it, and keys have a lifecycle that must be managed as rigorously as the cryptography itself. Every key passes through the same stages — generation, distribution, active use, rotation, and destruction — each with its own failure modes the design has to close off.

Generation depends entirely on the quality of randomness: a key is only as unpredictable as the entropy that produced it, so keys are generated from a properly seeded cryptographic random source, since weak or reused randomness is one of the most common ways otherwise-sound cryptography is broken in the field. Distribution is precisely the problem the KEM and hybrid exchange solve for session keys — secrets are established rather than transmitted. During active use, keys are held with least privilege, so that compromising the material that authorizes an operation does not automatically yield the material that can decrypt bulk data.

Rotation and the value of short-lived keys

Rotation is what bounds the damage of any single key's exposure. Session keys are ephemeral by construction and expire when the session ends, which is what delivers forward secrecy. Longer-lived data-encryption and key-encryption keys are rotated on a schedule, so even a slow, undetected leak has a limited window in which the key it exposed is still in service. Envelope encryption is what makes frequent rotation practical: re-wrapping a small number of key-encryption keys is cheap, whereas re-encrypting all underlying data would not be. Rotation also carries an operational benefit that is easy to overlook — a system that rotates keys routinely has proven it can, so responding to a suspected compromise, or adopting a new algorithm, is an exercise of an existing muscle rather than an emergency.

Destruction closes the lifecycle: when a key is retired, the goal is that no recoverable copy remains anywhere, because a key that lingers in a backup or a memory dump is one an attacker can still hunt for. Taken together, disciplined generation, least-privilege use, scheduled rotation, and reliable destruction are what turn a collection of good algorithms into a trustworthy system. Knowing exactly where every key lives and how each is rotated is also a prerequisite for changing the algorithms behind them, which is why the discovery and inventory phase of a Quantum-Safe Migration engagement spends as much time on key management as on the algorithms themselves.

Why it matters for your data

It is tempting to treat quantum threats as a problem for later, since a cryptographically relevant quantum computer does not yet exist in public knowledge. That intuition is wrong for one specific and important reason: harvest now, decrypt later.

An adversary does not need a quantum computer today to benefit from one tomorrow. They only need to capture encrypted data now and store it — network traffic can be recorded in bulk and archived cheaply. When a capable quantum computer eventually arrives, everything that was protected only by classical public-key cryptography becomes retroactively readable. The decisive question is therefore not "when will quantum computers break encryption?" but "how long does this data need to stay secret?" Any information with a secrecy lifetime measured in years — medical records, financial data, trade secrets, legal privilege, model weights — is effectively exposed the moment it crosses a classically protected channel.

This reframes post-quantum encryption from a future upgrade into a present obligation. Data encrypted today with the stack described here is protected against both the attackers of today and the retroactive decryption of tomorrow; data encrypted with classical-only cryptography is, in a real sense, already at risk. For a fuller treatment of the threat model and the transition timeline, see our companion piece on post-quantum cryptography, and the controls documented on our security page.

Frequently asked questions

The takeaway

Deflected's encryption stack is not a single quantum-safe algorithm bolted onto an otherwise-classical system. It is a genuinely layered post-quantum encryption stack: ML-KEM-1024 for key encapsulation, ML-DSA-87 and SLH-DSA for signatures across two unrelated mathematical families, AES-256-GCM as a symmetric core that is already quantum-resistant by design, hybrid X25519 + ML-KEM so security holds if either algorithm is weakened, ephemeral keys for perfect forward secrecy, and a zero-knowledge posture that minimizes what any component must reveal. Each rests on the finalized NIST standards — FIPS 203, 204, and 205 — and each is the default, not an upgrade. The result is a system designed to keep data confidential and authentic against the attackers of today and the quantum adversaries of tomorrow. To see how the stack fits into the wider platform, read the platform overview; to bring your own systems to the same posture, start with Quantum-Safe Migration.