EN 18031 and the CRA: What Security Testing Can Show, and What It Can’t

Since EN 18031 was cited in the Official Journal, product teams have been asking us a version of the same question: "If we test against EN 18031, are we CRA-compliant?" The honest answer is no, and the question behind the question is more useful: what can technical testing actually establish, for which framework, and what remains a documentation decision either way? This note separates the three things that keep getting conflated: the standard, the regulation, and the evidence.

The facts first, because they are widely misstated. EN 18031 is a three-part standard for the security of radio equipment, harmonized under the Radio Equipment Directive (RED), not under the Cyber Resilience Act. No harmonized standard for the CRA has been cited in the Official Journal yet; EN 18031 is best understood as a stepping stone whose technical content anticipates much of what the CRA will require. Testing against it produces strong evidence. It does not produce a presumption of conformity with the CRA.

The three parts, briefly

EN 18031-1 addresses network protection, 31 requirements on secure communication, update mechanisms, access control and similar properties for internet-connected radio equipment. Part 2 addresses personal data protection with 40 requirements; notably, a substantial share can be satisfied by a manufacturer's declaration rather than testing. Part 3 addresses fraud protection for financial transactions with 34 requirements. For most connected products, Part 1 is where the technical work concentrates, and where it overlaps most with what security testing has always done.

What testing establishes, and what it doesn't

Three kinds of evidence sit at the bottom of every conformity conversation, and they are not interchangeable:

• Design documentation shows intent: the architecture meant to restrict access, the update mechanism meant to be signed. It answers "what did you design?"
• Test reports show implementation: the signature check executed, the access control fired, the update was rejected. They answer "does the product behave as designed under the tested conditions?"
• Adversarial findings, penetration testing, show behavior under conditions nobody designed for. They answer "what happens when someone tries the things the design didn't anticipate?"

Conformity frameworks consume mostly the first two. Security reality is decided significantly by the third. A product can accumulate declarations and still ship an open debug port; a product can pass every functional security test and still trust every bearer of a shared credential. The frameworks know this, which is why EN 18031's "c" mechanisms (conditional requirements) explicitly allow more demanding evidence for higher risk classes, including adversarial testing.

Mapping tests to CRA requirements, the useful part

Even without a CRA presumption of conformity, the technical overlap is real and exploitable. The CRA's Annex I essential requirements, secure by default, secure updates, no exploitable vulnerabilities "knowingly and actively", protection of stored and transmitted data, minimization of attack surfaces, are exactly the properties an EN 18031-oriented test campaign exercises. A pragmatic pattern we recommend to product teams: build one technical evidence base, structured by security property (boot integrity, update security, access control, key management, communication security, data protection), and let it serve the RED declaration today and the CRA conformity assessment tomorrow. The tests don't change; the paperwork they feed does.

What changes with the CRA is the cost of gaps. Under the RED, a missing piece is a compliance risk. Under the CRA's reporting and assessment regime, the same missing piece, say, an update mechanism that accepts old signed images, see Firmware Anti-Rollback, becomes a vulnerability with a 24-hour reporting clock attached (see CRA Vulnerability Reporting). The standards conversation and the incident conversation are converging on the same technical facts.

Preparing without compliance theater

The teams that benefit from EN 18031 treat it as a test plan, not a talisman. Concretely: map your product's security properties to the relevant requirements once, honestly; identify where your evidence is a declaration that should be a test; fix the findings that matter technically, regardless of which regulation asked; and keep the evidence structured so it can be re-consumed. The teams that suffer print the requirement list, answer "yes" 105 times, and discover in an incident, or an assessment, that the answers described the design, not the product.

That, in the end, is the honest summary of the whole EN 18031 / CRA relationship: the frameworks will keep evolving, and the technical questions they circle around, is your boot chain real, your update path safe, your identity per-device, your data protected, do not change at all. Products that can answer those with evidence are prepared for whichever document asks next.