If your engineering organization builds software and sells it into the European market – or plans to – the EU Cyber Resilience Act (CRA) is now one of your operating constraints. It entered into force in December 2024, but the first binding deadline begins in September 2026 and full enforcement starts in December 2027.
The regulation applies to any company selling products, software or hardware, with digital elements on the EU market, regardless of the company’s headquarters location. That means nearly all global software companies will be subject to CRA requirements. A software team based in Austin, Sydney, or Shanghai that ships a product used by EU customers is a manufacturer under the CRA.
This post covers what the CRA requires, what those requirements mean at the software supply chain layer, how they apply depending on your product type, and what you need to start doing now. Consult with your internal compliance teams before implementing changes to ensure that those changes meet your company’s specific needs.
The CRA, more formally known as Regulation EU 2024/2847, establishes mandatory cybersecurity requirements for products with digital elements – a category defined broadly to cover software applications, connected hardware, cloud-delivered software, and components placed on the market independently.
The most useful comparison is GDPR. Like GDPR, the CRA applies to any organization doing business in the EU, not just organizations based there. Companies don’t need a physical presence in the EU to fall under its jurisdiction. And like GDPR, non-compliance carries penalties calibrated to be uncomfortable at scale.
The difference is focus. GDPR governs data privacy. The CRA governs the security of the product itself, from design through its full operational lifecycle – and that lifecycle dimension is worth highlighting. This is not a "set it and forget it" regulation. It requires ongoing attention to maintain compliance. The regulation frames the intent directly: it aims to ensure that "hardware and software products are placed on the market with fewer vulnerabilities and that manufacturers take security seriously throughout a product's lifecycle."
The CRA shifts the burden of cybersecurity from end-users to manufacturers. The questions the regulation asks are: can you demonstrate that you shipped secure software, that you knew what was in it, that you tracked vulnerabilities after release, and that you reported incidents to authorities within the required timeframes?
For most software organizations, the honest answer today is no – at least not completely.
The area that likely poses the biggest challenge to companies is reporting. Understanding what's expected helps to contextualize why the tooling and processes discussed later in this post matter.
The most imminent obligation in the CRA is the vulnerability reporting requirement under Article 14, which goes into effect starting 11 September 2026. This is more than a year before full enforcement begins and it’s the first hard deadline.
Under Article 14, manufacturers must report to the EU Agency for Cybersecurity (ENISA) and the relevant national Computer Security Incident Response Team (CSIRT) when they become aware that a vulnerability in their product is being actively exploited, or that a severe incident has occurred. There are three reporting windows for actively exploited vulnerabilities:
For severe incidents, i.e., those that negatively affect a product's ability to protect data integrity or confidentiality, or that lead to the introduction of malicious code, the early warning and notification windows are the same, but companies have more time to compile their final report. In these cases, the deadline is one month from submission of the incident notification, instead of 14 days.
The practical implication is significant. To meet these windows, you need to know in real-time what is in your product and whether any of its components are under active attack. This is where having a software bill of materials (SBOM), which functions like an ingredient list for your software, listing dependencies, licenses, and other key information, is critical. Automating processes like SBOM generation gives you the foundation to work at the speed these deadlines require.
Three key definitions in Article 3 of the CRA establish its vulnerability handling requirements. How these requirements relate to each other determines what the regulation actually demands of your engineering team.
The first tier (Article 3(40)) covers any weakness in a product that could be exploited. The obligation here is documentation: the CRA requires a continuously maintained SBOM covering all components and their dependencies. The SBOM is not a one-time deliverable. It needs to stay current SBOMs as your applications evolve. The SBOM is the foundation everything else depends on, because you can’t track vulnerabilities in components you haven't identified.
The second tier (Article 3(41)) covers vulnerabilities that are realistically exploitable under practical conditions. This is the shipping standard: the CRA requires that products reach customers without known exploitable vulnerabilities. The operative word is "exploitable" – meaning realistic exploitation under real-world conditions, not just theoretical presence. EPSS scoring is the practical tool for making that determination. The SBOM is what tells you whether an exploitable component is present in the first place.
The third tier (Article 3(42)) covers vulnerabilities for which there is evidence of active exploitation in the wild. Detecting active exploits is a runtime issue, but the documentation that helps triage and remediate these attacks comes from the software supply chain. An active attack triggers Article 14 reporting – the 24-hour clock. To meet that window, you need to know immediately when a component in your product crosses from exploitable to actively exploited. That requires your SBOM to be current at the moment the disclosure happens, and your monitoring to be continuous rather than scheduled.
The first two tiers are squarely supply chain concerns – what components are in your product and whether any of them are exploitable. The third tier is a runtime security problem: detecting active exploitation happens outside the supply chain layer. But the supply chain remains central to the response. The SBOM tells you exactly which products and versions a confirmed exploit affects, where those artifacts live, and helps you determine what a remediation path looks like. That data is what lets your team triage quickly and meet the reporting windows with confidence.
Keeping that information in a single platform matters. Fragmented tooling – separate registries, scanners, and audit systems that don't share context – creates gaps and slows response the precise moment speed matters most. Your team has more time to act on information when they don’t need to chase information across tools.
The reporting obligations get the most attention because they have the earliest deadline. But behind them sit broader design and process obligations that constitute the bulk of what the CRA demands. These obligations live in Annex I and Article 13, and they apply to the full product lifecycle starting December 2027.
The phrase the CRA uses consistently is "secure by design." At the software supply chain layer, that means security is not a post-build review step. It is enforced at every point where components enter and move through your engineering environment.
The following section identifies the CRA requirements related to the software supply chain and maps those onto Cloudsmith capabilities.
What the CRA requires: Manufacturers must identify and document all components in a machine-readable SBOM, covering at minimum top-level dependencies. The SBOM does not need to be publicly published, but it must be available to market surveillance authorities on request and must be actively used in vulnerability handling. Without an accurate, current SBOM, you cannot demonstrate what is in your product or respond to vulnerability disclosures effectively.
What Cloudsmith does: Cloudsmith automatically generates a complete, machine-readable SBOM for container images added to the platform, covering packages, dependencies, and license information, with no manual steps. Cloudsmith stores and distributes SBOMs alongside the artifacts they describe – versioned, access-controlled, and immediately retrievable for audit or authority submission. The platform tracks the dependency graph continuously as part of normal artifact management, not as a separate compliance task layered on top.
For more information about this requirement see Annex I Part II, Article 13.
What the CRA requires: The CRA requires manufacturers to systematically document vulnerabilities as they become aware of them, apply effective and regular security testing, and ship products without known exploitable vulnerabilities. The standard is continuous, not periodic.
What Cloudsmith does: Cloudsmith addresses this requirement in two ways: detection at ingestion, and continuous re-evaluation as new threats emerge.
At ingestion, Cloudsmith checks every package before it reaches developers. When a package request occurs, Cloudsmith fetches it from upstream, performs vulnerability matching against its database, and evaluates it against your registry policies. Packages that pass are served to developers, agents, or pipelines. Those that fail are blocked or quarantined according to your security policies.
Furthermore, packages that were clean at ingestion don't stay evaluated in isolation. Continuous package enrichment, available as part of Cloudsmith's advanced security, addresses what happens to cached packages when new vulnerabilities emerge that affect them. Data feeds from OSV.dev, GitHub Security Advisories, OpenSSF Malicious Packages, and EPSS update Cloudsmith's vulnerability database every few minutes. When new data hits the database, the platform runs a fresh match against cached artifacts. A match triggers policy evaluation immediately – packages get blocked or quarantined just as they would at ingestion. Because this is a matching process rather than a full scan, it is fast and efficient.
There is a compliance benefit here that's easy to overlook. When a package's security status changes and policy acts on it, that updated metadata is present at the next build. A build-time SBOM generated from that point reflects the current vulnerability picture automatically – no manual trigger required. For teams subject to the CRA's continuous documentation requirement, that means your SBOM stays current as a by-product of how the platform works.
For more information about this requirement see Annex I Part II, Article 13.
What the CRA requires: When a manufacturer becomes aware of an actively exploited vulnerability, the 24-hour clock starts. The obligation is not to discover exploitation within 24 hours – it is to report within 24 hours of becoming aware. That places the real burden on detection infrastructure.
What Cloudsmith does: Cloudsmith supports Article 14 readiness in two ways: continuous monitoring that surfaces newly disclosed exploitation activity as soon as it is known, and an immutable audit trail that provides the evidence chain regulators will ask for. Every artifact event – upload, download, policy action, vulnerability flag – is recorded in logs exportable via API. Hosted SBOMs are immediately retrievable and tied to the affected artifact version. Webhook and API notifications trigger automated incident workflows the moment a vulnerability flag occurs, giving security teams lead time before the 24-hour window closes.
The question Article 14 is really asking is not how fast you can file a report – it is whether your infrastructure would have made you aware at all. A defensible answer to that question requires continuous monitoring.
What the CRA requires: Organizations must design products to limit attack surfaces and protect data integrity. Manufacturers must exercise due diligence over every third-party and open-source component before it enters a product – including transitive dependencies in free and open-source software.
What Cloudsmith does: Cloudsmith sits between developers and public registries, acting as the enforcement layer for every dependency request before it reaches a build. All external packages – npm, PyPI, Maven Central, Docker Hub, and other public registries covering 25+ language and OS formats – pass through Cloudsmith. The platform enriches each package with metadata, and evaluates them against your customized policies to clear or block each one before reaching developer machines or build pipelines.
Organizations define policies as code using OPA/Rego. Cloudsmith applies policies consistently across every format and every team without manual enforcement. Define a policy once at the registry level and it runs everywhere. Three policy types are most directly relevant to CRA requirements: cooldown policies, malicious package policies, and vulnerability policies. Promotion workflows gate movement between development environments, with policy enforcement, scanning, and provenance checks at each stage. Artifacts are signed on upload and verified on download via Sigstore/Cosign, providing cryptographic provenance that directly addresses the CRA's authenticity requirements.
For more information about this requirement see Annex I Part I, Article 13.
What the CRA requires: Products must ensure protection from unauthorized access through appropriate control mechanisms. The same principle applies to the infrastructure used to build and distribute them – access must be controlled, least-privilege, and demonstrable to auditors.
What Cloudsmith does: Cloudsmith provides granular role-based access control at the organization, team, and repository level. SSO via SAML with automatic group sync connects to enterprise identity providers including Okta and Azure AD. SCIM provisioning and deprovisioning ensures access updates automatically when employees leave, eliminating stale credentials as an ongoing risk. OIDC support enables ephemeral, short-lived pipeline authentication, replacing long-lived static credentials in CI/CD pipelines.
For more information about this requirement see Annex I Part I, point (2)(d).
What the CRA requires: The CRA requires manufacturers to record and monitor relevant internal activity and maintain technical documentation available to market surveillance authorities for at least ten years, or the product's support period, whichever is longer. The CRA assumes manufacturers can produce a complete evidence trail on demand.
What Cloudsmith does: Cloudsmith maintains full records of user, API, and system activity – uploads, downloads, deletions, policy changes, permission changes, and authentication actions – at both organization and repository levels. The platform provides four distinct log types relevant to CRA evidence requirements: audit logs, decision logs, client logs, and usage logs – all immutable and exportable to your SIEM in JSON or CSV. When regulators ask who accessed what, and when, Cloudsmith has the answer ready to produce.
For more information about this requirement see Annex I Part I, point (2)(l).
11 September 2026: Article 14 reporting obligations take effect. Any manufacturer with products on the EU market must be operationally ready to detect actively exploited vulnerabilities and severe incidents, and report to ENISA within 24 hours of awareness.
11 December 2027: Full enforcement. All products with digital elements on the EU market must comply with the complete set of essential cybersecurity requirements, including conformity assessment and CE marking.
One critical point on scope: existing products are not exempt. A product already available to EU customers is subject to Article 14 reporting obligations from September 2026, regardless of when it was placed on the market.
The financial exposure attached to non-compliance is significant. Violations of the essential cybersecurity requirements, and of the obligations in Articles 13 and 14, carry fines of up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Procedural violations carry fines of up to €10 million or 2% of global turnover. Beyond fines, market surveillance authorities can prohibit non-compliant products from the EU market and order recalls.
Organizations that start now can make deliberate decisions about tooling and policy architecture. With Cloudsmith, building a defensible compliance posture – deploying policy, generating SBOMs, establishing continuous monitoring, consolidating audit infrastructure – is an infrastructure project with a known deadline, not a crisis.
The requirements above map to specific operational gaps that most engineering organizations need to close before September 2026. The Cloudsmith CRA Readiness Checklist covers each major requirement area – SBOM generation, vulnerability management, reporting infrastructure, supply chain controls, access management, and audit trails – and helps you assess where your current setup stands.
