On 11 September 2026 a 24-Hour Clock Starts. If You Do Not Know Your Bill of Materials, You Cannot Stop It.

What actually happens on 11 September 2026?

Most manufacturers have filed the Cyber Resilience Act under “2027 problem”. Understandable, and wrong. Regulation (EU) 2024/2847 entered into force on 10 December 2024, and its security requirements apply in full from 11 December 2027. Two dates sit in between. Since 11 June 2026, Chapter IV on notifying conformity assessment bodies applies, meaning Articles 35 to 51. From 11 September 2026, Article 14 applies: the reporting obligation (Art. 71(2)).

The gap between those dates is not a legal subtlety, it is a question of operational readiness. On 11 December 2027 you prove a product was built securely. On 11 September 2026 you file a report within 24 hours, which presumes you know what is inside your products, who runs them, and who answers the phone at night. The first is an engineering programme with 15 months of runway. The second is a capability that either exists or does not.

That order is the actual problem. Read the regulation back to front and you plan secure development for 2027 while missing that you must already report on insecure legacy products in 2026.

Deadline Reality

The 24-hour clock starts when you become aware, not when a CVE is published. For 2025, VulnCheck counted 884 vulnerabilities with first evidence of exploitation in the wild. 28.96 percent were already exploited on or before the day the CVE was published, up from 23.6 percent the year before. The clock routinely starts before any public record exists.

Why the three deadlines are harder than they sound

Article 14 has two triggers and three reports each: an actively exploited vulnerability contained in a product, and a severe incident affecting the security of the product. Both carry their own chain of deadlines, and the reference points differ.

Trigger	Early warning	Full notification	Final report
Actively exploited vulnerability	24 hours from awareness (Art. 14(2)(a))	72 hours from awareness (Art. 14(2)(b))	No later than 14 days after a corrective or mitigating measure is available (Art. 14(2)(c))
Severe incident	24 hours from awareness (Art. 14(4)(a))	72 hours from awareness (Art. 14(4)(b))	One month after submission of the 72-hour notification (Art. 14(4)(c))

The two final reports hang on entirely different anchors. For a vulnerability, the clock runs from the moment a countermeasure is available. The regulation text explicitly says a corrective or mitigating measure, so a documented workaround starts the 14 days just as a finished patch does. For an incident, what counts is submission of the 72-hour notification, not the moment of awareness and not the availability of a fix. Confuse the anchors and you plan the wrong calendar.

There is also an overlooked clause. Under Art. 14(6), the coordinating CSIRT can request an intermediate report at any point. The three deadlines are a floor, not the complete reporting load. Plan for 24, 72 and 14 without capacity for follow-up questions and you have sized the resources wrong.

What even counts as a severe incident?

Art. 14(5) provides a legal definition, and it deliberately contains no CVSS threshold. An incident is severe if it negatively affects or is capable of negatively affecting the ability of a product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Likewise if it has led or is capable of leading to the introduction or execution of malicious code (Art. 14).

The words “capable of” are the expensive part. The threshold is potential-based, not damage-based. An internal escalation rule reading “we report from CVSS 9.0” has no counterpart in the regulation. The assessment must be product-specific and happen within hours, not at the next security board.

The forgotten fourth duty

Art. 14(8) additionally requires the manufacturer to inform impacted users, and where appropriate all users, about the vulnerability or incident, including mitigating and corrective measures, in a machine-readable format that lends itself to automated processing. Fail to do this and the CSIRTs may inform the users themselves.

This is where many reporting processes tear organizationally. The filing is a form. The user notification is a distribution list, a channel and a machine-readable advisory format that somebody set up beforehand. Improvising both at once under time pressure does not work.

Why end-of-life dependencies are the biggest risk

Here is the real charge. Art. 69(2) largely exempts products placed on the market before 11 December 2027: the remaining CRA requirements only bite on substantial modification from that date. Paragraph 3 makes an exception, in plain words: “By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027” (Art. 69).

In operational language: for the entire legacy base you must report, but you need not have built it securely. The evidence duty is suspended, the reporting duty is not.

That lands precisely on the products nobody likes to talk about. The 2019 appliance generation with a frozen Linux distribution. The industrial gateway with an OpenSSL version that stopped getting updates years ago. The mobile app whose SDK vendor announced end of support. From 11 September 2026 none of it needs a declaration of conformity, but all of it needs a defensible answer to one question: is this vulnerability in one of our shipped products, and is it being exploited.

With end-of-life dependencies, that answer is structurally hard. There is no upstream advisory feed, no maintained version ranges, often not even a reliable package name. The vulnerability surfaces in an exploitation report, and nobody can say within 24 hours which firmware builds contain the affected library. That is why the groundwork for the reporting duty is not compliance work but a question of security architecture.

Why there is no 24-hour report without a bill of materials

An early warning after 24 hours requires three facts no ticketing system produces from nothing: which product is affected, in which shipped versions, and who runs those versions. Research them during the incident and you lose the deadline on the first phone call.

A software bill of materials is therefore not a documentation obligation but the data structure the deadline hangs on. What matters is not that an SBOM exists, but that it exists per shipped release, stored immutably and queryable by machine. An SBOM that lives only in the last CI run’s build directory is worth nothing when the vulnerability sits in a three-year-old version.

The first building block is generating it inside the release process, not after it:

# .github/workflows/release.yml (excerpt)
- name: Generate and sign SBOM
  run: |
    syft dir:. -o cyclonedx-json > sbom-${GITHUB_REF_NAME}.cdx.json
    cosign attest --type cyclonedx \
      --predicate sbom-${GITHUB_REF_NAME}.cdx.json \
      ghcr.io/acme/gateway:${GITHUB_REF_NAME}

- name: Write SBOM immutably into the release registry
  run: |
    curl -sSf -X POST "$SBOM_REGISTRY/api/releases" \
      -H "Authorization: Bearer $SBOM_TOKEN" \
      -F "product=acme-gateway" \
      -F "version=${GITHUB_REF_NAME}" \
      -F "shipped_at=$(date -u +%FT%TZ)" \
      -F "sbom=@sbom-${GITHUB_REF_NAME}.cdx.json"

The second is the query. It must answer in minutes what otherwise takes days, and it must include the legacy base:

def affected_releases(cve_id: str) -> list[dict]:
    """Produces the data basis for the 24-hour early warning
    and for the user notification under Art. 14(8)."""
    advisory = advisory_feed.get(cve_id)
    hits = []

    for release in sbom_registry.all_shipped_releases():
        for component in release["components"]:
            if component["purl"] not in advisory["affected_purls"]:
                continue
            if not version_affected(component["version"], advisory["ranges"]):
                continue

            hits.append({
                "product": release["product"],
                "version": release["version"],
                "component": component["purl"],
                "eol": component.get("end_of_life", False),
                "patch_available": advisory.get("fixed_version") is not None,
                "users": customer_registry.lookup(release["product"], release["version"]),
            })

    return hits

The last fields matter most. A hit with eol: true and patch_available: false means the 14-day clock for the final report only starts once a documented mitigating measure exists, and that measure must be described, approved and communicated. This is work you do before the incident or not at all.

In practice that means three integrations: the SBOM registry into the release process, the customer registry into the version records, and both into a continuously watched advisory and exploitation feed. Without the third, you learn about exploitation from a customer, and twelve of your 24 hours are already gone.

Who reports to whom, and through which tool?

The report is filed once. The Commission puts it unambiguously: “Manufacturers report only once through the CRA Single Reporting Platform (SRP)” (Commission, CRA reporting). The platform forwards it simultaneously to the coordinating CSIRT and to ENISA (Art. 14(1) and (3)). Under Art. 16(1) ENISA establishes it and also operates and maintains it.

The competent body is the CSIRT of the member state of your main establishment. The CRA defines that not via the commercial register but via the place where decisions on the cybersecurity of the products are predominantly taken (Art. 14(7)). For third-country manufacturers a cascade applies: authorised representative, then importer, then distributor, otherwise the member state with the most users. If development, product security and management sit in several countries, put that assignment in writing before it is disputed.

Two qualifications. First, forwarding to ENISA is not automatic: under Art. 16 a CSIRT may withhold dissemination of a report on justified cybersecurity grounds, in particular during an ongoing coordinated disclosure, and must then inform ENISA without undue delay about the decision, the justification and the planned time of dissemination (Art. 16). Second, per ENISA the list of designated coordinating CSIRTs is not yet published. For Germany, the BSI is developing technical guideline BSI TR-03183 to make the CRA requirements concrete for manufacturers and products, and contributes to CEN, CENELEC and ETSI.

Access runs through an EU Login account. Per ENISA, the authorisation is validated by the coordinating CSIRT after first platform access, in parallel with the ongoing reporting process. The account should therefore exist long before the first incident.

One detail to plan for: on 29 June 2026 the specialist service cyberresilienceact.eu noted that the Single Reporting Platform was not yet live, while ENISA had promised access and registration guidance, training and dry-run material for June 2026. Whether that has changed cannot be stated reliably. The Article 14 deadlines apply regardless of the tool’s availability. A process that relies exclusively on a portal has no fallback.

What has to be in place organizationally in the remaining weeks

The technical groundwork is one half. The other is a handful of decisions that cannot be bought.

Building block	What must be settled	Typical mistake
Competent CSIRT	Main establishment per Art. 14(7) documented, cascade for third countries	Registered office instead of where security decisions are taken
Platform access	EU Login account created, at least two people authorised	One account on one person, who is on holiday
Becoming aware	Which signal starts the 24-hour clock, and who starts it	Clock starts at the management meeting
Assessment	Product-specific classification per Art. 14(5), no CVSS threshold	Internal rule “report from CVSS 9.0”
User notification	Distribution list and machine-readable advisory format per Art. 14(8)	PDF attachment to a shared mailbox
Follow-ups	Capacity for intermediate reports per Art. 14(6)	Only the three mandatory deadlines staffed

The rest is process. Building the filing, the internal escalation and the user notification as one end-to-end automated chain does not save minutes in an incident, it saves the hours lost between becoming aware and the first management decision. It also produces the record of who knew what when that you need for the final report.

One new aid exists. On 27 July 2026 the Commission published its first official CRA application guidance, communication C(2026) 5252 with an annex, based on Art. 26 CRA. It covers scope, substantial modification, the support period and the reporting and risk assessment duties, contains 67 practical examples and targets micro, small and medium-sized enterprises (Commission, 27 July 2026). It is explicitly non-binding, but the best available indication of how supervisors will read the open terms.

What failure costs

Art. 64 sets the frame. Infringements of the requirements in Annex I and of the obligations in Art. 13 and Art. 14 carry fines of up to 15 million euro or 2.5 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. For other infringements the ceiling is 10 million euro or 2 percent, and for incorrect or incomplete information supplied to market surveillance authorities 5 million euro or 1 percent (Art. 64).

Two exemptions matter and are frequently skimmed. Microenterprises and small enterprises are exempt from fines for missing the 24-hour early warning under Art. 14(2)(a) or Art. 14(4)(a); the remaining Article 14 deadlines and duties are not covered. Open-source software stewards are exempt from fines for infringements of the regulation. Both defuse the deadline in the sanction, not in the duty. A manufacturer who fails to report has still infringed Article 14, with all the market surveillance consequences attached.

How the duty travels down the supply chain

The more interesting enforcement happens through contracts, not fines. Honeywell runs a public CRA supplier page requiring suppliers to have working vulnerability and incident reporting processes by 11 September 2026, including registration on the ENISA Single Reporting Platform; CRA compliance attestations or detailed roadmaps for all components feeding into EU products by Q4 2026; and full CRA conformity including conformity assessment, CE marking and EU declaration of conformity by 11 December 2027 (Honeywell).

That is what makes the deadline real. A supplier below every fine threshold still loses the framework agreement if it cannot produce the attestation.

The answer is forming in parallel on the open-source side. Seven foundations - Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation, Rust Foundation and Eclipse Foundation - announced on 2 April 2024 that they would develop common specifications for secure software development to implement the CRA (Eclipse). The Eclipse Foundation’s Open Regulatory Compliance Working Group, which grew out of it, now counts more than 50 members, including Microsoft, Red Hat, GitHub, Google, Nokia, Mercedes-Benz, ekxide and Open Source Matters, and published its first CRA resources plus a roadmap on 14 August 2025 (Eclipse Newsroom).

Supply Chain Effect

The CRA binds manufacturers. It gets enforced first through purchasing terms. Ship components into an EU product and the 11 September 2026 deadline reaches you from your customer rather than from an authority, complete with evidence and a roadmap.

What you have to decide this week

Until 11 September 2026 the regulation asks nothing about the quality of your software. It asks about the responsiveness of your organization: can you say within one working day whether an actively exploited vulnerability sits in one of your shipped products, and can you reach the people affected.

That capability breaks down into three decisions. First, a named person who starts the clock, plus a deputy. Second, an SBOM per shipped release, stored immutably, produced retroactively for the legacy base. Third, a machine-readable channel to users that is not built during the incident.

Everything else can wait until 2027. These three cannot. To see what this chain looks like in an existing product landscape, talk to us.

Sources

Note on sourcing: All citations of Regulation (EU) 2024/2847 are taken from matching full-text mirrors (craact.eu, european-cyber-resilience-act.com, springlex.eu); the EUR-Lex full text was unavailable on retrieval. Only the version published in the Official Journal is legally authoritative. The status of the Single Reporting Platform reflects the documented state as of 29 June 2026 and may have changed. The designation of coordinating CSIRTs was unpublished at the time of writing. This article is not legal advice; for your specific products and obligations, engage qualified counsel.

Key Takeaways