NIS2 · Article 21(2)(e)

NIS2 Article 21(2)(e): maintenance and vulnerability handling

Measure (e) asks you to buy, build and maintain your systems securely, and to have a way of dealing with vulnerabilities when they turn up. You can only deal with what you know about. Some weaknesses are visible on your domain to anyone who looks, and our free check will show you those.

Find what needs fixing

Written by the SkyQon engineering team · Last checked against the legal texts on 2 October 2026

The legal text

Article 21(2)(e) of Directive (EU) 2022/2555 asks for security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure. Article 12 sets up coordinated vulnerability disclosure across the EU: national CSIRTs act as go-betweens, and ENISA runs a European vulnerability database.

For the digital providers it covers, Implementing Regulation (EU) 2024/2690 adds detail in its annex, including procedures for handling and disclosing vulnerabilities and for fixing them in good time.

Official text: Directive (EU) 2022/2555 · Implementing Regulation (EU) 2024/2690

What our check finds

These are the weaknesses on your public side that our free check picks up:

Certificates that are expired, about to expire or self-signed, and certificates missing the names modern browsers insist on.
Weak certificate algorithms or keys worth replacing at the next renewal.
Missing revocation information, which leaves visitors unable to find out that a certificate was withdrawn.
Email and DNS settings that let attackers in more easily, for example a DMARC policy set to none, an SPF record that allows too much, or mail servers without STARTTLS.

A typical case

The check finds two things. The main certificate expires in nine days, and it has always been renewed by hand by a colleague who has since moved to another job. The DMARC policy was set to none "for testing" three years ago and never changed. Neither is a crisis today. Both are exactly what measure (e) means: a weakness someone should own and close, with a date on it.

This is a composite of things we often see, not a specific customer.

Where the check stops

Our check finds problems; it doesn't fix them, and it isn't a vulnerability scan of your applications. We can't see software versions, patches or anything on your internal network. A single check is also just one moment, while measure (e) is really about what happens afterwards and how quickly. Only a record kept over time can show that. One more gap: we don't test whether outsiders have a way to report a vulnerability to you. Publishing a security.txt file (RFC 9116) is a common way to give them one.

What you'll be asked to show

Auditors ask for vulnerability-handling records: what was found, when, and how long it took to fix. ENISA's June 2025 guidance gives the time from detection to resolution for expiring, weak or self-signed certificates as an example.

Putting dates on the fixes

The Digital Trust Center notes each problem on the day it shows up and again on the day it disappears. The NIS2 Evidence Pack turns that into a signed list of exceptions with the time each one took to fix. Our NIS2 mapping counts it as supporting evidence for 21(2)(e).

NIS2 Evidence Pack pricing · Open a sample signed report (PDF) · Check a report's signature yourself

Find out what needs fixing on your domain

It takes your domain name and nothing else. No account, no sign-up.

Find what needs fixing →

The other measures

Article 21(2) has ten measures in total. Most of them are about how you work inside the company, and we can't see those from outside. Our longer guide goes through all ten and says which ones leave something visible.

We explain the law here as plainly as we can, but this is not legal advice. NIS2 reaches you through your own country's law, and the details differ from one country to the next.