The NIS2 Directive changes SSL certificate management from an IT housekeeping task into a documented, auditable obligation that management answers for. If your organization runs energy, transport, healthcare, digital infrastructure, managed services, manufacturing, or any other sector listed in Annex I or II, NIS2 SSL certificate management now sits inside a legal framework with real fines. This article covers what the directive actually requires, where certificates fit in, and how to build a process that will hold up in an audit.
What NIS2 Actually Says About Cryptography
Directive (EU) 2022/2555 entered into force on 16 January 2023, and member states had until 17 October 2024 to transpose it into national law. Many missed that deadline. In late 2024 the European Commission opened infringement procedures against most member states. Most of them have since passed national laws, so audits now happen under real legislation.
The key text is Article 21. It lists minimum cybersecurity risk-management measures, and point (h) requires policies and procedures regarding the use of cryptography and, where appropriate, encryption. TLS certificates are the most visible part of that cryptography. They also break more often than any other part.
Three other Article 21 points apply to certificates indirectly. Business continuity (point c) covers outages caused by expired certificates. Supply chain security (point d) covers certificates managed by your CDN, SaaS vendors, and hosting providers. Asset management (point i) assumes you know which certificates you have.
For digital infrastructure providers – DNS, cloud, data centres, CDNs, managed service providers – Commission Implementing Regulation (EU) 2024/2690 adds more detailed technical requirements. Its annex has a dedicated section on cryptography and key management. If you are a managed service provider, the general wording no longer applies to you. Auditors will expect specific controls.
Myth: NIS2 Requires a Specific SSL Monitoring Tool
It doesn’t. NIS2 is technology-neutral and risk-based. Nothing in the directive says “monitor certificate expiry daily” or “maintain an A+ SSL grade”.
What it does require is that you can show your measures are appropriate to the risk. An auditor from a national authority – Traficom in Finland or BSI in Germany, for example – will ask how you know a certificate won’t expire unnoticed. “Our admin keeps a spreadsheet” is technically an answer. It won’t survive the follow-up questions.
A second misconception is that small organizations are exempt. The size-cap rule usually puts organizations in scope at 50 employees or €10 million in annual turnover. Some entities are in scope regardless of size, including DNS service providers, TLD registries, and trust service providers. A four-person company running authoritative DNS for clients is in scope.
When an Expired Certificate Becomes a Reportable Incident
Article 23 sets the reporting timeline. A significant incident requires an early warning within 24 hours, a full incident notification within 72 hours, and a final report within one month.
Here is a scenario many operations teams will recognize. A mid-sized logistics company classed as an important entity has a customer tracking portal behind an F5 load balancer. Certbot handles renewal on the origin servers, but the certificate on the load balancer was uploaded manually 13 months ago. It expires at 02:00 on a Saturday. The renewal reminder went to a former employee’s mailbox. Customers and partner APIs get handshake failures for nine hours until someone checks the on-call channel.
Is that reportable? Under Article 23(3), an incident is significant if it causes severe operational disruption or financial loss, or considerable damage to others. Nine hours of failed partner integrations could easily meet that threshold. Now the team also has a 24-hour clock running, legal is involved, and the post-incident review will ask why no control caught the expiry 30 days earlier.
An experienced SRE treats certificate expiry as an incident class in the runbook, with a decision tree for reportability already written. For more on that, see how SSL monitoring fits into incident response planning.
Building NIS2 SSL Certificate Management Step by Step
A seasoned security lead starts with inventory, not tooling. You can’t show control over certificates you haven’t found. Certificate Transparency logs (crt.sh, or Censys) often show 20-40% more certificates than internal records list, including ones issued by marketing agencies and forgotten staging systems.
The minimum workable sequence looks like this:
1. Discover every public and internal certificate using CT logs, network scans, and cloud provider APIs (AWS ACM, Azure Key Vault, GCP Certificate Manager).
2. Assign a named owner and a backup owner to each certificate – a person or team alias, never an individual mailbox.
3. Write a cryptography policy covering minimum TLS version (1.2, preferably 1.3), approved key types (RSA 2048+ or ECDSA P-256), allowed CAs, and CAA records.
4. Set up continuous external monitoring with staged expiry alerts and checks for chain correctness, OCSP, HSTS, and unexpected issuance in CT logs.
5. Produce monthly evidence – reports, grades, remediation tickets – and keep them for audits.
A structured approach to the first step is covered in building an SSL certificate inventory. If you already hold ISO 27001 certification, much of this maps directly onto Annex A controls 8.24 and 5.9. The ISO 27001 certificate controls can serve as your NIS2 evidence base.
Certificate validity is also getting shorter. CA/Browser Forum ballot SC-081 cut maximum public TLS certificate validity to 200 days from March 2026. It drops to 100 days in March 2027 and 47 days in March 2029. Manual processes that barely worked with 398-day certificates will fail on these timelines, and NIS2 auditors will see that.
Common Mistakes in NIS2 Certificate Compliance
The most common mistake is documenting policy without verifying reality. Teams write “TLS 1.0 and 1.1 are disabled” in the cryptography policy, while a legacy VPN appliance or an IIS server still negotiates TLS 1.0. Policy-to-reality drift is exactly what an auditor’s external scan finds in about five minutes.
The second mistake is trusting automation without monitoring it. ACME clients fail silently more often than people expect. A DNS-01 challenge breaks after a DNS provider migration, a cron job stops after an OS upgrade, or rate limits are hit during a bulk reissue. Automation reduces risk. It doesn’t prove anything to an auditor unless something outside it checks the result.
The third mistake is ignoring supply chain certificates. Your payment provider’s checkout subdomain, your Cloudflare edge certificate, the Zendesk help center on your domain – an outage on any of them is your outage. Article 21(2)(d) means you need visibility into them even when you don’t control them.
Exceptions and Edge Cases
Air-gapped OT environments in energy and water utilities often run internal PKIs with 5-10 year device certificates. External monitoring can’t reach these systems. NIS2 still applies, so the controls have to be internal: PKI audit logs, scheduled certificate scans from inside the segment, and documented compensating measures.
Public administration entities are covered differently in each member state, and some states exclude local government entirely. Organizations operating in several EU countries face multiple national authorities with different reporting portals. Generally, the member state where you have your main establishment has jurisdiction, but check this per sector.
FAQ
Does NIS2 apply to companies outside the EU?
Yes, if they provide covered services in the EU. Some digital providers, such as DNS, cloud, and managed service providers, must designate a representative in a member state.
Is an expired SSL certificate automatically a reportable NIS2 incident?
No. It’s reportable only if it meets the significance threshold – severe operational disruption, financial loss, or considerable damage to others. A lapsed certificate on an internal wiki rarely qualifies. On a customer-facing portal or partner API, it may.
What fines apply for weak certificate management?
Essential entities face fines of up to €10 million or 2% of global annual turnover, and important entities up to €7 million or 1.4%. Under Article 20, members of the management body can also be held personally accountable.
Making Certificate Controls Audit-Ready
NIS2 doesn’t introduce new certificate technology. It makes the gaps in your current process visible, puts them on a reporting clock, and assigns them to named executives. Organizations that pass audits without trouble have three things in place: a complete inventory, continuous external verification, and monthly evidence that someone reviewed the results.
A practical first step is to search crt.sh for your primary domain this week and compare the results with your internal records. Every certificate you didn’t know about is a gap an auditor would find.