Post-quantum cryptography

The foundations of today’s digital security — RSA, ECC, Diffie-Hellman — rest on mathematical problems that would take classical computers millions of years to solve. A quantum computer equipped with a sufficient number of stable qubits can solve those same problems in a matter of hours. This is not a scenario from a distant future: IBM presented the Condor processor with 1,121 qubits in 2023, Google announced the Willow chip with record-breaking quantum error correction, and Chinese scientific consortia are reporting advances that shorten the estimated dates for reaching “Q-Day” — the moment at which current cryptographic standards are broken.

In operational practice, preparing an organization for the post-quantum era begins not with purchasing new products, but with asking: which of our data, encrypted today, could be decrypted in five or ten years? The answer to that question determines migration priorities, the timeline of actions, and the urgency of investment. The NIST standards published in August 2024 give organizations a solid anchor point — for the first time in history, we have ready, standardized post-quantum algorithms that can be deployed in production.

Why do quantum computers threaten today’s encryption?

Asymmetric algorithms, on which virtually the entire trust infrastructure of the internet relies, owe their security to the computational difficulty of two mathematical problems: the factorization of large numbers (RSA) and the discrete logarithm (ECC, Diffie-Hellman). A classical computer, even the fastest supercomputing cluster, would need millions of years to factorize an RSA-2048 key by brute force. Shor’s algorithm, published by Peter Shor in 1994, shows that a quantum computer solves the same problem in polynomial time — rather than exponential time.

The mechanism is counterintuitive, but its consequences are concrete. A qubit, unlike a classical bit, can exist simultaneously in a superposition of the states 0 and 1. Quantum entanglement allows a quantum processor to explore exponentially many computational paths in parallel. Shor’s algorithm uses the quantum Fourier transform to find the period of a modular function — and it is precisely this step that reduces the factorization problem from an exponential task to a polynomial one. For RSA-2048, it is estimated that approximately 4,000 logical qubits are needed to break it; current machines have physical qubits rather than logical ones, with an error correction ratio of 1,000:1 — meaning roughly 4 million physical qubits would be required. We are therefore still far from breaking RSA-2048 on a real machine, but the pace of progress is alarming.

Grover’s algorithm is the second quantum threat, this time targeting symmetric cryptography. Grover speeds up the search of the key space from O(2^n) to O(2^(n/2)), effectively reducing the security of AES-128 to a level comparable to AES-64. The response is to switch from AES-128 to AES-256 and from SHA-256 to SHA-384/SHA-512 — a relatively simple change, with no need to abandon symmetric algorithms.

Asymmetric cryptography, however, requires a fundamental replacement of algorithms. RSA, ECDSA, ECDH, and DHE have no “quantum-resistant” version with a longer key — they are structurally vulnerable to Shor’s algorithm, regardless of key length. Every organization that today uses TLS, VPN, PKI, digital signatures, SSH, or public-key cryptography-based authentication protocols is directly exposed to this class of threats.

What is the “harvest now, decrypt later” attack and who does it affect?

The “harvest now, decrypt later” (HNDL) attack consists of intercepting and archiving encrypted network traffic now, with the intention of decrypting it in the future, once the attacker has access to a sufficiently powerful quantum computer. In cryptographic practice, this means that the protection lifetime of data is determined not by the current strength of the algorithm, but by the moment a quantum adversary appears.

Key principle: if data requires confidentiality for 10 or more years, it must be protected by quantum-resistant algorithms today — even if a quantum computer capable of breaking it does not yet exist.

Nation-state actors with advanced offensive capabilities (Tier-1 nation-state actors) are actively running HNDL programs. Intelligence reports from the NSA, GCHQ, and AIVD point to the systematic interception of encrypted internet traffic by at least several intelligence agencies with the intent of decrypting it in the future. From an attacker’s perspective, the cost is low — data storage is cheap — and the potential value of the archives grows with advances in quantum technology.

Which sectors are particularly exposed? Medical data — disease histories, genetic test results, psychiatric records — require protection for the patient’s entire lifetime. Legal documents: contracts, wills, attorney-client privileged communications. Intellectual property: patents in the application phase, research projects, pharmaceutical formulas. Diplomatic and intelligence communications. Financial data: historical transactions, terms of credit agreements. If an organization processes data from any of these categories, the HNDL threat is real for it today.

In operational practice, the HNDL principle requires inverting the traditional approach to prioritization. Instead of asking “when will a quantum computer appear?”, the right question is: “how long must our data remain confidential?”. Data that needs to remain confidential for 5 years can wait before migration. Data requiring 15-year confidentiality should be protected by post-quantum algorithms immediately.

What post-quantum cryptography standards did NIST publish in 2024?

In August 2024, the National Institute of Standards and Technology (NIST) published three final PQC standards following an eight-year intensive evaluation process in which 82 submitted algorithms were analyzed. This is the most significant event in the field of cryptography since the standardization of AES in 2001, and a direct signal to organizations that the time for implementation has arrived.

FIPS 203 — ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism). The ML-KEM algorithm, formerly known as CRYSTALS-Kyber, offers a key encapsulation mechanism based on the Module Learning With Errors (MLWE) problem on modular lattices. NIST has defined three security levels: ML-KEM-512 (comparable to AES-128), ML-KEM-768 (comparable to AES-192), and ML-KEM-1024 (comparable to AES-256). In practice, ML-KEM-768 is recommended for most applications — it offers a public key size of 1,184 bytes and a ciphertext size of 1,088 bytes, with key generation speed several times faster than RSA-2048. ML-KEM is intended to replace ECDH and DHE in TLS, VPN, and key exchange protocols.

FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm). ML-DSA, formerly CRYSTALS-Dilithium, is a digital signature algorithm based on the same mathematical foundation as ML-KEM. Standard security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. A signature generated by ML-DSA-65 is 3,293 bytes in size — significantly larger than an ECDSA signature (64 bytes), but signing and verification operations are fast: benchmarks show 20,000–50,000 operations per second on a typical server. ML-DSA will replace ECDSA and RSA-PSS in PKI certificates, code signatures, PDF documents, and S/MIME email systems.

FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm). SLH-DSA, derived from SPHINCS+, relies exclusively on the security of hash functions — without any algebraic assumptions. This makes SLH-DSA a naturally “last line of defense” algorithm: even if all assumptions about the difficulty of lattice problems turn out to be wrong, SLH-DSA remains secure. It pays for this with performance — signatures are 7,856–49,856 bytes in size depending on the variant — but in scenarios where long-term security is the priority (document signatures, timestamping, root CA certificates), this is a justified choice.

Beyond these three standards, NIST continues work on FIPS 206 (FN-DSA, derived from FALCON) — a signature algorithm based on NTRU lattices with exceptionally small signature sizes. NIST is also running a second evaluation process for KEM algorithms based on codes and isogenies, as a reserve in case of cryptanalytic breakthroughs against lattice-based algorithms.

How do you assess an organization’s exposure to quantum risk?

Assessing exposure to quantum risk requires a more precise approach than a standard security audit. The starting point is classifying data by the required confidentiality period: data requiring protection for more than 7 years constitutes a direct HNDL risk group. Next, it is necessary to identify which cryptographic mechanisms protect that data — both at rest (encryption at rest) and in transit (encryption in transit).

In cryptographic practice, an exposure assessment consists of four layers of analysis. First, an inventory of network protocols: TLS 1.2 and 1.3 commonly use ECDHE for key exchange and ECDSA or RSA for certificate authentication — both are vulnerable. IPsec in IKEv2 mode uses Diffie-Hellman — vulnerable. SSH with RSA or ECDSA keys — vulnerable. WireGuard — uses Curve25519 for Diffie-Hellman — vulnerable.

Second, PKI infrastructure: SSL/TLS certificates, code signing certificates, S/MIME email certificates, IoT device certificates. All those based on RSA or ECDSA are by definition within the risk scope. Certificates have a limited validity period — typically 1–2 years — so their replacement is relatively straightforward, but requires a mass operation, especially in environments with thousands of certificates.

Third, cryptographic applications and libraries: OpenSSL, BoringSSL, NSS, Windows CNG, Java JCA/JCE — each of these implements classical algorithms. The key question is: does a given library and version already support NIST PQC algorithms? OpenSSL 3.x with liboqs or the Open Quantum Safe provider, BoringSSL with its experimental quantum branch — these are available options, but they require a deliberate choice and configuration.

Fourth, hardware devices and embedded systems: HSMs (Hardware Security Modules), smart cards, microcontrollers, industrial controllers, medical devices. Migration here is the most difficult — it requires firmware updates or hardware replacement, and hardware replacement cycles in industrial and medical infrastructure are often measured in decades.

The result of an exposure assessment should take the form of a risk matrix with the dimensions: data value × required confidentiality period × vulnerability of the current algorithm × difficulty of migration. This is the tool that directly determines action priorities.

How to conduct a cryptographic inventory — where is encryption used in the organization?

A cryptographic inventory is the systematic process of identifying all locations where an organization uses cryptographic algorithms — both those vulnerable to quantum attacks and those that are resistant. In mature organizations, this list numbers dozens or hundreds of entries. In cryptographic practice, the approach to inventory begins with five search categories.

Network infrastructure. Firewalls, load balancers, reverse proxies, VPN gateways, WiFi controllers — each of these devices terminates TLS or VPN connections using public-key cryptography. Scanning tools: [nmap](/en/glossary/nmap/) --script ssl-enum-ciphers, testssl.sh, Qualys SSL Labs API, Censys or Shodan for external infrastructure. The output of this phase should be a table: IP address → protocol → TLS version → key exchange algorithm used → certificate algorithm → certificate expiration date.

Web applications and APIs. Every HTTPS connection, every JWT signed with RS256 or ES256, every OAuth 2.0 with RSA keys, every REST API with mutual TLS. Scanning can be partially automated — tools such as Dependency-Check, Snyk, or OWASP ZAP can identify cryptographic libraries in code and their versions. It is also essential to review JVM configurations (java.security), openssl.cnf files, and nginx/Apache configurations with regard to permitted cipher suites.

Databases and data stores. Column-level encryption in SQL Server (Always Encrypted), Oracle TDE, backup encryption in Veeam, volume encryption with BitLocker/LUKS — all use a combination of symmetric and asymmetric algorithms. The asymmetric elements (DEK keys encrypted with a KEK, which is an RSA or ECC key) are vulnerable.

Identity and access management systems. Active Directory uses Kerberos cryptography (AES-256 for sessions — secure, but Kerberos keys exchanged during domain join may be vulnerable), smart card certificates are ECDSA or RSA, ADFS uses RSA/ECDSA certificates for token signatures. AWS IAM, Azure AD, Okta — checking the algorithm configurations of JWT tokens and SAML certificates.

IoT, OT, and industrial infrastructure systems. This is the most difficult category to inventory. ICS/SCADA devices, PLC controllers, networked medical devices, smart grid meters — these often use protocols such as DTLS, CoAP with TLS, OPC-UA Security — all with public-key cryptography. Passive network monitoring (tools such as Claroty, Dragos, Nozomi) can help identify cryptographic communications without the need to actively scan sensitive systems.

The result of the cryptographic inventory should be a structured database (not a spreadsheet — that does not scale) containing: location, system/application, algorithm, key size, expiration date (if applicable), system owner, estimated migration time, and priority.

Which sectors should begin migration earliest — finance, healthcare, public administration?

Migration priorities to post-quantum cryptography are not the same for all organizations. In operational practice, we distinguish three key criteria that determine urgency: the required data confidentiality period, attractiveness to advanced attackers, and regulatory deadlines — deadlines set by supervisory authorities.

The financial sector should be at the front of the queue. Banks process transactional data with contractual obligations spanning 20–30 years (mortgages, long-term bonds), hold customer data subject to multi-year regulatory retention requirements, and are attractive targets for both cybercriminals and nation-state actors. The DORA (Digital Operational Resilience Act) directive, in force since January 2025, requires EU financial institutions to manage ICT risk in a way that accounts for “emerging risks” — and the European Banking Authority interprets this as a mandate to include quantum risk in digital resilience plans. The European Central Bank (ECB) and the European Securities and Markets Authority (ESMA) have issued informal recommendations regarding the preparation of PQC migration plans by the end of 2026.

The healthcare sector has a particularly long required data confidentiality period — medical records, genetic data, psychiatric history. The GDPR requires “appropriate technical measures” — with health data that must remain confidential for decades, “appropriate measures” at the current level of knowledge about quantum threats means post-quantum cryptography for data with a long confidentiality horizon. Hospitals and diagnostic laboratories that process genomic data (confidentiality period: the patient’s entire lifetime plus a period after death) should treat migration as urgent.

Public administration and the government sector in Poland are directly covered by the NIS2 directive and the Polish Act on the National Cybersecurity System (amendment to the KSC). The NIS2 directive requires essential and important entities to implement “state-of-the-art” measures in the area of cryptography. Given that NIST published PQC standards in August 2024 and ENISA issued Technical Guidelines on Post-Quantum Cryptography in 2023, organizations subject to NIS2 have increasingly weak arguments for delaying inventory and planning activities.

The defense industry and NATO supply chain providers are subject to the strongest requirements. NSM-10 (US National Security Memorandum) from May 2022 mandated all US federal agencies and government contractors to migrate to PQC in accordance with NIST timelines. Polish companies engaged in NATO procurement or cooperation with the defense sector should treat PQC requirements as soon-to-be mandatory qualification criteria.

What does a crypto agility strategy look like — readiness for rapid algorithm changes?

Crypto agility (cryptographic agility) is the ability of an IT system to quickly replace cryptographic algorithms without the need to redesign the architecture. In cryptographic practice, this is a strategic property of systems, not a one-time feature of an implementation — its absence means that every future change in standards requires costly redesigns.

Lessons from the SHA-1 → SHA-2 migration (which took over a decade in industry, despite SHA-1 vulnerabilities being published in 2005 and formal deprecation in 2011) show how difficult it is to replace algorithms in systems lacking crypto agility. Similarly, the migration from TLS 1.0/1.1 → TLS 1.2/1.3 dragged on for years, and some organizations are still not fully migrated to this day.

Implementing crypto agility is based on several architectural principles. The first: abstraction of the cryptographic layer. Cryptographic algorithms should be configurable, not hardcoded. In application code, instead of a direct call to RSA.encrypt(), there should be a CryptoProvider.encrypt() interface with external configuration. This allows changing the algorithm without modifying application code.

The second principle: algorithmic negotiation in protocols. TLS is the model here — during the handshake, client and server negotiate a cipher suite. Hybrid cipher suites, combining ML-KEM with ECDH (e.g., X25519MLKEM768 supported by Chrome 131+ and Firefox 132+), allow organizations to gradually deploy PQC protection while maintaining backward compatibility with older clients.

The third principle: centralized key and certificate management. Organizations using dozens or hundreds of certificates without a Certificate Lifecycle Management (CLM) system lack the ability to rapidly replace algorithms — they do not even know where all certificates are located. Tools such as Venafi, Keyfactor, Sectigo Certificate Manager, or HashiCorp Vault with PQC support are essential for organizations at any scale.

In cryptographic practice, crypto agility means that when NIST or ENISA issues a recommendation to deprecate a specific algorithm, the organization should be able to complete the replacement in weeks, not years. History shows that breakthrough cryptanalytic discoveries happen suddenly — the break of SIKE in 2022 by a classical algorithm on a laptop in a matter of hours is an example of how quickly security assumptions can change.

The fourth principle: testing cryptographic readiness. Regular “crypto fire drill” exercises — simulations of a forced algorithm replacement in a production environment — allow organizations to verify how long a migration actually takes and where the bottlenecks are. The result of such an exercise is far more informative than theoretical schedules.

What regulations (NIST, ENISA, Cyber Resilience Act) require preparation for the post-quantum era?

The regulatory landscape concerning post-quantum cryptography is evolving rapidly. Entities that delay action while waiting for “hard” legal requirements risk finding themselves under pressure from several regulations simultaneously — and a cryptographic migration carried out under time pressure costs several times more than one conducted methodically.

NIST SP 800-208 and final standards FIPS 203/204/205 (USA). NIST standards have the status of de facto global references — software, HSM, and cryptographic library manufacturers implement them first. In the USA, NSM-10 mandated federal agencies to complete a cryptographic systems inventory by 2023 (accomplished) and a migration plan by 2025. NIST SP 1800-38 is a draft migration guide for private-sector organizations.

ENISA Post-Quantum Cryptography Guidelines (EU). ENISA published the document “Post-Quantum Cryptography: Current State and Quantum Mitigation” in 2021 and updated recommendations in 2023. In 2024, ENISA published “Guidelines for Quantum-Safe Networks” with recommendations for critical infrastructure providers. ENISA recommends a hybrid approach (classical + PQC) as a transitional strategy and identifies ML-KEM, ML-DSA, and SLH-DSA as the recommended algorithms.

NIS2 Directive (EU 2022/2555). NIS2 has been in force since October 2024. Article 21 places essential and important entities under an obligation to apply “state-of-the-art” cybersecurity risk management measures, including “policies and procedures for the use of cryptography and, where appropriate, encryption”. In the context of the published NIST PQC standards and ENISA recommendations, supervisory authorities (UODO, CERT Polska, URE for the energy sector) may in the coming years interpret “state-of-the-art” as requiring a PQC migration plan from entities subject to NIS2.

Cyber Resilience Act (EU 2024/2847). The CRA, in force from 2027 for most digital products, contains security requirements that apply throughout a product’s lifetime. Manufacturers of network hardware, software, and IoT devices must provide security updates — including cryptographic updates — throughout the entire expected useful life of the product. This means that a manufacturer of a router with a 10-year lifecycle sold after 2027 must plan support for cryptographic algorithm updates — practically mandating crypto agility in product design.

eIDAS 2.0 and the European Digital Identity Wallet. The new eIDAS regulation introduces the European Digital Identity Wallet — a digital identity wallet for EU citizens intended to last for decades. Cryptographic certificates and signatures in this system must be resistant to quantum threats. Work is currently underway on a cryptographic profile for the EUDI Wallet that is to include PQC algorithms from the moment the system launches (planned for 2026–2027).

PCI DSS 4.0. The Payment Card Industry Data Security Standard version 4.0 (mandatory from March 2025) contains requirement 4.2.1: “Strong cryptography is used to safeguard PAN during transmission over open, public networks.” Although PCI DSS 4.0 does not explicitly mention PQC algorithms, the PCI SSC Council published a statement in 2024 announcing plans to include PQC requirements in future versions of the standard, advising organizations to proactively plan migration.

What does the post-quantum cryptography migration roadmap look like?

Phase	Time horizon	Key actions	Tools and technologies	Success criteria
Phase 0: Awareness and readiness	0–3 months	Establish PQC team; train technical staff on FIPS 203/204/205; preliminary quantum risk exposure assessment	NIST SP 1800-38 (draft), ENISA materials, OWASP PQCG	Board decision on budget allocation; PQC process owner designated
Phase 1: Cryptographic inventory	2–6 months	Full review of network protocols, PKI certificates, cryptographic libraries, data requiring long-term confidentiality	nmap ssl-enum-ciphers, testssl.sh, Venafi TLS Protect, Keyfactor Command, Censys	Cryptographic asset database; HNDL risk matrix; list of vulnerable systems
Phase 2: Pilots and hybrid TLS	4–12 months	Deploy X25519MLKEM768 in TLS for selected connections; ML-DSA pilot for code signatures; PQC performance testing in staging environment	OpenSSL 3.x + liboqs, BoringSSL with PQC, Cloudflare Workers with NIST PQC, nginx 1.27+ with PQC patch	Hybrid TLS operational for 10–20% of traffic; baseline performance metrics; zero functional regressions
Phase 3: PKI and certificate migration	8–24 months	Deploy PQC Root CA (hybrid); migrate TLS certificates to hybrid (RSA/ECDSA + ML-DSA); update certificate management policies	HashiCorp Vault 1.16+ (PQC support), Keyfactor EJBCA, Sectigo SCM, DigiCert CertCentral	100% of new certificates include a PQC component; CLM covers all certificates; certificate replacement MTTR < 1h
Phase 4: VPN and remote access migration	12–30 months	Update VPN gateways (IKEv2 with ML-KEM); deploy PQC in WireGuard or OpenVPN; migrate SSH to PQC-enabled SSH (OpenSSH 9.x)	StrongSwan 6.x with ML-KEM, OpenSSH 9.0+ (CRYSTALS-Kyber experimental) PAN-OS 12+	100% of VPN connections with quantum-resistant KEM algorithm; SSH key exchange with ML-KEM
Phase 5: Application and backend migration	18–36 months	Replace cryptographic libraries in applications; refactor code with hardcoded algorithms; deploy crypto agility layer	Bouncy Castle 1.78+ (PQC Java), cryptography.io 42+ (PQC Python), AWS KMS PQC, Azure Key Vault PQC	100% of JWT signatures using ML-DSA or SLH-DSA; no RSA/ECDSA in new code; all dependencies on libraries with PQC support
Phase 6: Hardware devices and OT/IoT	24–60 months	Update HSM firmware (Thales Luna, Entrust, AWS CloudHSM); replace devices without PQC support; migrate ICS/SCADA systems	Thales Luna 7.x (PQC firmware), Infineon OPTIGA Trust M2IoT, nShield Connect XC with PQC	100% of HSMs with ML-KEM and ML-DSA support; replacement plan for OT devices without PQC support defined
Phase 7: Deprecation of classical algorithms	36–72 months	Disable RSA and ECDH/ECDSA as sole mechanisms (preserving hybrid as optional); update security policies	Cipher policy configuration in OpenSSL (LEGACY level), monitoring of clients lacking PQC support	Zero production connections using classical algorithms exclusively; full crypto agility documented

The time horizon for individual phases is indicative and depends on the size of the organization, the complexity of the infrastructure, and the available resources. The key is to begin Phase 0 and Phase 1 without delay — a cryptographic inventory is a purely organizational action, without licensing costs, and provides the knowledge necessary for all subsequent decisions. Organizations that have not yet taken any action should treat August 2024 (publication of NIST standards) as the moment from which the absence of a migration plan becomes a risk management deficit requiring justification.

How does nFlo help organizations prepare for quantum threats?

nFlo has developed its approach to PQC migration based on experience from over 500 cybersecurity projects and 200+ clients from the financial, industrial, healthcare, and public administration sectors. Our approach is methodical and pragmatic: we start from facts, not alarmism, and we deliver concrete action plans to clients — not general recommendations.

Cryptographic inventory and HNDL risk assessment. The first and most frequently overlooked step — a systematic mapping of all cryptographic assets in the organization. Our team conducts active network scanning, configuration analysis, application code review, and infrastructure documentation review, delivering to the client a complete cryptographic asset register with HNDL risk classification. A typical inventory project for a mid-sized organization takes 3–6 weeks. The result: a migration priority matrix with specific recommendations.

Organizational readiness and crypto agility assessment. We conduct technical workshops with IT and security teams, assess the architecture of systems for their ability to rapidly replace algorithms, and identify competency gaps. Based on this assessment, we prepare a personalized training plan and recommendations regarding cryptography management processes.

Pilot deployments and proof of concept. We help organizations carry out their first hybrid TLS deployments, their first PQC-enabled VPN gateway, or their first PKI with a PQC component. Our experience with deployments of OpenSSL 3.x + liboqs, StrongSwan with ML-KEM, and HashiCorp Vault with NIST PQC algorithm support allows us to shorten pilot timelines and avoid typical configuration errors.

Regulatory support and NIS2/DORA/CRA compliance. We help organizations document PQC activities in the manner required by supervisory authorities, prepare materials for NIS2 and DORA audits, and assist in communications with regulators regarding migration plans. Our 98% client retention rate stems largely from the fact that we deliver not only technical implementations, but also the regulatory and business context essential for decision-makers.

Around-the-clock monitoring with a response time below 15 minutes. Cryptographic migration is a process, not a one-time project. During and after migration, organizations need continuous monitoring — detecting unauthorized connections using classical algorithms, monitoring expiring certificates, alerting on new vulnerabilities in PQC algorithms. Our SOC as a Service provides this monitoring in 24/7/365 mode with a guaranteed response time of under 15 minutes.

The quantum threat is real, but it is not sudden — we have time for methodical preparation. Organizations that begin with a cryptographic inventory today will have a solid foundation for managing quantum risk over the coming years. Organizations that delay risk having migration forced upon them — by regulators, by an incident, or by client pressure — and it will cost many times more.

Want to know where the greatest quantum risk lies in your organization? Contact us — we will conduct a preliminary HNDL risk exposure assessment.

FAQ

When will quantum computers be a real threat to cryptography?

Estimates vary depending on the source: the Global Risk Institute (2024) estimates a 50% probability of RSA-2048 being broken by 2031–2035; intelligence reports speak of potential capabilities of nation-state actors as early as 2028–2030. The key point, however, is that for data requiring multi-year confidentiality, the threat is already real today — through the HNDL (harvest now, decrypt later) attack.

Is it enough to simply change RSA key lengths to 4096 bits?

No. Increasing the RSA key to 4096 bits does not protect against Shor’s algorithm — a quantum computer will break RSA-4096 just as it would RSA-2048, requiring at most a few times longer computation time. The only solution is to replace the algorithm with a post-quantum one (ML-KEM, ML-DSA, SLH-DSA). For symmetric algorithms (AES), changing the key length from 128 to 256 bits is sufficient protection against Grover’s algorithm.

What is the difference between FIPS 203, 204, and 205?

FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber) is a key encapsulation mechanism — it replaces ECDH and DHE in key exchange protocols (TLS, VPN). FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium) is a digital signature algorithm — it replaces ECDSA and RSA-PSS in PKI certificates, code signatures, and S/MIME emails. FIPS 205 (SLH-DSA, derived from SPHINCS+) is an alternative signature algorithm based exclusively on hash functions — slower, but with exceptionally solid security foundations, recommended for root CA certificates and long-term documents.

Do PQC algorithms slow down application performance?

It depends on the algorithm and the use case. ML-KEM is faster than RSA for key generation, but produces larger public keys and ciphertexts (several times larger than ECDH keys). ML-DSA is comparable to RSA in terms of signature verification speed. The greatest performance challenge concerns systems with limited resources (IoT, smart cards) and protocols sensitive to packet size (DTLS for UDP). In typical server environments, the performance impact is measurable, but rarely critical.

What is the hybrid approach in post-quantum cryptography?

The hybrid approach combines a classical cryptographic algorithm (e.g., X25519 for key exchange) with a PQC algorithm (e.g., ML-KEM-768) in such a way that the security of the connection requires breaking both algorithms simultaneously. This means that if one of the algorithms proves vulnerable — whether the classical one against a quantum computer, or the new PQC one against unknown attacks — the other still provides protection. The hybrid approach is recommended by NIST, ENISA, and BSI as a transitional strategy and is already supported by Chrome 131+, Firefox 132+, and many web servers.

How long does migration to post-quantum cryptography take?

For a small organization with a homogeneous infrastructure — 12–24 months from inventory to full migration of network protocols and PKI. For a large organization with hundreds of systems, IoT devices, and OT infrastructure — 3–5 years for full migration. This is precisely why experts recommend starting now: organizations that begin in 2026 will be protected against a potential Q-Day in the worst-case scenario of 2030. Organizations that begin in 2028 may not make it in time.

Sources

NIST FIPS 203 (ML-KEM) — https://doi.org/10.6028/NIST.FIPS.203
NIST FIPS 204 (ML-DSA) — https://doi.org/10.6028/NIST.FIPS.204
NIST FIPS 205 (SLH-DSA) — https://doi.org/10.6028/NIST.FIPS.205
ENISA Post-Quantum Cryptography Guidelines (2023) — https://www.enisa.europa.eu/publications/post-quantum-cryptography
NSM-10: National Security Memorandum on Promoting United States Leadership in Quantum Computing — White House, May 2022
Global Risk Institute — Quantum Threat Timeline Report 2024
Open Quantum Safe Project (liboqs) — https://openquantumsafe.org
NIST SP 1800-38 (draft): Migration to Post-Quantum Cryptography — https://csrc.nist.gov/pubs/sp/1800/38/ipd

Explore key terms related to this article in our cybersecurity glossary:

Encryption — Encryption is the process of converting data into encrypted text that is unreadable without…
Cybersecurity — Cybersecurity is the set of techniques, processes, and practices for protecting IT systems…
PKI — Public Key Infrastructure (PKI) is a set of roles, policies, and procedures for managing…
Zero Trust — Zero Trust is a security model that assumes no default trust for…
Identity management — Identity management (IAM) refers to the processes and technologies for controlling access to resources…

Learn more

Read related articles in our knowledge base:

Check our services

Need support in the area of cybersecurity? See:

Security audits - comprehensive assessment of security posture
Penetration testing - identification of vulnerabilities in infrastructure
SOC as a Service - around-the-clock security monitoring

Post-quantum cryptography — why organizations must prepare for the quantum computer era today

Why do quantum computers threaten today’s encryption?

What is the “harvest now, decrypt later” attack and who does it affect?

What post-quantum cryptography standards did NIST publish in 2024?

How do you assess an organization’s exposure to quantum risk?

How to conduct a cryptographic inventory — where is encryption used in the organization?

Which sectors should begin migration earliest — finance, healthcare, public administration?

What does a crypto agility strategy look like — readiness for rapid algorithm changes?

What regulations (NIST, ENISA, Cyber Resilience Act) require preparation for the post-quantum era?

What does the post-quantum cryptography migration roadmap look like?

How does nFlo help organizations prepare for quantum threats?

FAQ

When will quantum computers be a real threat to cryptography?

Is it enough to simply change RSA key lengths to 4096 bits?

What is the difference between FIPS 203, 204, and 205?

Do PQC algorithms slow down application performance?

What is the hybrid approach in post-quantum cryptography?

How long does migration to post-quantum cryptography take?

Sources

Learn more

Check our services

Tags:

Share:

Talk to an expert

Grzegorz Gnych

Want to Reduce IT Risk and Costs?

Why do quantum computers threaten today’s encryption?

What is the “harvest now, decrypt later” attack and who does it affect?

What post-quantum cryptography standards did NIST publish in 2024?

How do you assess an organization’s exposure to quantum risk?

How to conduct a cryptographic inventory — where is encryption used in the organization?

Which sectors should begin migration earliest — finance, healthcare, public administration?

What does a crypto agility strategy look like — readiness for rapid algorithm changes?

What regulations (NIST, ENISA, Cyber Resilience Act) require preparation for the post-quantum era?

What does the post-quantum cryptography migration roadmap look like?

How does nFlo help organizations prepare for quantum threats?

FAQ

When will quantum computers be a real threat to cryptography?

Is it enough to simply change RSA key lengths to 4096 bits?

What is the difference between FIPS 203, 204, and 205?

Do PQC algorithms slow down application performance?

What is the hybrid approach in post-quantum cryptography?

How long does migration to post-quantum cryptography take?

Sources

Related concepts

Learn more

Check our services

Tags:

Share:

Talk to an expert

Grzegorz Gnych

Want to Reduce IT Risk and Costs?