CRA compliance for manufacturers

Control the software inside everything you ship

Your engineers and their AI agents now assemble firmware, containers, and packages faster than any review board can follow. Cloudsmith gives you one registry and one control point for all of it, with policy, SBOMs, and audit records attached. That includes the evidence the EU Cyber Resilience Act now requires.

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 obligationTechnical documentation must include a machine-readable software bill of materials (SBOM) covering top-level dependencies, produced before the product is placed on the market.
Cloudsmith capabilityA machine readable SBOM is generated with every build and stored alongside the artifact.
CRA obligationThroughout a product's support period, manufacturers must address vulnerabilities in all integrated components, including open source, without delay, providing security updates free of charge
Cloudsmith capabilityContinuous vulnerability monitoring covers everything held in the registry, not only what shipped on day one, keeping customers secure.
CRA obligationAn 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.
Cloudsmith capabilityBuild and distribution records show which versions are deployed where, so you can scope an incident and provide required details before the clock runs out.
CRA obligationProducts must ship with no known exploitable vulnerabilities and a secure default configuration, under the CRA's essential cybersecurity requirements.
Cloudsmith capabilityPolicy-as-code in OPA Rego blocks a package at ingest if it fails your rules, before it reaches a build.
CRA obligationManufacturers must retain the technical documentation and conformity records needed to demonstrate compliance for market surveillance authorities.
Cloudsmith capabilityClient and audit logs give you a defensible record of what shipped, when and where it came from.
Supply chain security

Policy-as-code for every dependency your engineers and AI agents pull

AI agents now write build scripts, drivers, and embedded services, and they install whatever dependencies the code calls for. Point them and your developers' package managers at Cloudsmith, and every request is proxied, checked against your OPA Rego policies, and logged before anything reaches a build. Quarantine packages over your CVE severity threshold, hold prohibited licenses for inspection, 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 and ISO/SAE 21434 requirements.
  • Industry-standard OPA Rego policy as code, applied to every package an AI agent or developer requests
  • Automated vulnerability scanning at ingestion, with retroactive rescans the moment a new CVE is published
  • License compliance checks to prevent legal exposure in commercial products
  • Cooldown policies hold newly-released packages back from agents and developers until they're proven safe
  • 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, and AI agents add a growing stream of dependencies on top. Cloudsmith is fully managed: nothing to deploy, patch, or scale, and no multi-day migration to dread. It becomes the single source of truth that your pipelines, developers, and AI agents all pull from.
  • Nothing to patch, scale, or maintain
  • Point developers and AI agents at one governed source for every dependency
  • 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. AI agents are now placing orders on your behalf, at machine speed. An ingestion policy gives software the same layer of control, so engineers and agents can move fast and you can still trust what goes into the product.
  • Every package, container, and firmware component, including those requested by AI agents, 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, where it runs, and how your teams use AI tools to build it. We'll show you what one registry looks like for your packages, firmware, containers, and updates.

FAQ

What manufacturing teams need to know

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. Configure your AI agents and developers' package managers to point at Cloudsmith, and every dependency they request flows through one governed source. Cloudsmith proxies public registries through upstreams and checks each package against your OPA Rego policies before making it available, so agents get the speed they need and you keep the control the CRA demands.

  8. Every package is evaluated against your policies before an agent or developer can use it. Packages above your CVE threshold can be quarantined or blocked, prohibited licenses held for inspection, poorly maintained packages tagged, and very new versions held back for a set period. The result is a dependency firewall in front of your build pipelines.

  9. No. The CRA holds you responsible for every component in the product, whoever or whatever chose it. Because every dependency requested by an AI agent passes through Cloudsmith, you keep the same SBOMs, policy decisions, and audit records for AI-assisted work as for any other release.

  10. Agents that pull from Cloudsmith draw on pre-cached, verified registries that record whether each dependency meets policy, can be used legally, and is your preferred option. That metadata acts as your organization's memory of what has been approved and shipped, which helps agents choose better dependencies and keeps software easier to maintain over a long product lifecycle.

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.