01Secure design and defaults
Essential requirements of Annex I Part I, 12 items (paraphrased).
1. Risk assessmentWas the security requirement set from a cybersecurity risk assessment when designing the product?
2. No known exploitable vulnerabilities at releaseBefore launch, did you scan for and address known exploitable vulnerabilities?
3. Secure default configurationIs the factory configuration secure, and can the product be reset to its original state?
4. Security update mechanismIs there a security update mechanism, with automatic updates on by default (opt-out for users) and notification of available updates?
5. Authentication and access controlDo you have authentication and identity and access management that prevents unauthorised access and can report likely unauthorised access?
6. Data confidentialityIs sensitive data encrypted at rest and in transit?
7. Data and code integrityAre data, commands, programs and configuration protected from unauthorised modification, for example firmware signing and secure boot?
8. Data minimisationDo you collect and process only the data necessary for the product to work?
9. Availability of key functionsDo essential functions keep working under attack, such as denial of service?
10. Reduced attack surfaceHave unnecessary external interfaces and services been closed, such as debug ports and open ports?
11. Security logging and monitoringDo you record security-relevant internal activity, with an opt-out for the user?
12. Data removal and transferCan users securely and easily erase all data and settings, and transfer data to another product securely?
02Vulnerability handling
Annex I Part II vulnerability-handling requirements plus the support period, 9 items (paraphrased).
13. Component inventory (SBOM)Do you maintain a list of components including third-party ones, covering at least top-level dependencies, in a machine-readable format?
14. Timely vulnerability fixesAfter finding a vulnerability, can you fix it promptly and provide a security update?
15. Regular security testing and reviewsDo you test and review the product security regularly?
16. Disclosing fixed vulnerabilitiesAfter releasing an update, do you publish the fixed vulnerabilities with description, severity and remediation guidance?
17. Coordinated vulnerability disclosure policyDo you have and enforce a coordinated vulnerability disclosure policy?
18. Vulnerability reporting channelDo you provide a contact so outsiders can report vulnerabilities?
19. Secure update distributionDo you distribute updates securely, for example with signature checks and secure channels?
20. Timely, free updatesAre security updates provided promptly and free of charge, with explanations?
21. Defined and published support periodHave you set a support period (generally at least 5 years unless the product is expected to be used for less) and told users?
Previous: scope and class checkFirst confirm whether the product is in scope and which class it is.CRA overview: timeline, core duties and product classesRead →
This tool paraphrases and simplifies the CRA. It is a preliminary self-check and does not constitute legal advice or a compliance certification. Rely on the regulation text (Regulation (EU) 2024/2847), harmonised standards and your legal adviser.