Most compliance calendars record the Cyber Resilience Act as a December 2027 obligation. That is when the substance of the regulation applies: security by design, technical documentation, conformity assessment and CE marking.
However, the reporting obligations arrive considerably earlier. From 11 September 2026, manufacturers of products with digital elements must notify actively exploited vulnerabilities and severe incidents within defined timeframes, and those duties extend to products already placed on the EU market. A product first shipped in 2018 and still sold today falls within scope from day one.
For manufacturers, this introduces a 24-hour reporting clock. For the far larger population of organisations that buy and operate technology rather than place it on the market, the CRA introduces something less visible and considerably less prepared for: a new stream of security notifications arriving from third parties, on their timetable rather than yours.
Two weeks before the date, very few organisations have determined who receives them.
No submission is due on the date itself. There is no declaration to file and no form to complete. 11 September is the point at which event-driven obligations take effect, which makes it harder to plan for than a conventional deadline. The trigger is an incident, and incidents do not observe calendars.
For manufacturers the framework is clear. Once an organisation becomes aware that a vulnerability in one of its products is being actively exploited, it has 24 hours to issue an early warning, 72 hours to provide a fuller notification, and a defined period thereafter to submit a final report. Penalties for non-compliance with the regulation's core manufacturer obligations reach €15 million or 2.5% of global annual turnover, whichever is higher.
Whether an organisation falls into that category is addressed below. The broader observation, which has attracted little attention so far, is that the CRA's most immediate operational effect will be felt by organisations it does not directly regulate.
It is worth pausing on the sequence of what takes effect in September.
The reporting platform operated by ENISA is scheduled to be operational by that date rather than in advance of it. The harmonised standards that will define what compliance looks like for manufacturers remain in public enquiry. And the requirement to maintain a coordinated vulnerability disclosure policy, the mechanism through which manufacturers most commonly learn that their products are being exploited, does not become generally applicable until December 2027.
The obligation to report therefore precedes the obligation to establish the channel through which most reports originate.
This is not an oversight. It reflects a deliberate change in how EU digital regulation is sequenced: obligations are staged and brought into force ahead of the supporting infrastructure, on the reasoning that waiting for complete tooling would delay risk reduction by years. NIS2 followed this pattern. The AI Act followed it. The CRA is following it now.
For GRC functions, the implication is structural rather than tactical. Compliance programmes increasingly have to operate in the interval between an obligation taking effect and the ecosystem around it maturing. Planning on the assumption that regulation arrives fully formed is planning against a model that no longer applies.
This warrants a short and deliberate assessment, because the exceptions are expensive.
Few organisations describe themselves as manufacturers. The regulation does not rely on self-description. It considers what is placed on the EU market and under whose name or trademark. Own-brand hardware, bundled firmware, connected devices resold under a company's own logo and software embedded within a physical product can all bring an organisation within scope. Importers and distributors that rebrand a product, or modify it substantially, assume the manufacturer's obligations along with it.
The relevant question is therefore not whether an organisation develops software. It is: what does the organisation place on the EU market, under whose name, and what does that product contain?
We would recommend documenting the answer this week. For most organisations it is a short exercise. For a minority it is the difference between a managed programme and an unplanned one.
Alongside its duties towards authorities, the CRA requires a manufacturer that becomes aware of an actively exploited vulnerability or severe incident to inform the users affected, and where appropriate all users, along with any mitigating action those users can take. Where a manufacturer does not do so within a reasonable period, the coordinating national CSIRT may communicate the information directly.
Considered from the recipient's side, this creates an entirely new inbound flow. From 11 September, organisations will begin receiving security notifications concerning products in their own environment, issued by the manufacturer of those products, which is frequently not the party holding the commercial relationship.
Three consequences follow.
Ownership is undefined. These notifications typically arrive with an account manager, within procurement, or in a shared mailbox reviewed during business hours. In our experience, supplier vulnerability advisories are rarely routed into incident triage by design. They are escalated informally, by whoever happens to recognise their significance.
The notification initiates assessment, not reporting. This distinction is frequently misstated and is worth being precise about. A manufacturer's advisory does not in itself constitute a reportable incident. Whether it becomes one under NIS2 or DORA depends on whether the organisation's own services are materially affected, which is rarely apparent within the first hour. That is precisely the argument for structuring the first hour. Where the threshold is subsequently met, the organisation will be expected to evidence the point at which it became aware.
Contracts do not currently address it. Few supplier agreements specify the notification channel, the format, the named recipient or the expected timeframe. Here the CRA offers procurement something it has previously lacked. For a decade, supplier security assurance has rested largely on questionnaires with limited contractual force. The regulation now establishes a baseline against which specific commitments can be negotiated: access to a software bill of materials, a published disclosure policy, a defined support period and agreed notification arrangements. It should be noted that the CRA obliges manufacturers to produce an SBOM; it does not oblige them to provide it to their customers. That distinction is what contract renewals are for, and most renewals fall well before December 2027.
Every timeframe in this regime runs from the point of awareness.
The European Commission has addressed this at the manufacturer level, publishing guidance in July 2026 that explains when a manufacturer is regarded as having become aware. What no external guidance can determine is who, within a given organisation, is capable of becoming aware on its behalf.
In practice the signal arrives through a support engineer at 19:00, a researcher writing to a generic mailbox, or a customer's security operations team contacting an account manager who is on leave.
The parallel with GDPR is instructive. Breaches have been declared weeks late, not through concealment, but through classification failure. Support recorded the issue as a defect. IT treated it as a misconfiguration. Nobody had agreed what constituted a reportable event, the assessment was never initiated, and legal became aware only when a customer raised a question.
Three things should exist in documented form before 11 September: the criteria that trigger immediate assessment, the individuals authorised to escalate and make a determination outside business hours, and the record in which that moment is captured.
Two weeks is not sufficient to establish a full CRA programme. It is sufficient to establish the components that operate first.
For organisations placing products on the EU market:
For all other organisations:
The final item is the only one that demonstrates whether the others function.
An organisation can deploy every available tool and still miss the moment that matters.
An early warning cannot be filed on the strength of a certificate. A product cannot be classified by a policy. And a 24-hour assessment cannot be conducted against a process that exists only as a document nobody has rehearsed.
The organisations that manage September well will be those in which a named individual, contacted at 19:00 on a Saturday, understands that they are authorised to act.
Whatever the technology, it begins with the right dose of governance.
Two weeks is not enough to build a CRA programme, but it is enough to answer the two questions this article raises: whether the regulation applies to your organisation, and who receives the notification when it arrives.
Our CRA services cover applicability scoping, Article 14 reporting readiness, supplier notification routing, and the integration of CRA obligations into the NIS2 and DORA programmes already under way.
We would encourage organisations to have that conversation before 11 September. After the date, it becomes a different one.