CRASPACE
Scanning · scope · class · risk
CRASPACE
30 min with a CRA specialist - your classification confirmed against real specs, your open questions closed. Free, no obligation.Rulebook v0.5.1Full compliance 11 Dec 2027
Worked example · Industrial / OT security

Important Class II - an OT product on an IT regulation's terms

An OT security vendor selling into manufacturing and utilities

Worked example - a product archetype run through the CRASPACE rulebook. Not a client engagement, and not a conformity assessment.

The verdict

CRA scope
In scope
Class
Important - Class II
Basis
Annex III, Part II
Conformity route
Third-party (notified body) assessment is mandatory

Descriptor matched: Intrusion detection / prevention

The products assessed

  • Industrial intrusion detection systemIntrusion detection · network, passive tap, API
  • Sensor applianceIntrusion detection · network, firmware

Why it lands there

  1. Industrial intrusion-detection systems are named in Annex III Part II. The class carries a mandatory notified body assessment, exactly as for an enterprise firewall.
  2. Operating in an OT environment does not reduce the obligation. It does make several Annex I requirements harder - a sensor on a production line cannot always be patched on the vendor's schedule - but "hard to update" is not a recognised basis for a lower class.
  3. The support period question is sharper here than anywhere else in these examples. Industrial equipment lives for a decade or more, and the support period must be declared against the product's realistic life, not the vendor's release cadence.
  4. A parallel-regime check matters for this archetype: NIS2 duties may fall on the *operators* buying the product, and those customers will push their obligations up the supply chain as procurement requirements well before December 2027.

What follows from it

  • Everything in the Important Class II list, plus:
  • A support period declared against real industrial asset life, with an update mechanism that works inside a maintenance window
  • Vulnerability handling that can deliver a fix to an air-gapped or change-controlled deployment
  • Evidence prepared with the knowledge that NIS2-regulated customers will ask for it independently of any market-surveillance authority

The trap on this one

"We are OT, the CRA is IT" is not a carve-out. The Art 2 carve-outs are sectoral and specific - medical devices, motor vehicles, certified aviation, marine equipment. Industrial security is not among them.

The questions this leaves open

A public-evidence scan cannot answer these. They are what a consultation is for, and they are deliberately questions rather than instructions.

  • What support period can genuinely be committed to, given the deployed life of the equipment this monitors?
  • How does a security update reach a customer who cannot accept an automatic one?
  • Which of your customers are NIS2-regulated entities, and what are they already contractually asking you to evidence?

The realistic next step

The realistic first move is pre-assessment against the Part II bar plus a hard look at the support-period commitment, because that commitment is contractual, long-lived, and expensive to revise once it is published.

This is an archetype. Yours is not. Run the check against your own company and get the same reasoning applied to the products you actually ship, each with a source you can open.