What is Annex I Part I?
Annex I Part I of the Cyber Resilience Act defines the essential product security requirements—the technical properties your product must have to be compliant. These requirements focus on how the product is designed, built, and configured.
Key Facts
- 14 core requirements (1 design principle + 13 lettered properties) covering security design and implementation
- Risk-based approach: Requirements apply based on product risk level
- Applies to all product categories: Default, Class I, Class II, Critical
- Must be met at time of market placement
Together with Annex I Part II (vulnerability handling), these requirements form the complete security baseline for CRA compliance.
All Part I Requirements
Below are all 14 requirements from Annex I Part I (1 design principle + 13 lettered properties), with plain English explanations:
Risk-Based Security Design
Official Text:
"Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks."
Plain English:
Build security into your product from day one. The level of protection should match the potential harm if something goes wrong—higher-risk products need stronger security.
Engineering Actions:
- Conduct threat modeling during design phase
- Perform cybersecurity risk assessment
- Document security requirements based on risks
- Implement secure development lifecycle (SDLC)
Security Properties (13 Sub-requirements)
Official Text:
"On the basis of the cybersecurity risk assessment referred to in Article 13(2), and where applicable, products with digital elements shall..."
(2)(a) No Known Vulnerabilities
"Be made available on the market without known exploitable vulnerabilities."
Scan for and fix all known vulnerabilities before release. Use CVE databases and automated scanners.
(2)(b) Secure by Default
"Be made available on the market with a secure by default configuration... including the possibility to reset the product to its original state."
Ship with security enabled. No default passwords. Include factory reset capability.
(2)(c) Security Updates
"Ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them."
Build an update mechanism with automatic updates ON by default, an easy opt-out, user notification of available updates, and the ability to postpone them.
(2)(d) Access Control
"Ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access."
Implement proper authentication and identity/access management, and be able to report on unauthorised access attempts.
(2)(e) Confidentiality
"Protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means."
Encrypt sensitive data in transit (TLS) and at rest using current best-practice mechanisms.
(2)(f) Integrity
"Protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions."
Prevent unauthorised tampering with stored/transmitted data, commands, programs, and configuration, and detect and report corruption.
(2)(g) Data Minimisation
"Process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation)."
Collect only what you need. Don't hoard user data unnecessarily.
(2)(h) Availability & Resilience
"Protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks."
Design for reliability. Implement rate limiting, failover, and DDoS protection — including recovery after an incident.
(2)(i) Minimise Impact on Other Devices/Networks
"Minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks."
Don't amplify attacks or degrade other devices/networks your product connects to.
(2)(j) Limit Attack Surfaces
"Be designed, developed and produced to limit attack surfaces, including external interfaces."
Disable unused features and ports. Reduce exposed APIs and services.
(2)(k) Incident Impact Mitigation
"Be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques."
Use ASLR, stack canaries, sandboxing. Contain breaches when they happen.
(2)(l) Security Monitoring
"Provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user."
Implement security logging with an opt-out. Record authentication attempts, access events, and modifications to data, services, or functions.
(2)(m) Secure Data Removal
"Provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner."
Provide secure, permanent wipe/factory reset. If data can be exported to another product, that transfer must also happen securely.
When Do These Apply?
Not all requirements apply to every product. Application is risk-based:
Always Apply
- Requirement (1): Risk-based design
- Requirement (2)(a): No known vulnerabilities
- Requirement (2)(b): Secure by default
- Requirement (2)(c): Security updates
Apply "Where Applicable"
- Requirements (2)(d)-(l) based on risk assessment
- More sophisticated products need more requirements
- Document which apply and why
Related CRA Articles
Track Your Compliance Progress
Use our Requirements Explorer to track your implementation of each requirement.