Post-quantum cryptography

A quantum computer is a machine that computes with qubits, which can hold a combination of 0 and 1 at the same time and can be linked so that their states depend on each other. For most tasks it is no faster than an ordinary computer. For a few problems with the right mathematical structure, a quantum algorithm makes the wrong answers cancel out and the right one stand out, and that gives an enormous speed-up. Today's machines have too few qubits and too many errors to threaten encryption. Breaking it would need a large, fault-tolerant machine that corrects its own errors, which nobody has built yet. For your company the practical point is narrow: such a machine would break the public-key cryptography that protects almost every connection you make, so the replacement has to be planned before it exists.

Because a large, fault-tolerant quantum computer running Shor's algorithm could break the public-key methods used today to agree keys and sign data: RSA and elliptic-curve cryptography (ECC). Those two protect the key exchange of almost every HTTPS, VPN and SSH connection, and the signatures on certificates, software updates and documents. An attacker with such a machine could read traffic recorded earlier and forge signatures. Symmetric encryption such as AES, which encrypts the data once the key is agreed, is weakened only modestly by Grover's algorithm and stays usable with 256-bit keys. No such computer exists today, and nobody can name the year one will. The risk is real for data that must stay secret for many years, and it is something to plan for, not an emergency. The fix is software, not hardware: new algorithms standardised by NIST in 2024, rolled out through updates.

It turns the hard problems they rely on into easy ones. RSA is safe because nobody can split a very large number into its two prime factors in reasonable time; elliptic-curve cryptography is safe because nobody can work out the secret number behind a public point on the curve. Peter Shor showed in 1994 that a quantum computer can find a hidden repeating pattern, a period, inside both problems, and from that period the secret follows quickly. On a large enough machine the attack takes a practical amount of time instead of an impossible one. Bigger keys do not save RSA or ECC: they only make the quantum attack somewhat slower. That is why the answer is new mathematics, such as the lattice problems behind ML-KEM and ML-DSA, for which no efficient quantum algorithm is known. Published estimates of the machine needed are still far beyond anything built so far.

Much less than Shor's algorithm means for RSA: it weakens symmetric encryption and hashing, but does not break them. Lov Grover showed in 1996 that a quantum computer can search through possibilities in about the square root of the usual number of steps. Applied to guessing a key, that roughly halves the key length in bits: in theory, a 128-bit AES key behaves more like a 64-bit one. In practice the attack is one very long chain of steps that cannot be usefully split across many machines, so even AES-128 stays far from easy to break. The common advice is simple: use AES-256 for data that must stay secret for a long time, and SHA-256 or stronger for hashing. Most modern systems already support both, so this part of the change is usually a configuration choice, not a migration project. The real work lies with the public-key methods.

Nobody knows, and anyone who names a year is guessing. A machine large and stable enough to run Shor's algorithm against today's key sizes needs advances in qubit quality, error correction and scale that have not been demonstrated yet. Expert surveys and vendor roadmaps give ranges, not dates, and the ranges move. Your planning does not depend on that date, though. Regulators have set their own timelines: the EU's coordinated roadmap of 23 June 2025 asks for high-risk use cases to be moved by the end of 2030, and NIST's transition guidance (NIST IR 8547, a draft in November 2024, final in October 2026) deprecates quantum-vulnerable public-key methods such as RSA and elliptic-curve cryptography after 2030 and disallows them under NIST standards after 2035. Customers, auditors and tenders will ask about those dates long before any quantum computer exists. For data that must stay secret for a decade or more, Mosca's inequality shows why waiting for the date is the wrong strategy.

Post-quantum cryptography (PQC) is public-key cryptography designed to stay secure against a large quantum computer while running on ordinary computers. NIST published the first standards on 13 August 2024: FIPS 203 (ML-KEM) for establishing keys, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. They rest on mathematical problems, such as finding short vectors in high-dimensional lattices, or on the security of hash functions, for which no efficient quantum attack is known. Migrating means updating software, libraries, protocols and certificates, not buying quantum hardware. It is also not the same as quantum key distribution, which needs special optical equipment. The price of the change is size: post-quantum keys and signatures are larger than today's, so handshakes grow and some old equipment struggles. Most organisations meet PQC first through updates of browsers, operating systems and VPN software, and then have to deal with their own servers and applications.

They are the first three post-quantum standards from the US National Institute of Standards and Technology (NIST), published on 13 August 2024 after an open, international competition that began in 2016. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism that lets two parties agree on a shared secret key; it takes over the role RSA and elliptic-curve Diffie-Hellman play in key exchange today. FIPS 204 specifies ML-DSA, the main digital signature scheme. FIPS 205 specifies SLH-DSA, a slower signature scheme with larger signatures that relies only on hash functions, kept as a conservative alternative. Although they are US federal standards, they are the reference worldwide: European agencies such as Germany's BSI and France's ANSSI recommend these algorithms, among others, usually combined with a classical one. For you, they are the names to look for in vendor documentation, product roadmaps and tender answers.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) is the post-quantum method for agreeing a secret key over an open network, and the one you will meet first. It grew out of the CRYSTALS-Kyber submission. One side publishes a public key; the other uses it to wrap a fresh random secret, and only the holder of the private key can unwrap it. That secret then keys fast symmetric encryption such as AES. It comes in three sizes, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, with 768 the common default. It is fast, often comparable to elliptic curves, but its public key and ciphertext are each around a kilobyte, against 32 bytes for X25519. That size is why some old firewalls and middleboxes struggle with post-quantum handshakes. In TLS, ML-KEM usually appears combined with X25519 as the hybrid group X25519MLKEM768, which is what most browsers already offer.

They are the two post-quantum signature standards: ML-DSA (FIPS 204, from CRYSTALS-Dilithium) and SLH-DSA (FIPS 205, from SPHINCS+). A digital signature proves who produced a piece of data and that nobody changed it; it protects certificates, software updates, firmware, documents and code. ML-DSA is the general-purpose choice: fast, with signatures of a few kilobytes instead of the 64 bytes a typical ECDSA signature takes. SLH-DSA relies only on the security of hash functions, which makes it very conservative, at the cost of larger signatures and slower signing; it suits long-lived roots of trust and firmware signing. Signatures matter less for harvest now, decrypt later, because a forged signature only helps an attacker once a quantum computer exists. That is why most organisations change key exchange first and signatures later. The certificate ecosystem for post-quantum signatures is still being built, so ask your suppliers for their plans rather than expecting post-quantum certificates today.

They are the next post-quantum algorithms on NIST's path, not yet final standards. HQC (Hamming Quasi-Cyclic) is a key-encapsulation method that NIST selected in March 2025 as a backup to ML-KEM. It rests on error-correcting codes rather than lattices, so if a weakness were ever found in lattice problems, an algorithm from a different mathematical family would be ready. NIST said at the time that it expected a draft standard about a year later and a final standard in 2027. FN-DSA, based on the FALCON submission, is a signature scheme planned as FIPS 206; its signatures are much smaller than ML-DSA's, which helps where space is tight, but it is harder to implement safely. For your planning, the lesson is not to bet on one algorithm forever. Choose products that can swap algorithms through configuration or updates. That ability, called crypto-agility, protects you if a standard changes or an implementation flaw appears.

Hybrid key exchange combines a classical method (X25519, an elliptic-curve exchange) with a post-quantum one (ML-KEM-768) in the same TLS handshake, and derives the session key from both. The key stays secret as long as either method holds: if a flaw were found in the still young ML-KEM, X25519 would still keep today's attackers out; against a future quantum computer, ML-KEM would. That is why most guidance, including from European agencies such as BSI and ANSSI, prefers hybrid during the transition. X25519MLKEM768 is the name of this combination in TLS. Major browsers already offer it by default, and large content-delivery networks and many cloud services accept it, so part of your web traffic may already use it without you having changed anything. A connection that uses it makes recorded traffic far harder to decrypt later. The ones to plan for are connections that still use only classical key exchange: older servers, appliances, VPNs and internal applications.

For almost every company, no. Quantum key distribution (QKD) uses the physics of single photons, sent over dedicated fibre or free-space links, to agree a key in a way that reveals eavesdropping. It needs special hardware at both ends, works over limited distances unless trusted relay stations are added, and does not authenticate the two parties by itself, so it still needs classical or post-quantum signatures. Post-quantum cryptography, by contrast, is software that runs on the networks and devices you already have. European security agencies, including Germany's BSI, France's ANSSI and the Dutch NLNCSA, have published a joint position that treats post-quantum cryptography as the main path and QKD as suited at most to niche uses. The EU's quantum communication infrastructure, EuroQCI, serves specific governmental needs and is a separate matter from what a mid-sized company should buy. If a vendor offers QKD as the answer to harvest now, decrypt later for an ordinary office network, ask what it does that a hybrid TLS or VPN configuration does not.

It means an attacker records encrypted traffic today and stores it, to decrypt it once a capable quantum computer exists. Recording is cheap and invisible to you: it can happen at an internet exchange, on a compromised router or at a provider, far from your own network. Only traffic whose key exchange is quantum-vulnerable is at risk, and only data that will still matter when it is decrypted. Health records, designs, source code, long-term contracts, legal files and personal data kept for many years are typical examples; this week's delivery schedule is not. A common way to weigh it is Mosca's inequality: if the years the data must stay secret plus the years your migration takes are more than the years until such a computer arrives, the time to start is now. The practical response is to move the key exchange that protects long-lived data to hybrid post-quantum methods first, because that is where today's recordings would become tomorrow's leaks. Signatures can follow later.

Data that crosses a network today and must stay confidential beyond the arrival of a large quantum computer. Ask two questions of each data set: does it travel over a connection with quantum-vulnerable key exchange, and for how many years would its disclosure still hurt? Typical long-lived examples are patient and HR records, product designs and source code, merger and legal files, public-sector contracts, biometric data and credentials that are never rotated. Short-lived data, such as a one-time code or this month's prices, is not worth worrying about. Stored data is a different question: it is usually protected by symmetric encryption such as AES, which a quantum computer does not break, unless its keys are exchanged or wrapped with RSA. Write the list down with an owner and a retention period per item: it becomes the priority order for your migration and the basis for the Mosca calculation. A network sensor cannot classify your data; that list comes from your business.

Put three numbers side by side for each important data set or system. X is how many years the data must stay secret. Y is how many years it will take you to move that system to post-quantum cryptography, including suppliers, testing and budget cycles. Z is how many years remain until a quantum computer can break today's public-key cryptography. If X plus Y is greater than Z, data sent today is already exposed to harvest now, decrypt later. Michele Mosca described the inequality in 2015, in a paper published as IACR ePrint 2015/1075. Z is unknown, so do not pretend to know it: try a cautious and a relaxed value and see which systems fail even under the relaxed one. For example, contracts that must stay confidential for 10 years, on a system that needs 5 years to migrate, fail for any Z under 15 years. The result is a priority list, not a forecast, and it is reasoning an auditor or a board can follow.

The threat is not hype, but much of the marketing around it is. The facts are solid: NIST published final standards in August 2024, browsers and large cloud providers already use hybrid post-quantum key exchange, and the EU has a coordinated roadmap with dates. What is uncertain is when a capable quantum computer will exist, and that uncertainty is exactly why planning beats waiting: changing cryptography across a company takes years. The hype lies in products that claim to make you immune to quantum attacks, in countdown clocks, and in pressure to buy hardware you do not need. A sober position for most mid-sized companies: no emergency spending, but an inventory this year, post-quantum questions in every new purchase, updates that switch on hybrid key exchange where vendors offer it, and priority for data that must stay secret for a long time. That costs little and avoids a rushed, expensive migration later.

Yes, as a planning and risk item, not as a crisis. It belongs on the board's agenda for three reasons. It is a long change across the company that touches suppliers, products and budgets over several years, and only management can sequence that. It affects data the company has promised to protect for many years, such as customer, patient or design data. And customers, insurers and public tenders are starting to ask about it, so the answer is becoming a commercial matter. Under NIS2, the management bodies of covered entities must approve and oversee the cybersecurity risk-management measures, and a policy on cryptography is one of them. What the board needs is short: an inventory of where quantum-vulnerable cryptography is used, a priority list based on how long data must stay secret, a named owner, and a timeline aligned with the EU's 2030 and 2035 milestones. It does not need a technical briefing on qubits.

Commission Recommendation (EU) 2024/1101 of 11 April 2024 asked Member States to coordinate the transition, and the NIS Cooperation Group published a coordinated roadmap on 23 June 2025: start the transition, protect high-risk use cases by the end of 2030 and move as many systems as feasible by 2035. It is a roadmap for Member States, not a law that binds your company directly; national authorities may turn it into guidance or rules. Its first practical step is knowing where you use cryptography.

That the transition has started everywhere. The coordinated roadmap published by the NIS Cooperation Group on 23 June 2025, following Commission Recommendation (EU) 2024/1101, sets three steps: first steps by the end of 2026, high-risk use cases moved by the end of 2030, and as many systems as feasible by 2035. The first step is about preparation: Member States set out national transition plans, organisations begin inventories of where they use quantum-vulnerable cryptography, and the risk of each use is assessed so that high-risk cases can be piloted early. The roadmap is addressed to Member States and their public and critical sectors, not directly to your company, and national authorities will translate it into their own guidance. Still, its logic applies to any organisation: by the end of 2026, know where your cryptography is, who owns each system, and which ones must move first. Check what your national cybersecurity authority publishes.

Not by name, but both point in that direction. NIS2, Directive (EU) 2022/2555, requires covered entities to have policies and procedures on the use of cryptography and, where appropriate, encryption, as part of the cybersecurity risk-management measures in Article 21. The Cyber Resilience Act, Regulation (EU) 2024/2847, requires products with digital elements to protect the confidentiality of data with state-of-the-art mechanisms, among the essential requirements in its Annex I. Neither names an algorithm. The state of the art moves, though: once NIST standards, European agency guidance and the EU roadmap treat hybrid post-quantum key exchange as normal, a product or a policy that ignores it becomes harder to defend in an audit or a tender. The EU roadmap itself presents the post-quantum transition as a no-regret step that supports NIS2 and the CRA. Check your national transposition of NIS2 and any guidance from your national authority, because the details can differ by country.

Mostly cheap, ordinary things. First, keep browsers, operating systems, VPN clients, servers and libraries up to date: much of the post-quantum change arrives through updates, and modern browsers already use hybrid key exchange by default. Second, list where you use cryptography you control yourself: your website and its hosting, remote access, e-mail, file transfer with customers, and any appliance with its own certificates. Third, mark the data that must stay secret for many years. Fourth, add one question to every new purchase or contract renewal: does the product support hybrid post-quantum key exchange, and if not, when? Fifth, prefer suppliers that can change algorithms through updates. Buying special quantum products is not on the list. NetSenX can help with the second step: NQCI, in preview, is visible on every plan and active from the Pro plan, and needs the packet-capture sensor, off by default, switched on for a Linux agent or a SPAN/TAP sensor; the basic macOS mode does not see handshakes.

Years for most organisations, which is why starting early matters more than the exact deadline. The change touches every place that agrees keys or signs data: websites, VPNs, SSH, e-mail, internal applications, certificates, hardware security modules, smart cards, machines and their firmware. Much of it depends on suppliers shipping post-quantum support, and on your own replacement cycles: a firewall bought this year may still be running in the next decade, and an industrial controller far longer. Past changes give a sense of scale: retiring SHA-1 and the old TLS versions took the industry many years from the first warnings to the final switch-off. A small company that runs mostly cloud services and up-to-date software may get much of the way through ordinary updates, inside a normal refresh cycle. A company with in-house software, long-lived devices or its own certificate authority should expect a programme spread over several years. The Y in Mosca's inequality is your own estimate, so write it down with its reasons.

You protect today's traffic from tomorrow's decryption, and you get several gains that do not depend on quantum computers at all. Data with a long shelf life stops being exposed to harvest now, decrypt later as soon as its key exchange moves to a hybrid method. The inventory you build along the way finds old TLS versions, weak ciphers, expired or forgotten certificates and unmanaged servers, which are risks today. Building crypto-agility, the ability to change algorithms by configuration, makes the next forced change cheaper, whatever triggers it. Commercially, you can answer tender and customer questions with facts and dates instead of a blank, and you are ready when national authorities turn the EU roadmap into guidance. Done within normal replacement cycles, the migration costs far less than one done under time pressure. What you do not gain is immunity: post-quantum cryptography protects key exchange and signatures, not stolen passwords, phishing or unpatched systems.

Mostly compatibility and performance, rarely the mathematics. Post-quantum keys are larger, so a TLS ClientHello carrying X25519MLKEM768 no longer fits in a single network packet; some older firewalls, load balancers and intrusion-prevention appliances mishandle that and drop or reset the connection. Hardware security modules, smart cards and embedded devices may lack the memory or firmware for the new algorithms. Signatures of several kilobytes enlarge certificate chains and slow down constrained links. Young implementations can contain bugs, which is one reason to use hybrid methods and well-maintained libraries. Interception proxies that decrypt TLS may not support the new groups and quietly push connections back to classical key exchange. Plan for it: test with real traffic in a staging segment, keep the classical fallback during the transition, check that middleboxes are updated, and measure afterwards which connections actually use hybrid key exchange. A view of the handshakes on the wire shows regressions that configuration files do not.

Crypto-agility is the ability to change the cryptographic algorithms a system uses without rewriting or replacing the system. In practice it means that algorithms are chosen by configuration, not hard-coded; software uses maintained libraries that receive new algorithms through updates; certificates and keys are managed centrally, with known owners and expiry dates; and you know where each algorithm is used. It matters now because the post-quantum transition will not be the last one: HQC and FN-DSA are still coming, parameters may be revised, and a flaw could appear in a young implementation. An organisation that makes one painful, manual migration will face the same pain next time; one that builds agility turns the next change into a configuration release. Ask about it in every purchase: can the product change its key-exchange and signature algorithms by update or setting, and does the vendor commit to doing so? A product that cannot is a migration problem you are buying today.

Increasingly, yes, but you have to check each product. OpenSSH made a hybrid post-quantum key exchange its default in version 9.0 in 2022, and version 10.0 in 2025 made the ML-KEM-based hybrid mlkem768x25519-sha256 the default; if both ends run current releases, your SSH sessions probably already use it. For VPNs the picture varies. The IPsec key exchange IKEv2 gained a standard way to add extra key exchanges, such as ML-KEM, in RFC 9370, and some vendors and open-source projects support it while others have only announced it. WireGuard can add a pre-shared symmetric key as an extra post-quantum protection layer, but its handshake itself is classical. Check the release notes of your firewall or VPN gateway firmware and the client versions actually in use, and remember that an old server at one end keeps the whole connection classical. Remote-access and site-to-site VPNs carry a lot of long-lived data, so they deserve a high place in your migration order.

Start with an inventory: certificates, VPNs, TLS on your servers, SSH, code signing and the libraries your applications use. Network traffic shows a large part of it, because the key exchange of each TLS connection is visible without decryption. NQCI, the NetSenX crypto inventory (in preview), is visible on every plan and active from the Pro plan: it shows which connections use quantum-vulnerable key exchange and which use hybrid post-quantum key exchange. It needs the packet-capture sensor, which is off by default: switched on for a Linux agent, or a sensor on a SPAN or TAP port. The agent's basic mode, used on macOS, does not see TLS handshakes. It gives visibility; the migration itself stays with you and your vendors.

A large part of it, yes, but not all of it. Every TLS connection announces, before any encryption starts, which key-exchange groups the client offers and which one the server picks, as well as the TLS version; SSH works in a similar way. A sensor that sees those handshakes can list, per server and per client, where quantum-vulnerable key exchange is still used and where hybrid post-quantum key exchange already is, for every device on the segment, including printers, appliances and machines that cannot run an agent. What it cannot see: cryptography inside applications and databases, keys and certificates stored on disk, code signing, encrypted backups, segments that are not monitored, and connections whose handshake never crosses the sensor. NQCI, the NetSenX crypto inventory (in preview), is visible on every plan and active from the Pro plan; it needs the packet-capture sensor, off by default, switched on for a Linux agent or a sensor on a SPAN or TAP port. The basic macOS mode does not see handshakes. Combine it with a certificate inventory and supplier questionnaires.

Look at the key-exchange group chosen in each TLS handshake: X25519MLKEM768 means hybrid post-quantum; X25519, secp256r1 or an RSA key exchange mean classical only. For a single server you can test from outside: OpenSSL 3.5 and later, and tools built on it such as curl, can offer the hybrid group and show what the server chooses, and some online TLS checkers report it. Browser developer tools also show the negotiated group for a site you visit. For the whole network a one-off test is not enough, because what matters is what really happens between your clients and servers every day: old clients, appliances and internal applications often fall back to classical groups. NQCI, in preview, shows this per connection on monitored traffic. It is visible on every plan and active from the Pro plan, with the packet-capture sensor switched on for a Linux agent or a SPAN or TAP sensor, because the basic macOS mode does not see handshakes. The result shows where updates have already done the migration and where it is still to do.

For each place where cryptography protects something, record what is protected, how, and who can change it. Practical fields: the system or service and its owner; what it protects, with the data type and how many years it must stay secret; the protocol, such as TLS, SSH, IPsec, S/MIME, code signing, or disk and database encryption; the algorithms for key exchange, signatures and encryption, with key sizes; certificates, their issuer and expiry; the library or product version and whether the vendor has a post-quantum plan; and whether the algorithm can be changed by configuration. Add a priority derived from Mosca's inequality. Sources differ by layer: network observation for what crosses the wire, certificate management and scanners for certificates, software composition analysis and supplier questionnaires for what sits inside applications. An inventory that lists only certificates misses key exchange, and one built only from the network misses data at rest. Keep it current, because each update can change the answer, and date every entry: auditors and tenders ask when it was last checked.

No, and no network monitoring product can. Protection against a future quantum computer comes from changing the cryptography in your own systems and in those of your suppliers: hybrid key exchange first, then post-quantum signatures. NetSenX is not an encryption product and does not change, upgrade or migrate anything. What it gives you is visibility, which is where every migration starts. NQCI, the NetSenX crypto inventory, is in preview: visible on every plan and active from the Pro plan. It shows which connections in monitored traffic still use quantum-vulnerable key exchange and which already use hybrid post-quantum key exchange, so you can see where updates have already done the work and where they have not, and spot regressions later. It needs the packet-capture sensor, which is off by default: switched on for a Linux agent, or a sensor on a SPAN or TAP port; the basic macOS mode does not see handshakes. It does not see cryptography inside applications, on disk or on segments that no sensor watches.

With facts about your plan, not slogans. Evaluators usually look for four things: that you know where you use quantum-vulnerable cryptography, that you have prioritised it, that you have a timeline, and that someone owns it. A strong answer names the inventory and its date; the method of prioritisation, for example Mosca's inequality applied to data retention periods; the steps already taken, such as hybrid key exchange enabled on public services and VPN and SSH versions checked; the dependencies on suppliers, with their stated plans; and milestones aligned with the EU's coordinated roadmap: first steps by the end of 2026 and high-risk use cases by the end of 2030. Refer to the NIST standards FIPS 203, 204 and 205 by name. Do not claim that your service is immune to quantum attacks, which an informed evaluator will mark down. If your inventory comes partly from network observation, say so and say what it does not cover. An honest partial answer with dates scores better than a confident blank.

Ask questions that have verifiable answers. Which post-quantum or hybrid algorithms does the product support today, by name, such as X25519MLKEM768 for TLS or ML-DSA for signatures, and from which version? If none yet, in which release and by when? Can the algorithms be changed by configuration or update, without replacing hardware? Which cryptographic library does the product use, and who maintains it? Does the hardware, such as a firewall, a hardware security module or a controller, have the capacity for larger keys, or will it need replacing? How will the vendor sign its own updates once signature algorithms change? Will the product keep working with clients that only support classical algorithms during the transition? Ask for the answers in writing, with dates. Be careful with answers that promise immunity to quantum attacks or that only talk about symmetric encryption: they avoid the real question. A vendor that cannot answer is a dependency to plan around, and its answer belongs in your inventory.