The Cyber Resilience Act, in plain terms

Part 1 of 3 in the Cyber Resilience Act series.

If your company ships containerised software, whether your customers run it inside their own Kubernetes clusters, whether you operate it as a SaaS with an installable agent or appliance, or whether your product is a container image other businesses pull and deploy, the Cyber Resilience Act (CRA) is the regulation that should be on your 2026 planning slide. It is the first horizontal EU law to put binding cybersecurity obligations on the people who build digital products, not just on the people who run critical infrastructure. And the timeline is no longer theoretical.

This is the first post in a short series. Subsequent posts walk through how a runtime-driven security platform like bifrost maps to the specific obligations, and what changes for a security team that adopts that approach.

What the CRA actually is

The Cyber Resilience Act is Regulation (EU) 2024/2847. It entered into force on 10 December 2024 and applies to “products with digital elements”: hardware or software placed on the EU market, including components shipped separately.

For our audience the practical translation is straightforward. If you produce a containerised product that your customers deploy in their own infrastructure, that product is in scope. If you ship a SaaS that includes installable components (an on-prem agent, a sidecar, a mobile app, an SDK or a downloadable client), those components are in scope, and so is the remote-data-processing layer they depend on when that layer is part of the product. Pure SaaS with no installable element and no integral remote-data-processing scope can fall outside CRA’s product-scope, but it rarely stays outside the regulatory perimeter for long: NIS2, DORA, and sector laws apply in parallel, and the EU is consistently tightening the SaaS edge. Most companies in our market should plan as if CRA applies and treat any exemption as a bonus.

The obligation belongs to the manufacturer: the legal entity that places the product on the market under its name or trademark. That is you. Importers and distributors carry derivative duties, but the substance lands on the company writing the software.

The dates that matter

Three dates anchor the planning.

11 June 2026. The CRA’s conformity-assessment and notification framework starts applying. The plumbing for third-party assessment begins to turn on.
11 September 2026. Reporting obligations under Article 14 apply. From this date, manufacturers must notify actively exploited vulnerabilities and severe incidents through the ENISA-run CRA Single Reporting Platform.
11 December 2027. Full applicability. Every in-scope product must meet the essential requirements, carry the CE marking, and ship with the prescribed information to users.

Penalties top out at €15 million or 2.5% of global annual turnover, whichever is higher.

What manufacturers are being asked to do

The substantive obligations live in Annex I, which has two parts.

Part I covers product properties. Your product must be designed to provide an appropriate level of cybersecurity given its risk profile. That means secure-by-default configuration, no known exploitable vulnerabilities at the point of placing on the market, protection from unauthorised access, integrity and confidentiality protection, minimisation of attack surface, reduction of incident impact, and the ability to log relevant internal activity. For a containerised product, this is largely a story about least-privilege defaults and what your container is allowed to do at runtime.

Part II covers vulnerability handling. For the full duration of a declared support period, you must identify and document components (including a Software Bill of Materials in a machine-readable format), address vulnerabilities without delay, regularly test the security of the product, distribute security updates, and operate a coordinated vulnerability disclosure process.

Two items deserve a second look.

The first is the SBOM requirement. CRA does not force you to publish an SBOM, but it does require one, in CycloneDX or a comparable machine-readable format, kept in the technical documentation and producible on request from market surveillance authorities. For a containerised product, the practical bar is: an SBOM per build, per image, stored alongside the version that produced it.

The second is the support period. You must declare your vulnerability handling window, making the end date visible at purchase. This isn’t an arbitrary choice: the CRA requires a baseline of at least 5 years (unless the product’s lifetime is demonstrably shorter). And while customers notoriously drag their feet on upgrading installable agents, you do not necessarily have to support every legacy version forever. In practice, this is a support-policy question: define which versions remain supported, make that lifecycle clear to customers, and make sure supported versions are covered by your vulnerability-handling process for the full declared support period. A free, seamless upgrade path can help narrow the versions you continue to support, but it does not by itself make CRA obligations apply only to the current release; legal should confirm the versioning position.

What the reporting timeline looks like

From 11 September 2026, any time you become aware of an actively exploited vulnerability or a severe incident affecting the security of your product:

24 hours. Early warning notification to your national CSIRT and ENISA via the Single Reporting Platform.
72 hours. Main notification with the information available at that point.
Final report. 14 days after a corrective measure is available for vulnerabilities, or 1 month after the 72h notification for severe incidents.

For a containerised product running across hundreds or thousands of customer environments, “becoming aware” can be ambiguous and the evidence is often scattered. The 24-hour clock is the operational change CRA forces, and the one security teams in our space most consistently underestimate.

How to start preparing

For a SaaS or containerised-product company, the practical next steps for the next two quarters: list every component you ship (containers, agents, SDKs, mobile apps, on-prem services) and confirm scope per component. Decide per product whether it is standard, important (Class I or II), or critical per Annex III/IV; that drives whether self-assessment is enough or a notified body is required. Make sure SBOMs are produced and stored per build in a format an auditor can read. Tighten the path from vulnerability discovery to a notification draft so the 24-hour clock is achievable on a holiday weekend. And start the conversation with engineering, product, and legal about the declared support period for each shipping artefact.

In the next post we walk through the CRA obligations one by one and show where a runtime-driven security platform fits, and where you still need process around it. CRA is not a tooling problem alone, but the right tooling makes the difference between an audit you survive and one that generates its own evidence.