NIS2 and Certificates: What the Directive Actually Requires of Your Encryption

What does NIS2 require about encryption and certificates?

NIS2 requires that you have policies and procedures for cryptography, and it stops there. Article 21(2) of Directive (EU) 2022/2555 lists ten risk-management measures that essential and important entities must take; point (h) is the cryptography one, and its wording is policies and procedures regarding the use of cryptography and, where appropriate, encryption. No algorithm, key size, protocol version or certificate type appears anywhere in it.

That style is deliberate. The same article also asks for multi-factor authentication and secured voice, video and text communications under point (j), again without naming a product or a standard. The directive sets outcomes and leaves the technical choices to you, which is generous until somebody asks you to justify them.

One passage does point at the certificate world directly, and it is rarely quoted. Article 24(1) lets Member States require the use of ICT products certified under a European cybersecurity certification scheme, and in the same breath says Member States shall encourage essential and important entities to use qualified trust services. Qualified trust services are the eIDAS category — qualified signatures, seals, timestamps and website authentication certificates — so the only nudge NIS2 makes toward a specific kind of certificate is toward the qualified ones, not toward a validation level for your web server.

The consequences are not gentle. Under Article 34, an essential entity that infringes Article 21 or Article 23 faces maximum administrative fines of at least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher; for important entities the figures are EUR 7 million and 1.4%. Those are ceilings national law must make available rather than prices for a specific mistake, and in practice the first thing you meet is a supervisory finding with a remediation deadline attached.

Which rulebook actually binds you?

Your national transposition law binds you, not the directive itself. NIS2 is a directive, so it takes legal effect through the law each Member State adopts, and those laws differ in scope, registration duties and supervision. Commission Implementing Regulation (EU) 2024/2690 is directly applicable across the Union, but it covers only a named set of sectors. Everything else is guidance.

The implementing regulation, adopted on 17 October 2024 and in force since 7 November 2024, applies to DNS service providers, TLD name registries, cloud computing providers, data centre providers, content delivery networks, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking platforms, and trust service providers. Its Annex carries thirteen sections of technical and methodological requirements built on European and international standards, including ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319 401.

If your sector is not on that list, the regulation is still the most useful document available to you, because it is the Commission's own statement of what adequate looks like. An assessor working from a national law with one sentence about cryptography has to benchmark you against something, and this is what exists.

Transposition is still uneven. Germany's implementing act took effect in December 2025. As of 19 August 2026, Ireland, Spain and France had no adopted NIS2 law, and Austria had adopted one that was not yet in force; on 8 July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice over incomplete transposition, asking for financial sanctions. A delayed national law does not postpone the work, since the measures arrive with the law whenever it lands, and evidence of control cannot be produced retroactively.

Who is in scope, and does being small help?

NIS2 generally applies to entities in its listed sectors that reach medium size, meaning at least 50 staff or more than EUR 10 million in annual turnover or balance sheet total. Below that you are usually out of scope, with exceptions that matter in this field: qualified trust service providers, TLD name registries and DNS service providers are covered regardless of size. A two-person qualified CA carries the same obligations as a large one.

Sectors in Annex I are essential entities and face supervision that does not wait for an incident; Annex II entities are important and are supervised reactively. The distinction changes how you are inspected and what the fines top out at, not what Article 21 asks of your cryptography.

Size stops being a defence the moment a customer is in scope. One of the ten measures covers supply-chain security, including the security of relationships with direct suppliers, so in-scope organizations push the requirement down their vendor chain through contracts and questionnaires. That is why a small SaaS vendor with twelve employees is answering questions about its TLS configuration and its certificate renewal process, even though no national law applies to it.

What belongs in a cryptography policy?

The Annex to Regulation 2024/2690 states the goal rather than the content: relevant entities shall establish, implement and apply a policy and procedures related to cryptography, with a view to ensuring adequate and effective use of cryptography to protect the confidentiality, authenticity and integrity of data in line with the entity's asset classification. Read that carefully and it tells you the shape of the document. Protection has to be proportionate to classification, which means the policy has to reference an asset inventory, and the Annex separately requires one of those.

A policy that survives an assessment covers six things:

• Approved algorithms and minimum key sizes, with the version of the standard or recommendation you took them from and the date you took it.
• Where each applies — data in transit on public networks, internal service-to-service traffic, data at rest, backups, email.
• Key management, covering generation, storage, distribution, rotation and destruction, and naming what holds the keys.
• Certificate issuance and renewal, including who is allowed to request one, from which CA, and who is accountable for renewing it.
• A TLS configuration baseline — protocol versions and cipher suites permitted, and how exceptions are recorded.
• A review trigger and cadence, so the algorithm choices get revisited on a schedule rather than after a headline.

Two practical notes. First, the regulation does not tell you to run TLS 1.3 or to prefer ECDSA over RSA; those remain your decisions, and the defensible version of any such choice is one with a dated source behind it. Second, if you already hold ISO/IEC 27001, the ENISA guidance published on 26 June 2025 ships with a mapping table to ISO 27001:2022, NIST CSF 2.0 and ETSI EN 319 401, which is the shortest honest route from controls you have to evidence an assessor recognises. Our guide to managing certificates at scale covers the operational half of the same ground.

Crypto-agility deserves a line of its own in the policy. The ability to change an algorithm without re-architecting a system is what makes the next migration survivable, and the post-quantum transition is already visible in vendor roadmaps. If you want the current state of that, we keep a plain-language summary of post-quantum cryptography up to date.

Can an expired certificate be a reportable NIS2 incident?

Yes, and this is the part of NIS2 that certificate owners tend to miss. Article 23(3) makes an incident significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected other persons by causing considerable material or non-material damage. Either limb is enough on its own. Neither mentions a cause, an attacker or malice.

So an expired certificate on a customer-facing service is not automatically a reportable incident, but it can become one on exactly the same test as an intrusion. If the outage is severe, the clock in Article 23 starts: an early warning to the CSIRT or competent authority within 24 hours, a fuller incident notification within 72 hours, and a final report within one month. The phrase capable of causing matters too, because containing the disruption before it fully lands does not obviously take you out of scope.

Now put that next to what happened to certificate lifetimes. Since 15 March 2026 a publicly trusted TLS certificate can be issued for at most 200 days, and CA/Browser Forum Ballot SC-081v3 takes the ceiling to 100 days on 15 March 2027 and 47 days on 15 March 2029. Renewal frequency roughly doubles next spring and roughly quadruples three years later. A spreadsheet and a calendar reminder were thin evidence of control at 398-day lifetimes; at 100 days they are not evidence at all. We wrote about the failure mode in detail in why certificate expiry still causes outages, and about the schedule itself in the 2026 lifetime changes.

What can you actually show an auditor?

A policy document on its own proves nothing, and assessors know it. What gets inspected is the trail the policy leaves behind: an inventory, a named owner per certificate, monitoring that would have caught the last near-miss, a renewal procedure somebody has followed recently, and a dated review of the algorithms in use. Five artefacts, none of them named in the directive.

The inventory is where most organizations discover their real problem. Certificates accumulate outside the process that is supposed to own them: a load balancer with a certificate the network team installed, an internal API behind a self-signed pair that predates the current architecture, a partner integration pinned to a certificate nobody remembers requesting. None of those appears in a purchasing record, so an inventory built from invoices is fiction. Build it from what the hosts are serving.

Monitoring earns its place in the file for a reason that is easy to state: it is the only one of the five artefacts that produces evidence continuously without anybody being asked. Alert history showing a certificate flagged at 30 days and renewed at 21 is worth more in an assessment than a policy paragraph promising it will happen. If you need a starting point, our notes on monitoring certificates before they expire cover what to watch and at what thresholds.

Does NIS2 require OV or EV certificates?

No. There is no validation level in NIS2, and a domain-validated certificate satisfies Article 21(2)(h) exactly as well as an extended-validation one. Anyone telling you the directive mandates organization validation is selling something. The encryption is identical; what differs is how much was checked about the organization before the certificate was issued.

Validation level becomes a real question in two narrower places. One is where your own risk assessment concludes that the organization behind a hostname should be verifiable from the certificate itself, which is common for banking, payment and regulated portals, and which is a decision you write down and defend rather than one the directive makes. The other is the Article 24(1) encouragement toward qualified trust services, which points at eIDAS qualified certificates for signatures, seals and timestamps rather than at your TLS endpoint. If you are weighing the first of those, the practical differences are laid out in our comparison of OV and EV validation, and the OV SSL certificates we issue put a vetted organization name in the certificate subject for that purpose.

The choice that matters more for NIS2 is not DV against EV. It is whether the certificate can be renewed by a process rather than by a person remembering. A certificate type you can automate beats a more thoroughly validated one you renew by hand, because the failure the directive can actually punish is the outage, not the validation level.

Your certificate authority is in scope too

Trust service providers sit inside NIS2's digital infrastructure sector and inside the scope of Regulation 2024/2690, which means the CA you buy from is a regulated entity under the same directive you are working through. Qualified trust service providers are covered regardless of size, and they are supervised as essential entities. For once, the supply-chain measure cuts in your favour: your CA has its own obligations, its own incident reporting duty and its own auditors.

That gives procurement two questions worth asking, both answerable from public records. Is the provider on an EU trusted list as a qualified trust service provider, and under which trust services? And can it produce its audit status without a sales call? Certum, the Polish CA whose certificates My-SSL resells, is listed as a qualified trust service provider on the Polish trusted list maintained by the national certification centre, which is the kind of statement you can verify yourself rather than take on trust.

One caveat worth keeping straight: qualified status applies to specific trust services, typically electronic signatures, seals and timestamps, and does not transfer to every product a CA sells. A publicly trusted TLS certificate is not a qualified certificate merely because the same organization issues both.

A certificate readiness checklist for NIS2

Nine things, in the order that makes each one cheaper than the last:

1. Confirm whether your national transposition law is in force and whether you are registered under it, since registration duties and deadlines differ by Member State.
2. Decide whether Regulation 2024/2690 binds you directly or serves as your benchmark, and note which in the policy.
3. Build the certificate inventory from what hosts are actually serving, not from purchase records.
4. Put a named owner against every certificate, with a team as the fallback rather than an individual who can leave.
5. Write the cryptography policy against the six headings above and date every standard you cite.
6. Set monitoring thresholds that leave room to act, and keep the alert history — it is your best evidence.
7. Re-plan renewal against 100-day lifetimes arriving on 15 March 2027, not against the interval you run today.
8. Add certificate expiry to your incident-response runbook, so someone knows on day one whether the Article 23 clock has started.
9. Record a crypto-agility position, including how you would change algorithm or key size across the estate and roughly how long it would take.

Compliance work on certificates has a pleasant property: almost all of it is work you wanted done anyway. The inventory prevents outages. The owner prevents the argument during one. The monitoring pays for itself the first time it fires.

FAQ