— Preparing for the Quantum Shift

Table of Contents The EU’s Post-Quantum Plan: Recommendation (EU) 2024/1101 + What will upcoming EU cybersecurity legislation require? And how can Java help you prepare? + Why this is significant for architects? + Java advisory note * NIS2 — Cryptography as Organizational Governance + Engineering Implications + Java advisory note * DORA — Operational Resilience + Engineering Implications + Java advisory note * Cyber Resilience Act — Secure-by-Design Software + Core Objectives + Engineering Implications + Java advisory note * Standards & Certification — ENISA EUCC, ACM v2, ETSI TS 103 744 + ENISA & EUCC + ETSI TS 103 744 — The Foundation of Hybrid TLS + Java advisory note * National Implementations — Germany and France * Practical Checklist for Java-Based Systems + For CTOs and Security Architects + For Platform Teams + For Java Developers * Conclusion * References Over the next decade, European cryptographic systems will undergo a significant transformation similar to the change from DES to AES and SSL to TLS. The converging forces of regulatory requirements, post-quantum research, and market pressure are set to redefine software security. This is particularly important for organizations in sectors such as finance, critical infrastructure, cloud services, public administration, and large-scale digital platforms. This is not optional:* it marks the beginning of a significant architectural shift that will impact nearly every system with a security boundary.

At the center of this shift lies a simple but powerful reality: The cryptography we rely on today will not be sufficient for the systems we build for tomorrow.

The European Union is preparing for this future through a combination of high-impact legislation (NIS2, DORA, the Cyber Resilience Act), forward-looking strategic documents (the Post-Quantum Cryptography Roadmap), and emerging standards (ETSI hybrid key-exchange profiles, ENISA’s EUCC and ACM mechanisms). Together, these frameworks make one expectation unmistakable: systems must be crypto-agile, updatable, and robust in the face of long-term cryptographic threats—including those posed by quantum computing.

For technical leaders, this means the timeline for learning about post-quantum transition and cryptographic lifecycle management is not “sometime in the 2030s”—it is right now. System designs created today must remain defensible five, ten, or fifteen years from now. Cryptographic decisions made today will determine whether your systems remain compliant, secure, and operational in the era of hybrid and post-quantum algorithms.

This article is written to help you navigate what comes next. It does three things:

1. It explains the major EU legislative and strategic changes that will require system upgrades over the coming years, what they mean, why they matter, and how they will influence long-term architecture.
2. It provides a practical advisory note for Java practitioners, showing how the JVM has quietly been preparing for this future through a series of foundational security enhancements.
3. It highlights recent Java features—KEM/KDF APIs, modern PEM support, hybrid TLS efforts, and PQC-related proposals and explains how they enable crypto agility and long-term resilience. This is not about compliance checklists or abstract policy. It is about engineering: how to build systems today that will still be secure and supportable a decade from now.

Java, with its modern cryptographic architecture, provider-based extensibility, and emerging support for hybrid and PQC operations, offers a powerful foundation for this transition. Many of the tools you need—structured KEM/KDF APIs, improved certificate handling, modular cryptographic providers, and simplified security models—already exist in current JDKs or are in active development.

The coming years will challenge our assumptions about how cryptography is integrated into software systems. But with the right understanding—and the right platform choices—you can position your systems to not just meet regulatory expectations, but to be resilient in a security landscape that is about to change more rapidly than any time in recent memory.

The EU’s Post-Quantum Plan: Recommendation (EU) 2024/1101What will upcoming EU cybersecurity legislation require? And how can Java help you prepare?Between the Post-Quantum Cryptography (PQC) transition, the NIS2 Directive, the DORA Regulation, and the Cyber Resilience Act (CRA), the EU is moving toward a future in which:

• Cryptography must be upgradable,
• Systems must be resilient against long-term threats, and
• Software products must be secure-by-design and maintainable for years. If you design, operate, or oversee systems that must endure well into the 2030s, these legal changes are not mere theoretical concepts; they are integral components of your engineering strategy. They affect protocol choices, PKI design, cryptographic libraries, update processes, compliance documentation, and runtime platform capabilities.

On 11 April 2024, the European Commission issued Recommendation (EU) 2024/1101 on a “Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography” [1]. It instructs Member States to “develop and implement a harmonised approach as the Union transitions to post-quantum cryptography.” [2]

Furthermore, “Within two years of this Recommendation, the NIS Cooperation Group should develop a coordinated implementation roadmap for the transition to post-quantum cryptography.” [3]

This Roadmap was subsequently published on 23 June 2025 [4].

The Roadmap defines phases, not hard deadlines.

These phases include guidance such as:

• By the mid-2020s: build governance, inventory crypto assets, identify exposure to “harvest-now-decrypt-later”, and launch PQC pilots [5].
• “Around 2030”: high-risk and high-value systems should use quantum-safe or hybrid cryptography—this phrasing appears in public commentary, not as an exact quote from the official text [6].
• “Beyond 2030”: wider system migration—again, this is interpretive, based on analyses that infer the long-tail implications of the roadmap [6]. Note: To be precise, the recommendation does not explicitly state “2030” or “2035”.

Why this is significant for architects?Even without binding deadlines, the roadmap clearly signals that:

• PQC migration will be expected for critical systems,
• Hybrid cryptography will act as the transition strategy,

• Long-term systems must be crypto-agile, not locked into fixed primitives. Java advisory noteJava offers several essential building blocks that are crucial for this transition:

• JEP 452 — Key Encapsulation Mechanism (KEM) API (Delivered: Java 21): clean provider-based integration point for PQC KEMs.

• JEP 510 — KDF API (Delivered: Java 25): necessary for combining classical and PQ secrets in hybrid schemes.
• JEP 524 — PEM Encodings (Preview / In development: Integrated: Java 26): modern handling of keys/certificates required for PQC formats.
• JEPs 496 / 497 — Quantum-Resistant Cryptography (Delivered: Java 24): Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism & Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
• Hybrid TLS Key Exchange (Under development: Candidate; JEP 527 — Post-Quantum Hybrid Key Exchange for TLS 1.3): draft efforts to enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms for TLS 1.3. Back to top

NIS2 — Cryptography as Organizational GovernanceThe NIS2 Directive—Directive (EU) 2022/2555—was adopted on 14 December 2022 and published on 27 December 2022 [7]. Its purpose is “to achieve a high common level of cybersecurity across the Union.” [7]

Member States were required to transpose NIS2 by 17 October 2024 [8].

NIS2 applies to essential and important entities across sectors such as:

• Energy, transport, water, healthcare, banking,
• Financial market infrastructures,
• Digital infrastructure, managed services,
• Public administration, and more. Most relevant to system architects is NIS2’s requirement to define “policies and procedures regarding the use of cryptography and, where appropriate, encryption.” [7]

Engineering ImplicationsNIS2 does not name algorithms. Instead, it demands:

• Documented cryptographic policies,
• Upgradeability strategies,
• Lifecycle management for keys and algorithms,

• Demonstrable resilience against known risks. This means:

• Fixed, non-upgradable TLS stacks become a liability.

• Systems must prepare for algorithm deprecation cycles.

• Quantum-vulnerable algorithms must be assessed as part of risk management. Java advisory noteRecent Java features support NIS2 expectations:

• The KEM/KDF APIs make algorithm agility feasible.

• Modern PEM support simplifies adoption of evolving certificate profiles.
• Forward-looking hybrid TLS implementations allow for controlled, gradual migration.
• Removal of the Security Manager (JEP 486) reduces the number of brittle, hard-to-audit legacy security layers. Back to top

DORA — Operational ResilienceRegulation (EU) 2022/2554 (DORA) became applicable on 17 January 2025 [9]. It states that “ICT systems support complex systems used for everyday activities.” [9]

DORA mandates:

• Continuous ICT risk management,
• ICT incident reporting,
• Operational resilience testing,

• Oversight of critical ICT third-party providers. Engineering ImplicationsDORA requires institutions to demonstrate:

• Resilience even under cryptographic degradation,

• Preparedness for long-term confidentiality threats,
• Robust key management and secure communications,

• Crypto agility and migration planning. Many financial infrastructures rely heavily on Java. This means:

• Java-based systems will be evaluated as part of ICT operational resilience.

• Quantum-resilience will increasingly be seen as part of ICT risk, not theoretical research. Java advisory noteJava’s modern crypto stack helps architects meet DORA’s expectations:

• KEM/KDF abstractions enable controlled PQ/HKDF migration designs.

• Hybrid TLS (draft features—exact JEP number requires verification) reduces exposure to “harvest now, decrypt later” attacks.
• Proposed PQ algorithms (JEPs 496/497) enable early integration testing. Back to top

Cyber Resilience Act — Secure-by-Design SoftwareThe Cyber Resilience Act—Regulation (EU) 2024/2847—entered into force on 10 December 2024. Most obligations take effect from 11 December 2027 [11]. CRA declares, “Cybersecurity is one of the key challenges for the Union.” [11]

Core ObjectivesIt applies to all products with digital elements, demanding:

1. Secure-by-design and secure-by-default development practices
2. Mandatory vulnerability management and disclosure processes
3. Obligatory security update mechanisms
4. Regulation of cybersecurity risks across the entire lifecycle of digital products

5. Increase transparency and accountability for vendors and manufacturers Engineering ImplicationsCRA influences platform choices due to its impact on user experience and engagement:

6. Cryptography must be updatable throughout the product’s lifecycle.

7. Security controls must be auditable.

8. The architecture must be maintainable for years to come. Java advisory noteJava provides:

9. Removal of the outdated Security Manager, improving auditability;

10. Standardized crypto APIs that enable algorithms to evolve;
11. Modern TLS and PEM handling for future profiles. These do not “make you CRA-compliant,” but they make compliance architecturally achievable.**

Back to top

Standards & Certification — ENISA EUCC, ACM v2, ETSI TS 103 744ENISA & EUCCThe EU Cybersecurity Act (Regulation (EU) 2019/881) established the EU cybersecurity certification framework [13]. Under it, ENISA published the EUCC Guidelines on Cryptography in July 2024 [14].

These guidelines recommend that developers use the Agreed Cryptographic Mechanisms version 2 (ACM v2) for certified products [15].

Public analyses confirm that ACM v2 introduces hybrid and quantum-safe mechanisms for high-assurance contexts [16].

ETSI TS 103 744 — The Foundation of Hybrid TLSETSI’s Quantum-Safe Cryptography working group authored TS 103 744, which defines “quantum-safe hybrid key establishment schemes pairing a high-assurance but quantum-vulnerable key exchange with a quantum-safe key encapsulation mechanism.” [17]

The updated version 1.2.1 describes itself as offering “a clear, testable, and interoperable path to deploy hybrid key establishment today.” [19]

Java advisory noteDraft and prototype implementations of hybrid TLS in Java follow this ETSI pattern:

• Classical ECDHE + PQC KEM → combined via a KDF
• Using provider abstractions defined in JEP 452/510. Back to top

National Implementations — Germany and FranceGermany: Draft law NIS2UmsuCG for NIS2 implementation [20] and FinmadiG for DORA and MiCAR alignment [21].

France: The Projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité was adopted in first reading by the Senate on 12 March 2025 [23].

These national laws that dictate how supervisory authorities will assess systems in real-world scenarios transform EU obligations into auditable operational requirements:

• Supervisory authorities can request evidence that systems support cryptographic evolution.
• Algorithms must be replaceable without requiring significant code rewrites.
• TLS configurations must be compatible with hybrid and post-quantum cryptographic mechanisms.
• PKI infrastructures must be able to handle new certificate profiles.
• Legacy security designs must be replaced with maintainable and testable architectures. Back to top

Practical Checklist for Java-Based SystemsFor CTOs and Security Architects Map your systems to NIS2, DORA, CRA applicability. * Identify sensitive data requiring long-term confidentiality. * Build a crypto-agility roadmap aligned with PQC phases. For Platform Teams Plan pilots of hybrid TLS and roadmap-aligned cryptography. * Transition away from legacy, hard-coded crypto. * Establish internal standards for provider-based crypto. For Java Developers Familiarize yourself with KEM/KDF APIs and PEM updates. * Avoid bespoke crypto; rely on JCA/JCE where possible. * Track PQC-related JEPs* (especially those still in proposal form). Back to top

ConclusionEU cybersecurity legislation is setting the direction for the next decade: resilience, agility, post-quantum readiness, and security-by-design. These requirements affect protocols, libraries, build pipelines, PKI, update mechanisms, and runtime platforms.

Java’s recent and proposed features—modern crypto APIs, hybrid-TLS work, improved certificate handling, simplified security architecture—provide solid foundations for architects who need to prepare for this future. The mandates are coming. The engineering must begin now.

Back to top

References [1] European Commission. Recommendation (EU) 2024/1101 of 11 April 2024 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography. 2024. url * [2] European Commission. Communication accompanying Recommendation (EU) 2024/1101 (quotation referenced). 2024. * [3] European Commission. Recommendation (EU) 2024/1101, Article 2: Tasking the NIS Cooperation Group. 2024. * [4] NIS Cooperation Group. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography.* 23 June 2025. url * [5] NIS Cooperation Group. PQC Roadmap – Phases and Timeline Guidance. 2025. * [6] Industry and policy analyses summarising PQC milestones (2026 planning, 2030 critical systems, ~2035 broader migration). 2025. * [7] European Parliament & Council. Directive (EU) 2022/2555 (NIS2 Directive) on measures for a high common level of cybersecurity across the Union. 2022. url * [8] European Commission. NIS2 Transposition Overview – Transposition by 17 October 2024. 2024. * [9] European Parliament & Council. Regulation (EU) 2022/2554 (DORA). 2022. url * [10] Legal and compliance analyses confirming DORA applicability from 17 January 2025. 2024–2025. * [11] European Parliament & Council. Regulation (EU) 2024/2847 (Cyber Resilience Act). 2024. * [12] Regulatory summaries detailing CRA’s entry into force (10 December 2024) and applicability (11 December 2027). 2024–2025. * [13] European Parliament & Council. Regulation (EU) 2019/881 (Cybersecurity Act). 2019. * [14] ENISA. EUCC Cryptography Guidelines. 17 July 2024. * [15] ENISA & ECCG. Agreed Cryptographic Mechanisms version 2 (ACM v2). 2024–2025. * [16] Keysight & other vendors. Analyses of ACM v2 and the introduction of hybrid/PQC mechanisms. 2024–2025. * [17] ETSI TC CYBER QSC. ETSI TS 103 744 – Quantum-Safe Hybrid Key Exchanges. 2020–2024. url * [18] ETSI. TS 103 744 – Technical definition of hybrid KEX (Classical KEX + PQC KEM). 2020–2024. * [19] ETSI. TS 103 744 v1.2.1 – “Clear, testable, and interoperable path to deploy hybrid key establishment today.” 2024. * [20] Germany (BMI). Draft NIS2UmsuCG – NIS2 Implementation and Cybersecurity Strengthening Act. 2024–2025. * [21] Germany. Finanzmarktdigitalisierungsgesetz (FinmadiG). 2024–2025. * [22] German legal commentaries discussing FinmadiG’s alignment with DORA/MiCAR. 2024–2025. * [23] France. Projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité – Senate Adoption 12 March 2025. 2025. * [24] French legal analyses on NIS2/CER/DORA transposition. 2025. Back to top

Ixchel RuizKarakun AG – Basel, Switzerland

Ixchel Ruiz has been developing software applications and tools since 2000. Her research interests include Java, dynamic languages, client-side technologies, and testing. As a member of the JCP Executive Committee, Java Champion, Oracle ACE Pro, Testcontainers Community Champion, CDF Ambassador, Hackergarten enthusiast, Open Source advocate, public speaker, and mentor, Ixchel is deeply committed to fostering inclusive and collaborative tech communities. She actively mentors aspiring developers and champions initiatives aimed at increasing diversity and accessibility in the technology sector.

Ixchel’s work is characterised by a relentless pursuit of innovation, a deep understanding of user needs, and an unwavering commitment to ethical technology development.

The post Breaking keys and building trust: The JAVA way! appeared first on JVM Advent.