Standards & Regulations
CRA compliance in practice: what demonstrating conformance actually requires from your product team
By Dunstan Power, a director at ByteSnap Design, an embedded electronics and software consultancy M
ost embedded product teams know the Cyber Resilience Act (CRA) is coming. The December 2027 deadline is on roadmaps
and engineers have read the headlines. What fewer have done is map out what demonstrating compliance actually requires in practice. That gap tends to surface at the worst possible moment: during conformity assessment, when the documentation is not there, the vulnerability disclosure process does not exist, or the security risk assessment turns out to have been a one-page addendum written after the fact rather than a genuine design-phase artefact.
EN 18031 is the harmonised standard series underpinning the Radio Equipment Directive’s mandatory cybersecurity requirements, in force for internet-connected radio equipment since 1 August 2025. It will almost certainly form the technical basis for CRA compliance too. ENISA has already published a mapping of CRA requirements against EN 18031, and the direction of travel is clear.
The standard covers three protection domains: network integrity (EN 18031-1), personal data protection (EN 18031-2), and financial transaction security (EN 18031-3). For most connected industrial and IoT products, EN 18031-1 is the relevant part.
At the product level, the requirements that apply to most connected devices fall into four areas: authentication (no default shared passwords, proper credential management, robust session handling); secure update mechanisms (cryptographically verified firmware delivery, protection against rollback or tampered images); vulnerability disclosure (a published, documented process for receiving and acting on vulnerability reports throughout the product’s supported lifetime); and network interface security (unnecessary services
14 June 2026
disabled, communications protected, standard network-layer attacks mitigated). These are requirements that must be evidenced during conformity assessment.
What demonstrating compliance actually requires
This is where product teams most often underestimate the workload. The technical requirements are one challenge. Building the documented evidence that you have met them is a separate one, and the CRA places that burden squarely on the manufacturer. For most products, the starting point is a self-declaration of conformity. The manufacturer assesses the product against the applicable requirements, prepares a technical file, and declares compliance. That technical file needs to contain: a description of the product and its intended use; a security risk assessment conducted during the design phase; test reports or analysis demonstrating that each applicable requirement is met; documentation of
Components in Electronics
the software update mechanism and how it is controlled; and a description of the vulnerability disclosure and lifecycle management process.
A third-party Notified Body assessment is required in specific circumstances, most commonly when the product triggers a restricted clause in EN 18031-1. The most widely encountered example is authentication: if a device permits a user to skip setting a password during initialisation, the manufacturer loses the presumption of conformity and must involve a Notified Body. This catches product teams off guard. Your conformity route is partly determined by early design decisions, and once a product ships with a permissive authentication flow, rerouting to self-declaration requires a redesign, not a documentation fix.
Five things product teams commonly get wrong
Working through EN 18031 compliance with connected product manufacturers over the
past year, we see the same failure modes come up repeatedly. Missing or inadequate update mechanism. Many products were not designed with authenticated firmware update in mind. Retrofit solutions are possible, but they need to be properly implemented and documented. A firmware update process that lacks cryptographic verification, or permits unsigned images, will fail assessment.
No vulnerability disclosure process. Vulnerability disclosure is a business process, not a firmware feature. It needs to be documented, live, and operational before the product ships. This is consistently underestimated.
Inadequate technical documentation. The security risk assessment in particular needs to be a genuine design-phase artefact rather than a retrospective write-up. An experienced assessor will spot the difference. Security testing not integrated into
www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
