CRA Annex I: Essential Cybersecurity Requirements Checklist

Req 1: No known exploitable vulnerabilities at time of market placement

Conduct a thorough vulnerability scan and penetration test before release. Document results in the technical file. Any known CVEs must be resolved or mitigated before the product ships.

Req 2: Secure by default configuration

Products must ship in the most secure configuration possible. Unnecessary services, ports, and features must be disabled by default. Users may relax security settings, but the default state must be secure.

Req 3: Protection against unauthorised access with appropriate access control mechanisms

Implement authentication, authorisation, and access control. Default credentials must be unique per device or require change on first use. Support role-based access where appropriate.

Req 4: Protection of confidentiality of stored, transmitted and processed data

Sensitive data at rest must be encrypted using current cryptographic standards (e.g., AES-256). Data in transit must use TLS 1.2 or higher. Avoid storing sensitive data unnecessarily.

Req 5: Protection of integrity of stored, transmitted and processed data

Use message authentication codes (MACs) or digital signatures to detect tampering. Validate inputs rigorously to prevent injection attacks that could corrupt data integrity.

Req 6: Processing only data, both personal and other, that is necessary for the intended use (data minimisation)

Conduct a data mapping exercise. Only collect and process data strictly required for the product's function. Document retention periods and implement automatic deletion where possible.

Req 7: Protection of availability of essential functions

Design for resilience. Critical functions must degrade gracefully under attack (e.g., DoS). Implement rate limiting, circuit breakers, and failover mechanisms as appropriate.

Req 8: Minimisation of attack surface

Disable unused ports, services, and interfaces. Remove debugging and test interfaces before release. Follow least-privilege principles for all internal components and dependencies.

Req 9: Ability to limit impact of exploitation via mechanisms for resilience and mitigation

Implement security compartmentalisation so that compromise of one component does not cascade. Use sandboxing, memory-safe languages or mitigations (ASLR, stack canaries, DEP/NX), and privilege separation.

Req 10: Ability to log and monitor for security-relevant events

Products must support security logging. Logs should capture authentication events, configuration changes, and security-relevant errors. Provide documentation on how to enable and retain logs.

Req 11: No vulnerabilities caused by unsupported third-party components

Maintain a complete SBOM. Track the support status of all third-party components. Replace or patch components that reach end-of-life before or during the product's supported lifetime.

Req 12: Identify and document product vulnerabilities — maintain an SBOM

Produce a machine-readable SBOM in SPDX or CycloneDX format covering all components and their versions. Update it on every release. Make it available to customers and market surveillance authorities on request.

Req 13: Address and remediate vulnerabilities without undue delay — including providing security updates

Establish a vulnerability management process with defined SLAs. Critical vulnerabilities (CVSS ≥9.0 or actively exploited) should be patched within days, not weeks. Document the remediation timeline in the technical file.

Req 14: Apply a coordinated vulnerability disclosure (CVD) policy

Publish a CVD policy and a publicly accessible reporting channel (email or web form). The policy should define acknowledgement timelines (typically 5 business days), investigation periods, and coordination with ENISA and national CSIRTs when required.

Req 15: Share information about vulnerabilities — CVE identifiers and CSAF advisories

Request CVE identifiers for vulnerabilities you discover or that are reported to you. Publish CSAF (Common Security Advisory Framework) documents for security advisories so customers can consume them programmatically.

Req 16: Take measures to prevent unauthorised access to vulnerability disclosure processes

Protect CVD intake channels against abuse. Implement authentication where necessary and ensure vulnerability reports are handled confidentially until a fix is available.

Req 17: Provide security updates for at minimum five years after market placement

Define and publish your support period commitment. The minimum is five years from market placement date, or the expected product lifetime if shorter. Communicate end-of-life dates clearly in product documentation.

Req 18: Ensure security updates are distributed in a timely and automatic manner

Provide an automatic update mechanism where technically feasible. Users should receive security updates promptly. Where automatic updates are not appropriate (e.g., industrial systems), document the update deployment process.

Req 19: Notify ENISA of actively exploited vulnerabilities (Article 14)

Report exploited vulnerabilities via the EUVD platform: early warning within 24 hours, detailed report within 72 hours, and a final report once resolved. Notifications also go to the relevant national CSIRT.

Req 20: Inform users about security issues without undue delay

When a vulnerability affecting your product is publicly disclosed or actively exploited, inform your users promptly with actionable mitigation guidance. Maintain a publicly accessible security advisory page.

Req 21: Ensure third-party components are maintained and do not introduce vulnerabilities

Continuously monitor the vulnerability status of all SBOM components. Use automated scanning integrated into CI/CD pipelines. Have a documented process for evaluating and integrating upstream security patches.