The EU CRA compliance checklist: 8 things you need in place
The EU Cyber Resilience Act compliance checklist for connected-product teams. The eight things you need in place, from SBOM to the 24-hour reporting process.
Searching "CRA compliance" usually turns up either the regulation text itself or a general explainer. This is neither. It is the checklist: the eight concrete things a connected-product company needs in place to meet the EU Cyber Resilience Act, in the order most teams should tackle them.
TL;DR: CRA compliance comes down to eight items: a device and component inventory, a current SBOM, vulnerability monitoring, a disclosure process, a security-update mechanism, a 24-hour active-exploitation reporting process, the right conformity assessment for your product class, and complete technical documentation. Most teams are missing the reporting process and the fielded-device patch path, not the paperwork.
The Cyber Resilience Act, Regulation (EU) 2024/2847, makes cybersecurity a legal requirement for any product with digital elements sold in the EU. It has been in force since December 2024, with reporting obligations applying from 11 September 2026 and the full essential requirements from 11 December 2027. For the full scope and who is covered, see our CRA framework page; for exactly when each obligation lands, see the CRA timeline.
The CRA compliance checklist
- A device and component inventory. Every product, hardware revision, and firmware version you have shipped, with the components each one depends on. This is the foundation everything else sits on, and it is the step most teams skip.
- A current Software Bill of Materials (SBOM). Generated for each actively shipping product line, not a one-time snapshot. Our hands-on SBOM walkthrough and CycloneDX vs SPDX guide cover the mechanics for embedded firmware.
- Ongoing vulnerability monitoring, tied to that SBOM, so a new CVE against a component you use surfaces automatically instead of relying on someone reading a mailing list.
- A coordinated vulnerability disclosure process, including a public point of contact for security researchers to report issues.
- A security-update mechanism that reaches devices already in the field, not just new units coming off the line. See how the CRA applies to IoT and embedded devices for why this is the hardest item on the list.
- A 24-hour active-exploitation reporting process. From 11 September 2026, an actively exploited vulnerability or severe incident must be reported to your national CSIRT and ENISA within 24 hours of becoming aware. Our CVE-to-patch pipeline covers the mechanics end to end.
- The right conformity assessment for your product class. Default-class products can self-assess; important and critical classes need a notified body. See self-assessment or notified body for how that classification works.
- Complete technical documentation, assembled from everything above, ready to hand to a notified body or a market surveillance authority on request.
What is the hardest item on the checklist?
Item 6, the 24-hour reporting process, and item 5, patching fielded devices, together. Most teams can produce an SBOM and a disclosure policy without much trouble. Very few can currently tell, within 24 hours of a vulnerability going actively exploited, exactly which of their already-shipped devices are affected and get a fix moving. That operational capability, not the documentation, is what actually determines whether a company is CRA-ready.
Do I need to complete this in order?
Roughly, yes. The inventory and SBOM (items 1 and 2) are prerequisites for everything after them, you cannot monitor vulnerabilities you have not mapped to components, and you cannot report on active exploitation you cannot detect. Start there. The conformity assessment (item 7) comes last in practice, since it is verifying work that is already done, not creating it.
Does this checklist apply to legacy products too?
Yes, on the same terms as new ones once the essential requirements apply from 11 December 2027, with the reporting obligation (item 6) applying to any product still in the field from 11 September 2026 regardless of when it was designed. See CRA exemptions for legacy products and small business for the narrow cases where a product is genuinely out of scope.
Where Scadable fits
Scadable runs this checklist continuously instead of as a one-time project: it maps every device, deployment, and component you have shipped, keeps the SBOM current, flags what is actively exploited, writes and backports the fix to fielded devices, and files the report inside the 24-hour window. Items 1 through 6 become infrastructure instead of a recurring scramble. If you want to see exactly where your gaps are, book a walkthrough.
Last reviewed: July 2, 2026.
Frequently asked questions
What does CRA compliance actually require? Eight things in practice: an inventory of every device and component you have shipped, a current SBOM, ongoing vulnerability monitoring, a coordinated disclosure process, a security-update mechanism, a 24-hour active-exploitation reporting process, the right conformity assessment for your product class, and complete technical documentation.
Is there an official CRA compliance checklist from the EU? No single official checklist exists yet; harmonised standards under the CRA are still being finalised. This checklist is built directly from the regulation text, Regulation (EU) 2024/2847, and covers the essential requirements every product with digital elements has to meet.
Do small companies need to complete the same checklist? Yes. There is no company-size exemption. Obligations scale by product risk classification, not headcount, though smaller companies get some simplified documentation options for the technical file.
What is the single item most teams miss? The 24-hour active-exploitation reporting process. Most teams have no way to tell, within 24 hours, which of their already-fielded devices are affected by a newly exploited vulnerability, which is exactly what the CRA requires from 11 September 2026.
How long does it take to complete the checklist? It depends on how many product generations you have shipped and whether an SBOM already exists for each. Teams starting from an accurate device and component inventory typically move through the checklist in weeks; teams starting from scratch on older fielded hardware should plan for months.