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 · Networking hardware
Important Class I - the conformity route depends on harmonised standards
A networking hardware manufacturer selling through EU retail
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 I
Basis
Annex III, Part I
Conformity route
Self-assessment only if harmonised standards are applied; otherwise a notified body
Descriptor matched: Network management system (router)
The products assessed
Wi-Fi 6 mesh routerRouter · Wi-Fi, cloud management, mobile app
Router management firmwareNetwork management · web UI, API, firmware
Why it lands there
A router is explicitly within the Annex III Part I family of network-management products. The rulebook matches it on the `network_mgmt` descriptor, so the class is not a judgement call.
Class I is the *lower* of the two Important tiers. It matters because Class I keeps a self-assessment route open - but only where the manufacturer actually applies the relevant harmonised standards. Absent those, a notified body is required.
The management firmware is not a separate class: it is the router's core functionality, and the core-functionality test (Impl. Reg 2025/2392) classifies the product by what it is for.
Being a consumer product does not lower the class. Annex III does not distinguish a €60 retail router from a rack-mounted one.
What follows from it
✓Everything in the Default list, plus:
✓A conformity route decision that is documented - which harmonised standards were applied, or which notified body was engaged
✓Evidence that the router ships secure by default: no shared default credentials, no unauthenticated management interface
✓A support period long enough to be credible for a product with a multi-year retail life
The trap on this one
"We self-assess because we are Class I, not Class II" is only half the rule. Class I permits self-assessment *conditionally*. If the harmonised standards you rely on do not cover your functionality, the route reverts to a notified body - and that discovery is expensive late.
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.
Which harmonised standards are being applied, and does their published scope actually cover this product's functionality?
Does the device ship with a unique-per-unit credential, or a printed default shared across the production run?
Is the cloud management plane assessed as part of the product, or treated as a separate service outside the technical file?
The realistic next step
EN 18031 covers exactly the router behaviours a Class I self-declaration has to stand on - default credentials, update integrity, exposed management interfaces. Testing against it first tells you whether the self-assessment route is genuinely open to you before you commit to it.
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.