Manufacturing entered NIS2 scope through Annex II, and industrial control products entered CRA scope. The two arrive from different directions at the same plant.
---
The short answer
Manufacturing did not used to be in scope of EU cybersecurity law. It is now, twice, and for different reasons.
NIS2 regulates YOU as an entity — Annex II includes manufacturing of
computers, electronics, electrical equipment,
machinery, motor vehicles, medical devices
CRA regulates WHAT you place on the market — PLCs, HMIs, gateways,
YOU SELL industrial software, remote access appliancesA machine builder is typically both: an entity under NIS2 for its own operations, and a manufacturer under the CRA for the controllers it ships.
These are different obligations with different evidence, and merging them is the most common structural error in this sector.
---
The NIS2 side: you are probably "important", not "essential"
Annex II sectors are generally classified as important entities rather than essential — which changes the supervisory regime, not the obligations.
essential supervised EX ANTE — an audit can arrive because of what you are
important supervised EX POST — after evidence of a problemThe ten measures of Article 21 apply either way. What differs is when someone comes looking, and the penalty ceiling.
The size threshold matters here more than in other sectors: many machine builders and component manufacturers sit near the medium-enterprise boundary, and national transpositions differ on how they treat groups and subsidiaries. This is a determination worth writing down with its reasoning, because the answer is not obvious and it changes over time.
---
The OT problem that Article 21 does not name
Article 21 asks for risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness review, hygiene, cryptography, access control and multi-factor authentication.
Applied to a plant, several of these hit assumptions that OT was built on.
Multi-factor authentication on a control network where operators share a station during a shift handover. Patching on machines whose vendor validated a specific firmware and will withdraw support if it changes. Access control on a line where a supplier's engineer plugs in a laptop during commissioning.
None of these is an argument against the obligation. They are the reason a copied IT policy fails audit in an industrial setting: it describes controls that were never implemented on the plant floor, and the gap between the document and the shop is visible to anyone who walks it.
The defensible answer is a documented compensating control with a dated risk acceptance — not a policy that claims a control nobody operates.
---
The CRA side: which of your products are actually in scope
A PLC, an HMI, an industrial gateway, a remote access appliance, the configuration software, the fleet portal — all products with digital elements.
Annex III includes categories that reach industrial products directly, including certain industrial automation and control systems, and Annex IV covers a narrower critical set. These push you toward heavier conformity assessment routes.
The determination is narrower than most teams fear and it must be written down. "We concluded default class, here is the reasoning, dated" is worth far more than an assumption — and it bounds the duration factor in any future penalty assessment.
---
Support periods against machine lifetimes
This is where industry has the hardest version of a common problem.
A production line runs for twenty or thirty years. The CRA requires a support period reflecting the expected product lifetime, with a five-year floor unless the product's expected lifetime is shorter, and technical documentation kept for ten years after placing on the market, or the support period, whichever is longer.
controller placed on the market 2027
supported for 20 years -> documentation into the 2050sDeclared at placement. Decided now.
And it propagates downward. Your customer cannot declare their machine's support period until you declare your controller's. Your controller vendor blocks you the same way. The whole chain is waiting on whoever is furthest upstream, and in most cases nobody has been asked yet.
---
Where the two regimes genuinely help each other
The asset inventory. NIS2 risk analysis needs it; CRA scope determination needs it; nothing downstream in either regime can be correct without it.
The supplier management. NIS2 Article 21(2)(d) requires it of you as an entity; the CRA makes your own customers require it of you as a manufacturer. Same programme, two directions.
The incident process. NIS2 Article 23 covers incidents affecting your services; CRA Article 14 covers exploited vulnerabilities in your products. One runbook, two trigger conditions — and they must be separated, because the clocks start on different events.
The vulnerability disclosure policy. Required outright by CRA Annex I, expected by NIS2 Article 21(2)(e), and checked first by every serious industrial buyer.
---
The commissioning problem nobody puts in a policy
Industrial systems are configured on site, by integrators, often by the customer's own contractors.
A controller shipped with secure defaults can be deployed with those defaults disabled because a commissioning engineer needed remote access at 11 p.m. to finish a ramp-up.
The CRA obligation attaches to the product as placed on the market, so secure defaults discharge it. But the NIS2 obligation attaches to the operator, and the plant now runs an insecure configuration.
This is exactly where the two regimes hand off, and where nobody owns the seam. The defensible answer is a documented commissioning procedure with recorded deviations — which is also, conveniently, effectiveness evidence under Article 21(2)(f).
---
Six things worth doing this quarter
- 1Write down your NIS2 classification — essential, important, or out of scope — with reasoning and a date.
- 2List every product you place on the EU market, and classify each under the CRA separately.
- 3Stop copying the IT policy onto OT. Document compensating controls and accept the residual risk explicitly.
- 4Decide and declare support periods. Your customers are blocked until you do.
- 5Separate the two incident triggers in one runbook.
- 6Write the commissioning procedure, and record deviations — it closes the seam and produces effectiveness evidence at the same time.
---
Check what reaches your plant and your products — free, no account
- [Free readiness assessment](/assess) — as an entity and as a manufacturer, separately
- [Compliance responsibility mapper](/resources/responsibility-mapper) — a RACI by role
- [Penalty calculator](/resources/penalty-calculator) — exposure on your own turnover
---
Further reading
→ Essential versus important under NIS2 → Important versus critical under the CRA → NIS2 and CRA overlap → Products with digital elements, defined → One evidence set across five EU regulations
---
*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. NIS2 scope, size thresholds and classification depend on national transposition and differ between Member States. Verify against the applicable national law and consult your competent authority or a qualified adviser.*