OnwynOnwyn › Standards › RED Cybersecurity (Directive 2014/53/EU, Art. 3(3)(d)-(f))
Regulation · EN 18031:2024RED Cybersecurity (Directive 2014/53/EU, Art. 3(3)(d)-(f))
The cybersecurity requirements of the EU Radio Equipment Directive, in force for radio equipment placed on the EU market. Article 3(3)(d) requires network protection, (e) the protection of personal data and privacy, and (f) protection from fraud; which of the three apply depends on what the product does. Conformity is normally shown against the harmonised standards EN 18031-1, -2 and -3, which were cited in the Official Journal with restrictions — and those restrictions decide whether you can self-declare or must involve a Notified Body. Scope covers the whole product, not only the radio. This pack follows the standard's own structure: a mechanism is assessed per item, and every applicability decision needs a written justification, because under the standard's verdict rule a missing justification is a failure on its own. It does not reproduce the decision trees themselves, which are published as diagrams and must be read from the standard.
What this standard asks for
Every requirement in RED Cybersecurity (Directive 2014/53/EU, Art. 3(3)(d)-(f)), grouped the way the standard groups them. In the Compliance Engine each one carries what to do, how to evidence it, what auditors commonly reject, and a button to bring in a consultant if you would rather not work it out alone.
Scope, applicability and assets
3 requirements
- 3(3)(d)-(f)Determine which of the three cybersecurity requirements apply
- AssetsIdentify and document the asset inventory
- DTRecord the decision-tree path and justification for every determination
Access control and authentication
9 requirements
- ACM-1Access control over security, network, privacy and financial assets
- ACM-2Access control mechanisms admit only authorised entities
- AUM-1Authentication over network and user interfaces
- AUM-2Authentication uses at least one recognised factor
- AUM-3Validate all relevant properties of authenticators
- AUM-4Authenticators can be changed
- AUM-5-1Factory default passwords are unique per unit or forced to change
- AUM-5-2Non-default passwords are set safely before network exposure
- AUM-6Authentication is resilient against brute force
Secure update
3 requirements
- SUM-1At least one update mechanism exists for security-relevant software
- SUM-2Updates install only software of valid integrity and authenticity
- SUM-3The update mechanism is capable of updating without per-device manual work
Secure storage
3 requirements
- SSM-1Assets held in persistent storage use secure storage
- SSM-2Secure storage protects integrity
- SSM-3Secure storage protects the secrecy of confidential parameters
Secure communication
4 requirements
- SCM-1Assets in transit use secure communication
- SCM-2Best-practice protection of integrity and authenticity in transit
- SCM-3Best-practice protection of confidentiality where needed
- SCM-4Replay protection
Cryptography and confidential keys
4 requirements
- CCK-1Confidential cryptographic keys reach at least 112-bit security strength
- CCK-2Key generation follows best practice
- CCK-3Preinstalled keys are unique per unit
- CRY-1Best-practice cryptography throughout
General equipment capabilities
6 requirements
- GEC-1No publicly known exploitable vulnerabilities
- GEC-2Factory default exposes only necessary interfaces and services
- GEC-3Optional services can be enabled and disabled
- GEC-4User documentation describes exposed interfaces and services
- GEC-5Physical external interfaces are exposed only where necessary
- GEC-6Input received over external interfaces is validated
Network resilience and monitoring — Part 1 only
3 requirements
- RLM-1Resilience against denial of service — Part 1 only
- NMM-1Network monitoring, where the equipment is network equipment — Part 1 only
- TCM-1Traffic control, where the equipment is network equipment — Part 1 only
Privacy, logging, deletion and notification — Part 2 only
5 requirements
- ACM-3-6Children's access and parental control — Part 2 only
- LGM-1-4Logging of privacy-relevant or financial events — Part 2/3 only
- DLM-1Users can delete their personal data — Part 2 only
- UNM-1-2Users are told about changes affecting privacy — Part 2 only
- GEC-7External sensing capabilities are documented for the user — Part 2 only
Financial-asset protection — Part 3 only
2 requirements
- AUM-1-3Authentication over machine interfaces — Part 3 only
- GEC-8Verified boot from a root of trust — Part 3 only
Conformity assessment, documentation and CE marking
4 requirements
- Art. 17Choose the conformity assessment route — and keep self-declaration if you can
- Art. 21 / Annex VTechnical documentation, drawn up before market and kept current
- Art. 18 / Annex VIEU declaration of conformity and CE marking
- CRAPlan the transition to the Cyber Resilience Act
The documents you will end up with
The recommended document set for RED Cybersecurity (Directive 2014/53/EU, Art. 3(3)(d)-(f)) — 22 in total. The engine tracks which you have, which are missing, and which of your existing documents already cover a requirement.
Which of Article 3(3)(d), (e) and (f) apply to this product, and therefore which parts of EN 18031 you must satisfy.
Every security, network, privacy and financial asset the equipment holds or processes, and the functions that touch each one.
The requirement-by-requirement record: applicability path per item, justification for each path, and where the evidence lives.
The threat picture for this product, mapped to the mechanisms that mitigate each threat.
How access to each asset is governed, how entities authenticate, and what happens to credentials from factory default onwards.
Evidence that no unit ships with a shared default password and that no user can end up with no password set.
The update mechanisms, how integrity and authenticity are verified at installation, and how the signing keys are managed across their lifecycle.
Which assets are persisted, where, and what protects their integrity and secrecy.
Every flow — interface, asset, protocol, direction, peer — with the protection applied and any deviation justified.
Every algorithm, mode, key length and key, measured against a named best-practice catalogue with its deprecation dates.
Every software and hardware component with versions, which assets each affects, and the vulnerability position for each.
The recurring record: what was scanned, from which source, what was found, and the justification for each finding.
Every network interface, exposed service and physical external interface as shipped, each with a necessity rationale.
The functional sufficiency evidence: brute-force resistance, fuzzing, tamper and extraction tests, replay tests, and update-rejection tests.
The shipped manual sections disclosing exposed interfaces and services, and any privacy-related sensing capabilities.
The denial-of-service resilience measures and recovery behaviour, and the documented determination of whether the product is network equipment.
The privacy-facing mechanisms of Part 2: children's access controls where relevant, the event log, the deletion mechanism and the change-notification policy.
The boot chain, the root of trust and its mutability, and the evidence that a modified image does not boot.
The route chosen under Article 17, which parts of EN 18031 were applied, and the alternative solution adopted for any part that was not.
The Annex V dossier the market surveillance authority can demand, pinned to the exact firmware versions assessed.
The Annex VI declaration covering the cybersecurity essential requirements and the standards applied.
How this work relates to the Cyber Resilience Act, what carries forward as evidence, and what does not.
Work that counts twice
RED Cybersecurity (Directive 2014/53/EU, Art. 3(3)(d)-(f)) overlaps with 2 other frameworks in the engine. When you start one of these, the requirements you have already settled here are carried across as suggestions for you to confirm — you review them, we never mark them done on your behalf.
Start RED Cybersecurity today
Every live framework is included in one subscription — no per-framework pricing. Your first 30 days are free, we ask for no card, and there is nothing to cancel. On any requirement you can bring in a senior consultant for a review, a call, or done-for-you implementation.