The EU NIS2 Directive: What Manufacturers Actually Need to Do for OT Security

The EU's NIS2 Directive (Directive (EU) 2022/2555) had its national transposition deadline on 17 October 2024 - over two years ago now. Yet a large share of mid-sized manufacturers still treat it as background noise rather than a law that applies to them directly. That gap matters, because NIS2 sorts manufacturers of "key products" - machinery, electrical equipment, motor vehicles, computer and electronic products, chemicals, and food, among others - into Annex II as important entities, and a medium or large manufacturer in one of those categories is in scope by default, size test alone, no sector-specific designation required.

If your plant has 50 or more employees, or turnover and a balance sheet total above the SME threshold in EU Recommendation 2003/361/EC, and you make something in Annex II's list, you're very likely covered. This post sets out what that actually means in practice: the incident-reporting clock, the baseline security measures Article 21 requires, how it overlaps with the EU Cyber Resilience Act and IEC 62443, and what to check before a supervisory authority asks.

Who's Actually In Scope

NIS2 splits covered organisations into two tiers:

• Essential entities - critical infrastructure sectors: energy, transport, banking, health, water, and digital infrastructure. These face proactive supervision - a regulator can inspect you before anything goes wrong.
• Important entities - a second list in Annex II, including postal services, waste management, chemicals, and manufacturing of key products (motor vehicles, machinery, electrical equipment, computer/electronic/optical products, and others). These face reactive supervision - an authority typically acts after an incident or a complaint, not on a routine audit cycle.

The size test follows the EU's standard SME definition: medium-sized (50-249 staff, €10-50 million turnover) and large organisations in an Annex II sector are in scope as important entities; small ones generally aren't, unless a member state designates them anyway (a sole supplier to a critical sector, for example, or an entity with cross-border significance). Worth checking directly against your national transposition law, since member states can and do set stricter thresholds for specific sub-sectors.

The practical trap: a plant manager who has never heard of NIS2 assumes "critical infrastructure" rules don't apply to a parts supplier. If that supplier makes machinery, electrical equipment, or automotive components and clears the size threshold, the directive already applies - whether or not a regulator has ever mentioned it by name.

The Incident-Reporting Clock

Article 23 sets a staged reporting timeline once an in-scope entity becomes aware of a "significant incident" - one causing, or capable of causing, severe operational disruption, financial loss, or considerable damage to others:

1. 24 hours - an early warning to the national CSIRT or competent authority, including whether the incident is suspected to be caused by unlawful or malicious action.
2. 72 hours - a full incident notification, updating the initial assessment, severity, and impact.
3. One month after the 72-hour notification - a final report detailing the incident, root cause, mitigation applied, and any cross-border impact.

Authorities can also request an intermediate status report for an incident that's still unfolding. None of this is optional paperwork filed after the fact - it's a live operational process your incident response plan needs to own, with a named decision-maker who can hit a 24-hour deadline outside office hours. For a factory floor, that means your OT incident response plan and your IT security team's existing process need to be the same plan, not two separate ones that quietly assume the other side will handle it.

Article 21: The Baseline Measures You're Actually Required to Have

NIS2's Article 21 lists ten categories of risk-management measures every in-scope entity must implement, proportionate to its size and risk exposure. The ones that land hardest on a factory floor:

• Risk analysis and information system security policies - a documented, maintained risk assessment, not a one-time consultant report from three years ago.
• Supply chain security (Article 21(2)(d)) - security requirements covering your direct suppliers and service providers, including their own vulnerabilities and secure-development practices. This is the clause that puts your PLC, gateway, and integrator vendors on the hook contractually, not just technically.
• Security in network and information systems acquisition, development, and maintenance (21(2)(e)) - vulnerability handling and disclosure as part of how you buy and maintain equipment.
• Policies on the use of cryptography and access control, asset management, and basic cyber hygiene - the fundamentals that most OT networks still handle informally.
• Business continuity and crisis management, including backup management and disaster recovery - tested, not assumed.

Article 21 is deliberately outcome-based: it doesn't name a specific standard. But for operational technology specifically, IEC 62443 is the standard most compliance programmes map against it in practice - 62443-2-1 for the cybersecurity management system the supply-chain clause expects, 62443-4-1 for a supplier's secure development lifecycle, and the zones-and-conduits model for the segmentation and asset management Article 21 otherwise leaves to your judgement. If you've already done segmentation work, a meaningful share of your Article 21 evidence already exists - it just needs to be organised and mapped to the article, not built from scratch.

Penalties Are Real, and Tiered

Article 34 sets penalty floors that national laws must meet or exceed:

• Essential entities: a maximum of at least €10 million or 2% of the group's total worldwide annual turnover in the prior financial year, whichever is higher.
• Important entities: a maximum of at least €7 million or 1.4% of worldwide turnover, whichever is higher.

These are floors, not caps - a member state can legislate higher maximums, and several have. Fines sit alongside separate supervisory powers (audits, binding instructions, and in some cases a temporary ban on a management-level individual carrying out duties until the deficiency is fixed) that Articles 32 and 33 give regulators, independent of whether a fine is ever issued.

A Worked Example: A Machinery Manufacturer Discovers It's In Scope

A 180-employee manufacturer of packaging machinery in a smaller EU member state ships equipment across the bloc and assumed NIS2 was a problem for its utility customers, not for itself. Three facts changed that:

1. Sector + size. Machinery manufacturing sits in Annex II, and 180 employees clears the medium-enterprise threshold. The company is an important entity by default - no designation letter required, no opt-out.
2. Supply chain clause. Several of its PLC and HMI suppliers had never been asked to document a secure development lifecycle or a patch-notification SLA. Under Article 21(2)(d), that's now the manufacturer's gap to close, not just the supplier's.
3. Incident response ownership. The plant's existing IT security runbook had a 24-hour escalation path for corporate email compromise, but nothing for an OT-side incident - no named owner, no CSIRT contact on file, no tested path to a 24-hour early warning if a line-side gateway were compromised.

None of the fixes required new platforms: an updated supplier questionnaire at contract renewal, a documented risk assessment covering the OT environment (not just IT), and a single incident response plan covering both sides of the plant, with the 24/72/one-month clock built in as a checklist rather than something improvised under pressure.

How NIS2 Fits Next to the CRA and IEC 62443

These three pieces of the puzzle are easy to conflate but answer different questions:

• IEC 62443 is a voluntary technical standard - how to design zones, conduits, and a cybersecurity management system.
• The Cyber Resilience Act regulates the products you buy and sell - what a device manufacturer must document, disclose, and patch.
• NIS2 regulates the operator - what your organisation, as the entity running the plant, must have in place for governance, risk management, and incident reporting, regardless of whose hardware you're running.

A plant that's already done IEC 62443 segmentation work and is tracking its vendors' CRA obligations has done most of the heavy lifting NIS2 asks for. The gap is usually process and paperwork: a documented risk assessment that actually covers OT, a supply-chain security clause in vendor contracts, and an incident response plan with a named owner for the 24-hour clock.

What to Check This Quarter

• Confirm scope under your national transposition law, not just the EU directive text - thresholds and sub-sector lists vary by member state.
• Find out who in your organisation owns the 24-hour reporting clock and confirm your national CSIRT contact is on file, tested, not assumed.
• Audit supplier contracts for Article 21(2)(d) language - secure development practices, vulnerability disclosure, patch SLAs.
• Map any existing IEC 62443 segmentation work against Article 21 - much of it already counts as evidence.
• Run a tabletop exercise that explicitly includes an OT-side incident, not just an IT phishing scenario, so the reporting plan is tested before it's needed for real.

If your team is still getting comfortable with the terminology this requires - ICS, CSIRT, zones and conduits - the glossary and the OT Security course track are a faster starting point than parsing the Official Journal text cold.

Sources:

• EUR-Lex - Directive (EU) 2022/2555 (NIS2)
• Springlex - NIS2 Directive, Article 23 (Incident Reporting)
• Springlex - NIS2 Directive, Article 34 (Administrative Fines)
• DNV - Leverage IEC 62443 for EU NIS2 Directive Compliance
• Trout Software - NIS2 Compliance: A Practical Guide to Meeting Article 21 Security Obligations