Post-quantum readiness: where to start

Post-quantum readiness starts with a question you can answer today, long before any quantum computer exists: where does your organisation use public-key cryptography that a future quantum computer could break, and which of those places protect data that must stay secret for years? Regulators and customers have started to ask exactly that. The EU's coordinated roadmap, the US National Security Agency's CNSA 2.0 and the cryptography duty in NIS2 all point to the same first step: a cryptographic inventory, then a prioritised migration.

This guide covers what is actually being asked, how to judge the risk without hype, what the new standards are in plain words, how much of the inventory you can build from network traffic, and a migration plan.

What regulators are asking for

The EU roadmap. Commission Recommendation (EU) 2024/1101 of 11 April 2024 asked Member States to coordinate the transition to post-quantum cryptography. On 23 June 2025 the NIS Cooperation Group published the coordinated implementation roadmap: first steps by the end of 2026, including national plans and inventories of where quantum-vulnerable cryptography is used; high-risk use cases moved by the end of 2030; and as many systems as feasible by 2035. The roadmap is addressed to Member States and their public and critical sectors, not directly to your company, but national authorities are turning it into guidance, and its logic applies to anyone: by the end of 2026, know where your cryptography is.

NIS2. Directive (EU) 2022/2555 requires covered entities to have policies and procedures on the use of cryptography and, where appropriate, encryption, among the risk-management measures of Article 21. It names no algorithm. But "state of the art" moves, and once standards bodies and agencies treat post-quantum key exchange as normal, a cryptography policy that ignores it becomes harder to defend.

United States. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets the algorithms for US national security systems: ML-KEM-1024 for key establishment and ML-DSA-87 for signatures. The NSA expects the transition of those systems to be complete by 2035, in line with National Security Memorandum 10. It binds US national security systems and their suppliers, not European companies, but suppliers to defence and government customers meet it in contracts.

None of these makes a product, including ours, "compliant" on your behalf. They ask organisations to know their cryptography and to plan its replacement.

Harvest now, decrypt later, without the panic

An attacker who records encrypted traffic today can store it and decrypt it once a capable quantum computer exists. That is "harvest now, decrypt later". It does not threaten everything equally. Data that is worthless in two years, such as most session traffic, is not at risk. Data that must stay confidential for ten or twenty years is: contracts, health and personal records, intellectual property, credentials that are never rotated, and anything a state actor would want.

Michele Mosca's inequality turns that into a priority list. For each important data set, X is how many years it must stay secret, Y is how many years it will take you to migrate the systems that carry it, and 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, the data you send today is already exposed. Z is unknown, so try a cautious and a relaxed value and see which systems fail even under the relaxed one. Those are the ones to move first.

The new standards in plain words

In August 2024 NIST published the first three post-quantum standards. FIPS 203 (ML-KEM) is a key-encapsulation mechanism: it lets two parties agree on a secret key over an open network, the job RSA and elliptic-curve Diffie-Hellman do in key exchange today. FIPS 204 (ML-DSA) is the main digital-signature scheme, and FIPS 205 (SLH-DSA) a slower, hash-based alternative. In practice you will first meet ML-KEM inside TLS as the hybrid group X25519MLKEM768, which combines a classical and a post-quantum exchange so that the connection stays protected if either one holds. The plain-words guide to ML-KEM and ML-DSA goes further, including why the larger keys break some old middleboxes.

How much of the inventory the network can show

A cryptographic inventory, sometimes published as a CBOM (cryptography bill of materials), lists where each algorithm, protocol version and key is used, by which system, and who owns it. A good part of it is visible on the wire, without decrypting anything:

Key exchange per connection. Every TLS handshake announces, before encryption starts, which key-exchange groups the client offers and which one the server picks, and the TLS version. SSH does the same for its key exchange. So a sensor can list, per server and per client, where quantum-vulnerable key exchange is still used and where hybrid post-quantum key exchange already is.
Devices nobody inventoried. It covers printers, appliances, OT gateways and old servers that cannot run an agent and are often the last to be updated.
Keys where the handshake exposes them. In TLS 1.2 the server certificate travels in clear, and SSH host keys are exchanged in clear, so their algorithms and key sizes are visible; in TLS 1.3 the certificate is encrypted.
Regressions. Once a service has moved to hybrid key exchange, a later connection that falls back to a classical group shows up.

What it cannot see: cryptography inside applications and databases, keys and certificates stored on disk, code signing, encrypted backups, and any segment no sensor watches. Combine the network view with a certificate inventory, your software bills of materials and supplier questionnaires. The crypto inventory from network traffic article walks through it.

A migration plan in five steps

Inventory. Build the list above, starting with internet-facing services and the systems that carry long-lived secrets.
Prioritise with Mosca. Rank systems by how long their data must stay secret and how long they take to change.
Turn on hybrid key exchange where it is already available. Current browsers, TLS libraries and SSH versions support it; often it is a configuration or update away. Verify it on the wire afterwards.
Ask suppliers. Put post-quantum key exchange and signatures on the roadmap questions of every tender and renewal, with dates.
Plan signatures and PKI. Post-quantum certificates and code signing take longer, because whole chains of trust must change. Start the planning now; the deadlines above give you years, not months.

What NetSenX shows

NetSenX does not protect anyone against quantum computers, and no monitoring product can: protection comes from changing the cryptography in your systems and your suppliers'. What NetSenX gives you is the visibility a migration starts from. NQCI, the NetSenX crypto inventory (in preview), is visible on every plan and active from the Pro plan with the packet-capture sensor switched on for a Linux agent or a sensor on a SPAN or TAP port. It shows which connections in monitored traffic still use quantum-vulnerable key exchange and which already use hybrid post-quantum key exchange, flags weak public keys seen in handshakes (for example RSA keys that share a factor with another key, the trace of a faulty random-number generator), and records changes over time, so you can see where updates have done the work and spot regressions later.

Sources

Written by the NetSenX Team at TriStiX S.L. Questions: info@netsenx.com.

Questions this guide answers

What is post-quantum cryptography?

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.

What does harvest now, decrypt later mean?

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.

Which of our data is at risk from harvest now, decrypt 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.

How do I apply Mosca's inequality?

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.

What are FIPS 203, 204 and 205?

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.

What is ML-KEM?

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.

What are ML-DSA and SLH-DSA?

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.

Does the EU require a post-quantum migration plan?

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.

What does the EU roadmap ask for by the end of 2026?

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.

How can we find where we use quantum-vulnerable cryptography?

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.

Can a network sensor build a cryptographic inventory?

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.

What should a cryptographic inventory include?

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.