What NIS2 Article 21 Actually Says
The NIS2 Directive (EU 2022/2555) came into force across EU member states in October 2024. Article 21 sets out the cybersecurity risk-management measures that essential and important entities must implement. It's a fairly broad list — network security, access control, incident handling, cryptography, supply chain — but the one that often gets overlooked in OT conversations is Article 21(2)(e): "vulnerability handling and disclosure."
The text requires entities to have processes for identifying, assessing, and addressing vulnerabilities in their network and information systems. It also requires policies for coordinated vulnerability disclosure. This isn't just about patching quickly — it's about being able to demonstrate that you have a systematic approach to managing vulnerabilities across your environment.
For OT environments, that's easier said than done.
One quick clarification before going further: NIS2 is an EU directive. The UK has its own NIS Regulations (2018, with updates under the Product Security and Telecommunications Infrastructure Act), which differ from NIS2 in scope and enforcement. If you're UK-only, you're not subject to NIS2 — though many of the principles are similar and worth following regardless.
Who Counts as an Essential Entity in Industrial Sectors
NIS2 defines essential entities across a range of sectors, including energy, transport, water, and digital infrastructure. Manufacturing of critical products (chemicals, medical devices, certain food production) falls under the "important entities" category, which has slightly lighter obligations but still requires Article 21 compliance.
If you operate in the EU and your organisation meets the size thresholds (150+ employees or €10M+ annual turnover, broadly), you're likely in scope. Sector regulators in each member state are responsible for enforcement, and approaches vary — some are further ahead than others.
The key point for OT operators is that NIS2 doesn't distinguish cleanly between IT and OT systems. If your ICS, SCADA, or plant network is part of the system that delivers your essential service, it falls within scope of the obligation.
What Vulnerability Handling Actually Means in an OT Context
In IT environments, vulnerability management usually means running a scanner, triaging the output by CVSS score, and pushing patches through a change process. That model doesn't translate well to OT. You often can't run scanners against live plant without affecting availability. Patches require vendor qualification. Maintenance windows are infrequent. Rebooting a controller to apply a firmware update is not a trivial decision.
Article 21 doesn't specify how you manage vulnerabilities — it requires that you have a process. For OT environments, that process realistically includes:
- Maintaining an inventory of your automation components and knowing which vendor products you're running
- Monitoring for advisories from CISA, ICS-CERT, and relevant vendors (Siemens, Schneider Electric, Rockwell Automation, etc.)
- Assessing whether disclosed vulnerabilities affect your specific versions and configurations
- Documenting your risk acceptance decisions where you can't patch immediately — with a rationale and a compensating control
- Tracking remediation or mitigation over time
The documentation part matters more than most people realise. Regulators aren't necessarily expecting you to patch everything immediately — they're expecting you to demonstrate that you know what's out there and that you're making informed decisions about it.
What Evidence You Need for Regulators
NIS2 enforcement is still developing, and national competent authorities will vary in what they ask for. That said, the kind of evidence that's going to be relevant includes:
- Records showing you receive and review vulnerability disclosures for your systems
- An asset register or similar that maps advisories to actual equipment in use
- Documented risk assessments for high-severity findings — particularly anything in the CISA Known Exploited Vulnerabilities (KEV) catalogue
- Evidence of remediation or compensating controls, with dates
- A vulnerability disclosure policy (for the coordinated disclosure aspect of 21(2)(e))
The ENISA guidelines on NIS2 implementation give more detail on expected practices, and it's worth reading the guidance your sector regulator publishes if they've issued any.
Where Monitoring Tools Fit
Staying on top of ICS vendor advisories is genuinely difficult to do manually. CISA publishes advisories daily. Vendors like Siemens publish monthly patch days. BSI publishes advisories in German. The volume is manageable with the right tooling, but not with a weekly manual search.
OTWarden monitors CISA ICS advisories, CISA's KEV catalogue, and vendor feeds (Siemens, Rockwell, Schneider, BSI, NVD), and sends email alerts when something matches your watchlist — filtered by vendor, product, or sector. It also tracks EPSS scores and compliance deadlines, which are useful for prioritising what to look at first and for building a paper trail.
That said, OTWarden is a monitoring and evidence-collection tool, not a complete NIS2 solution. Article 21 compliance involves incident response planning, access control, supply chain risk, and a lot more than vulnerability alerts. We don't do any of that. What we do is make sure you're not missing advisories relevant to your kit, and give you a structured way to track your response to them.
What to Do Next
If you're working through NIS2 Article 21 obligations and want to understand specifically what OTWarden covers and doesn't cover, there's more detail at otwarden.com/compliance.
If your organisation is still at the stage of figuring out what ICS advisories are even relevant to you, that's a reasonable place to start — knowing what's being disclosed about your vendors' products is the foundation everything else builds on.