NIS2, DORA, and the EU Post-Quantum Roadmap

The quantum problem the law is quietly solving

The easiest way to misunderstand post-quantum cryptography (PQC) is to treat it as “future crypto.” In the EU’s own framing, it is a present governance and resilience problem: data protected with today’s non‑quantum‑safe public‑key cryptography can be harvested now and decrypted later, while future quantum computers could also undermine authenticity (signatures) and trust chains. 

That framing matters because it immediately turns PQC from an R&D topic into a regulated-risk topic. If you are a CISO under NIS2 or DORA, you are already expected to run a risk-management system that tracks material, evolving threats – and to implement “state‑of‑the‑art” controls appropriate to the risk. The EU’s PQC roadmap is effectively saying: quantum is now one of those evolving threats you must govern. 

The most important conceptual shift for leadership teams is this: the EU is not (yet) mandating “deploy algorithm X by date Y” for most private entities. Instead, it is building a layered regulatory machine that makes crypto agility and cryptographic asset management auditable – and then publishing a coordinated PQC timeline that supervisors, auditors, customers, and procurement teams can point to when they ask whether your cryptography will still work in 2030–2035. 

How NIS2 translates quantum risk into governance, controls, and penalties

NIS2’s direct “quantum” references are limited; its leverage is stronger than that: it codifies a CISO’s obligation set in a way that naturally pulls PQC into scope once public authorities define PQC as a relevant threat and publish a timeline.

Under NIS2, essential and important entities must implement cybersecurity risk-management measures that explicitly include “policies and procedures regarding the use of cryptography and, where appropriate, encryption,” alongside supply-chain security, secure development, and effectiveness testing. 

NIS2 also hardens accountability. Management bodies must approve the risk-management measures, oversee implementation, and “can be held liable” for infringements. It also requires management-body training. This is a powerful PQC accelerant because PQC migration is long-horizon, cross‑platform, and budget-heavy – exactly the kind of program that dies without board-level ownership. 

Where NIS2 becomes a “market lever” (not just a security control catalog) is in enforcement and in supply-chain/procurement hooks:

• Administrative fines must be available for infringements of core obligations (notably risk management and incident reporting), at least up to EUR 10M or 2% worldwide turnover for essential entities, and EUR 7M or 1.4% for important entities (maximums). 
• The Directive pushes Member States to address cybersecurity in public procurement, including requirements relating to “encryption” and certification, and it emphasizes supply-chain risk as a systemic driver of incidents. 
• NIS2 provides a path for certification-as-proof: Member States may require certified ICT products/services/processes to demonstrate compliance with specific requirements, and the Commission can adopt delegated acts to require categories of entities to use certified products or obtain certificates under EU cybersecurity certification schemes. 

In other words: NIS2 doesn’t need to say “deploy PQC.” Once EU and national bodies treat quantum as a material cryptographic threat and publish roadmaps/standards, NIS2’s “cryptography policies,” procurement expectations, certification pathways, and executive liability become the legal rails on which PQC programs run. 

The NIS2–DORA boundary is itself a PQC governance clue

NIS2 explicitly treats DORA as a sector-specific act for financial entities, meaning DORA’s ICT risk management and reporting regime applies “instead of” the NIS2 provisions for those entities – while still preserving information-sharing and coordination between regimes. For CISOs in financial services groups that also operate NIS2-covered businesses, that is a practical signal: you will likely need a single PQC program that produces evidence artifacts usable in two regulatory dialects. 

Member State transposition and supervisory practice will vary (and is jurisdiction-specific), because NIS2 is a Directive and must be implemented into national law; this article does not presume how any given Member State authority will interpret “state-of-the-art” in cryptography for PQC specifically. 

How DORA turns “crypto agility” into an explicit supervisory expectation

If NIS2 is the broad “cyber hygiene + governance + enforcement” engine, DORA is the precision instrument for the financial sector – and it gets unusually concrete on cryptography’s moving threat landscape.

At the top, DORA makes ICT risk a management-body responsibility. Management must define/approve/oversee ICT risk management; it must set policies aimed at high standards of data confidentiality, integrity, authenticity, and availability; and it must allocate budget, including for training. 

Then DORA operationalizes those responsibilities through three levers that are directly relevant to PQC migration:

Cryptography as a living control, not a static standard

In the ICT risk management RTS (Commission Delegated Regulation (EU) 2024/1774), cryptographic controls are tied to data classification and ICT risk assessment, and financial entities are expected to “remain abreast” of developments in cryptanalysis and handle “cryptographic threats, including threats from quantum advancements.” The RTS also requires encryption/cryptographic control policies, mandates lifecycle key management requirements, and – critically for PQC – requires provisions for updating or changing cryptographic technology based on cryptanalysis developments, plus recorded, reasoned exceptions when leading practices/standards cannot be followed. 

Cryptographic asset management becomes auditable

The same RTS requires structured ICT asset management records (including interdependencies) and requires entities to create and maintain a register for all certificates and certificate-storing devices for at least assets supporting critical or important functions – exactly the sort of inventory backbone you need before you can plan hybrid certificates, PQC key sizes, or HSM upgrades. 

Third-party and concentration risk makes PQC a contractual requirement

DORA forces an explicit register of contractual arrangements, due diligence on providers, minimum contractual provisions on data protection attributes (availability/authenticity/integrity/confidentiality), and demonstrable exit strategies. It also creates an oversight regime for critical ICT third‑party providers, including the possibility of periodic penalty payments for noncompliance by such providers – an enforcement lever that can propagate “PQC-ready cryptography” requirements upstream into providers’ product roadmaps. 

DORA’s effective date matters operationally: it applies from 17 January 2025, so the “quantum advancements” expectation in the RTS is not theoretical; it is sitting inside an applicable supervisory regime right now. 

The EU PQC recommendation and roadmap: timelines, risk tiers, and a path to harder law

The EU’s PQC policy stack is not just guidance; it is explicitly designed as a pipeline from coordination to enforceable law if coordination doesn’t deliver.

The Commission’s PQC Recommendation (Commission Recommendation (EU) 2024/1101) frames PQC as necessary “as swiftly as possible,” encourages Member States to build a coordinated transition roadmap, and explicitly points to deploying PQC via hybrid schemes that can combine PQC with existing cryptography or with quantum key distribution (QKD). It also states the Commission intends to monitor progress and may determine whether “additional steps, including proposing binding acts of Union law,” are required. 

That recommendation was then operationalized through the NIS Cooperation Group workstream and the coordinated implementation roadmap. In June 2025, the Commission and Member States published a coordinated roadmap and – importantly – put dates in public, press‑release form: Member States “should start transitioning… by the end of 2026,” and “critical infrastructures should be transitioned… no later than by the end of 2030.” 

The roadmap itself adds the missing machinery CISOs need: a risk-based prioritization model (high/medium/low quantum risk) and a third milestone for completing transition “for as many systems as practically feasible” by 2035, aligning with international timelines it references (including NIST’s transition approach). It also suggests that many actions are “no-regret” because they improve security generally and support NIS2 compliance. 

Timeline chart: EU compliance dates and the PQC migration clock

Below is a text timeline you can paste into a board pack; it compiles the highest-signal EU dates that typically drive budgets, audits, and vendor pressure. 

2024

• NIS2 transposition deadline: Member States adopt/publish measures by 17 Oct 2024; apply from 18 Oct 2024. 
• PQC Recommendation issued: 11 Apr 2024 (sets governance and a possible path to binding EU acts). 
• DORA ICT risk management RTS published in OJ (includes “quantum advancements” in cryptographic threat landscape). 
• Cyber Resilience Act enters into force 10 Dec 2024 (per Commission summary page). 

2025

• DORA applies from 17 Jan 2025. 
• Coordinated EU PQC roadmap published and promoted by the Commission (June 2025). 

2026

• EU PQC: start transition by end of 2026 (Member States; also drives public-sector and “critical infrastructure” expectations). 
• CRA reporting obligations apply from 11 Sep 2026. 
• European Digital Identity Wallets: Member States must provide wallets by end of 2026 (eIDAS 2.0 implementation timeline). 

2030

• EU PQC: transition “critical infrastructures” / high‑risk use cases by end of 2030. 

2035

• EU PQC: complete transition for as many systems as feasible; prioritize completing medium‑risk use cases by end of 2035. 

The broader EU lever stack: products, identity, certification, procurement

To understand how the EU can “push” PQC migration without a single PQC-only regulation, it helps to see the wider set of levers that touch cryptography indirectly—often more forcefully than technology-specific mandates.

Product rules that reshape what vendors can sell you

The Cyber Resilience Act (Regulation (EU) 2024/2847) sets horizontal cybersecurity requirements for “products with digital elements” placed on the EU market, with staged applicability (including earlier reporting obligations). While the CRA is not a PQC statute, it is a major supply-chain accelerator: if PQC becomes part of “secure by design” expectations over the life cycle of long-lived products (industrial systems, networking gear, IoT), vendors will be pressured to design for cryptographic upgrade paths and to maintain vulnerability handling that includes cryptographic agility. 

This interacts directly with the EU PQC roadmap’s emphasis that long transition periods for complex systems (notably PKI and long‑lived devices) demand early action and “quantum‑safe upgrades enabled by default” after the 2030 milestone. 

Identity and trust services: the EU’s crypto “spine”

eIDAS 2.0 (Regulation (EU) 2024/1183) establishes the European Digital Identity framework and drives rollout of EU Digital Identity Wallets by end‑2026. The eIDAS ecosystem is PKI-heavy (signatures, certificates, trust services). If you are a regulated organization issuing certificates, using qualified trust services, or integrating wallets, PQC-readiness becomes a practical dependency – because identity systems have some of the longest crypto migration lead times. 

This connects back to NIS2’s push toward qualified trust services and to the roadmap’s warning that PKI is a long-transition dependency that must start early. 

Certification and conformity: turning “recommended” crypto into procurement reality

The EU Cybersecurity Act (Regulation (EU) 2019/881) establishes the EU cybersecurity certification framework. NIS2 can use that framework as proof of compliance and, via delegated acts, can even mandate certification for categories of entities if “insufficient levels of cybersecurity” are identified. 

Separately, the EU has been rolling out specific certification schemes such as the EU Common Criteria-based scheme (EUCC), which is described as covering ICT products including security products like encryption devices and electronic signature devices (among others). Certification schemes are not “PQC mandates,” but they are a mechanism through which “state-of-the-art cryptography” can become a concrete market access requirement – if scheme requirements evolve to treat cryptographic agility and PQC support as baseline security functionality for relevant product classes. 

Standards alignment as a regulatory force multiplier

The PQC Recommendation explicitly calls for common European standards and EU-level evaluation/selection of PQC algorithms, while also emphasizing interoperability with international partners and standards bodies. DORA’s RTS similarly requires alignment with “leading practices and standards” and updating cryptography as cryptanalysis evolves. 

This is where the EU policy stack locks onto the global standardization stack:

• National Institute of Standards and Technology has published finalized PQC standards (FIPS 203 for ML‑KEM, FIPS 204 for ML‑DSA, FIPS 205 for SLH‑DSA). 
• IETF working documents specify how to negotiate ML‑KEM and hybrid ECDHE‑MLKEM key agreement in TLS 1.3, and how to use ML‑DSA for TLS authentication – critical for “real-world PQC,” because most enterprises consume cryptography through protocols, not primitives. 
• ETSI publishes a long-standing set of quantum-safe migration and hybrid-scheme documents, including staged migration guidance and hybrid key establishment specifications; these are increasingly aligned with NIST‑standardized primitives. 
• ENISA has published PQC state-of-standardization analysis and early mitigations (notably hybrid approaches and PSK mixing), which reinforces the migration logic regulators are now putting into roadmaps and RTS. 

In a regulated environment, “standards alignment” is not academic neatness; it is how supervisors decide whether your cryptography is defensible as “state-of-the-art,” especially when the regulatory texts intentionally stay technology-neutral. 

Practical PQC migration patterns CISOs can actually ship

A CISO audience doesn’t need another taxonomy of lattice-based algorithms. You need an upgrade pattern that survives procurement, audit, and incident response. The EU roadmap’s repeated preference is pragmatic: use standardized, tested hybrid solutions where feasible; prioritize high-risk use cases; and treat cryptographic asset management as foundational. 

Below are the migration patterns that best match the EU regulatory direction (risk-based, evidence-heavy, supply-chain aware), and the current standards reality.

Hybrid-by-default, then PQC-only where it actually reduces risk

Hybrid designs (classical + PQC) help in two very practical ways: (1) they reduce the risk of “betting the company” on a single new primitive, and (2) they preserve interoperability during phased migrations—exactly the dual challenge ETSI highlights when discussing mixed client populations and migration issues. 

Concretely:

• For key establishment, a common enterprise pattern is hybrid key exchange (e.g., ECDHE + ML‑KEM), reflected in TLS working documents and in ETSI’s quantum-safe hybrid key establishment specification, which states the derived key remains secure if at least one component KEX remains secure. 
• For signatures, hybrid and composite approaches are being specified for TLS and PKI ecosystems to manage interoperability and “migration safety,” while standards also exist for pure PQC signatures (e.g., ML‑DSA, SLH‑DSA) when you can control endpoints and certificate chains. 

The EU’s own policy documents explicitly endorse hybrid schemes (including the option to combine with QKD) as a deployment bridge. 

The “cryptographic bill of materials” becomes your compliance backbone

The biggest operational blocker to PQC is not algorithm choice; it is not knowing where cryptography lives – in code, libraries, appliances, firmware update chains, cloud services, outsourced platforms, and embedded devices. The EU roadmap puts “mature cryptographic asset management” at the center and treats it as a no‑regret move that supports NIS2 compliance. 

DORA reinforces this in enforceable form: it requires structured ICT asset inventories (including interdependencies) and a register of certificates and certificate-storing devices for critical/important functions. 

ETSI’s staged migration guidance similarly begins with inventory compilation as the first formal stage in a migration framework. 

For many CISOs, this converges into a single program artifact: a cryptographic asset inventory / CBOM-like register that maps:

• crypto mechanism (KEM/signature/symmetric/hash)
• protocol usage (TLS, SSH, IPsec/VPN, S/MIME, JWT/JOSE/COSE, code signing, database TDE, etc.)
• key/cert properties (algorithm, key size, certificate profiles, validity, issuance)
• dependency graph (services, vendors, hardware modules, update channels)
• data classification and confidentiality horizon
• migration feasibility score (time/effort—explicitly one of the EU roadmap’s quantum risk factors). 

PKI and HSM realities: PQC is a platform migration

The EU roadmap explicitly flags PKI as a “complex system” with long transition periods, which is why it argues early action is necessary even before final technical recommendations are published. 

DORA’s RTS requirements around certificate registers, key lifecycle policies, and mandatory documentation of cryptographic technology updates effectively force you to treat PKI/HSM constraints as first-class in your ICT risk management framework. 

Practically, this means PQC readiness is not only “enable ML‑KEM in TLS.” It is also:

• can your internal CA issue PQC/hybrid certificates (and can your endpoints validate them)? 
• can your certificate lifecycle tooling handle bigger keys/signatures and updated profiles without breaking renewal automation (especially where DORA expects prompt renewal)? 
• can HSM/KMS layers support the new algorithms, or will you need vendor roadmaps, firmware upgrades, or architectural changes that must be contracted and tested under DORA’s third-party regime? 

The CISO playbook: mapping obligations to controls, evidence, and a PQC program that survives audit

This section is designed as an “audit-ready” translation layer: it maps what regulators and roadmaps say into controls and evidence artifacts you can actually produce.

Obligations-to-evidence mapping table

The mapping below draws from NIS2 governance/risk-management requirements, DORA’s management and operational resilience duties, DORA’s ICT risk management RTS (including the quantum-cryptanalysis expectation), and the EU PQC recommendation/roadmap milestones. 

A practical, regulator-aligned PQC program structure

A PQC program that is credible under NIS2/DORA tends to look less like a “crypto upgrade project” and more like a regulated transformation with three persistent threads:

Governance thread (who owns risk, who signs acceptance): driven by NIS2 management liability and DORA management-body duties. 

Inventory + risk thread (what breaks, what matters first): driven by the EU roadmap’s risk-tier model and by DORA’s asset/certificate register requirements. 

Engineering + supplier thread (what you can actually deploy): driven by DORA’s contract controls and by standards availability (NIST FIPS; protocol drafts/specs), plus certification/procurement levers. 

For implementation, ETSI’s staged migration framing is a useful mental model: inventory → plan → execute. It aligns cleanly with what both supervisors and the EU roadmap implicitly require as “no‑regret” foundations. 

Minimal technical baseline CISOs can defend as “state-of-the-art” today

This is not a protocol prescription (your environment will vary), but it is a defensible baseline aligned with the current standards posture:

• Prefer standardized PQC primitives (e.g., ML‑KEM, ML‑DSA, SLH‑DSA as published), not ad‑hoc algorithms. 
• Prefer standardized hybrid deployment patterns where interoperability and migration safety require it; both EU and ETSI materials treat hybrid approaches as practical early mitigations and migration bridges. 
• Ensure protocol support (TLS, PKIX) is anchored in the standards ecosystem (e.g., TLS hybrid ECDHE‑MLKEM working documents; PKIX identifiers for ML‑DSA). 

What “quantum readiness” evidence looks like in a DORA/NIS2 audit

A useful rule: if you cannot show it (in an artifact), it doesn’t exist.

The EU roadmap and DORA RTS repeatedly imply the need for: dependency maps, risk analyses, asset inventories, pilots, and monitoring of cryptographic threat evolution. 

Evidence artifacts that tend to work well in supervised environments include:

• Cryptographic asset inventory (including certificate register exports and dependency graphs). 
• Quantum risk classification per system/use case (high/medium/low), grounded in confidentiality horizon, impact, and migration effort. 
• Cryptography policy with update triggers, explicitly referencing monitoring of cryptanalysis and documenting exceptions. 
• Supplier contract clauses requiring crypto agility and PQC roadmap commitments, aligned with DORA contractual governance. 
• Runbooks and test evidence (especially where DORA expects resilience testing programs and “learning and evolving” after incidents/tests). 
• Board-facing oversight (approved roadmap, budget, training evidence), aligned with NIS2 governance and DORA management obligations. 

Appendices

Sample board memo

Subject: Quantum-safe cryptography readiness under NIS2/DORA: risk, timeline, and funding decision

Why this is on the board agenda now
EU policy bodies have published a coordinated PQC roadmap with milestones that begin by end‑2026 and prioritize transitioning critical/high‑risk use cases by end‑2030. Separately, DORA’s ICT risk management RTS explicitly expects us to monitor cryptographic threats “including threats from quantum advancements,” and to update cryptographic technology accordingly. These expectations convert PQC from a “future architecture topic” into a governed operational resilience requirement. 

Business risk framing

• Long‑lived confidentiality and trust chains (PKI, authentication, software signing) are exposed to “store now, decrypt later” risk and to future signature compromise scenarios. 
• Migration lead times are multi‑year, especially for PKI and embedded/long-lived assets, so delaying until “standards settle” increases the probability of noncompliance and rushed, risky implementation later. 

Regulatory accountability

• Under NIS2, the management body must approve and oversee cybersecurity risk-management measures and can be held liable for infringements; NIS2 also contemplates significant administrative fines for noncompliance. 
• Under DORA, the management body is responsible for ICT risk management and must ensure policies that maintain confidentiality/integrity/authenticity/availability; DORA also requires mandatory ICT security awareness and resilience training for staff and senior management. 

Decision requested
Approve a two‑track PQC readiness program:

1. Foundations (0–6 months): cryptographic asset inventory (incl. certificate register), quantum risk classification, supplier impact assessment, and a phased PQC roadmap aligned to EU milestones. 
2. Delivery (6–24 months): pilots for high‑risk use cases (hybrid where appropriate), contract updates for critical ICT providers, and operational monitoring/reporting for cryptographic threat evolution. 

KPIs the board will see quarterly

• % of critical services with cryptographic inventory completed
• % of certificates/keys covered by register and lifecycle controls
• of high-risk use cases with PQC pilot or migration plan approved
• % of strategic vendors with PQC/crypto agility contractual commitments
• Exceptions to leading practices/standards (with documented rationale) 

One-page checklist for CISOs

Scope and governance

• Confirm whether the entity is in-scope for NIS2, DORA, or both (group structure matters). 
• Assign accountable exec sponsor; define decision rights for crypto exceptions and risk acceptance. 
• Build management training module on PQC risk and timeline; log completion. 

Inventory and classification

• Build/refresh cryptographic asset inventory (protocols, libraries, appliances, firmware signing, PKI). 
• Maintain certificate register for critical/important functions (certificates + storage devices). 
• Classify systems/use cases into quantum risk tiers (high/medium/low) using: crypto weakness + impact + migration effort. 

Architecture and migration planning

• Define crypto agility principles (algorithm agility, certificate agility, key rotation). 
• Select standards-aligned primitives and protocol approaches (prefer standardized and tested hybrid where needed). 
• Publish a phased roadmap aligned to EU milestones (start by end‑2026; critical/high-risk by end‑2030; broad completion by 2035). 

Supplier and procurement levers

• Update vendor contracts under DORA: PQC roadmap commitments, crypto agility requirements, audit/inspection rights, and tested exit plans. 
• Add PQC readiness criteria to procurement specs (especially long-lived products with digital elements). 

Operations and evidence

• Maintain a living cryptography policy that includes review triggers based on cryptanalysis developments and records exceptions with rationale. 
• Run pilots and record outcomes; integrate lessons learned into resilience testing and risk processes.