NIS2 and DORA: What 'State-of-the-Art Cryptography' Actually Requires
NIS2 and DORA never name post-quantum algorithms — but their 'state-of-the-art' and risk-based language increasingly implies a PQC plan. Here's how to read them.
If you've gone looking for the words "post-quantum" or "ML-KEM" in NIS2 or DORA, you won't find them. Neither regulation names a specific algorithm. Yet both are increasingly understood to require a post-quantum plan. This article explains how that works — the difference between prescriptive and risk-based regulation, and what "state-of-the-art cryptography" actually obliges you to do.
For the full migration picture, start with our Post-Quantum Cryptography Migration Guide.
Two ways a regulation can demand cryptography
There are two styles of cryptographic regulation. Prescriptive rules name the algorithms and the dates — CNSA 2.0 is the clearest example, mandating ML-KEM-1024 by specific milestones. Risk-based rules instead require you to use cryptography appropriate to the threat, and leave the specifics to you and the evolving consensus on what "good" looks like.
NIS2 and DORA are firmly in the second camp. That doesn't make them weaker — it makes them moving targets. As the industry consensus shifts toward post-quantum, the bar that "state-of-the-art" sets rises with it.
NIS2: "state-of-the-art" in Article 21
The NIS2 Directive (EU 2022/2555) applies to essential and important entities across critical sectors — energy, transport, health, digital infrastructure, and more. Its Article 21 requires these entities to take appropriate technical measures, explicitly including the use of state-of-the-art cryptography where appropriate.
The operative phrase is "state-of-the-art." It is deliberately not pinned to a fixed algorithm list, because the state of the art evolves. With NIST's post-quantum standards finalised and the EU's own coordinated roadmap published, the reasonable reading of "state-of-the-art" is shifting to include having a credible post-quantum transition plan — especially for long-lived data and critical infrastructure. NIS2 also carries real teeth: penalties can reach up to €10 million or 2% of global annual turnover.
DORA: ICT risk management in Article 9
DORA (EU 2022/2554), in force since January 2025, governs the financial sector. Its Article 9 requires firms to implement strong ICT risk management, including cryptographic controls appropriate to the risk. Financial data has a long confidentiality lifetime — transaction records, contracts, customer information — which makes it precisely the kind of data exposed by "harvest now, decrypt later."
Like NIS2, DORA doesn't name PQC. But a financial institution doing genuine ICT risk management in 2026, with the quantum threat well documented and the standards available, would struggle to argue that the risk of long-term decryption is outside scope. The financial sector's own bodies have published post-quantum agility playbooks for exactly this reason.
Why "they don't name PQC" is not a reason to wait
The trap is reading "the regulation doesn't mention post-quantum" as "I don't have to do anything yet." That gets the logic backwards. Risk-based regulation transfers the judgment to you: you have to assess the threat and apply appropriate controls. The quantum threat is documented, the algorithms are standardised, and the migration takes years. An auditor or regulator looking back will ask whether you took reasonable steps given what was knowable — and "we waited because the rule didn't spell it out" is not a strong answer.
This is reinforced by the surrounding EU framework. The Cyber Resilience Act pushes secure-by-design with upgradable cryptography. eIDAS2 requires trust services to use cryptography reflecting current best practice. The EU Coordinated PQC Roadmap asks for national roadmaps by end-2026 and high-risk migration by 2030. NIS2 and DORA don't sit in isolation — they're part of a regulatory environment that is collectively moving toward post-quantum.
What a defensible position looks like
You don't need to have finished migrating to be defensible. You need to show you've engaged with the risk:
- A cryptographic inventory — you know where you use cryptography and what algorithms.
- A risk classification — you've identified which data is long-lived and exposed.
- A roadmap — you have a plan with timelines, even if execution is multi-year.
- Hybrid key exchange deployed on your most exposed endpoints, the low-risk first step.
That combination — inventory, classification, roadmap, and a started migration — is what turns "state-of-the-art" from a vague phrase into a position you can document and defend.
For the US counterpart and how it compares, see CNSA 2.0 Deadlines Explained.
Start with visibility
The inventory and risk classification both start with knowing what your systems actually use. PQScore gives you a per-domain readout of your TLS, certificate, DNS and email posture, mapped against the frameworks that apply to you — the evidence base for a defensible NIS2 or DORA position.