Post-Quantum Cryptography Under NIS2: ‘Quantum’ Appears 0 Times in the CIR — How 9.2(b) Agility and 9.3 ‘State of the Art’ Pull the EU Roadmap’s 2030 Milestone Into Your Audit

Short answer: NIS2 sets no post-quantum deadline. The word “quantum” appears zero times in the NIS2 Directive and zero times in its Implementing Regulation. But for the digital providers it covers, two provisions of that Regulation do the work instead. Annex point 9.2(b) asks for “a cryptographic agility approach” where appropriate, and point 9.3 makes you review your cryptography policy “taking into account the state of the art in cryptography”. Since June 2025 the EU’s most detailed public statement on that state of the art for quantum risk has been a Cooperation Group roadmap with milestones at the end of 2026, 2030 and 2035. You don’t have to follow it, but a policy review that ignores it will be hard to defend.

One disclosure: we sell NIS2 templates, including a toolkit with an encryption policy. Weigh the product mention below with that in mind. Everything else here is sourced to the Official Journal, the NIS Cooperation Group, ENISA, the European Parliament or NIST.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Does this apply to you? Scope first

In plain terms: every NIS2 entity needs a cryptography policy. Only eleven types of digital-sector provider are bound by the detailed Annex wording quoted in this guide. Financial entities answer to DORA, whose rules actually mention quantum.

Article 21(2)(h) of the NIS2 Directive requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption”. Article 21(1) adds that measures must take into account “the state-of-the-art and, where applicable, relevant European and international standards”. The detail sits in Implementing Regulation (EU) 2024/2690 (the CIR), and its Article 1 limits the Annex to a named list of entities.

Your organisation	What governs your PQC planning	The legal test
DNS service provider, TLD name registry, cloud, data centre, CDN, managed service provider, managed security service provider, online marketplace, search engine, social networking platform, trust service provider	CIR Annex points 9.1, 9.2(b) and 9.3 apply directly	The Annex text, plus national supervision
Any other essential or important entity (energy, health, transport, manufacturing and so on)	Article 21(1) and 21(2)(h) as transposed into national law	Your national law. The Annex is a reference point, not the binding text
Bank, insurer, investment firm or other DORA financial entity	DORA’s ICT risk rules, which name quantum explicitly (see below)	DORA and its technical standards
Organisation outside NIS2 and DORA	No legal PQC duty from these acts	Contracts and customer requirements may still ask for it

If you’re on the CIR list, read the points below as binding detail. If not, read them as the clearest EU statement of “state of the art” cryptography governance. Our guide to the ten CIR Annex 9 cryptography controls covers the rest of the chapter.

The legal chain: how a non-binding roadmap reaches a binding audit

In plain terms: the law never says “migrate to post-quantum algorithms”. It says keep your cryptography current and build it so you can change it. The EU roadmap now describes what “current” means for quantum risk.

Four links connect the two, and each one is a sentence in the Official Journal:

1. Article 21(1) NIS2 sets the yardstick: measures must take into account “the state-of-the-art”. That applies to every NIS2 entity.
2. CIR point 9.2(b) requires your policy to set the protocols, algorithms, cipher strength and usage practices “to be approved and required for use”, “following, where appropriate, a cryptographic agility approach”. This is the only place “agility” appears in the CIR.
3. CIR point 9.3 requires you to “review and, where appropriate, update” the policy “at planned intervals, taking into account the state of the art in cryptography”. No “where appropriate” softens the review itself. Only the update depends on what the review finds.
4. CIR Article 2(2) closes the escape hatch. If you decide a “where appropriate” measure, such as the agility approach, isn’t appropriate for you, you “shall in a comprehensible manner document [your] reasoning to that effect”.

So you can decide crypto-agility doesn’t fit a system, but you must write down why. And every planned review must show what the state of the art was. Since June 2025 that includes an EU roadmap that names NIS2 entities. Its section 3.1 says “public administration entities and other critical infrastructures, notably those in scope of the NIS2 Directive should refer to this document and its further releases”. Section 6.3 goes further: “One may also consider to include cryptographic agility in evaluation of NIS2 conformity.”

“Should refer” and “may also consider” bind no one. The roadmap is Cooperation Group guidance resting on a non-binding Recommendation. Point 9.3 is what gives it weight: a 2026 review that says “state of the art reviewed, no change needed” without mentioning the quantum threat is a weak answer when the auditor asks what was reviewed.

Word census: what each EU text actually says about quantum

In plain terms: the binding texts say nothing about quantum and the guidance says a lot. Keeping them apart avoids the most common error on this topic: calling 2030 a legal deadline. We counted the terms across the full text of each instrument.

Instrument	Binding on entities?	What it says on quantum or agility
NIS2 Directive 2022/2555	Yes, via national law	“Quantum” ×0. Art 21(1) “state-of-the-art”; Art 21(2)(h) cryptography policies
CIR 2024/2690 Annex	Yes, for the eleven listed provider types	“Quantum” ×0. “Agility” ×1 (9.2(b)). “State of the art” ×2 (9.3 cryptography, 11.6.3 authentication)
ENISA Technical Implementation Guidance, June 2025	No	“Quantum” ×1: agility features include “future-proofing by considering quantum cryptographic algorithms”
Commission Recommendation (EU) 2024/1101	No; addressed to Member States	Asks Member States to build a coordinated PQC roadmap for public administrations and other critical infrastructures
NIS CG PQC Roadmap, June 2025, and FAQ, April 2026	No	Milestones 2026 / 2030 / 2035; “shall not be used stand-alone after the end of 2030” for high-risk use cases
Proposal COM(2026) 13 amending NIS2	No; a proposal, and aimed at Member States	New Art 7(2)(k): national strategies to include a policy “for the transition to post-quantum cryptography”. No date
DORA RTS 2024/1774	Yes, for financial entities (Article 6; the recital is interpretive)	Recital 9: “threats from quantum advancements”; Art 6(4): update cryptography “on the basis of developments in cryptanalysis”

The Commission’s January 2026 proposal only obliges Member States to put a PQC policy into their national strategies, “taking into account the transition timelines and relevant requirements set out in applicable Union legal acts and policies”. It sets no date for anyone. The Parliament’s procedure file shows it still awaiting a committee decision, with the ITRE draft report dated 24 September 2026. Our overview of the 13 proposed NIS2 amendments covers the rest of the package.

Financial entities are further ahead. The DORA technical standard on ICT risk management names quantum in a recital, and its Article 6(4) makes cryptanalysis-driven updates a binding part of the encryption policy. Our NIS2 vs DORA comparison explains which regime leads.

Two EU definitions of crypto-agility, and why the difference matters

In plain terms: ENISA and the Cooperation Group define crypto-agility differently. Copy the wrong one and you may call a downgrade risk an agility feature.

The ENISA Technical Implementation Guidance (footnote 86, p. 118) defines it as “the ability of a system to quickly and seamlessly switch between different cryptographic algorithms and protocols without significant changes to the system’s infrastructure”. Its example is X.509 certificates, which can carry different key types and hash algorithms.

The Cooperation Group roadmap (section 3.2) defines it as “the design of cryptographic protocols and systems in a modular way that enables replacing the cryptographic components”. It then adds a warning ENISA doesn’t give: agility “must not be confused with a requirement to negotiate the cipher suite during protocol execution; the latter often leads to downgrade attacks if not done very carefully.”

A server that accepts a long list of legacy and modern cipher suites “switches seamlessly” in ENISA’s loose sense, but that is the negotiation the roadmap warns about. The reading that satisfies both: agility is your ability to replace an algorithm through configuration or a contained code change, not your willingness to accept old ones at runtime. For a 9.2(b) policy, that means four statements an auditor can test:

• Cryptographic functions are called through a central service or library (a KMS, HSM, PKI or secrets manager), not hard-coded per application.
• Algorithm and key-length choices are configuration, with an owner and a change procedure.
• Protocol negotiation is restricted to the approved list from 9.2(b). Fallback to deprecated suites is disabled, not merely discouraged.
• Software and firmware update paths can be re-signed with a new signature scheme. The roadmap wants quantum-safe software and firmware upgrades “enabled by default” by the end of 2030.

Our HashiCorp Vault mapping to CIR Annex 9 shows how a transit or PKI engine turns an algorithm change into configuration rather than a rewrite.

The roadmap’s dates: what they are and who they bind

In plain terms: the end-2026 milestone is for governments. The 2030 and 2035 milestones are deployment targets by risk level, and they’re the dates to plan against.

Date	What happens	Addressed to
11 April 2024	Recommendation (EU) 2024/1101 asks for a coordinated roadmap within two years	Member States
13 August 2024	NIST publishes FIPS 203 (ML-KEM) among its first PQC standards	Market (US standard)
23 June 2025	NIS CG publishes the roadmap, Part 1 (version 1.1 dated 11 June 2025)	Member States; NIS2 entities “should refer” to it
15 April 2026	NIS CG publishes the roadmap FAQ	All organisations; NIS2 entities “at a minimum”
31 December 2026	First Steps done and initial national PQC roadmaps in place; planning and pilots for high- and medium-risk use cases started	Member States
11 December 2027	Cyber Resilience Act fully applies; the roadmap expects crypto-agility in new products from then	Product manufacturers
31 December 2030	High-risk use cases migrated; quantum-safe software and firmware upgrades on by default	Deployment target (non-binding)
31 December 2035	Medium-risk use cases migrated; low-risk “as much as feasible”	Deployment target (non-binding)

The April 2026 FAQ says the milestones “apply to the deployment of PQC”, so vendors have to be ready earlier. The 2035 date matches the US and UK: the roadmap cites NIST’s proposal to disallow traditional public-key mechanisms after 2035, though NIST IR 8547 is still an initial public draft. And the Commission’s PQC page says a second roadmap deliverable is in preparation, with no date set.

The urgency rests on forecasts. The roadmap cites a 2024 BSI study that a cryptographically relevant quantum computer is likely “in a maximum of 16 years (i.e. by 2040 or earlier)”, and an expert survey giving a 19% to 34% chance that RSA-2048 can be broken in 24 hours within the next decade.

Is your use case high-risk? A triage you can run this quarter

In plain terms: how long your data must stay secret and how long migration will take decide your deadline. AES isn’t your first problem; RSA and elliptic-curve key exchange and signatures are. The left columns restate the roadmap’s section 5 rules for systems protected today by public-key cryptography, plus the FAQ; the examples are our own reading, so test them against your data.

Condition	Quantum risk level	Roadmap target	Typical example (our reading)
Confidentiality must hold 10+ years, or past 2035, and a later break still causes significant damage	High	End of 2030	VPN or TLS links carrying health records, trade secrets or long-retention archives (exposed to “store now, decrypt later”)
Migration effort over 8 years and high impact if broken	High	End of 2030	Firmware and software signing, root PKI, embedded or OT devices with long lifetimes
Confidentiality needed, but for a short period	Medium or high	2030–2035	Customer portal sessions, internal email transport
Migration effort over 8 years, lower impact	Medium or high	2030–2035	Large legacy application estates with embedded RSA
Symmetric-only protection (e.g. AES)	Not prioritised	Monitor	Disk and database encryption at rest with AES keys

The FAQ says attacking AES “currently does not seem practical in the foreseeable future (even with 128 bit keys)”. For high-risk systems that can’t migrate by 2030, it suggests stop-gaps: a new PQC-capable PKI alongside the old one, or pre-shared symmetric keys in the short term.

On algorithms, the roadmap recommends “standardised and tested hybrid solutions, whenever feasible and suitable”, and the FAQ calls quantum key distribution “currently not considered a viable quantum-safe alternative”. The workstream won’t publish an algorithm list; it points to existing standards such as the ECCG Agreed Cryptographic Mechanisms version 2 and BSI TR-02102-1.

Feed the ratings into your main NIS2 risk assessment, not a separate spreadsheet. CIR point 9.1 ties the cryptography policy to the point 2.1 risk assessment, and the roadmap wants the quantum threat “discussed and evaluated at the board level”.

What to put in front of an auditor in 2026

In plain terms: nobody expects your estate to be quantum-safe today. An auditor can reasonably expect a policy that names the threat, an inventory that shows where it hits, and a review record that proves someone looked. The FAQ’s answer 7.4 is the closest thing to a to-do list addressed to you. “At a minimum, entities in scope of the NIS 2 Directive … should create an inventory of cryptographic assets and dependency maps, involve the supply chain, and perform a quantum risk analysis.” Answer 4.2 adds that you don’t need to finish the inventory before you start planning. Mapped to the binding text, the evidence pack looks like this:

Evidence	Anchors it to	Effort
Policy statement that names the quantum threat and commits to agility as a design principle (or documents why not)	CIR 9.1, 9.2(b), Art 2(2)	Low
Approved-algorithm list that records each public-key mechanism’s quantum status and the planned replacement (e.g. hybrid ML-KEM key exchange)	CIR 9.2(b)	Low
Cryptographic inventory: algorithms, keys, certificates and libraries per system (the roadmap recommends the CBOM format; see our 12-field cryptographic inventory guide)	CIR 9.2(a)–(c); roadmap First Steps	High
Quantum risk rating per use case, using the table above	CIR 2.1, 9.1	Medium
Dated 9.3 review minutes that cite the June 2025 roadmap, the April 2026 FAQ and the standards you track	CIR 9.3	Low
Supplier questions on PQC and agility roadmaps for products you depend on	CIR 5.1; roadmap “Include the supply chain”	Medium

ENISA’s 9.3 guidance suggests reviewing the policy “at least annually”, which is guidance but a defensible interval. The supplier row matters more than it looks: most of your migration will arrive as vendor updates, so the questions belong in your supplier due diligence now.

Role	What to do first
CISO / IT security	Start the inventory with external TLS, VPN and code-signing. Turn off cipher-suite fallback. Test hybrid key exchange in one pilot.
Compliance officer	Schedule the next 9.3 review, cite the roadmap and FAQ in it, and write an Art 2(2) note for any system where agility isn’t applied.
Board / management body	Approve quantum risk as an entry in the risk register. Under Article 20(1), the board approves and oversees Article 21 measures and can be held liable.
SME owner	Ask your hosting, VPN and software vendors one written question: “What is your post-quantum plan, and when will hybrid key exchange be on by default?” File the answers.

No PQC-specific penalty exists. A weak cryptography policy is a possible Article 21 infringement, for which Article 34 sets maximum fines of at least €10 million or 2% of worldwide turnover for essential entities and €7 million or 1.4% for important ones. For essential entities, Article 32(4) also lets supervisors issue warnings or order measures brought into line with Article 21 within a set period.

Frequently asked questions

Is there a NIS2 deadline for post-quantum cryptography?

No. Neither the Directive nor the CIR mentions quantum. The 2026, 2030 and 2035 dates come from the NIS Cooperation Group’s non-binding roadmap, and the end-2026 milestone is addressed to Member States. National roadmaps due by the end of 2026 may add expectations, so check what your authority publishes.

Will an auditor fail us for using RSA today?

Unlikely, on that basis alone. RSA is still in wide use and the roadmap’s own targets run to 2030 and 2035. The defensible gap is different: a cryptography policy with no inventory, no quantum risk rating and a 9.3 review that never mentions the threat.

Should we choose hybrid or pure post-quantum algorithms?

The FAQ notes BSI recommends hybrids and the UK NCSC treats them as an interim measure; there’s no EU guidance yet on whether hybrids are short- or long-term. Follow your national authority and record the choice, with a review date, in your 9.2(b) approved list.

We’re not on the CIR list. Do 9.2(b) and 9.3 matter to us?

Indirectly. Your binding test is Article 21 as transposed nationally, including “state-of-the-art”. The CIR points are the most detailed EU statement of what that looks like, and FAQ 7.4 addresses all NIS2 entities.

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex, Official Journal text. Articles 20(1), 21(1), 21(2)(h), 32(4) and 34(4)–(5).
2. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex, Official Journal text. Articles 1 and 2(2); Annex points 2.1, 5.1, 9.1–9.3 and 11.6.3.
3. Commission Recommendation (EU) 2024/1101 of 11 April 2024 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography — EUR-Lex.
4. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, Part 1, version 1.1 — NIS Cooperation Group, published 23 June 2025. Sections 2, 3.1, 3.2, 4, 5, 6.2 and 6.3.
5. EU Roadmap on PQC – Frequently Asked Questions — NIS Cooperation Group, 15 April 2026. Answers 2.1, 2.3, 2.4, 3.2, 3.4, 4.1, 4.2, 5.3, 5.6 and 7.4.
6. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 — ENISA, June 2025. Guidance and evidence under Annex points 9.2 and 9.3, footnotes 83 and 86.
7. Proposal for a Directive amending Directive (EU) 2022/2555, COM(2026) 13 — European Commission. New Article 7(2)(k).
8. Procedure file 2026/0012(COD) — European Parliament Legislative Observatory, consulted 13 October 2026.
9. Commission Delegated Regulation (EU) 2024/1774 (DORA RTS on the ICT risk management framework) — EUR-Lex. Recital 9 and Article 6.
10. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard — NIST, 13 August 2024.
11. NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards — NIST, 12 November 2024.
12. Post-Quantum Cryptography policy page — European Commission, last updated 3 September 2026.