NIS2, DORA, and the EU Post-Quantum Roadmap

[This article was updated on 13 Feb to include references to the new EU cybersecurity proposal]

The quantum problem the law is quietly solving

Here’s the easiest way to misunderstand post-quantum cryptography: treat it as “future crypto.” Something for the next decade. A problem to track but not to fund – not yet.

The European Union disagrees. In Brussels, PQC has already crossed the line from “R&D curiosity” to “regulated risk.” The reasoning is blunt and hard to argue with: data protected by today’s public-key cryptography can be harvested right now and decrypted later, the moment a sufficiently powerful quantum computer comes online. It’s the threat model the security community calls “Harvest Now, Decrypt Later” – or HNDL – and it means sensitive data you encrypted this morning might already be sitting in an adversary’s archive, waiting for a key that doesn’t exist yet but probably will.

But it’s not only confidentiality at stake. Quantum computers won’t just read secrets – they could forge signatures, undermine trust chains, and make it impossible to tell whether a software update, financial transaction, or government document is genuine. Once you see the full threat surface, the EU’s urgency starts to look less like regulatory overreach and more like an overdue correction.

And that’s the conceptual shift that matters most for leadership teams. The EU isn’t (yet) mandating “deploy algorithm X by date Y” for most organizations. What it is doing is far more methodical: building a layered regulatory machine that makes crypto agility and cryptographic asset management auditable – then publishing a coordinated PQC timeline that supervisors, auditors, customers, and procurement teams can point to when they ask the uncomfortable question: Will your cryptography still work in 2030?

If you’re a CISO operating under NIS2 or DORA, you’re 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 stamping quantum as one of those evolving threats. And once that stamp lands, the regulatory machinery takes over. 

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

You won’t find many direct “quantum” references in NIS2. That’s by design – and the regulation’s leverage is stronger for it. What NIS2 does is codify a CISO’s obligation set in a way that naturally pulls PQC into scope the moment public authorities define quantum as a relevant threat and publish a timeline. Which they have.

The baseline: cryptography is already in the requirement set

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.” That sits alongside supply-chain security, secure development, and effectiveness testing. In other words, your cryptography posture isn’t a nice-to-have annex – it’s a core compliance obligation.

The accountability hook: boards can’t delegate this away

NIS2 hardens accountability in a way that should make any general counsel sit up. Management bodies must approve risk-management measures, oversee their implementation, and “can be held liable” for infringements. The directive also mandates management-body training on cybersecurity risk.

This is a powerful PQC accelerant, even if it doesn’t mention quantum once. PQC migration is long-horizon, cross-platform, and budget-heavy – exactly the kind of program that withers and dies without board-level ownership. NIS2 makes that ownership non-optional.

The enforcement teeth: fines, procurement, and certification

Where NIS2 becomes a market lever – not just a security control catalog – is in three areas that compound on each other:

Fines. Administrative fines for infringements of core obligations (notably risk management and incident reporting) run up to €10 million or 2% of worldwide turnover for essential entities, and €7 million or 1.4% for important entities. These are maximums, but they set the ceiling high enough to change budget conversations.

Procurement hooks. The directive pushes Member States to address cybersecurity in public procurement, including requirements relating to encryption and certification. It also treats supply-chain risk as a systemic driver of incidents. Translation: if you’re selling to the EU public sector and your products aren’t on a credible crypto-agility path, you have a problem.

Certification-as-proof. Member States may require certified ICT products, services, or processes to demonstrate compliance. And the Commission can adopt delegated acts to require entire categories of entities to use certified products under EU cybersecurity certification schemes. That’s a built-in escalation path: if voluntary adoption stalls, mandatory certification can be switched on.

Here’s the bottom line: NIS2 doesn’t need to say “deploy PQC.” Once EU and national bodies treat quantum as a material cryptographic threat – and they already have – NIS2’s cryptography policies, procurement expectations, certification pathways, and executive liability become the legal rails on which PQC programs run.

January 2026: the EU just proposed explicit PQC inclusion in NIS2

And then, on 20 January 2026, Brussels dropped the other shoe.

As part of a broader cybersecurity simplification package aligned with the proposed Cybersecurity Act 2, the European Commission published COM(2026) 13 final – a proposed directive amending NIS2 with targeted changes including, for the first time, an explicit post-quantum cryptography requirement written directly into the directive text.

The key provision is a new Article 7(2)(k), which would require Member States to adopt national policies “for the transition to post-quantum cryptography, taking into account the transition timelines and relevant requirements set out in applicable Union legal acts and policies.” In other words: PQC migration planning would no longer be implied by NIS2’s general “state-of-the-art” language or inferred from external roadmaps. It would be a named obligation in the directive itself.

The proposal’s recitals go further than any previous EU legislative text on quantum risk. Recital (8) explicitly names HNDL attacks as “likely occurring already now,” flags future quantum risks to signature integrity, and references the “planned deprecation of certain algorithm implementations and full disallowance of current public-key cryptographic algorithms.” It calls on Member States to create support measures and tools for assessing cryptographic asset exposure, building migration plans, and testing PQC deployment – while also fostering the emergence of “formally verified and evaluated European PQC solutions.” The recital anchors these efforts to the NIS Cooperation Group’s Coordinated Implementation Roadmap from June 2025, reaffirming the 2030 deadline for critical use cases and 2035 for medium- and low-risk systems.

For CISOs, this proposal changes the compliance calculus in a tangible way. Until now, PQC readiness under NIS2 was a matter of interpretation – defensible, but still requiring you to connect the dots between “cryptography policies,” “state-of-the-art,” and external PQC guidance. If COM(2026) 13 is adopted, that interpretive gap closes. PQC transition policies become a mandatory component of each Member State’s national cybersecurity strategy, which in turn shapes what supervisors expect from the entities they regulate.

The proposal is currently in the legislative process and would require transposition by Member States within 12 months of entry into force. But even before adoption, its existence sends a clear signal: the EU’s regulatory machinery is moving from “PQC is implied” to “PQC is required.” Organizations that haven’t started their cryptographic inventory and migration planning are now running behind a publicly stated legislative intent.

The NIS2–DORA boundary is itself a PQC governance clue

There’s a governance clue buried in the relationship between these two regulations. NIS2 explicitly treats DORA as a sector-specific act for financial entities, meaning DORA’s ICT risk management and reporting regime applies “instead of” NIS2 for those entities – while still preserving information-sharing and coordination between the two regimes.

For CISOs in financial services groups that also operate NIS2-covered businesses, this is a practical signal: you’ll likely need a single PQC program that produces evidence artifacts usable in two regulatory dialects. Build once, speak twice.

A note on jurisdiction: because NIS2 is a Directive (not a Regulation), Member States must transpose it into national law, and supervisory practice will vary. This article doesn’t presume how any given authority will interpret “state-of-the-art” in cryptography for PQC specifically. But the direction of travel is clear. 

How DORA turns “crypto agility” into supervisory expectation

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

At the top of the stack, DORA makes ICT risk a management-body responsibility. Management must define, approve, and 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. That’s the governance frame. But DORA operationalizes those responsibilities through three levers that are directly relevant to PQC migration – and each one is worth unpacking.

Lever 1: Cryptography as a living control

DORA’s ICT risk management RTS – that’s Commission Delegated Regulation (EU) 2024/1774, for the citation-minded – ties cryptographic controls to data classification and ICT risk assessment. Financial entities are expected to “remain abreast” of developments in cryptanalysis and handle “cryptographic threats, including threats from quantum advancements.”

Read that again. The RTS doesn’t say “consider quantum at some future date.” It says “quantum advancements” are part of the cryptographic threat landscape you must monitor now. The RTS also requires encryption and cryptographic control policies, mandates lifecycle key management, and, critically for PQC, requires provisions for updating or changing cryptographic technology based on cryptanalysis developments. If you can’t follow leading practices or standards, you need recorded, reasoned exceptions.

This isn’t aspirational language. DORA applies from 17 January 2025, so the “quantum advancements” expectation in the RTS is sitting inside an applicable supervisory regime right now.

Lever 2: Cryptographic asset management becomes auditable

The same RTS requires structured ICT asset management records, including interdependencies, and mandates that entities create and maintain a register for all certificates and certificate-storing devices – at least for assets supporting critical or important functions.

If that sounds like the inventory backbone you’d need before planning hybrid certificates, PQC key sizes, or HSM upgrades – that’s exactly what it is. DORA is effectively requiring the preconditions for PQC migration whether it uses the words “post-quantum” or not.

Lever 3: Third-party risk makes PQC a contractual requirement

DORA forces financial entities to maintain an explicit register of contractual arrangements with ICT providers, perform due diligence, include minimum contractual provisions on data protection attributes (availability, authenticity, integrity, confidentiality), and demonstrate workable exit strategies.

It also creates an oversight regime for critical ICT third-party providers, including the possibility of periodic penalty payments for noncompliance. That’s an enforcement lever that can propagate “PQC-ready cryptography” requirements upstream into providers’ product roadmaps. Your cloud provider, your HSM vendor, your certificate authority – they’re all in scope.

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

The EU’s PQC policy stack isn’t just guidance. It’s explicitly designed as a pipeline – from coordination to enforceable law, if coordination doesn’t deliver fast enough.

The recommendation: “as swiftly as possible”

The Commission’s PQC Recommendation (EU) 2024/1101 frames PQC transition as necessary “as swiftly as possible.” It encourages Member States to build a coordinated transition roadmap and explicitly endorses deploying PQC via hybrid schemes – combining PQC with existing classical cryptography, or with quantum key distribution (QKD).

The quiet power move is in the final clause: the Commission says it intends to monitor progress and may determine whether “additional steps, including proposing binding acts of Union law,” are required. That’s regulatory speak for we’re giving you a chance to move voluntarily, but the mandate is loaded and ready.

The roadmap: dates on the public record

In June 2025, the Commission and Member States published a coordinated roadmap – and, crucially, put hard dates in public, press-release form:

• End of 2026: Member States “should start transitioning.”
• End of 2030: “Critical infrastructures should be transitioned.”
• End of 2035: Complete transition “for as many systems as practically feasible.”

The roadmap adds the machinery CISOs have been asking for: a risk-based prioritization model (high, medium, low quantum risk) and alignment with international timelines, including NIST’s transition approach. It also makes a pragmatic argument: many of these actions are “no-regret” moves because they improve security generally and support NIS2 compliance regardless of when a cryptographically relevant quantum computer arrives.

The timeline at a glance

Here’s the compilation of the highest-signal EU dates – the ones that typically drive budgets, audits, and vendor pressure:

2024

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

2025

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

2026

• COM(2026) 13 proposed: January 2026 – amends NIS2 to explicitly require Member State PQC migration policies (Article 7(2)(k)).
• EU PQC: start transition by end of 2026 (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 timeline).

2030

• EU PQC: transition critical infrastructures and 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, you have to zoom out and see the wider set of levers that touch cryptography indirectly – often more forcefully than technology-specific mandates.

Product rules that reshape what vendors sell you

The Cyber Resilience Act (Regulation (EU) 2024/2847) sets horizontal cybersecurity requirements for “products with digital elements” placed on the EU market. While the CRA isn’t a PQC statute, it’s a supply-chain accelerator with long reach: if PQC becomes part of “secure by design” expectations over the lifecycle of long-lived products – industrial systems, networking gear, IoT devices – vendors will face pressure to design for cryptographic upgrade paths and to maintain vulnerability handling that includes crypto agility.

This connects directly to the EU PQC roadmap’s emphasis that long transition periods for complex systems (PKI, long-lived devices) demand early action and “quantum-safe upgrades enabled by default” after the 2030 milestone. The CRA creates the enforcement surface to make that stick.

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 of 2026. The eIDAS ecosystem is PKI-heavy – signatures, certificates, trust services. If you’re a regulated organization issuing certificates, using qualified trust services, or integrating wallets, PQC readiness becomes a practical dependency, not a theoretical one.

Identity systems have some of the longest cryptographic migration lead times in any enterprise. This connects back to NIS2’s push toward qualified trust services and to the roadmap’s explicit warning that PKI is a long-transition dependency that must start early.

Certification and conformity: where “recommended” crypto becomes a market gate

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

The EU has been rolling out specific schemes like the EUCC (EU Common Criteria-based scheme), covering ICT products including encryption devices and electronic signature devices. These schemes aren’t “PQC mandates” today. But they’re the 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. Given the direction of travel, that evolution feels less like “if” and more like “when.”

Standards alignment as a regulatory force multiplier

This is where the EU policy stack locks onto the global standardization ecosystem – and the combined force is substantial.

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

On the global side, the building blocks are falling into place:

• NIST 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” isn’t academic neatness. It’s 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. What you need is 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 running in parallel – help in two very practical ways. First, they reduce the risk of betting the organization on a single new primitive whose real-world track record is, by definition, short. Second, they preserve interoperability during phased migrations – exactly the dual challenge that arises when you have a mixed population of quantum-safe and not-yet-upgraded clients and servers.

In practice, this means:

For key establishment: The common enterprise pattern is hybrid key exchange (e.g., ECDHE + ML-KEM), reflected in TLS working documents and in ETSI’s hybrid key establishment specification. The design principle is straightforward: the derived key remains secure if at least one component key exchange remains secure. That’s the insurance policy.

For signatures: Hybrid and composite approaches are being specified for TLS and PKI ecosystems to manage interoperability and “migration safety.” Pure PQC signatures (ML-DSA, SLH-DSA) are also standardized for environments where you control both endpoints and the full certificate chain.

The EU’s own policy documents explicitly endorse hybrid schemes – including the option to combine with QKD – as a deployment bridge. If you’re looking for regulatory cover for a “hybrid first” strategy, it doesn’t get much clearer than this.

The “cryptographic bill of materials” – your compliance backbone

The biggest operational blocker to PQC isn’t algorithm choice. It’s 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 of its guidance and treats it as a no-regret move that supports NIS2 compliance regardless of quantum timelines.

DORA reinforces this in enforceable form: structured ICT asset inventories including interdependencies, plus a register of certificates and certificate-storing devices for critical and important functions. ETSI’s staged migration guidance similarly begins with inventory compilation as the first formal step.

For many CISOs, this converges into a single program artifact: a cryptographic asset inventory (or 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 and 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 force you to treat PKI and HSM constraints as first-class concerns in your ICT risk management framework.

In practice, this means PQC readiness isn’t just “enable ML-KEM in TLS.” It’s also:

• Can your internal CA issue PQC or hybrid certificates? And can your endpoints actually validate them?
• Can your certificate lifecycle tooling handle bigger keys and signatures without breaking renewal automation – especially where DORA expects prompt renewal?
• Can your HSM and 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?

These aren’t theoretical questions. They’re the difference between a migration that takes months and one that takes years.

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. 

What a regulator-aligned PQC program actually looks like

A PQC program that’s credible under NIS2 and 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 DORA’s asset/certificate register requirements.

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

For implementation sequencing, 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.

A minimal technical baseline you can defend as “state-of-the-art” today

This isn’t a protocol prescription – your environment will vary – but it’s a defensible baseline aligned with the current standards posture:

1. Prefer standardized PQC primitives (ML-KEM, ML-DSA, SLH-DSA as published by NIST), not ad-hoc or proprietary algorithms.
2. 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.
3. Ensure protocol support is anchored in the standards ecosystem – TLS hybrid ECDHE–MLKEM working documents, PKIX identifiers for ML-DSA, and so on. Don’t roll your own protocol integration.

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

A useful rule of thumb: if you can’t 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:

Board-facing oversight documentation – approved roadmap, budget allocation, training evidence, aligned with NIS2 governance and DORA management obligations

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 cryptanalysis monitoring and documenting exceptions with rationale

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 and tests

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.