NIS2, DORA, and the Evidence a Supervisor Will Ask For

Start with the file, not the algorithm

A supervisory information request rarely mentions quantum computing. It asks for your cryptography policy. It asks for the date the policy was last reviewed and the name of the person who reviewed it. It asks for the register of certificates supporting your critical functions, for the trigger that causes a cryptographic control to change, and for the last three exceptions you granted along with the reasoning behind each one.

Those questions are answerable from documents you already hold, or they aren’t. European post-quantum regulation is built around that fact. With one proposed exception, discussed below, the instruments do not tell most organisations to deploy a named algorithm by a named date. They oblige you to make cryptographic decision-making auditable, and then they publish a timeline that tells an auditor what “adequate” is expected to look like in 2030.

For a governance and compliance team, this changes what the quantum problem actually is. The scarce capability here is the ability to produce a defensible file rather than lattice mathematics: an inventory that is current, a risk tiering that survives challenge, contracts that bite, and a policy with an owner and a date on it. This article works from the artifact backwards, through the obligations that demand it, to the competence a team needs to hold up its end.

Where the obligation comes from

Three layers are in force or in flight, and they operate differently.

DORA, binding since 17 January 2025

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies to financial entities. It also establishes an EU oversight regime for ICT third-party providers designated as critical, and it requires financial entities to manage and contractually govern their ICT third-party risk. Its detail sits in Commission Delegated Regulation (EU) 2024/1774, a set of regulatory technical standards, or RTS, which is the binding secondary legislation that turns a regulation’s general duties into specific requirements.

Four requirements in that RTS matter for quantum risk, and none of them uses the phrase “post-quantum migration.”

Financial entities must set cryptographic controls against data classification and ICT risk assessment, rather than by habit. They must keep abreast of developments in cryptanalysis, and the text names threats from quantum advancements among the cryptographic threats to be accounted for. They must have provisions for updating or changing cryptographic technology when cryptanalysis develops, which is a standing obligation rather than a project. And where they cannot follow leading practices or standards, they must record the exception with its reasoning.

Alongside this sits an inventory duty. The RTS requires structured ICT asset records including interdependencies, and a record of all certificates and certificate-storing devices, at least for ICT assets supporting critical or important functions.

Read those together and DORA has already required most of the groundwork for a migration, in enforceable form, without naming it.

NIS2, which works by governance rather than by specification

Directive (EU) 2022/2555 covers essential and important entities across energy, transport, water, health, digital infrastructure, public administration and more. Member States were to transpose it by 17 October 2024, and because it is a directive rather than a regulation, national law and supervisory practice vary.

Article 21 requires risk-management measures that take into account the state of the art, and it lists among them “policies and procedures regarding the use of cryptography and, where appropriate, encryption.” Supply chain security and testing the effectiveness of measures sit in the same list.

Article 20 is the part that moves budgets. Management bodies must approve the risk-management measures, oversee their implementation, and can be held liable for infringements. The same article requires management bodies to follow training on cybersecurity risk. Article 34 sets administrative fine ceilings of EUR 10 million or 2% of worldwide annual turnover for essential entities, and EUR 7 million or 1.4% for important entities.

So NIS2 never has to say the word quantum. Once national authorities treat cryptanalytic advances as a material threat, and they have, the cryptography policy obligation, the state-of-the-art test, and personal accountability at board level do the work.

The dates on the public record

Recommendation (EU) 2024/1101 of 11 April 2024 asked Member States to begin the transition to post-quantum cryptography as swiftly as possible, endorsed hybrid deployment, and stated that the Commission would monitor progress and consider whether binding acts of Union law were needed.

In June 2025 the NIS Cooperation Group published a coordinated implementation roadmap with three milestones: Member States should start transitioning by the end of 2026, critical infrastructure and high-risk use cases should be transitioned by the end of 2030, and the transition should be complete for as many systems as practically feasible by the end of 2035. The roadmap also sets out a risk-tiering model, sorting use cases into high, medium and low quantum risk.

Two adjacent instruments set dates your suppliers will feel. The Cyber Resilience Act, Regulation (EU) 2024/2847, brings reporting obligations from 11 September 2026 and full application from 11 December 2027, covering products with digital elements placed on the EU market. Under eIDAS 2.0, Regulation (EU) 2024/1183, Member States are to make European Digital Identity Wallets available by the end of 2026, which puts a large public key infrastructure programme on a fixed clock.

The proposal now in front of the co-legislators

In January 2026 the Commission proposed amending NIS2 so that Member States would have to adopt national policies for the transition to post-quantum cryptography, taking account of the timelines set out in applicable Union acts and policies. The proposal has not been adopted, and transposition would follow adoption by a further period.

Its practical effect on a compliance function is narrow but real. Today, arguing that PQC readiness falls within NIS2 requires you to connect the cryptography policy duty to the state-of-the-art test to an external roadmap. That argument is defensible, and it is still an argument. If the amendment is adopted, a national policy duty replaces the argument, and the compliance question becomes which national instrument applies to you.

Read your certificate register the way a supervisor would

Here is an exercise worth running this quarter, whichever regime applies to you. Pull the certificate register for one critical service. Not the whole estate. One service.

For each certificate, check three columns are actually populated: the signature algorithm and key size, the expiry date, and a named human owner. Most registers fail on the third column, because ownership was recorded as a team that has since been reorganised.

Then ask four questions the columns don’t answer.

Which service breaks when this expires? A register without a dependency mapping tells you what you have and not what it holds up. DORA’s requirement for interdependencies in asset records exists for this reason.

Can the issuing authority produce a different algorithm? Public key infrastructure, or PKI, is the system of certificate authorities, certificates and validation rules that lets one machine trust another. If your internal certificate authority can only issue RSA and ECDSA certificates, the migration question is a vendor and platform question long before it’s a configuration question.

Will renewal automation survive larger signatures? The NIST standards published in August 2024 give three algorithms: ML-KEM (FIPS 203) for establishing keys, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. Their keys and signatures are substantially larger than what most certificate tooling was built around. Automation that silently truncates or times out is discovered during a renewal window, which is the worst possible moment.

How long does the data behind this certificate need to stay confidential? Call this the confidentiality horizon. It is the number of years the protected data would still cause harm if disclosed. The horizon drives priority because of harvest now, decrypt later, usually shortened to HNDL: an adversary records encrypted traffic today and stores it until a cryptographically relevant quantum computer can recover the key. Data with a two-year horizon is not urgent on this axis. Patient records, sealed legal files, long-lived credentials and industrial designs are.

When you generalise this exercise across the estate, you get what the field calls a cryptographic bill of materials, or CBOM: a register of where cryptography is used, in which protocol, with which key properties, supporting which service, protecting data with which horizon. The CBOM is the single artifact most audit answers depend on, and it is the one that takes longest to build. The methodology for constructing one is set out in detail at pqcframework.org.

Read one supplier contract for crypto agility

Second exercise, for the third-party risk function. Take the contract with the ICT provider you would find hardest to replace, and search it for the word “encryption.”

You will almost certainly find one clause committing the provider to industry-standard encryption in transit and at rest. That clause is unenforceable for our purposes, because it delegates the definition of “standard” to the party you are trying to hold to it.

Crypto agility is the property of a system that can change cryptographic algorithm without redesign: the algorithm is a configurable parameter, not an assumption baked into interfaces, key sizes and stored formats. A contract that supports agility says three things the boilerplate doesn’t.

It names the standards body whose output defines “standard,” so the term moves when NIST and ETSI move. It requires notice before the provider changes or deprecates an algorithm, with a stated period. And it requires the provider to publish a migration path for the cryptography it operates on your behalf, on a timeline you can align with the 2030 milestone.

DORA gives financial entities the mechanism to insist. It requires a register of information covering contractual arrangements with ICT providers, pre-contractual due diligence, minimum contractual provisions covering confidentiality, integrity, availability and authenticity, and demonstrable exit strategies. The oversight regime for critical ICT third-party providers adds pressure from above. Outside financial services, the same pressure arrives through NIS2’s supply chain obligations and through public procurement, where Member States are pushed to address encryption and certification requirements.

The Cyber Resilience Act works on the same problem from the manufacturer’s side. Long-lived products with digital elements will need secure-by-design lifecycles and vulnerability handling, and a device shipping in 2027 with a fixed, unupgradeable signature algorithm is a device that has to be replaced rather than patched. Procurement specifications written this year decide how much of that replacement cost lands on you.

One programme, two regulatory dialects

Financial entities inside a larger group face a boundary question. NIS2 treats DORA as a sector-specific act, so DORA’s ICT risk management and reporting regime applies to those entities in place of the corresponding NIS2 provisions, while coordination and information sharing between the regimes continues.

For a group with a bank and a telecoms or energy subsidiary, the practical answer is one programme producing one set of artifacts, described twice. The inventory, the risk tiering, the policy and the contract clauses are identical work. What changes is the vocabulary of the reporting pack and the supervisor it goes to. Building two programmes because two regulators exist doubles the cost and halves the consistency, which is the opposite of what either supervisor wants to see.

The competence gap behind the artifacts

Both regimes make training an obligation rather than an aspiration. NIS2 requires management bodies to follow cybersecurity risk training and encourages entities to offer comparable training to employees. DORA requires ICT security awareness programmes and digital operational resilience training as compulsory modules, explicitly including senior management.

Which means the training record is itself an audit artifact. The question is what it should contain.

Four competences carry the artifacts described above, and none of them requires a cryptographer.

Inventory and dependency mapping. Knowing where cryptography lives in code, appliances, firmware update chains, outsourced platforms and embedded devices, and how to keep that record current rather than accurate once. This produces the CBOM and the certificate register.

Risk tiering against a confidentiality horizon. Sorting use cases into high, medium and low quantum risk using data sensitivity, impact, and migration effort. This produces the prioritised roadmap that shows a supervisor your internal dates sit ahead of the EU dates for critical functions.

Enough algorithm and protocol literacy to review a design. What ML-KEM does and what it doesn’t. Why hybrid key establishment, which runs a classical exchange such as ECDHE alongside a post-quantum one and derives a key that stays secure if either component holds, is the default early pattern and the one Recommendation 2024/1101 endorses. Where a hardware security module, the tamper-resistant appliance that stores keys and performs cryptographic operations, becomes the constraint that sets your timeline. Enough to challenge a vendor claim, which is a different skill from making one.

Contractual and procurement drafting. Turning agility requirements into clauses with notice periods, evidence rights and exit tests.

We built Quantum Academy’s post-quantum training around this division of labour, because in most organisations the person who owns the audit answer is not the person who owns the TLS configuration, and the gap between them is where migration programmes stall. Learners who own evidence need to interrogate the technical work rather than perform it.

Name a review owner and a review date

One recommendation carries more weight per hour spent than anything else in this article.

Your cryptography policy should name a review owner by role, state the date of the last review, state the date of the next, and list the events that force a review outside that cycle. Reasonable triggers include a new NIST standard or deprecation notice, a published cryptanalytic result affecting an algorithm you deploy, a change in a critical provider’s cryptographic posture, and a change in the EU roadmap or its transposition into national law.

That single page answers the recurring supervisory question directly. It converts the RTS obligation to update cryptographic technology from a claim into a documented process. And it costs an afternoon.

The next ninety days

Six items, in order, none of which requires a budget approval to start:

1. Confirm which regime applies to each legal entity in the group, including where DORA displaces NIS2.
2. Add the review owner, review date and trigger list to the cryptography policy.
3. Complete the certificate register for one critical service end to end, and use what breaks to scope the rest.
4. Tier your top twenty use cases by confidentiality horizon and migration effort.
5. Read the three hardest-to-replace supplier contracts for crypto agility, and draft the clause you want at renewal.
6. Put a quantum risk briefing in front of the management body, with the 2026, 2030 and 2035 dates and your position against them, and minute it.

Items two, five and six produce audit evidence within the quarter. Items three and four are the long work, and the reason the roadmap put the first milestone at the end of 2026 rather than at 2030.

Building the capability

The EU has asked most organisations to be able to show their reasoning rather than to finish a migration, on a timeline that starts now and tightens in 2030, with named accountability at board level and fines attached to systemic failure.

Teams that can produce that reasoning tend to have one thing in common: someone in the compliance function understands the cryptography well enough to ask the second question. Quantum Academy’s post-quantum programs are built for that person, with the credential aimed at governance, risk and compliance practitioners rather than at engineers. You can see the current programs, the assessment format and the access windows at quantumacademy.com/.

For the underlying migration methodology, pqcframework.org sets out the inventory and prioritisation approach in full. For deeper technical background on the regulatory instruments discussed here, see the extended analysis at PostQuantum.com.