Product security (Annex I, Part I)
The overarching requirement
Products with digital elements are designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.
Everything else follows. “Appropriate based on the risks” means the reference is not a universal catalogue of measures but your documented risk assessment.
The requirements, one by one
No known exploitable vulnerabilities
The product is made available without known exploitable vulnerabilities. That requires a blocking gate at the end of the build chain, fed by the SBOM and by vulnerability sources — see CI/CD integration.
Secure by default configuration
The product ships in a secure by default configuration, with the ability to reset it to its original state. Concretely: no shared default passwords, no service exposed without need, no active maintenance account.
Remediation through security updates
Vulnerabilities can be addressed through security updates, including, where appropriate, automatic updates enabled by default, with a clear opt-out mechanism, notification of available updates and the ability to defer them.
Protection from unauthorised access
Protection through appropriate control mechanisms — authentication, identity and access management — and reporting of unauthorised access.
Confidentiality
Protection of the confidentiality of data stored, transmitted or processed, through encryption at rest and in transit using state-of-the-art mechanisms.
Integrity
Protection of the integrity of data, commands, programs and configuration against any unauthorised manipulation or modification, and reporting of corruption.
Data minimisation
Processing only data that is adequate, relevant and limited to what is necessary in relation to the product’s intended purpose. A mirror of the GDPR requirement, but here independent of whether the data is personal.
Availability of essential functions
Protection of the availability of essential and basic functions, including resilience against and mitigation of denial-of-service attacks.
Not harming other systems
Minimising the negative impact of the product on the availability of services provided by other devices or networks — a product must not become an attack relay.
Limiting attack surfaces
Limiting attack surfaces, including external interfaces: services disabled, ports closed, debug functions removed from production builds.
Reducing incident impact
Use of appropriate exploitation mitigation mechanisms and techniques: compartmentalisation, least privilege, binary hardening, memory protections.
Logging and monitoring
Providing security-related information by recording and monitoring relevant internal activity, including access to and modification of data, services and functions, with the ability for the user to opt out.
Secure erasure and portability
The ability for users to securely and permanently remove all data and settings and, where such data can be transferred to other products or systems, to do so securely.
What makes these requirements verifiable
None of these requirements is verifiable as written. Each must be turned into a test criterion:
| Requirement | Typical test criterion |
|---|---|
| No known exploitable vulnerabilities | Blocking software composition analysis, defined threshold, VEX for exceptions |
| Secure default configuration | Hardening baseline, install test from factory state |
| Encryption | Inventory of flows and stores, verification of cipher suites |
| Integrity | Signature verification at boot and at update, rollback test |
| Attack surface | Map of ports and interfaces, delta against the specification |
| Logging | Presence of expected events, opt-out test |
| Erasure | Reset test, verification of non-recoverability |
That table is the entry point to the traceability matrix described in Essential requirements.
Reference frameworks
Pending harmonised standards, several frameworks cover a large share of these requirements and yield reusable evidence: IEC 62443-4-1 (secure development process) and 62443-4-2 (technical component requirements), NIST SP 800-218 (Secure Software Development Framework), ETSI EN 303 645 (consumer IoT), EN 18031-1/-2/-3 (radio equipment), ISO/IEC 27001.
Careful: applying these frameworks confers no presumption of conformity under the Regulation until they are harmonised standards cited in the Official Journal. They make the demonstration easier; they do not replace it.