Cyber Resilience Act
CRA compliance checklist: what to prepare, in order
A CRA compliance checklist starts with scope and reporting, because Article 14 already applies from 11 September 2026, and then works through vulnerability handling, security requirements and documentation before the rest of the Cyber Resilience Act applies on 11 December 2027. The list below follows that order.
Free plan, no card required.
1. Scope and roles
Start by deciding which of your products are products with digital elements and which role you play for each: manufacturer, importer or distributor. The answer drives everything else.
- List every product and version you make available in the EU, including software sold on its own.
- Record your role for each product: manufacturer, importer, distributor or open-source steward.
- Check whether any product falls in the important (Annex III) or critical (Annex IV) categories.
- Note products covered by excluded sector rules, such as medical devices or motor vehicles.
2. Reporting, already in force
Article 14 applies from 11 September 2026 and covers products already on the market. This part cannot wait.
- Identify the CSIRT designated as coordinator for your main establishment.
- Get access to ENISA's single reporting platform.
- Name the people who decide that a vulnerability is actively exploited, with deputies.
- Prepare templates for the 24-hour early warning, the 72-hour notification and the final report.
- Decide how you will inform affected users, preferably in a machine-readable format.
3. Know what is in your product
You cannot report on, or fix, a component you do not know you ship. Annex I Part II starts with an inventory.
- Produce an SBOM for each product version, covering at least the top-level dependencies.
- Use a commonly used, machine-readable format such as CycloneDX or SPDX.
- Include firmware and container images, not only source repositories.
- Keep SBOMs for every version still supported, not only the latest build.
4. Vulnerability handling
These obligations apply from 11 December 2027 for products placed on the market from that date.
- Check components against known vulnerabilities on a regular schedule.
- Remediate without delay, with security updates separate from feature updates where feasible.
- Publish a coordinated vulnerability disclosure policy and a contact address.
- Disclose fixed vulnerabilities once an update is available.
- Distribute security updates securely, free of charge, with advisory messages.
- Test and review the product's security regularly.
5. Security requirements and support period
Annex I Part I sets the product's security properties. Several of them are design decisions that are hard to change late.
- Ship with a secure default configuration and the possibility to reset it.
- Protect against unauthorised access and protect data confidentiality and integrity.
- Minimise the attack surface and limit the impact of incidents.
- Set a support period of at least five years, unless the product is expected to be used for less, and show its end date at purchase.
6. Documentation and conformity
The last step turns the work into a file an authority can review. Technical documentation must be kept for ten years or for the support period, whichever is longer.
- Write the technical documentation described in Annex VII, including the SBOM and the vulnerability-handling process.
- Choose the conformity assessment procedure for each product's category.
- Draw up the EU declaration of conformity and affix the CE marking.
- Provide user information and instructions as set out in Annex II.
7. Keep it running
Compliance is not a one-off project. The obligations run for the whole support period of every product version you sell, so the checklist becomes a routine.
- Re-check the SBOM of every supported version whenever new vulnerability data is published.
- Review your coordinated vulnerability disclosure inbox and triage reports on a fixed rhythm.
- Rehearse an Article 14 report once a year, from detection to final report.
- Update the technical documentation when a product is substantially modified.
Available in KROMSE today
Several items on this list are what KROMSE produces today.
- SBOMs in CycloneDX and SPDX for every scan of a repository, container image or Linux-based firmware image.
- Checks of your components against known vulnerabilities, including known-exploited flags from CISA KEV.
- On paid plans, internal Article 14 drafts for all reporting stages, completed and submitted by a person.
- Recorded decisions and a CRA evidence pack for your technical file.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q4 2026CRA conformity assessment. A guided workflow will map your evidence to the Annex I requirements, for a person to review and complete.
- Coming · Q4 2026EU Declaration of Conformity generator. KROMSE will draft the EU Declaration of Conformity from your product record, for your signatory to check and sign.
Frequently asked questions
What should a manufacturer do first for the CRA?
Prepare for reporting. Article 14 has applied since 11 September 2026 and covers products already on the market, so the first step is knowing your coordinating CSIRT, having access to ENISA's single reporting platform and knowing which products contain which components.
Is an SBOM mandatory under the Cyber Resilience Act?
Yes, for products in scope. Annex I Part II requires manufacturers to identify and document components, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. It is part of the technical documentation, not something to publish.
How long must security updates be provided?
For the support period, which must reflect the expected use time of the product and be at least five years unless the product is expected to be used for less. Each security update must stay available for at least ten years or for the rest of the support period, whichever is longer.
Does the checklist apply to open-source projects?
It depends on the role. A company that places an open-source product on the market in the course of a commercial activity is a manufacturer and follows the full list. Open-source software stewards have a lighter set of obligations and cannot be fined, and non-commercial contributors are generally outside the Regulation.
Can I download this checklist?
Yes. Use the print button on this page and choose Save as PDF in your browser's print dialog. The checklist is for orientation and does not replace legal advice on whether and how the Regulation applies to your products.