RED cybersecurity: can you self-assess, or do you need a Notified Body?

· INTECH

For the RED cybersecurity requirements, there are two ways to demonstrate conformity. One is fast and you can do it yourself. The other costs money and weeks of a third party’s time. The gap between them often comes down to a handful of design decisions — so it pays to understand what pushes you from one to the other.

Route 1: Module A self-assessment

For the cybersecurity essential requirements, the standard path is Module A — internal production control. No external test lab is required. You:

  • evaluate the product against the applicable parts of EN 18031,
  • produce the technical documentation and rationale,
  • issue the EU Declaration of Conformity yourself.

You carry the responsibility, but you keep control of cost and schedule. For most connected products, this is the route you want to stay on.

What makes self-assessment possible

Module A works because fully implementing EN 18031 gives a presumption of conformity. Meet the requirements as the harmonised standard describes them, and authorities accept that you satisfy the RED essential requirements — no Notified Body needed.

The keyword is fully. The presumption is all-or-nothing per requirement.

Route 2: when a Notified Body becomes mandatory

The harmonisation of EN 18031 came with restrictions. Some requirements contain restricted conditions — and if your product triggers one, you lose the automatic presumption of conformity for that requirement. At that point you can no longer simply self-declare against it; a Notified Body must assess it.

Common triggers are exactly the kind of “convenience” choices product teams make without thinking about compliance:

  • letting a user skip setting a password or ship with a default one,
  • weak or optional access control on sensitive functions,
  • gaps in parental / child-access controls on devices in scope of -2,
  • shortcuts in financial-transaction safeguards for devices in scope of -3.

None of these are exotic. They are ordinary UX decisions that quietly change your regulatory route.

Why this matters before you finalise the design

If you discover a restricted-clause problem after the product is built, your options are bad: redesign late, or pay for a Notified Body assessment and absorb the schedule hit. If you catch it during design, the fix is usually cheap — a mandatory password on first boot instead of an optional one, for example.

That is the whole argument for doing the cybersecurity gap analysis early: not to generate paperwork, but to keep your product on the self-assessment route where it belongs.

The practical takeaway

  1. Assume you want Module A self-assessment — it’s faster and cheaper.
  2. Map your design against EN 18031’s restricted clauses specifically.
  3. Fix anything that would forfeit presumption of conformity while it’s still cheap to fix.
  4. Only accept Notified Body involvement where it is genuinely unavoidable.

Not sure which route your product is on? Our EN 18031 work starts exactly here — finding the restricted-clause risks before they cost you a redesign or a Notified Body bill.

This is general information, not legal advice.