--- title: "Cyber Resilience Act Compliance for Manufacturers" description: "Secure firmware, containers, and supplier software for manufacturers under the EU Cyber Resilience Act. SBOMs, policy, and audit records, one registry." canonical_url: "https://cloudsmith.com/solutions/manufacturing-hardware-connected-devices" last_updated: "2026-10-13T09:51:38Z" --- # Cyber Resilience Act Compliance for Manufacturers CRA compliance for manufacturers ## Control the software inside everything you ship Firmware, containers, supplier binaries, and packages all carry risk once they leave the factory. Cloudsmith gives you one registry for all of it, with policy, SBOMs, and audit records attached. That includes the evidence the EU Cyber Resilience Act now requires. [Book a demo](/book-a-demo) CRA compliance ## Ship safe software and meet your CRA obligations You already ship a lot of software, and the Cyber Resilience Act now holds you responsible for every component in it, regardless of where it came from. Reporting duties started 11 September 2026, and full compliance is due 11 December 2027. Cloudsmith gives you one point of control over that software: we apply your policies and produce the evidence for compliance monitoring. | CRA obligation | Cloudsmith capability | | --- | --- | | Technical documentation must include a machine-readable software bill of materials (SBOM) covering top-level dependencies, produced before the product is placed on the market. | A machine readable SBOM is generated with every build and stored alongside the artifact. | | Throughout a product's support period, manufacturers must address vulnerabilities in all integrated components, including open source, without delay, providing security updates free of charge | Continuous vulnerability monitoring covers everything held in the registry, not only what shipped on day one, keeping customers secure. | | An actively exploited vulnerability or severe incident must be reported to ENISA within 24 hours, followed by a full notification within 72 hours and a final report. | Build and distribution records show which versions are deployed where, so you can scope an incident and provide required details before the clock runs out. | | Products must ship with no known exploitable vulnerabilities and a secure default configuration, under the CRA's essential cybersecurity requirements. | Policy-as-code in OPA Rego blocks a package at ingest if it fails your rules, before it reaches a build. | | Manufacturers must retain the technical documentation and conformity records needed to demonstrate compliance for market surveillance authorities. | Client and audit logs give you a defensible record of what shipped, when and where it came from. | Supply chain security ## Policy-as-code that keeps watching after the product ships Define security policies in OPA Rego to automate decisions at ingestion. Quarantine packages over your CVE severity threshold, block prohibited licenses, and soak new packages until they're proven safe. When a new vulnerability appears, Cloudsmith rescans everything already stored, not just what's pulled today. Detailed log data gives you the audit trail you need to meet CRA, ISO/SAE 21434 requirements. - Industry-standard OPA Rego policy as code - Automated vulnerability scanning at ingestion, with retroactive rescans the moment a new CVE is published - License compliance checks to prevent legal exposure - Cooldown policies for newly-released packages - Full audit trails for CRA, ISO/SAE 21434, ISO/IEC 62443-4-1, and ASPICE For platform engineering teams ## One registry, nothing to maintain Firmware, containers, packages, and supplier binaries end up split across different tools, each with its own patching and on-call burden. Cloudsmith is fully managed: nothing to deploy, patch, or scale, and no multi-day migration to dread. - Nothing to patch, scale, or maintain - Migration support for URL remapping and credential remediation - One control plane for every artifact type you ship For budget owners ## Goods inwards, for software Think of an SBOM as the ingredient list that arrives with a shipment: the goods inwards team checks it against purchase orders before the material goes onto the production line. A package that is not on the list does not go in. An ingestion policy provides the same layer of control for software. - Every package, container, and firmware component is checked against your rules the moment it arrives. - A component that fails the check is blocked before it can cause damage or reach sensitive systems. - That ingredient list and gate give a security or compliance lead the audit trail they need for every component you ship. ## Book a conversation Tell us what you ship and where it runs. We'll show you what one registry looks like for your packages, firmware, containers, and updates. [Book a conversation](/book-a-demo) FAQ ## What manufacturing teams need to know ### How does Cloudsmith generate the SBOM the CRA requires in technical documentation? An SBOM is generated automatically with every build and stored alongside the artifact it describes, so the documentation the CRA requires is ready before an auditor asks for it, not reconstructed after the fact. [Read the SBOM docs](https://docs.cloudsmith.com/artifact-management/sbom) ### How do OPA Rego policies stop a non-compliant component before it reaches a build? A policy written once in OPA Rego evaluates every package against your rules the moment it's uploaded. A component that fails, on license, vulnerability, or malware grounds, is quarantined or blocked automatically, before it reaches a build pipeline. [Read the policy docs](https://docs.cloudsmith.com/supply-chain-security/epm) ### What happens when a vulnerability is disclosed against a component after we've shipped? Cloudsmith rescans everything stored in the registry continuously, not only packages pulled today. A component that was clean at ingest gets flagged the moment a CVE is published against it, and you can trace it to every build, container, and release that used it. [Explore supply chain security](https://docs.cloudsmith.com/supply-chain-security) ### How do we control which customers and devices can pull firmware updates? Entitlement tokens scope access per customer or device, so updates are distributed on read-only, revocable credentials instead of shared ones. Access can be issued or revoked individually without touching the rest of the registry. [Read the entitlement token docs](https://docs.cloudsmith.com/software-distribution/entitlement-tokens) ### Where do we get the evidence to show an auditor what shipped and when? Client and audit logs record every push, pull, and policy action against a named identity, giving you a defensible record for an incident report, a customer audit, or a CRA reporting obligation. [Read the audit log docs](https://docs.cloudsmith.com/logs-and-observability/audit-logs) ### What's the difference between the September 2026 and December 2027 CRA deadlines? 11 September 2026 is when reporting duties start: 24 hours for an early warning on an actively exploited vulnerability or severe incident, 72 hours for full notification, then a final report. 11 December 2027 is when full compliance is required across all manufacturer obligations, including technical documentation and vulnerability handling. Further reading ## Additional Resources Curious about CRA compliance and what good supply chain security looks like for manufacturers? Take a look at the resources below to learn more. ### [What is the EU Cyber Resilience Act?](/blog/what-is-the-eu-cyber-resilience-act) EU law is changing for hardware and software makers. Here's your 2-minute summary of the Cyber Resilience Act. ### [The EU Cyber Resilience Act: What engineering teams need to do to meet CRA requirements](/blog/the-eu-cyber-resilience-act-what-engineering-teams-need-to-do-to-be-compliant) The EU Cyber Resilience Act (Regulation EU 2024/2847) is the first EU-wide regulation that places mandatory cybersecurity requirements on digital products throughout their entire lifecycle, from design and development all the way through deployment and end-of-life. ### [How artifact management closes the CRA compliance gaps that leave you exposed](/blog/how-artifact-management-closes-the-gaps-that-leave-you-exposed-under-the-cra) The Cyber Resilience Act reaches beyond product security into the components inside what you ship like the open-source packages your team pulled, or the transitive dependencies nobody explicitly chose. Fragmented artifact practices aren't just operational debt; they're a structural compliance liability. ### [EU CRA compliance: building a defensible posture with Cloudsmith](/blog/eu-cra-compliance-building-a-defensible-posture-with-cloudsmith) The EU Cyber Resilience Act sets binding cybersecurity requirements for any company selling software into the EU market, with the first deadline landing in September 2026. This post breaks down what the regulation requires at the supply chain layer and how Cloudsmith addresses those obligations. ### [How to Analyze an SBOM](/blog/how-to-analyze-an-sbom) Ciara discusses how to analyze SBOMs for vulnerabilities using Open Source tools, and how Cloudsmith can take actions like quarantining your images if it contains vulnerabilities above a certain level. ### [What is the SLSA framework? A guide to SLSA levels and supply chain security](/blog/slsa-a-route-to-tamper-proof-builds-and-secure-software-provenance) Would you be able to prove how your software was built – from what source, on what infrastructure, under what controls – if a customer asked? The Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") framework is a structured answer to that problem.