Cyber Resilience Act reporting starts with system design
From September 2026, tight reporting windows will expose weak ownership and poor product telemetry. Prepare the operating system, not just the form.
The EU Cyber Resilience Act reaches an operational milestone on 11 September 2026. Manufacturers must begin reporting actively exploited vulnerabilities and severe incidents affecting products with digital elements. The Commission describes an early warning within 24 hours of awareness and a fuller notification within 72 hours, submitted through a single reporting platform.
Those windows are short, but the reporting form is not the hard part. The difficult work is knowing that something happened, understanding which products and customers are affected, deciding who owns the response and preserving reliable evidence while a team is under pressure.
Build an inventory you can use during an incident
A spreadsheet created for an audit is not necessarily an operational inventory. Teams need to connect released product versions to components, deployment environments, owners, support periods and affected customers.
A useful software bill of materials can support that work, but only if it reflects what was actually built and shipped. Generate it in the build pipeline, retain it with the release artefact and make it searchable during triage. Include first-party services and operational dependencies, not only open-source packages.
Define "awareness" before a real event
Reporting clocks depend on when the organisation becomes aware. Product telemetry, vulnerability feeds, customer support and supplier notices may all surface the first signal. Write down how each enters the incident process and who has authority to classify it.
Instrument products so a team can answer basic questions without guesswork:
- Which supported versions contain the affected component?
- Is the vulnerable path enabled and reachable?
- Is there evidence of exploitation or material impact?
- Which corrective measure can be delivered safely, and when?
- Who must be informed inside and outside the organisation?
Logging everything is not the answer. Collect the evidence needed for security and support, protect it appropriately, define retention, and test whether responders can retrieve it.
Separate fast decisions from complete answers
An early warning will rarely contain the final root cause. The operating model should allow an authorised person to report credible preliminary information without waiting for certainty, then progressively improve the record.
Create templates for the facts available at each stage. Run a tabletop exercise where the first report is due outside normal hours. Include engineering, security, legal, communications, customer support and senior decision-makers. Test deputies as well as named leads.
Make maintenance a product feature
The CRA reinforces a broader truth: a digital product includes the machinery that updates and supports it. Secure update paths, clear support periods, vulnerability intake and customer communication are part of the product promise.
Procurement must reflect that reality too. Contracts should define vulnerability notification, evidence access, patch expectations and exit support for critical suppliers. A dependency that cannot support your reporting timeline becomes your operational risk.
The immediate deadline is reporting. The durable advantage is a product organisation that can see, understand and correct its software estate quickly.
This article is operational guidance, not legal advice. Confirm whether the CRA applies and how the reporting rules affect your products.