The EU's new cyber rules put software makers on a 24-hour clock

A major cyber rule has moved from preparation to practice

A connected lock, a router and a business application can fail in very different ways. Yet all can leave users exposed when a serious security problem is known inside a supplier but the people who can coordinate a response do not have timely information. The European Union is trying to narrow that gap.

On September 11, 2026, reporting obligations under the Cyber Resilience Act began applying to manufacturers of products within its scope. The European Commission confirmed the start, while ENISA, the EU cybersecurity agency, announced the initial operating capability of a shared reporting platform. This is an implementation milestone, not the announcement of a newly discovered cyberattack.

The immediate change concerns reporting actively exploited vulnerabilities and severe incidents affecting product security. It is important not to confuse that with the CRA's wider product-design and conformity requirements: those mainly become applicable on December 11, 2027.

Sources: European Commission: September 11 reporting duties begin; ENISA: Single Reporting Platform launch, September 11; European Commission: CRA overview and phased application

The rules follow the product, not just the company's address

The CRA covers software and hardware made available on the EU market whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network. A manufacturer does not escape the framework simply because its headquarters are outside the EU. Nor are covered older products automatically outside the reporting regime: Article 69 expressly extends Article 14 to products placed on the market before December 11, 2027.

That is not the same as saying every website, cloud service or developer is covered. The regulation distinguishes a product's necessary remote data-processing functionality from unrelated websites and cloud services, and it contains sector-specific exclusions. An ordinary business using software is not automatically its manufacturer. Classification depends on the product and the organisation's role; this article is general news analysis, not a legal assessment of a particular business.

Sources: Cyber Resilience Act: Articles 2, 14, 16, 69 and 71; European Commission: Summary of the legislative text

An exploited vulnerability is not simply an imperfect app

ENISA identifies two mandatory reporting categories. An actively exploited vulnerability involves reliable evidence of exploitation by a malicious actor, not merely the discovery that a flaw could be exploited. A severe incident is a separate category, assessed against the CRA's product-security criteria. The distinction prevents a headline about reporting from turning into an instruction to treat every software bug as an emergency notification.

For illustration, a researcher identifying a weakness and an attacker using it without permission are different facts. A manufacturer still needs to assess a report, preserve what is known and avoid inventing certainty. A reassuring statement that a problem is only theoretical is also insufficient if credible exploitation evidence exists. These are explanatory examples, not findings about any named supplier.

Sources: ENISA: Reporting platform FAQ and launch limitations

The reporting clock has stages—and two different finish lines

The Commission's reporting guidance sets out an early warning within 24 hours of awareness and a more detailed notification within 72 hours of awareness. Both must be made without undue delay. The second deadline does not mean 72 additional hours after the first report.

The final-report trigger then differs by event type. Article 14 links a vulnerability's final report to the availability of a corrective or mitigating measure; for a severe incident, it links the final report to the incident notification. These are reporting deadlines, not a universal promise that a patch must exist within 24 hours. The distinction matters when an investigation is still developing.

Sources: European Commission: CRA reporting obligations; Cyber Resilience Act: Articles 2, 14, 16, 69 and 71

For users, the value is an actionable warning

Article 14 also requires manufacturers to inform impacted users—and, where appropriate, all users—about the vulnerability or incident and, where necessary, measures they can take. A notification to authorities is therefore not the whole communication task. Readers should nevertheless avoid assuming that every official submission immediately becomes a public alert containing every technical detail.

Our assessment is that a useful customer warning answers ordinary questions: is my model or version affected, what should I do now, and where will the next update appear? A notice that is technically complete but impossible to understand can leave the person holding the device no better equipped to respond. Success should be judged partly by whether the warning reaches the right users and gives them a feasible action.

Sources: Cyber Resilience Act: Articles 2, 14, 16, 69 and 71

One reporting platform can help—and creates responsibilities of its own

ENISA says the Single Reporting Platform lets a manufacturer submit once and communicate with the relevant authorities. Its launch supports mandatory reporting; voluntary reporting functionality is planned for a later phase. The agency describes the release as an initial capability and says it will expand and improve the platform based on operational experience.

Coordination has an obvious potential benefit: the same vulnerable product can be sold across several countries, while knowledge about an attack may initially sit in one place. But concentrating sensitive information also makes confidentiality and controlled access essential. ENISA describes safeguards, and the legal framework allows delayed dissemination in exceptional cybersecurity-related circumstances.

Those safeguards are a design requirement, not evidence that the system is invulnerable. Lumacta has not audited the platform or submitted a test incident. The result to watch is whether it helps defenders act sooner without unnecessarily widening access to sensitive, still-unresolved information.

Sources: ENISA: Single Reporting Platform launch, September 11; ENISA: Reporting platform FAQ and launch limitations; Cyber Resilience Act: Articles 2, 14, 16, 69 and 71

Small firms face an operational problem, not just a form

For a small software or hardware company, the hard part may happen before anyone opens the reporting portal. Someone has to recognise an incoming security report, identify the affected product, involve the right colleague and keep track of what is established. Our analysis is that weak internal ownership can consume a short deadline faster than the form itself.

The Commission recognises the resource gap and points to support such as training, testing, regulatory sandboxes and funded assistance initiatives. Its legislative summary also explains a targeted protection from administrative fines for micro and small manufacturers missing the 24-hour early-warning deadline. That is not a blanket exemption from reporting or from the rest of the framework.

A practical planning question is who can respond when the usual security contact is unavailable. Answering that question does not require a large enterprise department, but it does require an explicit responsibility. How much implementation costs smaller firms remains an outcome to measure, not a number established by this launch.

Sources: European Commission: Support for micro, small and medium enterprises; European Commission: Summary of the legislative text

Open-source contributors are not all treated like commercial vendors

The CRA has a differentiated approach to open source. The Commission explains that commercial activity matters and that people contributing code to free and open-source software outside their responsibility are not simply treated as its manufacturer. A commercial product does not, however, become exempt merely because some or all of its code is available to inspect.

There is also a separate category of open-source software stewards: organisations that provide sustained support for certain projects intended for commercial use. ENISA's launch announcement specifies that the relevant steward reporting obligations start on December 11, 2027, not on the September 2026 manufacturer date.

The distinction is economically important. A volunteer contributor, a foundation maintaining infrastructure and a company selling a finished product may occupy different roles. Treating them as interchangeable would mislead readers and obscure who can actually organise a response. Individual projects should use the official guidance for their own circumstances.

Sources: European Commission: Open-source provisions; ENISA: Single Reporting Platform launch, September 11

The economic stakes go beyond a compliance budget

Our reading is that the CRA raises a broader question about the price of digital products: who pays for security after the sale? A low purchase price can look less attractive if the buyer later faces an outage, emergency replacement or time spent trying to identify an abandoned version. The reporting phase makes serious problems more visible to authorities; the wider framework aims at product lifecycle responsibilities.

There are plausible gains and costs. Better information and clearer ownership could reduce duplicated investigations and give responsible suppliers a more credible way to demonstrate their approach. Conversely, additional engineering, documentation and coordination work could weigh more heavily on smaller portfolios. These are mechanisms to evaluate, not measured economic effects of the first day.

For suppliers serving several markets, maintaining different product processes may itself be expensive. A company could choose to apply some stronger practices more broadly, but a worldwide improvement is not automatic. Neither a European competitive advantage nor a collapse in innovation can be inferred from the launch of one reporting system.

Sources: European Commission: CRA overview and phased application; European Commission: Support for micro, small and medium enterprises

September's reporting milestone is not full product certification

The Commission's CRA overview describes a wider framework for secure design, vulnerability handling and maintenance across a product's lifecycle, supported by conformity assessment and CE marking. Its main obligations apply from December 11, 2027. Some conformity-assessment-body provisions started earlier, on June 11, 2026; the timetable is deliberately phased.

This means a shop full of connected products does not become newly CRA-certified overnight because reporting has begun. Nor does the date itself repair vulnerable firmware already installed in a home. For buyers, a concrete support policy and intelligible security notices remain more useful evidence than an unsupported claim that a product is now completely safe.

For businesses, preparing for the later requirements is a separate task from meeting today's reporting duties. Keeping those tracks distinct helps avoid two opposite mistakes: waiting until 2027 to consider reporting, or describing every future product obligation as already enforceable in September 2026.

Sources: European Commission: CRA overview and phased application; European Commission: Summary of the legislative text

What would make this a success?

The strongest test is not how many reports reach a portal. It is whether relevant information reaches defenders in time, affected users receive useful guidance and the interval between awareness and practical protection becomes shorter. A rising notification count might initially reflect better visibility rather than a sudden deterioration in security.

Our conclusion is that this is a consequential change in accountability, but not a technological cure. A reporting deadline can create urgency and a common channel can improve coordination. Neither replaces a capable investigation, a tested mitigation or a customer who can actually install an update.

The next chapter should be judged on operational evidence: the quality of notifications, the handling of sensitive information, the burden on small suppliers and the experience of users dealing with an affected product. Those results will determine whether the new clock delivers safer technology or merely faster paperwork.

Sources: European Commission: September 11 reporting duties begin; ENISA: Single Reporting Platform launch, September 11