Annex I essential requirements

Annex I of the Cyber Resilience Act (Regulation (EU) 2024/2847) defines the essential cybersecurity requirements that every product with digital elements must meet before being placed on the EU market. These requirements apply identically to all product categories: Default, Important Class I, Important Class II, and Critical.

What differs by category is how compliance is verified, not what is required. See Conformity assessment for the assessment procedures.

Info: The CRA Profile in your product settings includes an attestation checklist for each requirement below. For Default and Class I products using self-assessment (Module A), these attestations form part of your conformity evidence. For Class II and Critical products, the checklist helps you prepare for the notified body audit.

Part I: security requirements

Part I covers the design, development, and production of the product itself.

1. Risk-based cybersecurity design

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.

What this means in practice:

Conduct a threat model before development starts (STRIDE, PASTA, or equivalent)
Maintain a cybersecurity risk assessment (Annex VII) that reflects the current product version
Design decisions should trace back to identified risks. Document why you chose specific controls.
Security architecture should be proportionate to the risk profile (a smart lightbulb and an industrial PLC have different threat landscapes)

Evidence: risk assessment document, threat model, design review records.

CRA Evidence attestation: Risk-based cybersecurity design

2. Security properties

These requirements address the core security properties of the product during operation.

2.2 Data confidentiality and encryption

Products shall protect the confidentiality of stored, transmitted and otherwise processed data, personal or other, by appropriate means such as encryption of relevant data at rest or in transit.

Encrypt data in transit (TLS 1.2+ for network communications)
Encrypt sensitive data at rest (user credentials, PII, configuration secrets)
Use well-established cryptographic algorithms (no custom cryptography)
Key management: keys should be stored separately from the data they protect

Evidence: architecture documentation showing encryption points, cipher suite configuration, key management procedures.

CRA Evidence attestation: Data confidentiality / encryption

2.3 Data integrity

Products shall protect the integrity of stored, transmitted and otherwise processed data against unauthorised manipulation or modification, and shall report on corruptions.

Validate data integrity on storage and transmission (checksums, digital signatures, MACs)
Detect and report tampering (integrity monitoring, audit logs)
Protect configuration data from unauthorised modification

Evidence: integrity verification mechanisms documented in technical file.

CRA Evidence attestation: Data integrity protection

2.4 Data minimisation

Products shall 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.

Collect only the data the product needs to function
Do not enable telemetry or analytics collection by default unless required for core functionality
Provide users with the ability to limit data processing where feasible
Apply data retention limits. Do not store data indefinitely without justification.

Evidence: data flow diagram, privacy impact assessment, default configuration documentation.

CRA Evidence attestation: Data minimisation

2.5 Availability

Products shall be designed and developed so that their availability and the availability of their essential functions is resilient against denial-of-service attacks.

Implement rate limiting and input validation to resist resource exhaustion
Design for graceful degradation under load
Essential safety functions should remain available even during a denial-of-service condition

Evidence: resilience testing results, architecture documentation for high-availability features.

CRA Evidence attestation: Availability measures

2.6 Service availability

Products shall minimise the negative impact on the availability of services provided by other devices or networks.

Products should not consume excessive network bandwidth, processing power, or storage on connected systems
Implement proper resource management (connection pooling, backoff strategies)
Compromised products should not be usable as a platform for attacking other devices

Evidence: network behaviour documentation, resource usage analysis.

CRA Evidence attestation: Service availability

2.7 Attack surface minimisation

Products shall be designed, developed and produced to limit attack surfaces, including external interfaces, to the minimum necessary for the intended purpose.

Disable unnecessary services, ports, and protocols by default
Remove debug interfaces, test accounts, and development endpoints from production builds
Apply the principle of least privilege to all components
Reduce the number of exposed network interfaces to what is required

Evidence: port/service inventory, hardening checklist, penetration test results.

CRA Evidence attestation: Attack surface minimisation

2.8 Security mitigations

Products shall be designed, developed and produced in such a way as to mitigate the impact of an incident affecting the security of the product.

Implement security monitoring and logging to detect incidents
Design containment boundaries. A compromised component should not give access to the entire system.
Support incident response: provide mechanisms for forensic analysis, isolation, and recovery

Evidence: incident response architecture, security monitoring design, compartmentalisation documentation.

CRA Evidence attestation: Security mitigations

2.9 Logging

Products shall provide for recording and monitoring of relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user.

Log security-relevant events: authentication attempts, configuration changes, access to sensitive data, firmware updates
Logs should include timestamps, source identification, and event description
Provide users with the ability to opt out of logging where feasible (balancing security needs with privacy)
Protect log integrity. Logs should not be modifiable by the product user in a way that conceals security events.

Evidence: logging specification, sample log output, log protection mechanisms.

CRA Evidence attestation: Logging capability

2.10 Security updates

Products shall ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates, and enable the notification of available updates to users.

Implement a secure update mechanism (see Update mechanism documentation)
Security updates must be delivered separately from feature updates where feasible
Users must be notified when security updates are available
Security updates must be free of charge for the entire support period

Evidence: update mechanism documentation, update delivery architecture, notification mechanism.

CRA Evidence attestation: Security updates ensured

3. Identity and access management

3.1 Credential protection

Products shall protect stored and transmitted credentials through appropriate mechanisms.

Never store passwords in plaintext. Use strong hashing (argon2id, bcrypt, scrypt).
Protect credentials in transit with encryption
Do not ship with default passwords. Require users to set credentials during initial setup.
Support credential rotation without requiring product reinstallation

Evidence: authentication architecture, credential storage documentation, default configuration audit.

CRA Evidence attestation: Credential protection

3.2 Hardware credential management

Where the product includes hardware elements, products shall provide protection for credential storage through hardware mechanisms such as secure elements.

For hardware products: use secure elements (TPM, secure enclave, HSM) for credential storage where available
Protect hardware-stored keys against physical extraction
Support secure provisioning of hardware-bound credentials

Note: This requirement applies to products with hardware elements. CRA Evidence automatically marks this as N/A for software-only products.

Evidence: hardware security module integration documentation, secure boot chain documentation.

CRA Evidence attestation: Hardware credential management

3.3 Access control

Products shall implement appropriate access control mechanisms to ensure that only authorised entities can access or modify data, services or functions.

Implement role-based or attribute-based access control
Enforce the principle of least privilege
Authenticate all access to administrative functions
Support multi-factor authentication where appropriate for the product type

Evidence: access control matrix, authentication mechanism documentation.

CRA Evidence attestation: Access control mechanisms

3.4 Unauthorised access protection

Products shall protect against unauthorised access to their functions and data.

Implement brute-force protection (account lockout, rate limiting, CAPTCHA)
Protect against common attack vectors (injection, authentication bypass, privilege escalation)
Ensure physical interfaces (USB, JTAG, serial) are protected or disabled in production

Evidence: penetration test results, vulnerability scan results, hardening documentation.

CRA Evidence attestation: Unauthorised access protection

3.5 Security event notification

Products shall notify the user of security-relevant events and provide the capability to log such events.

Alert users about security events: failed login attempts, configuration changes, firmware update status, detected anomalies
Notifications should be actionable: tell the user what happened and what to do
Support integration with external monitoring systems (syslog, SIEM) where appropriate

Evidence: notification specification, sample alerts, monitoring integration documentation.

CRA Evidence attestation: Security event notification

4. Vulnerability handling and updates

4.1 Secure update mechanism

Products shall be capable of being updated securely, and the update mechanism shall be designed to prevent the installation of unauthorised or tampered updates.

Sign update packages with a cryptographic key controlled by the manufacturer
Verify signatures before applying updates: reject unsigned or incorrectly signed packages
Protect the update channel (HTTPS minimum, certificate pinning recommended)
Support rollback to a known-good state if an update fails

Evidence: update mechanism architecture, code signing process, update verification documentation.

CRA Evidence attestation: Secure update mechanism

4.2 Automatic updates

Products shall, by default, provide for automatic security updates, and allow the user to opt out of automatic updates.

Enable automatic security updates by default
Allow users to disable automatic updates (the CRA requires this user choice)
Clearly separate security updates from feature updates where technically feasible
Ensure updates do not require user interaction for security-critical patches (unless the user has opted out)

Evidence: default update configuration, opt-out mechanism documentation.

CRA Evidence attestation: Automatic updates capability

4.3 Vulnerability information sharing

Products shall facilitate the sharing of information about vulnerabilities, including a public point of contact for reporting.

Publish a security.txt file at /.well-known/security.txt (RFC 9116)
Maintain a public vulnerability disclosure policy (see CVD policy)
Publish security advisories for fixed vulnerabilities with CVE IDs where applicable
Provide SBOM access to enable downstream vulnerability tracking

Evidence: published security.txt, CVD policy URL, security advisory archive, SBOM availability.

CRA Evidence attestation: Vulnerability information sharing

Part II: vulnerability handling obligations

Part II of Annex I covers the manufacturer's ongoing obligations for vulnerability management during the support period. These are tracked separately in CRA Evidence through:

Vulnerability handling policy. Your documented procedures.
Version-level vulnerability scanning. Automated detection via SBOM analysis.
ENISA notification workflows. For actively exploited vulnerabilities.

Part II requirements include:

Identifying and documenting vulnerabilities (including in third-party components)
Addressing vulnerabilities without undue delay through security updates
Applying regular testing and review of security
Publishing information about fixed vulnerabilities
Facilitating vulnerability reporting (CVD policy, security.txt)
Distributing security updates without delay, free of charge
Providing the SBOM in a machine-readable format
Notifying ENISA of actively exploited vulnerabilities within 24 hours

For ENISA notification timelines and procedures, see ENISA notifications.

How assessment differs by category

The requirements above are identical for all product categories. The difference is in who evaluates compliance:

Category	Who assesses	What the checklist means for you
Default	You (self-assessment, Module A)	Your attestations are the primary compliance evidence. Document thoroughly.
Important Class I	You (if harmonised standards applied) or notified body	If self-assessing, same as Default. If using a notified body, the checklist helps you prepare.
Important Class II	Notified body (Module B+C or H)	The notified body verifies each requirement. Use the checklist to prepare your technical documentation.
Critical	Notified body (Module B+C or H)	Same as Class II. The checklist is your preparation tracker for the audit.

For details on each assessment procedure, see Conformity assessment.

Official sources

Last updated April 21, 2026

Was this page helpful?

Thanks for your feedback!

Help us improve. What was missing or unclear?