A duty that took effect on 11 September 2026 applies to products placed on the EU market years ago, including products that may never have to meet the Regulation’s security requirements. What a board governs now is whether the company could report an exploited flaw in its own back catalogue within 24 hours.
What changed
On 11 September 2026, the German Federal Office for Information Security announced that the Cyber Resilience Act’s reporting obligations now apply to manufacturers of products with digital elements placed on the EU internal market.
Those manufacturers must report actively exploited vulnerabilities, and severe incidents that affect the security of their products. Reports are filed through the Single Reporting Platform operated by ENISA, and reach the coordinating CSIRT of an EU member state and ENISA at the same time. In Germany that CSIRT is CERT-Bund, inside the BSI.
The governance point sits in the timing. The Cyber Resilience Act applies in general from 11 December 2027, but Article 14 applies from 11 September 2026. Article 69 then sharpens it. Products placed on the market before 11 December 2027 become subject to the Regulation’s requirements only if they are substantially modified after that date. The Article 14 reporting obligations are carved out of that relief and apply to every in-scope product already on the market, including products that may never have to meet the Regulation’s substantive security requirements. The duty to disclose has arrived ahead of the duty to engineer to the standard.
Why it matters
The Act is widely read as a product security engineering regime with a 2027 deadline, which leaves the next fifteen months unattended. Until it applies in general, a company can be legally required to tell a regulator within 24 hours about an actively exploited flaw in something it sold on the EU market long before these rules existed.
The clock runs from awareness. For an actively exploited vulnerability, an early warning notification is due without undue delay and in any event within 24 hours, a vulnerability notification within 72 hours covering the product, the nature of the exploit and any mitigating measures taken, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident affecting product security, an early warning is due within 24 hours, stating at least whether the incident is suspected of being caused by unlawful or malicious acts, an incident notification within 72 hours, and a final report within one month of that notification.
Reporting under the NIS2 Directive and the Digital Operational Resilience Act concerns incidents happening to the entity. Article 14 concerns a flaw in what the entity placed into other people’s environments. The centre of gravity moves from enterprise security operations to product accountability, and those two capabilities usually sit in different parts of a company, with different reflexes and different lawyers.
What changes for management
Management needs a defensible view of the company’s back catalogue. The operational test is plain: what did the company place on the EU market, where is it still available or running, and would anyone know if something in it were being actively exploited.
Each part of that test is harder than it sounds. A product with digital elements covers software or hardware and its remote data processing solutions, including components placed on the market separately. Remote data processing counts where the manufacturer developed the software, or had it developed under its responsibility, and the product would not perform one of its functions without it. A product retired from the price list but still supported, distributed, or reliant on a hosted component is not out of reach.
The manufacturer concept also catches organisations that do not think of themselves as technology sellers. A manufacturer markets products with digital elements under its own name or trademark, whether it developed them or had them developed, and whether it charges for them, monetises them or gives them away. An importer or distributor that puts its own name on a product, and anyone who substantially modifies a product and makes it available, is treated the same way. A white-labelled application, a branded device, a customer-facing tool given away without charge: each can carry the obligation.
Whether the company is a manufacturer at all is a legal determination, and most boards have never been asked to confirm it. Reaching an answer takes the legal reading and a working knowledge of what the company actually ships, which is why it resolves faster worked through alongside the people who own each product line than from the corporate register alone.
What changes for the board
A board does not run the reporting process. It does need assurance the process exists before the first warning arrives, because that warning will probably come from outside.
The BSI made that point explicitly. A manufacturer may learn of an actively exploited vulnerability from IT security service providers or from its own customers, and of a severe incident from external tip-offs or from internal log analysis. Awareness can therefore begin in a support inbox, a partner escalation, a security mailbox or a routine log review, inside a team that has no idea it has just started a statutory clock. This is the same governance problem as the moment a reporting clock starts under the financial sector rules, moved to the product side and applied to far more companies. Most companies route inbound security reports through queues built for triage, never for proving when awareness began.
Article 14(8) then moves control of customer communication. Once aware, the manufacturer must inform impacted users, and where appropriate all users, of the vulnerability or incident and of any mitigation and corrective measures they can deploy, in a structured machine-readable format where appropriate. Where the manufacturer fails to inform users in a timely manner, the notified coordinating CSIRTs may inform those users themselves. A company that holds disclosure until a fix is ready may find the disclosure has been made for it.
Jurisdiction deserves board attention for a similar reason. The coordinating CSIRT follows the member state where the manufacturer has its main establishment in the Union, and that is defined as the member state where decisions relating to the cybersecurity of its products are predominantly taken. For a manufacturer with no main establishment in the Union, the Regulation works through authorised representatives, importers, distributors, and finally the location of users. Which regulator supervises the company is therefore set by where engineering and security decisions are actually made, an organisational fact rather than a legal-entity one, and it may not point at the country a board would assume.
Questions boards should now ask
- Which products with digital elements has the company placed or made available on the EU market, including any supplied free of charge?
- Which of those are still in use, supported, distributed, or dependent on a hosted component the company operates?
- Has management formally determined whether the company is a manufacturer under the Regulation, through own-name marketing or substantial modification of another party’s product?
- Where are decisions on product cybersecurity predominantly taken, and which coordinating CSIRT follows from that?
- Which teams could first receive credible evidence of active exploitation, and do they know a 24 hour clock may start when they read it?
- Can the company evidence when an external report or an internal log finding first became known internally, and who may submit an early warning before root cause and impact are settled?
- Can management identify and reach impacted users quickly enough to inform them ahead of a regulator doing so?
- What happens to the release plan when users have to be told before a fix exists?
Practical implications
The task this creates is narrower than the 2027 programme and more immediate: an inventory connecting products to market availability, user reach, reporting ownership and evidence sources, and an operating process in which legal classification, product security triage and customer communication meet before an incident rather than during one.
The exposure is board-level in scale. Non-compliance with the essential cybersecurity requirements in Annex I and with the obligations in Articles 13 and 14 is subject to administrative fines of up to EUR 15,000,000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.
The question this development puts to a board is narrow and answerable: could the company recognise and report active exploitation in something it has already sold, this week. The back catalogue has become a live governance object, and it became one on 11 September.