{"regulation":"CRA","regulationName":"EU Cyber Resilience Act","packVersion":"0.4.0","legalBasis":"Regulation (EU) 2024/2847","source":"https://eur-lex.europa.eu/eli/reg/2024/2847","implementingRegulation":{"ref":"Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025","date":"2025-11-28","eli":"http://data.europa.eu/eli/reg_impl/2025/2392/oj","note":"Binding technical descriptions of the Annex III (Class I/II) and Annex IV categories, adopted under Art. 7(4); in force since 21 December 2025. Decision-tree item scoping follows its Annex I/II descriptions."},"guidance":{"ref":"C(2026) 5252","date":"2026-07-27","title":"Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)","url":"https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation","note":"C(2026) 5252 approves the CONTENT of a draft Communication; the guidance is formally adopted only once all language versions are available. Paragraph references may shift in the adopted text — verify before relying on them. It does not change the application dates: Chapter IV from 11 June 2026, Article 14 reporting from 11 September 2026, full application from 11 December 2027."},"status":"draft","notes":"Annex I Part I requirements lettered against the final OJ text (2)(a)-(m) and displayed in official order; requirement ids (I.2, I.3a-k, I.3m) are STABLE internal keys kept for data compatibility and intentionally do not mirror the official letters — legalRef is authoritative. Annex III/IV category item strings are verbatim from the OJ, omitting only footnote markers and institutional citation tails ('of the European Parliament and of the Council'). Category scoping notes come from Implementing Regulation (EU) 2025/2392. naAllowed marks the requirements for which Art. 13(3) permits a documented non-applicability determination (Annex I Part I(2) only). Version every assessment against packVersion.","documents":["technical-file-annex-vii","eu-doc-annex-v","simplified-doc-annex-vi","annex-ii-user-information","risk-assessment-record"],"riskAssessment":{"legalRef":"Article 13(2)-(4),(7)","mandatory":true,"note":"Foundational. Must be documented, included in the technical file, updated over the support period, and used to decide the applicability of the Annex I Part I(2) requirements (justify any marked not applicable, Art. 13(4)). For Part II, the risk assessment informs HOW the requirements are applied — it cannot disapply them (Art. 13(3)).","fields":[{"id":"purpose","label":"Intended purpose","ref":"Art. 3(23)"},{"id":"foreseeable","label":"Reasonably foreseeable use & misuse","ref":"Art. 3(24)-(25)"},{"id":"opEnv","label":"Conditions of use / operational environment","ref":"Art. 13(3)"},{"id":"assets","label":"Assets to be protected","ref":"Art. 13(3)"},{"id":"useTime","label":"Expected time in use","ref":"Art. 13(3),(8)"},{"id":"risks","label":"Threats & risk analysis","ref":"Art. 13(2)"}]},"sections":[{"id":"annexI-partI","title":"Annex I Part I — Product security properties","requirements":[{"id":"I.1","legalRef":"Annex I Part I(1)","type":"product","naAllowed":false,"title":"Appropriate cybersecurity based on risk","explanation":"Design, develop and produce the product to ensure an appropriate level of cybersecurity based on the risks, as informed by your risk assessment.","howToSatisfy":"Show your security measures trace to the risks identified in the risk assessment."},{"id":"I.2","legalRef":"Annex I Part I(2)(a)","type":"product","naAllowed":true,"title":"No known exploitable vulnerabilities at delivery","explanation":"Make the product available on the market without known exploitable vulnerabilities. Art. 3(41) defines an exploitable vulnerability as one an adversary could effectively use under practical operational conditions, so a finding that only reproduces in a lab or simulation does not automatically count. A vulnerability should be regarded as known once it is listed in a public vulnerability database such as the European vulnerability database (Art. 12(2) of Directive (EU) 2022/2555); it may also be known once you learn of it privately through coordinated disclosure or your own testing, or once it is prominently reported in reliable media (guidance §9.2.2 paras 233-234).","howToSatisfy":"Screen components before release: the built-in scan queries OSV, which aggregates CVE, GHSA and ecosystem feeds; also monitor the European vulnerability database (EUVD) and vendor advisories. Remediate or justify anything open. Record when you learned of each finding and what your investigation concluded: a report alone does not establish that a vulnerability is exploitable or applicable to your product, and a limited period may pass while you confirm it (guidance C(2026) 5252 s.9.2.2)."},{"id":"I.3a","legalRef":"Annex I Part I(2)(b)","type":"product","naAllowed":true,"title":"Secure-by-default & resettable","explanation":"Make the product available with a secure by default configuration — unless otherwise agreed between manufacturer and business user for a tailor-made product — including the possibility to reset the product to its original state.","howToSatisfy":"Hardened defaults; documented factory reset; record any tailor-made agreement that varies the defaults."},{"id":"I.3k","legalRef":"Annex I Part I(2)(c)","type":"product","naAllowed":true,"title":"Addressable via security updates","explanation":"Ensure vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates installed within an appropriate timeframe and 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.","howToSatisfy":"Secure update mechanism; automatic updates on by default with opt-out where applicable; notify users and allow postponement.","limbs":[{"id":"update-capability","label":"Vulnerabilities can be addressed through security updates","naAllowed":false,"note":"The capability itself is unconditional — a product that cannot be updated cannot meet point (c)."},{"id":"automatic-updates","label":"Automatic security updates, enabled by default","naAllowed":true,"note":"The CRA qualifies this limb with \\u201cwhere applicable\\u201d and recital 46 recognises that automatic installation may be inappropriate where an update could disrupt a safety-relevant or continuously operating installation. A machine controller whose operator schedules maintenance windows is the standard example. Record the reason here; it prints into the technical file."},{"id":"opt-out","label":"A clear and easy-to-use opt-out from automatic updates","naAllowed":true,"note":"Only meaningful where automatic updates apply."},{"id":"user-notification","label":"Users are notified about available updates and can postpone them","naAllowed":true,"note":"Where updates are installed by an operator rather than pushed, describe how that operator is told."}]},{"id":"I.3b","legalRef":"Annex I Part I(2)(d)","type":"product","naAllowed":true,"title":"Access control / authentication","explanation":"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.","howToSatisfy":"Enforce authentication; no blank/shared defaults; document the mechanisms and how unauthorised-access attempts are reported."},{"id":"I.3c","legalRef":"Annex I Part I(2)(e)","type":"product","naAllowed":true,"title":"Confidentiality (encryption)","explanation":"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.","howToSatisfy":"Encrypt sensitive data at rest and in transit; record the algorithms."},{"id":"I.3d","legalRef":"Annex I Part I(2)(f)","type":"product","naAllowed":true,"title":"Integrity & corruption reporting","explanation":"Protect the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions.","howToSatisfy":"Signing/checksums/secure boot; tamper detection and reporting."},{"id":"I.3e","legalRef":"Annex I Part I(2)(g)","type":"product","naAllowed":true,"title":"Data minimisation","explanation":"Process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose.","howToSatisfy":"Document what data is processed and why; remove the unnecessary."},{"id":"I.3f","legalRef":"Annex I Part I(2)(h)","type":"product","naAllowed":true,"title":"Availability & DoS resilience","explanation":"Protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks.","howToSatisfy":"Rate-limiting, watchdogs, failover; document DoS mitigations and post-incident recovery."},{"id":"I.3g","legalRef":"Annex I Part I(2)(i)","type":"product","naAllowed":true,"title":"Minimise impact on other devices/networks","explanation":"Minimise the negative impact by the product itself or connected devices on the availability of services provided by other devices or networks.","howToSatisfy":"Prevent the product being abused to attack others; egress controls."},{"id":"I.3h","legalRef":"Annex I Part I(2)(j)","type":"product","naAllowed":true,"title":"Limit attack surface","explanation":"Design, develop and produce the product to limit attack surfaces, including external interfaces.","howToSatisfy":"Disable unused ports/services; document exposed interfaces."},{"id":"I.3i","legalRef":"Annex I Part I(2)(k)","type":"product","naAllowed":true,"title":"Exploitation mitigation","explanation":"Design, develop and produce the product to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques.","howToSatisfy":"Memory protections, sandboxing, least privilege; document techniques."},{"id":"I.3j","legalRef":"Annex I Part I(2)(l)","type":"product","naAllowed":true,"title":"Security logging / monitoring (user opt-out)","explanation":"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.","howToSatisfy":"Security event logging with access records; document what is logged and how the user can opt out.","limbs":[{"id":"logging","label":"Security-relevant internal activity is recorded and monitored","naAllowed":false,"note":"The recording duty itself is unconditional for this point."},{"id":"log-opt-out","label":"The user can opt out of the monitoring","naAllowed":true,"note":"Annex I Part I(2)(l) attaches the opt-out to the monitoring it describes; where no user-identifiable activity is recorded, say so here."}]},{"id":"I.3m","legalRef":"Annex I Part I(2)(m)","type":"product","naAllowed":true,"title":"Secure permanent data removal & transfer","explanation":"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.","howToSatisfy":"A wipe/factory-reset that genuinely erases user data and settings; where you offer data transfer or migration, make it secure and document it.","limbs":[{"id":"secure-erase","label":"Users can permanently and securely remove all data and settings","naAllowed":false,"note":"Unconditional for this point."},{"id":"secure-transfer","label":"Where data can be transferred to another product or system, that transfer is secure","naAllowed":true,"note":"Qualified by \\u201cwhere such data can be transferred\\u201d. If your product offers no migration or export path, record that here rather than marking the whole point not applicable."}]}]},{"id":"annexI-partII","title":"Annex I Part II — Vulnerability handling","requirements":[{"id":"II.1","legalRef":"Annex I Part II(1)","type":"process","naAllowed":false,"title":"SBOM & vulnerability identification","explanation":"Identify and document vulnerabilities and components, including a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies.","howToSatisfy":"Generate a CycloneDX/SPDX SBOM in CI; keep it current per version."},{"id":"II.2","legalRef":"Annex I Part II(2)","type":"process","naAllowed":false,"title":"Remediate without delay; ship security fixes separately","explanation":"In relation to the risks posed to the product, address and remediate vulnerabilities without delay, including by providing security updates. Where technically feasible, new security updates must be provided separately from functionality updates.","howToSatisfy":"Documented triage-to-fix-to-release process with timelines; decouple security patches from feature releases where technically feasible."},{"id":"II.3","legalRef":"Annex I Part II(3)","type":"process","naAllowed":false,"title":"Regular security testing","explanation":"Apply effective and regular tests and reviews of the security of the product.","howToSatisfy":"Pen tests / SAST / DAST on a schedule; keep the reports as evidence."},{"id":"II.4","legalRef":"Annex I Part II(4)","type":"process","naAllowed":false,"title":"Disclose fixed vulnerabilities","explanation":"Once a security update is available, share and publicly disclose information about fixed vulnerabilities (description, affected products, impact, severity, remediation help). In duly justified cases, where you consider the security risks of publication to outweigh the benefits, you may delay publication until users have been given the possibility to apply the patch.","howToSatisfy":"Publish security advisories (e.g. CSAF) when you ship fixes; document any justified publication delay."},{"id":"II.5","legalRef":"Annex I Part II(5)","type":"process","naAllowed":false,"title":"Coordinated vulnerability disclosure policy","explanation":"Put in place and enforce a coordinated vulnerability disclosure (CVD) policy.","howToSatisfy":"Publish a CVD/security policy and a security.txt with the single point of contact."},{"id":"II.6","legalRef":"Annex I Part II(6)","type":"process","naAllowed":false,"title":"Facilitate info-sharing & reporting contact","explanation":"Take measures to facilitate the sharing of information about potential vulnerabilities in the product and in third-party components it contains, including a contact address for reporting vulnerabilities discovered in the product.","howToSatisfy":"Monitored security contact; process for inbound reports and third-party components."},{"id":"II.7","legalRef":"Annex I Part II(7)","type":"process","naAllowed":false,"title":"Secure update distribution","explanation":"Provide for mechanisms to securely distribute updates to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner.","howToSatisfy":"Signed updates over secure channels; on-device integrity verification; automatic distribution where applicable."},{"id":"II.8","legalRef":"Annex I Part II(8)","type":"process","naAllowed":false,"title":"Free & timely patches with advisories","explanation":"Where security updates are available, disseminate them without delay and — unless otherwise agreed between manufacturer and business user for a tailor-made product — free of charge, accompanied by advisory messages giving users the relevant information, including on potential action to be taken.","howToSatisfy":"Patches free and prompt; advisory tells users what action to take; record any tailor-made agreement."}]},{"id":"process-obligations","title":"Process & lifecycle obligations (Articles 13 & 14)","requirements":[{"id":"P.1","legalRef":"Article 13(5)-(6)","type":"process","naAllowed":false,"title":"Third-party & open-source component due diligence","explanation":"Exercise due diligence on integrated third-party components (incl. FOSS); on finding a component vulnerability, report it upstream to the maintainer and share fixes.","howToSatisfy":"Track component provenance; monitor upstream advisories; have an upstream-reporting process."},{"id":"P.2","legalRef":"Article 13(8)","type":"process","naAllowed":false,"title":"Vulnerability handling for the whole support period","explanation":"Handle vulnerabilities effectively for the entire support period (at least 5 years, or expected use time if shorter).","howToSatisfy":"Resourced process that runs for the full support period, not just at launch."},{"id":"P.3","legalRef":"Article 13(9)","type":"process","naAllowed":false,"title":"Security-update availability retention","explanation":"Keep each issued security update available for at least 10 years or the remainder of the support period, whichever is longer.","howToSatisfy":"Archive/host updates for the required retention."},{"id":"P.4","legalRef":"Article 14","type":"process","naAllowed":false,"title":"Reporting of actively exploited vulnerabilities & severe incidents","explanation":"Report to the CSIRT coordinator and ENISA via the Single Reporting Platform. Actively exploited vulnerabilities: 24h early warning, 72h notification, final report no later than 14 days after a corrective or mitigating measure is available. Severe incidents: 24h early warning, 72h notification, final report within 1 month of the incident notification. Inform impacted users. Binds every manufacturer from 11 September 2026, including for products placed on the market before 11 December 2027 (Art. 69(3)) — it cannot be disapplied by a risk-assessment justification.","howToSatisfy":"Have the process, owner and templates ready before September 2026. ENISA schedules the Single Reporting Platform to be operational by 11 September 2026 — verify current status."},{"id":"P.5","legalRef":"Article 13(19)","type":"process","naAllowed":false,"title":"Support-period end date disclosed, expiry notified","explanation":"State the end date of the support period at the time of purchase, clearly and understandably, giving at least the month and year. Once the support period expires, show users a notification where that is technically feasible given the nature of the product.","howToSatisfy":"Show the support end date in the purchase flow, on the product page or on packaging, and carry the same date into the Annex II user information. Add an in-product or update-channel notice at expiry, or record why that is not technically feasible for this product."},{"id":"P.6","legalRef":"Articles 29–30","type":"process","naAllowed":false,"title":"CE marking affixed correctly","explanation":"Affix the CE marking visibly, legibly and indelibly to the product with digital elements. Where that is not possible or not warranted by the product's nature, put it on the packaging and the accompanying documentation. For a product made available in a form other than physical — software — the marking goes on the EU declaration of conformity or on the website accompanying the product. Where a notified body is involved in the production control phase, its identification number follows the CE marking.","howToSatisfy":"Point at where the marking is actually affixed: the device or its data plate, the packaging and documentation, or — for software — the declaration of conformity and the download or product page. Check the marking's proportions and legibility against the general principles of Article 30 of Regulation (EC) No 765/2008, and record the notified body number placement if one is involved. The marking may only be affixed once the declaration of conformity can honestly be signed — it is the last step, not a design element."}]}],"categories":[{"id":"default","label":"Default","route":"self-assessment","module":"A","verdict":"You can self-assess: the internal control procedure (Module A, Annex VIII Part I) is always available for default-category products (Art. 32(1)).","note":"Any product with digital elements not listed in Annex III or IV."},{"id":"important-1","label":"Important — Annex III, Class I","route":"conditional","module":"A only with standards; else B+C, H, or certification scheme","verdict":"Self-assessment (Module A) is available only where you apply, in full, relevant harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least 'substantial', covering at least the risks of the product's core functionality (Art. 32(2); guidance §6.2). No CRA harmonised standard is cited in the Official Journal yet (as of August 2026 — verify current status), so today the route is Module B+C, Module H or, where available and applicable, such a certification scheme. Products qualifying as free and open-source software may instead use Module A with publicly available technical documentation (Art. 32(5)).","items":["Identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers","Standalone and embedded browsers","Password managers","Software that searches for, removes, or quarantines malicious software","Products with digital elements with the function of virtual private network (VPN)","Network management systems","Security information and event management (SIEM) systems","Boot managers","Public key infrastructure and digital certificate issuance software","Physical and virtual network interfaces","Operating systems","Routers, modems intended for the connection to the internet, and switches","Microprocessors with security-related functionalities","Microcontrollers with security-related functionalities","Application specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) with security-related functionalities","Smart home general purpose virtual assistants","Smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems","Internet connected toys covered by Directive 2009/48/EC that have social interactive features (e.g. speaking or filming) or that have location tracking features","Personal wearable products to be worn or placed on a human body that have a health monitoring (such as tracking) purpose and to which Regulation (EU) 2017/745 or (EU) No 2017/746 do not apply, or personal wearable products that are intended for the use by and for children"]},{"id":"important-2","label":"Important — Annex III, Class II","route":"third-party","module":"B+C, H, or certification scheme (≥ substantial)","verdict":"Third-party conformity assessment is mandatory (Art. 32(3)): EU-type examination plus conformity to type (Module B+C), full quality assurance (Module H), or — where available and applicable — a European cybersecurity certification scheme pursuant to Art. 27(9) at assurance level at least 'substantial'. Products qualifying as free and open-source software may instead use Module A with publicly available technical documentation (Art. 32(5)). Note: no notified bodies are designated under the CRA yet (as of August 2026 — verify current status and plan lead time).","items":["Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments","Firewalls, intrusion detection and prevention systems","Tamper-resistant microprocessors","Tamper-resistant microcontrollers"]},{"id":"critical","label":"Critical — Annex IV","route":"certification-or-third-party","module":"Certification per Art. 8(1) delegated act; until then B+C, H, or scheme (≥ substantial)","verdict":"A delegated act under Art. 8(1) may in future require a European cybersecurity certificate (e.g. under the EUCC scheme) at a set assurance level. No such delegated act has been adopted (as of August 2026 — verify current status), so Annex IV products are currently subject to the Article 32(3) procedures: Module B+C, Module H or, where available and applicable, a European cybersecurity certification scheme at assurance level at least 'substantial' (Art. 8(1); Art. 32(4)).","items":["Hardware Devices with Security Boxes","Smart meter gateways within smart metering systems as defined in Article 2, point (23) of Directive (EU) 2019/944 and other devices for advanced security purposes, including for secure cryptoprocessing","Smartcards or similar devices, including secure elements"]}],"changelog":{"note":"One entry per released pack version, newest first. `changed` and `added` list requirement ids whose text or obligations moved — the in-app review queue uses them to tell a user assessed under an older pack exactly which answers to re-read.","versions":[{"version":"0.4.0","date":"2026-08-30","added":["P.6"],"changed":["I.3j","I.3k","I.3m"],"summary":"Adds CE marking (Articles 29–30) as requirement P.6 — trivially satisfied, previously absent, and an assessor checks it first. Records limb-level applicability added to points (2)(c), (2)(l) and (2)(m) since 0.3.0, and introduces this changelog."},{"version":"0.3.0","date":"2026-07-31","added":["I.3m"],"changed":["I.1","I.2","I.3a","I.3b","I.3c","I.3d","I.3e","I.3f","I.3g","I.3h","I.3i","I.3j","I.3k","II.1","II.2","II.3","II.4","II.5","II.6","II.7","II.8","P.1","P.2","P.3","P.4","P.5"],"summary":"Aligns the whole pack with the Official Journal text and Implementing Regulation (EU) 2025/2392: nearly every requirement's wording was revised against the adopted text, secure data erasure (point (2)(m)) was added as I.3m, and the decision tree carries the final Annex III/IV category lists. Assessments made under 0.2.0 should re-read every answer."},{"version":"0.2.0","date":"2026-07-27","added":["P.5"],"changed":["I.2"],"summary":"Aligns with Commission guidance C(2026) 5252: adds the Art. 13(19) support-period disclosure duty as P.5 and revises when a vulnerability counts as known under point (2)(a)."},{"version":"0.1.0","date":"2026-07-16","added":[],"changed":[],"summary":"Initial pack: 25 requirements across Annex I Parts I and II and the Article 13/14 process obligations, with citations to the adopted regulation."}]}}