The EU Cyber Resilience Act, explained for manufacturers
What the CRA requires for products with digital elements: a living inventory of what you shipped, vulnerability handling, Article 14 reporting from 11 September 2026, and evidence for December 2027.
The Cyber Resilience Act (CRA) is an EU regulation that sets mandatory cybersecurity requirements for "products with digital elements" sold in the EU, including embedded devices, industrial gateways, and their firmware. It requires secure-by-design engineering, a machine-readable SBOM, vulnerability handling, and security updates across the product lifetime.
The object of assessment is the shipped product: what you placed on the market, version by version. September 2026 is a report to CSIRT/ENISA when something is actively exploited, not an obligation to email end customers. alloy-it helps you run that living workflow: inventory, scan, triage, awareness clock, evidence, and a rebuild path when you must patch.
Key CRA deadlines
Non-compliance can trigger fines of up to €15 million or 2.5% of global annual turnover.
The six obligations that matter for manufacturers
Secure-by-design & by-default
Build cybersecurity into the product from the start, with a secure default configuration.
Machine-readable product SBOM
Maintain a Software Bill of Materials (SPDX/CycloneDX) covering at least top-level dependencies, per software version of what you place on the market.
Vulnerability handling
Identify, document, and remediate vulnerabilities across the product lifetime; report actively exploited ones to ENISA and national CSIRTs (Article 14 from 11 Sep 2026).
Security updates
Provide security updates for the support period (a minimum of five years) over a signed, integrity-protected channel.
Technical documentation
Keep documentation (including the SBOM) available for market-surveillance authorities on request.
Conformity assessment & CE marking
Self-assess (≈90% of products) or use a notified body for important/critical products before affixing the CE mark. alloy-it is not CE-marking software.
First: inventory of what you placed on the market
You cannot report what you cannot find. Article 14 readiness starts with products and releases, a vendor SBOM (and optionally a firmware-derived inventory), continuous rescan, and triage decisions, then an awareness timestamp when something is actively exploited in a shipped release.
Build-environment and toolchain SBOMs are useful depth for technical documentation and long-support rebuilds. They are not what September 2026 reporting asks for.
How alloy-it maps to CRA requirements
| CRA requirement | What it demands | How alloy-it helps |
|---|---|---|
| Machine-readable product SBOM | SPDX / CycloneDX, at least top-level dependencies, per software version. | Upload a vendor CycloneDX/SPDX SBOM per release. Optionally derive an inventory from the firmware binary and compare, trust but verify. |
| SBOM stays current | A new SBOM for each software version; must not go stale. | Every release carries its own SBOM. Continuous rescan keeps findings current across the support period. |
| Vulnerability handling & triage | Identify, document, and remediate; decide what is in the product. | Component-level triage with justification and history. Defensible affected / not-affected decisions for assessors. |
| Actively exploited reporting (Art. 14) | 24h early warning / 72h notification to ENISA and national CSIRTs from 11 Sep 2026. | KEV / EUVD overlay on product inventory, awareness timestamp, and copy-JSON SRP payload. Alloy does not submit and does not auto-email customers. |
| Technical documentation & evidence | Evidence for audits and market-surveillance authorities. | Evidence packs per release: SBOM(s), findings, triage decisions, and awareness history. |
| Updates over the lifetime | Track and patch components for 5+ years (support period). | Link the release to the blueprint that built it. Reconstruct that environment to ship a patched release back into monitoring. |
| Build-environment / toolchain SBOM | Optional depth for technical docs; not what Article 14 asks for in Sep 2026. | Blueprints produce a per-version SBOM that includes the toolchain and build-time dependencies when you need that evidence. |
Cyber Resilience Act FAQ
When does the CRA take effect?
The CRA entered into force on 10 December 2024. Vulnerability and incident reporting obligations apply from 11 September 2026, and full application (including CE marking and conformity assessment) is required from 11 December 2027.
Does the CRA require an SBOM?
Yes. Manufacturers must produce a machine-readable Software Bill of Materials (SPDX, CycloneDX, or SWID) covering at least the top-level dependencies, kept current for each software version and included in the technical documentation.
What does Article 14 require from 11 September 2026?
Manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and national CSIRTs: 24-hour early warning, 72-hour notification, and a 14-day final report. That is a report to authorities, not an obligation to email end customers. Informing users sits with vulnerability handling toward full application in December 2027.
Does the CRA apply to my product?
It applies to products with digital elements (hardware and software) placed on the EU market. Roughly 90% of products fall into the default category and can self-assess; important and critical products may require a notified body.
What are the penalties for non-compliance?
Non-compliance with the essential requirements can trigger fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.
Does the CRA apply to open source?
Open-source software stewards are subject to a lighter-touch regime. Organizations that distribute open source commercially are generally treated as manufacturers with the full set of obligations.
Who does the CRA actually bind?
The heaviest duties sit with the manufacturer of the product with digital elements, including anyone who markets it under their own name, and with anyone treated as a manufacturer after a substantial modification. Authorised representatives, importers, and distributors have their own duties, mainly documentation and gatekeeping, not the Article 13 and 14 operations loop. alloy-it is built for the manufacturer of record.
CRA compliance hub
CRA SBOM requirements
Format, scope, and per-version rules for a CRA-compliant product Software Bill of Materials.
CRA for embedded & firmware
Why firmware needs vendor SBOM plus binary-derived inventory, and how HEX/encrypted images differ.
CRA compliance checklist
A practical checklist mapping each CRA obligation to what your team must do.
Vulnerability handling & Article 14
24h / 72h / 14-day reporting, KEV/EUVD, awareness clock, and what Sep 2026 actually requires.
Build-environment SBOM
Toolchain and build-time dependencies for technical docs: useful depth, but not what Sep 2026 reporting requires.
This page provides general information about the EU Cyber Resilience Act and is not legal advice. The regulation and its harmonised standards are still evolving: consult the official EU, ENISA, and BSI sources and qualified counsel for your specific product. alloy-it helps with product inventory, SBOM monitoring, triage, Article 14 evidence, and the rebuild path; it is not CE-marking software, not a notified body, and does not submit reports to ENISA or national CSIRTs.
Get Article 14-ready before September 2026
Start with a product inventory, continuous scan, triage, and awareness evidence, then a rebuild path when you must patch.