I have been critical of the European Union's appetite for regulation before, and I expect I will be again. Europe has accumulated an extraordinary regulatory burden around technology, data and cybersecurity. GDPR, NIS2, DORA, the AI Act and now the Cyber Resilience Act all have legitimate objectives, but every additional obligation consumes money, people and management attention. Large enterprises can absorb much of that through legal, compliance and specialist technology teams. Smaller companies have no such luxury.
That matters because regulation is not free. Money spent demonstrating compliance is money that cannot be spent somewhere else, and there is always a danger that businesses become better at producing evidence of security than actually being secure. Europe needs to take that problem seriously if it wants its companies to remain competitive.
So I approached the Cyber Resilience Act, or CRA, with some scepticism. Having looked more closely at what it requires, however, I find myself in the slightly uncomfortable position of agreeing with its central premise.
If you sell a connected product, you should know what is inside it. You should know how long you intend to support it, how you will deal with vulnerabilities discovered after it leaves your factory and how you will reach affected customers. If somebody discovers that a component inside your product is being actively exploited, you should be capable of determining whether your customers are exposed and acting accordingly.
I struggle to regard any of that as unreasonable bureaucracy. In an increasingly software-defined world, it looks rather more like basic product responsibility.
And from 11th September 2026, part of that responsibility acquires a regulatory clock.
What actually happens on 11th September?
The CRA entered into force in December 2024 and establishes a horizontal EU-wide cybersecurity framework for products with digital elements. Its reach is deliberately broad. Software can fall within scope, as can IoT equipment, embedded systems and industrial machinery containing software that connects directly or indirectly to another device or network. Crucially, that does not necessarily mean a direct connection to the public internet. A machine connected to a customer’s industrial network may potentially fall within scope even where internet access is controlled through firewalls, proxies or other infrastructure. There are exclusions, particularly where products are already subject to comparable sector-specific regimes, but manufacturers are very much at the centre of the legislation.
It is important not to exaggerate what happens this week. The entire Cyber Resilience Act does not suddenly become applicable on 11th September. The wider regime becomes fully applicable from 11th December 2027, including substantial requirements around secure product development, cybersecurity risk assessment, vulnerability handling, conformity and technical documentation. Among those future obligations is the requirement to identify and document product components, including through a machine-readable Software Bill of Materials, or SBOM.
What changes on 11th September 2026 is nevertheless significant. Article 14's mandatory reporting obligations begin, and ENISA's Single Reporting Platform becomes operational. Manufacturers and open-source software stewards within scope must provide an early warning without undue delay and, in any event, within 24 hours of becoming aware of an actively exploited vulnerability or severe incident affecting the security of a product with digital elements. A more detailed notification follows within 72 hours. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective measure becomes available; for a severe incident, the final report follows within one month of the 72-hour notification.
That sounds, initially, like a reporting requirement. Get the right people together, establish what happened, fill in the necessary information and submit it.
I think that interpretation substantially understates the challenge.
Reporting something within 24 hours is relatively straightforward if the organisation already knows what happened, what is affected, where the affected products are and who owns the response. The real test begins when any of those answers are uncertain.
A manufacturer confronted with an actively exploited vulnerability may need to establish quickly which products contain the affected component, across which hardware, firmware and software revisions, how those products reached the portfolio, and which customers or markets may be exposed. In a modern manufacturing business, that information may be distributed across PLM, ERP, source repositories, supplier records, engineering systems, CRM and people's memories. Acquisitions add another layer. So do third-party components and open-source libraries. Products that stopped being manufactured years ago may still be operating at customer sites.
If establishing the answer requires five departments, three spreadsheets and somebody remembering which engineer worked on the product in 2019, the 24-hour deadline is not really the problem. The organisation's product knowledge is.
11th September isn't the day manufacturers suddenly acquire a new cybersecurity problem. It is the day some of their existing cybersecurity problems acquire a regulatory clock.
This cannot belong to the CISO alone
Cybersecurity naturally points towards the CISO, and the security organisation clearly has a central role. It needs to understand emerging vulnerabilities, assess evidence of exploitation and connect threat intelligence with the company's product estate. It also needs an escalation process capable of recognising when a security event has crossed the threshold into a potential regulatory event.
Yet the CISO cannot analyse information the organisation cannot produce.
Product security may sit within engineering. Product lifecycle information may sit elsewhere. Supplier dependencies may belong to procurement. Customer information may be controlled by sales or service organisations. Incident management may sit within IT. Legal and compliance will need to interpret regulatory obligations, while communications may become involved if customers need to be informed.
This is why I think the CRA is as much a CIO issue as a CISO issue.
The CIO may not own product engineering, but the ability of an enterprise to find, correlate, move and trust information across organisational boundaries is very much a technology leadership concern. If security cannot establish where a component exists because product, supplier and customer information live in disconnected systems, that fragmentation becomes part of the incident.
There is also an important question around the word "aware". The CRA clock is tied to the manufacturer becoming aware of an actively exploited vulnerability or severe incident. In a large enterprise, information rarely arrives neatly at the executive responsible for it. A vulnerability may first appear in a supplier notification, a SOC alert, an engineering conversation, a customer-support case or a message from a security researcher.
Companies therefore need to decide operationally how those signals reach the people authorised to assess them. Waiting for somebody eventually to tell the CISO is not an incident process.
The DPO has a different role, and I think businesses should resist the temptation to make every cyber regulation a privacy programme. The CRA is product-cybersecurity legislation; it does not turn the Data Protection Officer into the owner of product security. But a severe cyber incident may also involve personal data, in which case the organisation can find itself dealing with CRA and GDPR obligations at the same time. The CISO, CIO, DPO and legal function need to understand those intersections before the incident rather than discovering them while separate regulatory clocks are running.
Ultimately, however, this lands at the CEO.
Calling the CRA an IT compliance project would be a serious mistake because the consequences do not remain inside IT. The legislation provides for administrative fines of up to €15 million or 2.5% of total worldwide annual turnover, and enforcement can extend beyond monetary penalties to market-access restrictions, product recalls and increased scrutiny from market-surveillance authorities.
For a manufacturer, the commercial consequences of that second category could dwarf the fine. A product that cannot be sold, has to be withdrawn or requires remediation across a large installed base creates a very different conversation from an internal security finding. Revenue, engineering capacity, customer confidence, legal exposure and brand reputation can all become involved.
Consider an industrial machine that has been operating at a customer’s factory for five years. Its embedded software contains a third-party component that is suddenly found to have an actively exploited vulnerability. The manufacturer may now need to establish which machine models contain it, which firmware versions are affected, which customers operate those machines and whether a corrective measure can be deployed. The fact that the machine sits behind the customer’s firewall does not make the product-security problem disappear.
That is why I think the CEO should be asking whether the business is ready for the CRA, not whether IT has completed its CRA project.
What happens if you simply get it wrong?
There is an inevitable question whenever regulation introduces large fines: can an executive go to prison?
The answer needs some care. The CRA itself establishes an administrative enforcement regime and requires Member States to provide effective, proportionate and dissuasive penalties. It does not create a blanket EU-wide prison sentence for a CIO, CISO or CEO because an Article 14 report was late.
That should not be interpreted as saying individual conduct can never have criminal consequences. National criminal law continues to exist, and behaviour such as fraud, deliberate concealment or other independently unlawful conduct could obviously change the legal position depending on the jurisdiction and circumstances. But claiming that a CIO can simply be imprisoned under the CRA for missing the 24-hour deadline would be misleading.
Frankly, I don't think the threat of prison is necessary to make the point.
Imagine explaining to your board that the company faces an eight-figure regulatory exposure because nobody was certain who was responsible for reporting. Imagine telling customers that a product has to be withdrawn because its cybersecurity obligations were not met. Or explaining that engineering could not establish whether a known exploited vulnerability existed inside products that had already been sold.
The reputational question may be even simpler: why didn't we know?
For executives, that is where accountability becomes uncomfortable. Regulators can ask what the organisation knew, when it knew it, what processes existed and what happened after the information became available. A PowerPoint stating that the CRA programme was green will be of limited comfort if the operating reality says otherwise.
Europe isn't alone, but Europe is going further
It is tempting, particularly for those of us who regularly criticise European regulation, to treat the CRA as another uniquely Brussels creation. That would be unfair.
The United Kingdom already has its own product-security regime under the Product Security and Telecommunications Infrastructure Act. Its scope is different and considerably more focused on consumer connectable products, but the underlying principle is familiar: manufacturers placing connected products onto the market carry security obligations. The UK regime is hardly toothless either; its maximum financial penalty can reach the greater of £10 million or 4% of qualifying worldwide revenue, with additional daily penalties possible for continuing breaches.
Other industries have been moving in the same direction through sector-specific cybersecurity and product-safety regimes. The distinction with the CRA is its horizontal reach. Europe is effectively embedding cybersecurity into the conditions under which a very broad range of digital products can participate in the Single Market.
I can criticise Brussels for the volume of regulation while still accepting that this particular direction of travel is rational.
Products have changed. A manufacturer once sold a largely physical object whose behaviour was substantially fixed when it left the factory. Increasingly, the product is a combination of hardware, firmware, software, cloud dependencies, third-party libraries and continuing updates. The manufacturer's responsibility cannot realistically end at the loading bay when the product's security can change months or years later because a vulnerability has been discovered in one of those components.
The uncomfortable part is that many manufacturers' organisational structures have not evolved at the same speed as their products.
Engineering knows one part of the product. IT knows another. Security understands the threat. Procurement knows the supplier. Service knows the customer. Legal understands the liability. Nobody necessarily owns the complete picture.
The CRA is about to make that fragmentation considerably more visible.
Where I think Brussels still needs to be careful
Supporting the principle does not mean giving the regulation a free pass.
European policymakers have a habit of looking at the resources of the largest technology companies when designing obligations that will ultimately affect businesses with dramatically fewer resources. A multinational can build product-security teams, employ regulatory counsel, automate SBOM generation and operate dedicated vulnerability-management processes. A specialist manufacturer employing a few hundred people may have similarly complicated technology inside its products without anything approaching the same compliance machinery.
That asymmetry matters. Good regulation should improve security without creating a market in which only the largest companies can afford the cost of proving that they are secure.
Enforcement will matter enormously here. The CRA provides the framework, while national market-surveillance authorities and the wider European enforcement structure will determine how it feels in practice. If enforcement becomes an exercise in demanding perfect paperwork, Europe will create another compliance industry. If it focuses on whether manufacturers genuinely understand their products, manage vulnerabilities, support customers and respond responsibly when problems arise, it could materially improve product security.
There is a distinction worth protecting between evidence of security and security itself.
An SBOM illustrates the point nicely. The CRA's wider requirements will make software-component documentation increasingly important, and rightly so. But generating an SBOM is not the objective. Being able to use that information when a component becomes vulnerable is the objective.
A beautifully maintained inventory that nobody can connect to products in the field is compliance theatre. So is a vulnerability-management procedure that takes three days to identify the people required to execute it.
I would rather see a manufacturer with an imperfect process that can identify an affected product in 30 minutes than one with a flawless 80-page procedure that takes three days to produce an answer.
The regulation should encourage the former rather than inadvertently rewarding the latter.
What I would do before Thursday
With the reporting obligation only days away, I would not commission another CRA presentation. I would test the organisation.
Take a plausible critical vulnerability in a software component that could conceivably exist somewhere in the product portfolio and start a clock. Give the technology, security and product organisations an hour to establish where that component exists, which products and versions could be affected, how it entered the product, which customers may have those products and who owns the response.
Then ask for the evidence.
That final part matters. "Engineering thinks we don't use it" is not the same as knowing that you don't. Nor is "the current release doesn't contain it" sufficient if earlier versions remain deployed with customers.
I would also walk through the reporting process itself. ENISA's Single Reporting Platform goes operational on 11th September, and its current guidance already describes the information required at the early-warning, 72-hour and final-report stages. Not every field is required in the first 24 hours, which is important: the regulation is not demanding a completed forensic investigation within a day. It is demanding that organisations recognise the event and begin reporting it promptly.
That makes organisational readiness even harder to excuse.
The test should include the CISO, but it should not stop there. The CIO needs to understand whether the underlying information systems can support the response. Product and engineering leaders need to demonstrate that component and version information is retrievable. Legal needs to understand the reporting threshold and process. The DPO needs to know when a parallel personal-data issue pulls them into the incident. Communications and customer teams need to understand what happens when users must be informed. The CEO needs to know who has authority to act when the organisation is under pressure.
None of that requires waiting until the wider CRA obligations become fully applicable on 11th December 2027.
It is simply sensible operational preparation.
My problem with the CRA isn't the principle
I remain concerned about Europe's regulatory trajectory. The cumulative cost of GDPR, NIS2, DORA, the AI Act, the CRA and whatever comes next is not imaginary. Compliance teams do not generate themselves, lawyers are not free, and every executive hour spent interpreting another regulatory framework is an hour not spent building something.
Europe cannot regulate itself into technological leadership.
But neither can European industry compete by pretending that software inside physical products somehow ceases to be the manufacturer's responsibility once the product has been sold.
On this, I think the EU has identified a genuine problem.
If you manufacture a connected product, knowing what software it contains should be normal product management. Having a process for receiving vulnerability reports should be normal security practice. Knowing how long you will support the product should be part of the commercial proposition. Being capable of identifying affected customers should be basic operational competence. And responding quickly when you discover that a vulnerability is actively being exploited should not require a regulator to explain why urgency matters.
The CRA formalises those expectations and attaches consequences to failing them. I may question some of the implementation and I will be watching closely to see whether enforcement produces better security or merely better paperwork. But I cannot seriously argue against the underlying responsibility.
That is why 11th September 2026 matters.
It is not the finish line for the Cyber Resilience Act. Most of the regime still lies ahead, with the broader requirements applying from 11th December 2027. But this week the first significant operational test becomes real. When an in-scope manufacturer becomes aware of an actively exploited vulnerability or severe incident, there is now a clock attached to what happens next.
If your company is not ready, you can blame Brussels for creating another regulation. Some of that criticism may even be justified.
But if you cannot identify what software is inside the products you sell, cannot establish which customers are affected, cannot determine who owns the response and cannot get the right information to a regulator within 24 hours, I don't think Brussels is your biggest problem.
The regulation has simply exposed the one you already had.
The Pragmatic View
The Cyber Resilience Act is another regulation arriving on the desks of European businesses already carrying a considerable compliance burden. I remain concerned that Europe is becoming better at regulating technology than creating the conditions in which technology companies can compete.
But that does not make the principle behind the CRA wrong.
If you sell a connected product, you should know what is inside it. You should know who is responsible when a vulnerability is discovered, which customers may be affected and how quickly you can respond. Those are not unreasonable expectations created by Brussels. They are responsibilities that should already come with putting a digital product into somebody else's hands.
From 11th September 2026, part of that responsibility gets a clock.
My concern is therefore less about whether businesses have completed their CRA compliance programme and more about what happens when the first real incident arrives. If identifying an affected component requires three departments, several spreadsheets and an engineer who remembers what happened seven years ago, no policy document is going to save you.
Europe should enforce the CRA in a way that rewards genuine product security rather than perfect paperwork. Businesses, in return, need to stop treating product cybersecurity as something that ends when the product leaves the factory.
You can criticise the regulation.
You can criticise the bureaucracy.
But if you don't know what you shipped, don't blame the 24-hour clock when you cannot answer in time.
