prEN 40000-1-4 is the part of the EN 40000 family that manufacturers will open most often. Where Part 1-3 defines how to handle vulnerabilities, Part 1-4 defines which technical controls can bring a product to an appropriate level of cybersecurity under CRA Annex I, Part I, and how to prove each one works.
The current draft (CEN/CLC/JTC 13/WG 9 N 847, dated 10 July 2026) was submitted to the European Commission for assessment ahead of CEN Enquiry. It runs to roughly 200 pages: 13 essential requirements, 18 control families, 65 technical controls, and a pass/fail assessment method for every control.
As Rapporteur for this part, I want to go beyond the overview. This article walks through how the document is built, how to read it, and how to start using it before it is final. For how Part 1-4 fits with the rest of the family, see my companion article on the EN 40000 family.
From CRA requirement to verdict
Clause 5 breaks each CRA requirement into threats and matching security objectives; Clause 6 holds the controls that meet them, each with its own pass/fail assessment. Three informative annexes help navigation: Annex A puts the whole chain in one table, Annex B maps CRA Annex I, Part I to the clauses, and Annex C maps every EN 18031 requirement to its Part 1-4 counterpart.
Reading the conditional “shall”
The most important sentence in Part 1-4 is in subclause 6.1, and it is easy to miss. Clause 6 is written with “shall” requirements, but they are conditional: they apply once a control has been selected to mitigate a risk identified in the product’s risk assessment.
In practice, this means:
- Selection is driven by risk, not by the catalogue. A battery-powered sensor and an industrial gateway will select very different subsets. The draft says so explicitly: some products need only some controls; others need more.
- Once selected, a control is not optional in its detail. The “shall” fixes how the control must be implemented and how it is verified.
- The catalogue is a floor for thinking, not a ceiling. Where residual risk remains, the manufacturer can add controls that are not in the document at all.
- The RDPS follows the product. A control selected for the device is selected for its remote data processing solution too.
This is the biggest conceptual difference from EN 18031. There, each mechanism opened with an applicability requirement and a decision tree. Here, those applicability controls ([ACM-1], [AUM-1], [SSM-1], [SCM-1]) are “void”: the decision belongs to the risk assessment the CRA already requires. It is the same principle I stressed in my ITS interview: run the risk assessment first, because everything else depends on it.
The flip side is accountability. Without a decision tree, a manufacturer cannot point to a flowchart to justify leaving a control out. The justification has to come from identified threats. A risk assessment that cannot explain the selection will not survive a conformity assessment.
Thirteen essential requirements, one map
Clause 5 has one subclause per CRA Annex I, Part I, (2) requirement, and Annex B summarises which controls can support each. This is the table to keep on your desk:
CRA Annex I, Part I | Clause | Controls that can support it |
|---|---|---|
(2)(a) No known exploitable vulnerabilities | 5.2 | GEC-1 |
(2)(b) Secure by default configuration, with reset | 5.3 | AUM-5, DLM-1, GEC-2, GEC-3, GEC-9, GEC-10, GEC-11, GEC-13, DTM-1, DTM-2 |
(2)(c) Security updates | 5.4 | SUM-1 to SUM-7 |
(2)(d) Protection from unauthorised access | 5.5 | ACM-2, AUM-2 to AUM-6, GEC-14 |
(2)(e) Confidentiality | 5.6 | SSM-3, SCM-2 to SCM-4, CCK-1 to CCK-3, CRY-1, CRY-2, SPD-1 |
(2)(f) Integrity | 5.7 | SSM-2, SCM-2, SCM-3, UNM-2, CCK-1 to CCK-3, GEC-8, GEC-14, CRY-1, CRY-2, SPD-1 |
(2)(g) Data minimisation | 5.8 | UNM-1, UNM-2, DTM-1 to DTM-3 |
(2)(h) Availability of essential functions | 5.9 | RLM-1 to RLM-6 |
(2)(i) Minimise impact on other devices and networks | 5.10 | NMM-1, TCM-1, GEC-8, LIM-1 to LIM-5 |
(2)(j) Limit attack surfaces | 5.11 | GEC-2, GEC-3, GEC-5, GEC-6, GEC-13 |
(2)(k) Reduce incident impact through exploitation mitigation | 5.12 | GEC-12 |
(2)(l) Security information by recording and monitoring | 5.13 | LGM-1 to LGM-6, NMM-1, MON-1, MON-2 |
(2)(m) Secure data removal and transfer | 5.14 | SCM-2 to SCM-4, DLM-1, CCK-1 to CCK-3, CRY-1, CRY-2 |
Two things stand out. First, many controls serve several requirements: cryptography ([CRY], [CCK]) supports confidentiality, integrity and secure data transfer at once, so getting it right pays off three times. Second, some requirements rest on a single control. (2)(a) is GEC-1 alone, and (2)(k) is GEC-12 alone, which makes those two controls carry a lot of weight in any assessment.
Inside each Clause 5 subclause, the draft first lists the threats (for example Threat.SoftwareUpdateTampering), pairs each with a security objective (SO.SecureUpdate), and only then points to the controls. Annex A puts the whole chain in one table.
The 18 control families
Clause 6 groups the 65 controls into 18 families. The identifiers follow EN 18031, so numbering gaps marked “void” are intentional.
Family | Controls | What it covers |
|---|---|---|
[ACM] Access control mechanism | ACM-2 | Only authorised entities reach protected assets, consistently on every interface |
[AUM] Authentication mechanism | AUM-2 to AUM-6 | Authentication, authenticator validation and change, password strength, brute-force protection |
[SUM] Secure update mechanism | SUM-1 to SUM-7 | Updateability, authentic updates, automatic updates on by default with opt-out and postponement, user notification |
[SSM] Secure storage mechanism | SSM-2, SSM-3 | Integrity and confidentiality of stored assets |
[SCM] Secure communication mechanism | SCM-2 to SCM-4 | Integrity, authenticity, confidentiality and replay protection in transit |
[LGM] Logging mechanism | LGM-1 to LGM-6 | Logging, persistence, minimum events, timestamps, option to disable, no sensitive data in logs |
[DLM] Deletion mechanism | DLM-1 | Secure deletion of user data and settings |
[UNM] User notification mechanism | UNM-1, UNM-2 | How and what the product tells the user |
[RLM] Resilience mechanism | RLM-1 to RLM-6 | Resilience, incident recovery, network and resource prioritisation, resource management, backup |
[NMM] Network monitoring mechanism | NMM-1 | Detecting anomalous network behaviour |
[TCM] Traffic control mechanism | TCM-1 | Controlling traffic to and from the product |
[CCK] Confidential cryptographic keys | CCK-1 to CCK-3 | Appropriate keys, key generation, no static default keys |
[GEC] General capabilities | GEC-1 to GEC-14 | Known vulnerabilities, exposed interfaces and services, input validation, product integrity, secure defaults and startup, reset, exploit mitigation, no unneeded components, reporting of unauthorised access |
[CRY] Cryptography | CRY-1, CRY-2 | State-of-the-art mechanisms (ECCG ACM or justified), crypto agility |
[DTM] Data minimisation (new) | DTM-1 to DTM-3 | Only the data needed for the intended purpose, minimal by default, user-configurable |
[MON] Monitoring of security activities (new) | MON-1, MON-2 | Monitoring security-relevant activity, with an option to disable it |
[SPD] Secure processed data (new) | SPD-1 | Protecting data in use: memory, registers, caches, buffers |
[LIM] Limitation of negative impact on external systems (new) | LIM-1 to LIM-5 | Egress rate limiting, no open reflectors or relays, anti-spoofing, abuse monitoring, quarantine mode |
[GEC] is the largest family by far, with 14 controls. It collects the cross-cutting capabilities that do not belong to a single mechanism, and it carries several of the most-cited CRA obligations.
Controls worth a closer look
[GEC-1] No insufficiently mitigated known exploitable vulnerabilities. The wording matters. A vulnerability is acceptable if it cannot be exploited in the product’s specific conditions, has been mitigated to an acceptable residual risk, or has been accepted on a risk basis. The guidance points to the EU Vulnerability Database, the NVD, exploit repositories and code platforms, and links back to a vulnerability handling process like Part 1-3. In the APPtake paper, Enrico Frumento and I showed why this is getting harder: AI coding tools pull in dependencies nobody chose consciously, and the manufacturer remains liable for all of them.
[CRY-1] and [CRY-2] Cryptography. The default configuration must use mechanisms listed in the ECCG Agreed Cryptographic Mechanisms catalogue, or mechanisms justified as suitable for the use case. Interoperability cases, such as a PKI using RSA-2048, are explicitly anticipated. Where a mechanism is expected to be deprecated during the product’s lifetime, CRY-2 requires a way to update or retire it.
[AUM-5] Password strength. Factory default passwords must be unique per product and of state-of-the-art strength, or changed before or on first use.
[SUM-4] to [SUM-6] Automatic updates. Where automatic installation is supported and operationally appropriate, it is on by default; users can opt out; and updates can be postponed so they do not interrupt essential or safety-critical operation.
[LIM-2] No open reflectors or relays. In the factory default state, the product must not expose to untrusted networks a service that can be abused as an unauthenticated reflector, amplifier or open relay. In plain terms: your product should not become someone else’s DDoS weapon.
[SPD-1] Secure processed data. Data at rest and in transit were already covered by [SSM] and [SCM]. SPD-1 closes the gap for data in use.
[LGM-6] No sensitive data in logs. Logs must not contain personal data, secrets or credentials. Together with [LGM-5] and [MON-2], this is where security logging meets data protection.
Anatomy of a control: [SUM-2] as a worked example
Every control in Clause 6 follows the same template: Requirement, Rationale, Guidance and Assessment. The assessment always has five parts. The same text is meant to work for a manufacturer self-assessing, an internal test lab, or a notified body. Here is how it plays out for [SUM-2] Secure updates integrity and authenticity.
Requirement. The integrity and authenticity of every software update is validated before installation, either by the product itself or by supporting measures. The note explains that supporting measures can mean, for example, the operating system’s installer doing the check instead of a low-level chip.
Rationale. An unprotected update mechanism is one of the easiest ways to inject malicious code into a product at scale.
Guidance. Typically a cryptographic check against a trust anchor, on the product or on a trusted component. Anti-rollback is recommended as good practice. Three implementation categories are offered: digital signatures by authorised entities; a secure channel to the authorised update source; or access control limited to authorised entities combined with hash-protected updates.
Assessment.
Step | What happens for SUM-2 |
|---|---|
1. Objective | Conceptual assessment, functional completeness, and functional sufficiency of each mechanism in the secure default configuration |
2. Preparation | A complete list and description of the validation mechanisms; test setups for integrity checks, authenticity checks, and behaviour when validation fails |
3. Activities | Check that every mechanism in the product is documented and every documented mechanism exists; test that integrity and authenticity are validated before installation and that failing updates are rejected |
4. Verdict | PASS only if the documentation shows conformity, the documentation is complete and correct, and every mechanism passes the tests; FAIL otherwise |
5. Evidence | Records of the documentation review, plus descriptions and records of every test performed |
Two lessons generalise to every control:
- Documentation is tested, not just read. The assessor checks both directions: nothing undocumented in the product, nothing documented that is not in the product. An architecture description that drifts from the real product is a FAIL in itself.
- Negative tests matter. SUM-2 is not passed by showing a valid update installs. It is passed by showing a tampered one is refused.
This is why I recommend building the evidence into development rather than reconstructing it before an assessment. Every test you run in your pipeline today is a record the standard will ask for tomorrow.
Migrating from EN 18031
If your products already comply with the RED delegated act through EN 18031, Annex C is your migration map. It lists every EN 18031 requirement next to its Part 1-4 counterpart and labels the change: same name, renamed, merged, void, or new.
EN 18031 series | prEN 40000-1-4 | |
|---|---|---|
Legal basis | RED Art. 3(3)(d), (e), (f) | CRA Annex I, Part I, (2)(a) to (m) |
Products in scope | Internet-connected radio equipment | All products with digital elements, including RDPS |
Deciding what applies | Applicability requirements and decision trees | The manufacturer’s risk assessment |
Toy and childcare controls (ACM-3 to ACM-6) | Normative | Void, left to vertical standards |
Control families | 14 | 18 |
Technical controls | Source of 36 revised controls | 65 (36 revised, 29 new) |
Cryptography | Best-practice cryptography | ECCG ACM-listed or justified, plus crypto agility |
Three practical points for a migration:
- “Same name” does not mean “same content”. Annex C states that carried-over controls were revised to align with the CRA. Re-read every one; do not assume your RED evidence still passes.
- The new controls cluster where RED never looked. Updates (SUM-4 to SUM-7), secure defaults and hardening (GEC-9 to GEC-14), resilience (RLM-2 to RLM-6), data minimisation [DTM], monitoring [MON], data in use [SPD] and external impact [LIM]. Expect your gaps here.
- Your applicability rationale has to move. Arguments that relied on EN 18031 decision trees need to be rewritten as risk-based justifications.
What this means for manufacturers
Part 1-4 is first and foremost a catalogue: for manufacturers building their control set, and for vertical standards, which are meant to select and tighten controls for their product categories. In practice, Part 1-4 and the verticals were drafted in parallel, so that cross-referencing is not yet in place; I hope the next release closes the gap. As I explained in my ITS interview, the horizontal parts play different roles. Part 1-3 is the one designed to carry presumption of conformity on its own; Part 1-4 is the toolbox the rest of the system draws on. Its Annex B shows how the controls relate to CRA Annex I, Part I.
That does not make it less urgent. Whatever route to conformity you take, you will need to show how your product meets the thirteen requirements of Annex I, Part I, and Part 1-4 is the most detailed public description of what that looks like. My advice:
- Start with the risk assessment. It decides which controls you select, and it must justify the ones you leave out.
- Map your product against the Annex B table. For each requirement, which controls do you already have, and which are missing?
- Prioritise the single-control requirements. GEC-1 for (2)(a) and GEC-12 for (2)(k) carry a lot of weight on their own.
- Build the evidence into your pipeline. Documentation reviews and test records are part of every verdict.
- Do not forget the RDPS. Your remote data processing needs the same coverage as your device.
- Govern AI-assisted development. As the APPtake paper argues, AI-generated code does not change your obligations, but it makes component tracking, GEC-1 and GEC-13 harder to meet. Keep humans in control of architecture, verification and security.
Looking ahead
The Commission’s assessment is the next gate, followed by CEN Enquiry, where national members will comment. Based on Part 1-3, I expect a large volume of comments and a better standard because of them. The target of the publication is October 2027 at the latest. The essential requirements apply from 11 December 2027, so the window between final text and deadline will be short. Manufacturers who start working with the draft catalogue now will be far better placed than those who wait.
Further reading
- CRA standards play different roles – interview with Angelo D’Amato, ITS, 18 June 2026
- AI-Assisted Coding and the Cyber Resilience Act, APPtake instant paper by Angelo D’Amato and Enrico Frumento, July 2026
- prEN 40000-1-3 reaches the pre-Formal Vote HAS assessment, Vulnir, 3 August 2026
Help needed for your compliance journey?
At Vulnir, we help manufacturers put prEN 40000-1-4 into practice: gap analyses against EN 18031 and the Part 1-4 catalogue, risk-based control selection, assessment evidence preparation, and training for product and test teams on the full prEN 40000 series. To learn where your product stands, get in touch.
Get In Touch