EU Cyber Resilience Act adds 24-hour vulnerability reporting from 11 September 2026

The reporting obligations of the EU Cyber Resilience Act take effect on 11 September 2026, and they apply to anyone placing a product with digital elements on the European market — for most software vendors, that means the software they ship. A dev.to article published at the end of August 2026 walks through what changes on that date and what does not: only part of the regulation starts applying, but that part puts a hard clock on vulnerability disclosure.

A 24-hour clock to ENISA

The duty that begins on 11 September is narrow but strict. If a vendor learns that a vulnerability in its product is being actively exploited, it has 24 hours to notify ENISA, the EU's cybersecurity agency. The dev.to article stresses that this reporting piece is what kicks in now — not the full regulation — so teams cannot wait for the broader framework to arrive before standing up a notification process.

A staggered timeline

According to the article, Regulation (EU) 2024/2847 lands in three stages. Provisions covering conformity assessment bodies took effect on 11 June 2026 and have already passed. Vulnerability and incident reporting starts on 11 September 2026. The substantive obligations — technical documentation and the software bill of materials requirement — follow on 11 December 2027.

The SBOM clause sits in Annex I, Part II, point 1. It requires components to be documented in a commonly used, machine-readable format covering at least the top-level dependencies. Crucially, the SBOM does not need to be published; it needs to exist and to be handed over when a market surveillance authority asks for it.

The wider compliance landscape

The dev.to post situates the CRA among the other instruments aimed at engineering teams. SOC 2, which descends from the accounting-focused SAS 70 standard published in 1992 and became a separate report in 2010, is voluntary and market-driven: teams pursue it because customers demand it. NIS2, Directive (EU) 2022/2555, is not optional. It applies to entities in essential and important sectors, and its Article 21(2) requires those entities to weigh the security practices of their direct suppliers. That is why NIS2-derived questionnaires reach companies that fall outside the directive's own scope — selling to someone in scope is enough.

The evidence trap

A recurring point in the article is that SOC 2 defines criteria rather than controls. It states outcomes that must be true and leaves each organisation to write, and then prove, the controls that meet them. That freedom cuts both ways: a vaguely worded control can pass an audit while protecting little. For teams running containers on Kubernetes, the article points to CC6 through CC8 — logical and physical access, system operations and change management — as where most technical evidence lands, with CC6.8 covering the introduction of unauthorized or malicious software, which in practice means the image supply chain.

Type II reports add a further constraint. They cover a period, typically six months for a first report, and auditors sample across the entire window. Evidence therefore has to exist continuously rather than be assembled after the fact, which is why last-minute folders of screenshots tend to fail.

Why it matters

The CRA is law rather than a market preference, and 11 September 2026 is a fixed date rather than a negotiation with a customer. Any organisation shipping software into Europe, wherever it is based, needs the ability to detect an actively exploited vulnerability, confirm it, and get a notification to ENISA within a single day. That is an operational capability — detection, triage and escalation — not a documentation exercise, and teams that only confront these questions when a security questionnaire arrives are, on the article's account, already behind.