EU CRA 24-Hour Vulnerability Reporting Is Live: A PSIRT and SBOM Runbook for Software Vendors

EU CRA 24-Hour Vulnerability Reporting Is Live: A PSIRT and SBOM Runbook for Software Vendors

Since 11 September 2026, any manufacturer whose software or connected products are sold in the EU must report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act: an early warning within 24 hours, a notification within 72 hours, and a final report later. That includes non-EU vendors, UAE companies among them. Meeting the clock takes a working PSIRT and a current SBOM.

This post is the practical version: who is in scope, what the clock actually requires, and the runbook and tooling that make it achievable. It is not legal advice. Check the regulation text and your counsel for edge cases.

What exactly went live on 11 September 2026?

The CRA (Regulation (EU) 2024/2847) phases in. Article 14, the reporting obligation, came first. According to the European Commission, manufacturers must now report:

• Actively exploited vulnerabilities in their products with digital elements.
• Severe incidents that affect the security of those products.

Reports go to the CSIRT designated as coordinator and to ENISA, submitted through the ENISA Single Reporting Platform, which went live on the same day (Crowell & Moring).

The bigger set of obligations (essential cybersecurity requirements, conformity assessment, CE marking) applies from 11 December 2027. But under Article 69(3), the reporting duty already covers products placed on the EU market before that date, so your installed base counts today.

Does the CRA apply to UAE and other non-EU vendors?

Yes, if your products reach EU customers. The CRA attaches to products with digital elements made available on the EU market: installable software, firmware, connected devices, and the remote data processing a product needs to work. Where the manufacturer is incorporated does not matter.

For a manufacturer without an EU main establishment, Article 14(7) sets an order for working out which national CSIRT receives reports, based on where your EU authorised representative, importer or distributor sits, with user location as a fallback. Read the article text yourself, because picking the wrong coordinator can mean resubmitting under time pressure.

Pure SaaS that is not tied to a product is generally outside the CRA, but the line gets blurry fast. If you sell an agent, app or appliance that talks to your cloud, assume you are in.

What are the 24-hour, 72-hour and final report deadlines?

The clock starts when you become aware, not when you finish the investigation. That is the part that catches teams out.

Article 14(8) also requires informing impacted users about the vulnerability or incident and the mitigations they can take. Plan that message in parallel, not after the final report.

Penalties for breaching the reporting obligations sit in the CRA’s top tier, reported as up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.

What does a CRA PSIRT runbook look like?

Here is the runbook we would put on the wall. Times are from the moment someone in the company becomes aware.

Two rules make this work. First, the on-call rota has to cover weekends and public holidays, because 24 hours includes Saturday. Second, the “report or not” decision is recorded every time, including the times you decide not to report.

Which roles does a minimum viable PSIRT need?

You do not need a ten-person team. You need named people:

1. PSIRT lead who owns the queue, the decision log and submissions to the platform.
2. On-call engineer per product line who can confirm exploitability fast.
3. Legal or compliance contact for threshold calls and the coordinator question.
4. Comms owner for user advisories.
5. A published intake channel: a security.txt file and a vulnerability disclosure policy, so researchers can reach you. For a step-by-step version, see the two-week vulnerability disclosure program setup plan on bugs.ae.

Why is an SBOM the difference between 4 hours and 4 days?

When a CVE drops in a library like OpenSSL or a logging framework, the first question is “which of our shipped versions contain it?” Without an SBOM per release, that answer comes from engineers grepping repositories across product lines. With one, it is a query.

Annex I of the CRA requires manufacturers to draw up an SBOM in a commonly used machine-readable format, covering at least top-level dependencies. That formally applies from December 2027, but the reporting clock makes it urgent now.

We compare these in depth in our SBOM tools ranking and Trivy vs Grype guides. For signing, see Cosign vs Notary.

The pattern we recommend:

1. Generate an SBOM in CI for every release artifact, not just container images.
2. Sign it and store it next to the artifact, keyed by product and version.
3. Upload it to Dependency-Track so new CVEs are matched against everything you have shipped.
4. Publish VEX statements for “present but not exploitable” findings, so you are not triaging noise at 2am.
5. Keep SBOMs for every version still supported in the field, since reporting covers the installed base.

What should vendors do this month?

If you ship to the EU and do not yet have this running, prioritise in this order:

1. Register with the ENISA Single Reporting Platform and confirm which CSIRT is your coordinator.
2. Name a PSIRT lead and set up a 24/7 on-call rota with a written decision log.
3. Publish an intake channel: security.txt and a disclosure policy.
4. Generate SBOMs for every currently supported release, starting with the products with the most EU customers.
5. Run a tabletop exercise against the runbook above using a real past CVE, and time how long the SBOM lookup takes.

UAE teams already working toward NESA, DESC or CBUAE controls will find a lot of overlap. Our secure CI/CD compliance checklist covers the pipeline side.

Get the PSIRT and SBOM pipeline in place

devsecops.ae sets this up as a fixed-scope engagement: PSIRT roles, runbook and decision log, intake channel, and an SBOM pipeline (Syft or Trivy, signing, Dependency-Track, VEX) wired into your existing CI/CD, finished with a timed tabletop exercise. Talk to us about your product line and EU exposure, and we will scope it against your release process.