9 min read<\/p>\n
On 11 September 2026, Article 14 of the Cyber Resilience Act comes into force.<\/strong> From that date, manufacturers must report actively exploited vulnerabilities and serious security incidents within fixed deadlines. For CIOs and CDOs, the real message is in procurement: the reporting obligation applies to the manufacturer. Organisations that source products from manufacturers whose processes are not yet in place will learn about an actively exploited vulnerability in their own environment too late-or not at all.<\/p>\n Key Takeaways<\/p>\n Related<\/span>Why Your Cloud Bill Never Gets Smaller<\/a> \/<\/span> AI Regulation: Up to 3 Percent of Corporate Revenue<\/a><\/p>\n The Cyber Resilience Act entered into force on 10 December 2024. The main obligations take effect on 11 December 2027. In between lies the deadline that is now occupying operations: Article 14 kicks in on 11 September 2026. In larger organisations, CIOs, CDOs and IT strategists control budgets, supplier relationships and architectural decisions. It is precisely here that the impact of the reporting obligation lands-even though the organisation itself is generally not subject to the reporting obligation.<\/p>\n What is the Cyber Resilience Act?<\/strong> The Cyber Resilience Act is an EU legal framework for the cybersecurity of products with digital elements. It obliges manufacturers to meet security requirements throughout the product lifecycle and to report actively exploited vulnerabilities and serious security incidents. The CRA entered into force on 10 December 2024. Article 14 applies from 11 September 2026, with the main obligations taking effect on 11 December 2027.<\/p>\n For the CIO, the assignment of obligations is the central message. The reporting obligation falls on the manufacturer. The operator purchases products that run in networks, controls and specialist applications. If the manufacturer does not have its reporting and information channels under control, the operator lacks timely information about actively exploited vulnerabilities in its own environment. The action perspective therefore lies in contracts, supplier discussions and supply-chain governance.<\/p>\n Manufacturers must report simultaneously to the coordinating CSIRT and to ENISA. A joint reporting platform is provided for this purpose. Technical details of this platform have not yet been publicly clarified. For operational purposes, the process within the supply relationship is key: the manufacturer remains the addressee of the reporting obligation and the point of contact for the buyer.<\/p>\n The responsibility does not end at the manufacturer\u2019s bill of materials. The manufacturer remains accountable for the entire component, even if it sources parts externally. The deadlines of 24 and 72 hours apply to the manufacturer. They do not automatically apply to every supplier in the chain. If you, as a CIO, manage a multi-tier supply chain, you must clarify how information flows from sub-suppliers to the manufacturer and from the manufacturer into your own operations.<\/p>\n Even the end of support only partially alters the allocation of responsibility. When a component reaches end-of-support, the manufacturer remains responsible for vulnerability remediation for at least five years. For architectures with long operational lifespans, this means: a product that falls out of active support does not fall out of the manufacturer\u2019s security responsibility. This timeframe must be factored into procurement decisions when evaluating product lifecycle and replacement strategy.<\/p>\n Article 14 distinguishes between two scenarios: actively exploited vulnerabilities and severe security incidents. Both paths begin with an early warning within 24 hours. These deadlines apply to the manufacturer. For operators, these tight timelines do not constitute a separate statutory reporting obligation under Article 14, but they do set the pace at which information must circulate within the manufacturer\u2019s ecosystem if your own infrastructure is affected.<\/p>\n For actively exploited vulnerabilities, additional information must follow within 72 hours, and a final report within 14 days of a corrective measure becoming available. For severe security incidents, the incident report must be filed within 72 hours, and the final report within one month of the incident report. If you, as a CIO, discuss incident and vulnerability processes with manufacturers, these stages form the baseline for the conversation: when does the customer learn of the early warning, when of the follow-up report, and when of the corrective action?<\/p>\n The CRA provides for fines of up to \u20ac15 million or 2.5 percent of global annual turnover. The sanction applies to the entity subject to the obligation-in the reporting logic of Article 14, this is the manufacturer. For the purchasing CIO, the potential fine height shifts the balance of negotiation power: a manufacturer with unclear processes carries regulatory risk that translates into delivery, delay, and information risks within the supply relationship. Predictions about enforcement practices by authorities should not be factored into planning, as they are not substantiated. What is substantiated are the deadlines, the addressees, and the sanction framework.<\/p>\n General assurances of legal compliance are not enough. Supplier contracts must include evidence, reporting channels, updates, and a defined end of support. These points are documented as requirements. There are no official template texts for specific contract clauses. Procurement, legal, and security teams must translate these requirements into their own contractual language and apply them to existing supplier relationships.<\/p>\n Evidence must clarify whether the manufacturer actually controls its CRA-relevant processes. Reporting channels must specify how the operator learns about an actively exploited vulnerability and who internally receives the information. Updates must define how corrective measures are provided and documented. A defined end of support clarifies when active support ends and how the at least five-year responsibility for vulnerability remediation after support ends is reflected in the relationship.<\/p>\n In supplier discussions, a simple audit framework is useful. Who at the manufacturer is responsible for reporting to the coordinating CSIRT and ENISA? How does the information reach the customer channel in parallel? Which sub-suppliers are part of the overall component for which the manufacturer remains responsible? How long does support run, and how is the remediation obligation organized afterward? These questions remain within the scope of the documented requirements and avoid speculation about regulatory practices or implementation costs.<\/p>\n Architectural decisions hinge on the same points. Products with unclear end-of-support, vague update paths, or missing reporting channels increase operational risk. Article 14 obliges the manufacturer to report actively exploited vulnerabilities and severe incidents to the coordinating CSIRT and ENISA. Affected users must also be informed in parallel. End of support and update paths are governed by other parts of the CRA. The CIO manages risk through selection, contract design, and escalation paths, even though the legal reporting obligation lies with the manufacturer.<\/p>\n The DIHK warns of significant burdens on small and medium-sized enterprises due to CRA implementation. Many smaller manufacturers are unsure whether the CRA even applies to them. Some are considering withdrawing products from the market. For the CIO, this is not an abstract report on the middle market-it\u2019s a procurement problem as soon as a niche supplier exits or streamlines its portfolio.<\/p>\n Larger organizations often rely on specialized components: control modules, sensors, industry-specific software, embedded systems. If a small manufacturer deems CRA obligations too onerous and discontinues a product, replacements, expertise, and migration paths disappear. The proactive approach lies in identifying critical niche suppliers early, verifying their CRA readiness, and preparing alternatives or transition strategies.<\/p>\n This counterpoint therefore belongs in every supplier discussion with smaller providers. The key question is whether the manufacturer can meet the reporting and security requirements by September 11, 2026, and the main obligations from December 11, 2027. If the answer remains unclear, the risk of product discontinuation rises. The operator then bears the consequences in architecture and operational continuity, even if it itself is outside the reporting obligation.<\/p>\n The BSI technical guideline TR-03183 consolidates requirements across three parts: general requirements, software bill of materials, and vulnerability reporting. Parts 1 and 3 are available in version 1.0.0, while Part 2 is at version 2.1.0. The initial comment period closed on 30 November 2024. Since then, the BSI has treated Part 1 as a living document, and Part 3 was released in September 2025. Versions 0.9.0 and 2.0.0 are archived.<\/p>\n For CIOs and IT strategists, the guideline serves as a reference framework when engaging with manufacturers supplying products that include digital elements. General requirements, software bill of materials, and vulnerability reporting define the core topics around which evidence and processes should be structured. Understanding the version statuses helps avoid misaligned expectations: all three parts are now finalized, with Part 1 continuously updated as a living document.<\/p>\n The coming weeks-up to 11 September 2026-are ideal for targeted supplier engagement. Prioritize products with high operational relevance and long lifecycles. Request evidence, reporting channels, update commitments, and a defined end-of-support date. Clarify roles across the supply chain, as the 24- and 72-hour deadlines apply directly to manufacturers, who remain accountable for the entire component. Monitor smaller suppliers for signs of product discontinuation to mitigate risk before Article 14 takes effect and before the next compliance milestone on 11 December 2027.<\/p>\n The reporting obligation applies to the manufacturer. The operator is not covered by this obligation under Article 14. However, the impact remains significant for CIOs, as they purchase products from manufacturers subject to reporting and rely on their information channels.<\/p>\n<\/details>\n No. The 24-hour and 72-hour deadlines apply to the manufacturer. They do not automatically apply to every supplier in the chain. The manufacturer remains responsible for the entire component, even if it sources parts externally.<\/p>\n<\/details>\n Manufacturers report simultaneously to the coordinating CSIRT and to ENISA via a joint reporting platform. For actively exploited vulnerabilities, early warnings must be issued within 24 hours, further information within 72 hours, and a final report within 14 days of a corrective measure becoming available. For severe security incidents, early warnings must be issued within 24 hours, incident reports within 72 hours, and a final report within one month of the incident report.<\/p>\n<\/details>\n Contracts should include evidence, reporting channels, updates, and a defined end of support. A general assurance of compliance is not sufficient. There are no official standard clauses. Even after support ends, the manufacturer remains responsible for addressing vulnerabilities for at least five years.<\/p>\n<\/details>\n The DIHK warns of significant burdens on small and medium-sized enterprises due to CRA implementation. Many smaller manufacturers are unsure whether the CRA applies to them. Some are considering withdrawing products from the market. A CIO whose niche supplier exits then faces procurement and migration challenges within their own infrastructure.<\/p>\n<\/details>\n More from the MBF Media Network<\/p>\n\n
Four Weeks Until Article 14: Procurement\u2019s Position<\/h2>\n
Who Reports, Where, and for What the Manufacturer is Liable<\/h2>\n
Deadlines, Reporting Content, and Sanctions<\/h2>\n
\n\n
\n \nDeadline<\/th>\n What applies<\/th>\n To whom<\/th>\n<\/tr>\n<\/thead>\n \n 10 December 2024<\/td>\n Cyber Resilience Act enters into force<\/td>\n Manufacturers and other CRA addressees<\/td>\n<\/tr>\n \n 11 September 2026<\/td>\n Article 14: Reporting obligations for actively exploited vulnerabilities and severe security incidents<\/td>\n Manufacturers as reporting entities<\/td>\n<\/tr>\n \n Within 24 hours<\/td>\n Early warning for actively exploited vulnerability or severe security incident<\/td>\n Manufacturers, reporting to coordinating CSIRT and ENISA<\/td>\n<\/tr>\n \n Within 72 hours<\/td>\n Additional information for vulnerabilities or incident report for severe security incidents<\/td>\n Manufacturers<\/td>\n<\/tr>\n \n Within 14 days after availability of a corrective measure<\/td>\n Final report for actively exploited vulnerability<\/td>\n Manufacturers<\/td>\n<\/tr>\n \n Within one month after the incident report<\/td>\n Final report for severe security incident<\/td>\n Manufacturers<\/td>\n<\/tr>\n \n 11 December 2027<\/td>\n Main obligations of the CRA take effect<\/td>\n Manufacturers and other CRA addressees<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n What now belongs in contracts and supplier discussions<\/h2>\n
The counterpoint: Burden on small and medium-sized manufacturers<\/h2>\n
Alignment with BSI TR-03183 and Next Steps<\/h2>\n
Frequently Asked Questions<\/h2>\n
Who is subject to the reporting obligation under Article 14 from 11 September 2026 onwards?<\/summary>\n
Do the 24-hour and 72-hour deadlines also apply to every supplier in the chain?<\/summary>\n
Where must manufacturers report, and what are the specific deadlines?<\/summary>\n
What should supplier contracts include to ensure operational security?<\/summary>\n
Why do smaller manufacturers pose a risk to procurement despite the CRA focusing on manufacturer obligations?<\/summary>\n