The CRA reporting clock is running. Here is how to start

The Cyber Resilience Act has been law since December 2024, but until this month it asked nothing of anyone. That changed on 11 September 2026. From that date, software manufacturers must report actively exploited vulnerabilities and severe incidents, with an early warning due within 24 hours. The full set of product requirements, CE marking included, follows on 11 December 2027.

We covered the regulation in depth earlier this year. This post is shorter and more practical: what this means for organisations building custom software, whether delivered as SaaS, managed single-tenant environments, or customer-hosted containers, and what to do first.

If you build custom software, assume you are in scope

The CRA applies to “products with digital elements” placed on the EU market. For B2B software vendors, the dividing line isn’t just what you build, but where your software runs across customer environments:

• Single-tenant & customer-hosted deployments. Containers, Helm charts, sidecars, or agents installed directly in your customer’s cloud tenant or on-premises cluster. This is software placed on the market, squarely in scope. You are legally the manufacturer.
• Hosted SaaS & multi-tenant architectures. A pure hosted service with no installed client components is governed primarily by NIS2 rather than the CRA. However, if your SaaS relies on installed components (agents, connectors, edge nodes) or operates dedicated single-tenant infrastructure per customer as part of the product boundary, those components, and often the remote data processing tied to them, fall under the CRA.

Most companies shipping custom B2B software operate a hybrid model. The sensible position is to plan as if the CRA applies across your entire deployment footprint and treat any technical exemption as a bonus. The first post in our series covers scope edge cases and support periods in detail.

What the reporting obligation actually requires

The obligation live today is Article 14. When you reach a “reasonable degree of certainty”, the EU’s legal standard for becoming aware, that an actively exploited vulnerability or severe incident exists in your software, you face a strict timeline:

• 24 hours: Submit an early warning.
• 72 hours: Submit a detailed notification including initial severity assessments and impact.
• 14 days to 1 month: Submit a final report (due 14 days after a fix or mitigation becomes available for vulnerabilities, or 1 month for incident resolution).

All submissions are routed through ENISA’s Single Reporting Platform (SRP) and your national CSIRT.

Filing the form isn’t the bottleneck. Reaching that “reasonable degree of certainty” within hours is. To meet a 24-hour deadline, you must instantly answer: Which software components are running in which customer environments, and is the vulnerability actually reachable or exposed in production? For engineering teams managing custom software across dozens of single-tenant deployments, that answer is rarely at hand.

To get started, a few tips

None of this requires a compliance programme. It is engineering hygiene the CRA happens to make mandatory, and the first two steps are open source.

1. Generate an SBOM for every build

The CRA mandates a Software Bill of Materials in a machine-readable format as part of your technical documentation. The practical standard is one SBOM per container or artefact per build, stored alongside the artefact that produced it.

Integrate a generator like Syft or Trivy into your CI pipeline, export in CycloneDX or SPDX, and attach the file to the image as an OCI artefact or push it to your registry. Everything else relies on this baseline inventory.

2. Collect SBOMs across environments with Dependency-Track

A repository of static SBOM files won’t satisfy an ongoing vulnerability obligation. You need something that ingests them, cross-references them against updated CVE feeds continuously, and alerts you when a component deployed months ago acquires a fresh vulnerability.

OWASP Dependency-Track is the natural starting point. It ingests CycloneDX and SPDX, tracks project versions across environments, and flags newly published vulnerabilities in your dependencies. Wire your CI pipeline to push every build and you have the “identify and document vulnerabilities” requirement in Annex I Part II covered for the length of your support period.

At this point you know what you ship and what is in it. That is a real position for the 24-hour clock. It is also where most organisations stop, with a complete list and no way to say which items on it matter.

3. Add runtime context with something like bifrost

Modern stacks carry thousands of CVEs across their dependencies. The CRA requires you to address vulnerabilities without delay, but patching everything at once is impossible, and ranking by CVSS score alone leads to endless triage. To reach the “become aware” threshold without spending 20 hours in telemetry, you need to know whether a vulnerable path can be reached at all.

That is what a runtime security platform like bifrost adds. It ingests your SBOMs, or collects one for every container it observes, and shows you where in the SDLC you have each component: which version is in staging, which is in production, and in which customer environment. It re-scans those SBOMs several times a day against new CVEs. Then it collects runtime data on how each container is deployed and what it actually does, and gives every CVE a verdict: reachable, mitigated by the profile, or never loaded. The reachable ones form your engineering backlog. The rest carry a documented runtime reason. In production that has meant up to 90% fewer CVEs to triage.

The same runtime data produces a profile per workload, enforced at the kernel with AppArmor. Anything outside it is blocked, whether a known exploit or one nobody has written yet. That shaves even more CVEs off the list, because an exploit that needs a step outside the profile is mitigated before any code changes. And every blocked event is logged with pod, image, profile version and attempted action: the technical context a 24-hour early warning needs to contain.

The result is a real-time overview of your CVE exposure and evidence for the ones you do not need to report. When a zero-day drops, “are any of our single-tenant or SaaS instances exposed?” becomes a lookup, not a war room.

Where bifrost fits, and where it does not

bifrost provides the underlying evidence: SBOM histories, runtime verdicts, workload profiles, and violation logs. How that maps to your specific compliance framework remains a decision for your team and your auditor (see our compliance page for what the evidence looks like). Legal declarations, coordinated vulnerability disclosure (CVD) policies, and direct submissions to ENISA stay within your operational workflows.

If you want to see the picture for your own SaaS or customer-tenant workloads, deploy via Helm and the first profile is there in under 10 minutes. The reporting clock is running. The best way to satisfy it is by shipping software that is resilient on its own.