Post-Quantum Cryptography Is Now a Core Network Security Interview Topic

NIST finalized its first three post-quantum cryptography standards in August 2024 — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — and in April 2026, Meta's engineering organization published a detailed account of its own internal migration framework, including the maturity model it uses to track quantum-readiness across its infrastructure. Between the finalized standards and a hyperscaler publicly showing its migration work, post-quantum cryptography has moved from a theoretical topic to something senior network security interviews are now asking about directly — not as a future concern, but as a program already underway.

The reason migration cannot wait for quantum computers to actually exist is a threat model called harvest-now-decrypt-later. An attacker does not need a working quantum computer today — only access to encrypted traffic in transit. They record it now, and decrypt it later once a cryptographically relevant quantum computer exists and can break the RSA or elliptic-curve key exchange that protected it. This is passive interception: it generates no alerts, no anomalous traffic pattern, and no log trace, which is exactly why national security agencies have publicly confirmed that state-linked actors are already running this kind of collection against data with long confidentiality value. Meta's framework treats harvest-now-decrypt-later exposure as the top migration priority for exactly this reason — anything encrypted only with classical key exchange today is already at risk, regardless of when a quantum computer arrives.

ML-KEM is the mechanism that closes that gap for key exchange. It replaces classical Diffie-Hellman and RSA key exchange in TLS, VPN tunnels, and other encrypted channels with a lattice-based key encapsulation mechanism — public keys of roughly 1,200 bytes and ciphertexts of roughly 1,100 bytes, both meaningfully larger than the classical algorithms they are standing in for. ML-DSA plays the equivalent role for digital signatures, replacing RSA or ECDSA in certificates and code-signing paths. SLH-DSA exists as a structurally different, hash-based signature scheme kept in reserve — if a future cryptanalytic advance ever weakens the lattice assumptions underneath ML-KEM and ML-DSA, SLH-DSA does not share that failure mode, which is why NIST standardized a mechanism built on entirely different mathematics rather than betting the whole migration on one approach.

Almost nobody is deploying pure post-quantum cryptography in 2026 — what is actually shipping in browsers, CDNs, and cloud platforms today is hybrid key exchange: a TLS handshake runs classical ECDH and ML-KEM in parallel and derives the session key from both outputs. An attacker has to break both algorithms to compromise the session, which matters because ML-KEM, despite NIST standardization, is still a comparatively young algorithm family relative to decades of cryptanalysis against RSA and ECDH. Interviewers ask candidates to explain hybrid key exchange specifically because it tests whether you understand migration as a defense-in-depth engineering decision, not just a protocol swap — the honest answer is that nobody, including NIST, is confident enough to remove the classical layer yet.

Meta's five-level maturity model — PQ-Unaware, PQ-Aware, PQ-Ready, PQ-Hardened, and PQ-Enabled — is worth knowing not because you will be quizzed on the exact labels, but because it is the shape interviewers expect a migration answer to take. PQ-Unaware means an organization has not yet inventoried where classical cryptography is used. PQ-Aware means the inventory and risk assessment exist but implementation has not started. PQ-Ready means hybrid mechanisms are implemented but not yet deployed everywhere they need to be. PQ-Hardened means deployment is complete everywhere currently possible, but gaps remain because some vendors or embedded systems do not yet support post-quantum primitives at all. A candidate who can walk through why an organization gets stuck at PQ-Hardened — and what that implies about vendor contracts and legacy hardware — is demonstrating real operational understanding, not just recall of NIST algorithm names.

The operational cost interviewers probe next is size. ML-KEM's larger public keys and ciphertexts mean a hybrid TLS handshake carries meaningfully more bytes than a classical-only handshake did — enough to affect CPU load on TLS-terminating load balancers at hyperscale, and enough to interact badly with constrained links or MTU-sensitive paths if nobody accounts for it. This is the detail that separates a candidate who has memorized 'post-quantum cryptography is more secure' from one who has thought about what breaks when every handshake in a fleet of millions of connections gets measurably larger, and what capacity planning that requires before a mandatory migration deadline arrives.

The interview question pattern for this topic clusters around three areas. The first is mechanism: why hybrid key exchange rather than pure ML-KEM today, and what specifically each layer protects against. The second is migration strategy: given a large, partly legacy estate and a fixed migration window, how do you sequence the work — cryptographic inventory first, then prioritization by harvest-now-decrypt-later exposure and data confidentiality lifetime, then staged hybrid deployment. The third is failure handling: what happens when a hybrid-capable client negotiates with a classical-only server, how that negotiation is supposed to degrade safely, and how you would monitor a large fleet to know which systems have and have not completed migration.

Most candidates preparing for network security roles know the acronyms — ML-KEM, quantum-safe, post-quantum — without having reasoned through migration as an operational program under real constraints: legacy hardware that cannot be patched, vendors on their own timelines, and a performance budget that does not disappear just because the cryptography changed. Practise explaining harvest-now-decrypt-later out loud until the urgency argument is automatic, then practise walking through a staged migration the way Meta's maturity model does — inventory, prioritize, deploy hybrid, account for what does not move. Betty, My Next Hop's AI mock interviewer, runs exactly this kind of migration-under-constraint scenario on the Network Security Engineer track, including follow-up questions that test whether your staging logic actually holds up or just sounds structured.

NIST's guidance assumes roughly a ten-year migration horizon, but 2026 is when the hardest sequencing decisions are actually being made — vendor contracts increasingly requiring post-quantum readiness, national security systems operating on their own accelerated mandates, and hyperscalers publishing migration frameworks precisely because the work is underway now, not scheduled for later. Treat this as required depth for a senior network security interview in 2026, not a topic you can defer to 2029.

More from the blog