The CRA reporting clock starts on 11 September: is your software team ready?

On 11 September 2026, the first major obligations of the EU Cyber Resilience Act begin to apply.

The deadline is now drawing visible attention on X from security practitioners, embedded-software companies and open-source organisations. That attention is justified: manufacturers of products with digital elements may have only 24 hours after becoming aware of an actively exploited vulnerability or a severe security incident to submit an early warning.

This is easy to misread as a compliance-form problem.

It is actually an engineering and operating-model problem.

If a team cannot quickly identify affected products, versions, customers and mitigations, it cannot produce a reliable notification under pressure. If ownership is unclear, a 24-hour clock disappears into internal forwarding, technical debate and management escalation.

The practical question for product leaders is therefore not only “Do we understand the regulation?” It is:

Can our software organisation detect, classify and escalate the right event in time?

What changes on 11 September 2026

The Cyber Resilience Act, Regulation (EU) 2024/2847, applies broadly to products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect connection to a device or network.

Most of the regulation applies from 11 December 2027. The reporting obligations begin earlier, on 11 September 2026.

Under Article 14, manufacturers must notify:

• actively exploited vulnerabilities in a product with digital elements; and
• severe incidents that affect the security of such a product.

For both categories, an early warning must be submitted without undue delay and, at the latest, within 24 hours after the manufacturer becomes aware of the event. Unless the relevant information has already been supplied, a fuller notification follows within 72 hours.

The later deadlines differ. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month after the incident notification.

Notifications are submitted through the EU’s single reporting platform to the relevant coordinating CSIRT and ENISA.

The distinction matters: this is not a duty to report every bug, every attempted attack or every service interruption. The regulation defines specific thresholds. Teams need a classification path that can distinguish them quickly and consistently.

This article is an engineering readiness guide, not legal advice. Whether a particular product or company is in scope requires a proper assessment of the product model, supply chain and applicable exclusions.

The hardest word is “aware”

The reporting clock starts when the manufacturer becomes aware of the actively exploited vulnerability or severe incident.

That makes awareness an operational property.

Imagine a customer reports suspicious behaviour to support on Friday afternoon. A dependency scanner has already raised an alert, but it sits in a dashboard nobody owns. An engineer sees related errors in production logs. The product team does not yet know whether exploitation is active or which versions are affected.

At what point is the company aware? Who is authorised to decide? Who preserves the evidence? Who wakes the security and legal contacts?

A policy document cannot answer these questions during an incident unless the workflow behind it has been designed and rehearsed.

The organisation needs a defined intake path for signals from:

• customers and support;
• security researchers and coordinated disclosure channels;
• dependency and container scanners;
• cloud, identity and endpoint alerts;
• application logs and anomaly detection;
• suppliers, maintainers and public vulnerability feeds.

Every relevant signal needs an owner, a severity path and an escalation time. Otherwise “awareness” is scattered across inboxes, dashboards and individual judgement.

The 24-hour deadline depends on product architecture

When an actively exploited vulnerability appears, the first technical questions are predictable:

• Which products contain the affected component?
• Which versions and deployments are exposed?
• Is the vulnerable path reachable in the actual configuration?
• Which customers or markets may be affected?
• Can the feature be disabled, isolated or rate-limited?
• Is a patch available, and can it be deployed safely?

These are architecture questions before they are reporting questions.

A maintained component inventory, software bill of materials, deployment inventory and ownership map can reduce investigation time dramatically. But documents alone are not enough. The information must connect a dependency to a product, a product to deployed versions, and those versions to an accountable team.

The same is true for observability. Logs should make security-relevant behaviour visible without exposing sensitive information. Deployment data should show what is actually running, not only what the repository says should be running. Feature flags and isolation boundaries should provide safe mitigation options when a complete fix cannot be delivered immediately.

Good architecture does not guarantee compliance. It makes timely, evidence-based decisions possible.

Build a reporting lane into incident response

Many incident-response plans focus on containment, recovery and customer communication. The CRA adds a parallel regulatory lane.

That lane needs explicit roles:

1. Technical incident lead: establishes facts, affected versions, severity and mitigation status.
2. Product owner: explains product use, customer impact and operational consequences.
3. Security or compliance owner: applies the reporting criteria and coordinates the notification.
4. Executive decision owner: resolves high-impact decisions without becoming a bottleneck.
5. Communications owner: keeps customer guidance consistent with technical and regulatory reporting.

For a small company, one person may hold several roles. The important point is not the size of the chart. It is that the responsibilities are named before the incident.

The team should also prepare a minimum evidence package:

• product and affected-version identifiers;
• discovery time and source;
• current assessment of exploitation or incident severity;
• affected security properties and business functions;
• countries where the product is available, where relevant;
• corrective or mitigating actions already taken;
• actions users can take;
• open questions and the owner of each one.

The first report does not require a complete root-cause analysis. Waiting for certainty can be the greater failure. The workflow should support an accurate early warning with clearly marked unknowns, followed by better information at the later stages.

Five readiness checks to run now

With the deadline days away, teams should prioritise the controls that determine whether they can respond at all.

1. Confirm scope and ownership

Create a list of products with digital elements placed on the EU market, the legal manufacturer for each product and the accountable product and security owners. Clarify edge cases with qualified legal counsel rather than allowing assumptions to persist.

2. Define the classification decision

Translate the Article 14 thresholds into a short triage guide. Include examples for actively exploited vulnerabilities, severe security incidents and events that do not meet the threshold. State who can make the reporting decision and who acts if that person is unavailable.

3. Connect technical inventories

Test whether the team can move from a vulnerable package or component to affected products, deployed versions and customer impact. An SBOM that cannot be connected to production reality is incomplete operationally.

4. Prepare the notification workflow

Confirm access to the reporting platform, relevant coordinating CSIRT details, internal contact lists and the information needed for 24-hour and 72-hour submissions. Do not discover access or approval problems during a live incident.

5. Run a tabletop exercise

Choose a realistic scenario: an exploited dependency in a customer-facing product, a malicious update, or a security incident that affects confidentiality or integrity. Start the clock and observe where the process stalls. Fix those handoffs first.

AI-assisted development increases the need for traceability

AI coding tools can increase the rate at which teams introduce, update and combine software components. They can also help analyse dependency graphs, draft incident timelines, compare affected versions and keep response documentation current.

But automation does not remove accountability.

AI-generated code still needs provenance. Suggested dependencies still need ownership. Agent-made changes still need review and deployment records. An AI assistant may accelerate investigation, but it should not make unsupervised legal classifications or send regulatory notifications.

The useful pattern is supervised acceleration: machines gather evidence and reduce manual search; accountable people evaluate the threshold and approve external reporting.

The deadline exposes whether the product is operable

The CRA reporting clock is a compliance requirement, but it also reveals something more fundamental.

A product organisation that knows what it runs, who owns it, how it fails and how to mitigate it is better prepared for customers, audits and ordinary incidents. A team that cannot answer those questions within 24 hours has an operational problem even before regulation enters the discussion.

The strongest response to 11 September is therefore not a new document stored in a compliance folder. It is a tested path from signal to decision:

detect, classify, contain, evidence, notify and improve.

That path belongs in the architecture and operating model of every serious digital product.

If your team needs to turn CRA requirements into a practical product-security workflow, McDougall Digital can help map the architecture, ownership, evidence and incident-response changes before the first real notification clock starts.