Beyond IT and Software

Beyond IT and Software 

Why the EU Cyber Resilience Act Speaks a Language ITSM Already Knows 

In a matter of weeks, on 11 September 2026, a piece of European law starts asking manufacturers a question many of them are not ready to answer. From that date, the EU Cyber Resilience Act requires makers of connected products to report actively exploited vulnerabilities and severe incidents, on a statutory clock, through a central European platform. 

Most of the commentary I read treats this as a distant 2027 concern, or as a problem only for “software companies.” Both readings are wrong, and the second one is dangerously so. 

Here is the detail that tends to make people sit up. The September obligation does not only apply to shiny new products still on the drawing board. It reaches products already placed on the EU market, including ones sold years ago and still in the field. Your legacy estate is in scope this September, not in 2027. And this is no longer theoretical: large industrial manufacturers such as Honeywell have already published supplier pages instructing their vendors to have reporting processes operational by 11 September 2026 and full compliance attestations soon after. The Act is already reshaping commercial behaviour up and down the supply chain. 

My argument in this piece is simple. The organisations that will struggle with the Cyber Resilience Act are the ones treating it as a security-team compliance checkbox. The ones that will cope have understood something quieter: the CRA is not really a new language at all. It is asking, with legal force, for the disciplines that service management has advocated for years. It is a lifecycle problem wearing a regulatory badge. 

What the CRA Actually Is 

The Cyber Resilience Act, formally Regulation (EU) 2024/2847, is the first EU-wide law to set mandatory cybersecurity requirements for products with digital elements across their entire lifecycle. It entered into force on 10 December 2024. Its reporting obligations apply from 11 September 2026, and its full requirements apply from 11 December 2027. 

The core shift is easy to state and hard to overstate. The CRA turns product cybersecurity from a voluntary good practice into a condition of market access. If your product has digital elements and you want to place it on the EU market, security is no longer a differentiator you may choose to invest in. It is a gate you must pass through. Products that meet the requirements carry a CE marking; products that do not, in time, cannot be sold. 

The scope is defined around “products with digital elements,” meaning hardware or software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. A handful of product categories that already have their own regimes are carved out, notably medical devices, motor vehicles, and civil aviation. Almost everything else with a connection is in. 

The Scope Is Deliberately Broad, and That Is the Part Most Coverage Misses 

When people hear “cybersecurity regulation,” they picture enterprise software and IT systems. The CRA is far wider than that, and deliberately so. It is a horizontal regulation, meaning it cuts across sectors rather than targeting one. 

Consider what that actually captures. A smart thermostat in a home. A connected refrigerator. A fitness tracker. A network router or security camera. Then move into the industrial world, which is where the implications get serious: a programmable logic controller on a factory floor, an industrial IoT sensor array, a connected robot in an automation line. And then into places most cybersecurity conversations never reach at all: a precision-irrigation controller in a field, a soil-moisture sensor network, an agricultural drone surveying a crop. 

These are not edge cases the regulator forgot to exclude. They are squarely the point. The Cyber Resilience Act does not care whether you think of your business as a “software company” or a “manufacturer” or an “agritech firm.” It cares whether your product has digital elements and reaches the EU market. Precision agriculture, industrial automation, consumer IoT, and drones are all governed by the same horizontal rulebook that governs a laptop operating system. 

For anyone building or exporting connected hardware, and India has a great many such firms, this breadth is the story. The mental model of “cyber compliance is an IT department problem” simply does not survive contact with the CRA. 

The Obligations That Matter in Practice 

Strip the regulation down to what a practitioner has to actually do, and four obligations dominate. 

• Secure by design and by default. Security must be a documented, designed-in property of the product, informed by a cybersecurity risk assessment that runs across planning, design, development, production, and maintenance. It cannot be a feature bolted on at the end. Default settings must be the secure ones. 

• A Software Bill of Materials. Manufacturers must know and document the components inside their products, including third-party and open-source dependencies, in a machine-readable form. Think of the SBOM as the ingredient list of your product. You cannot report a vulnerability in a component in 24 hours if you do not know the component is in there. 

• The reporting cascade. This is the obligation that bites first, on 11 September 2026. On becoming aware of an actively exploited vulnerability or a severe incident, a manufacturer must submit an early warning within 24 hours, a fuller notification within 72 hours, and then a final report within 14 days once a corrective measure is available for a vulnerability, or within one month for a severe incident. Reports go through ENISA’s Single Reporting Platform to the relevant national CSIRT. It is worth being precise here, because the common shorthand of “24/72/14” quietly omits the one-month track for incidents. 

• Support-period duties. Manufacturers must define, and clearly communicate, a support period during which they will handle vulnerabilities and provide security updates. The era of shipping a device and forgetting it is precisely what the law is written to end. 

Who Actually Carries the Burden 

A great deal of confusion dissolves once you see how the CRA distributes responsibility across roles. 

Manufacturers bear the primary weight: the essential requirements, the risk assessment, the technical documentation, the conformity assessment, the reporting. Importers and distributors carry lighter but real due-diligence duties, verifying that the manufacturer has done its job, that the CE marking and documentation are present, and cooperating on vulnerabilities. And there is a trap worth flagging: if an importer or distributor sells a product under its own name or brand, or substantially modifies it, the law treats it as the manufacturer, with all the obligations that follow. 

Two distinctions matter especially for the readers of this piece. First, non-EU manufacturers are not off the hook. If your product reaches the EU market, you are in scope, wherever you built it. For Indian and other global exporters, that is the sentence to re-read. Second, pure Software-as-a-Service is generally outside the CRA’s scope, since the Act targets products placed on the market rather than services. But “generally” is carrying weight there. Where software is part of, or necessary for, a product’s core functionality, such as the app that makes a smart watch work, it is pulled back into scope. And even pure SaaS providers should not assume immunity, because their customers will increasingly demand CRA-equivalent assurances as a matter of procurement, regardless of the formal scoping. 

Here Is Where It Gets Familiar: The CRA Speaks ITSM 

Read the four obligations again and notice something. Not one of them is conceptually new to anyone who has run services professionally. The Cyber Resilience Act is, almost line for line, a restatement of disciplines the service-management world has advocated for two decades. The law has simply made them mandatory. 

Consider the mapping honestly, because I do not want to force a connection that is not there. It is there. 

• Secure-by-design and support periods are lifecycle ownership. The whole spine of modern ITSM, and explicitly of ITIL’s product and service lifecycle thinking, is that you are responsible for a digital product from its conception through to its retirement, not merely at the point of sale. The CRA has now legislated exactly that posture. 

• The 24 and 72-hour cascade is incident and problem management with a statutory clock. An organisation that already runs disciplined incident management, with clear severity classification, defined escalation, and rehearsed response, is not learning a new capability for the CRA. It is pointing an existing one at a legal deadline. 

• The SBOM is configuration and asset management. Knowing every component inside your product, tracking versions, and understanding dependencies is what a well-run configuration management system has always delivered. The CRA calls it an SBOM. Service managers call it knowing your estate. 

• Supplier attestations are supplier management. The Honeywell example earlier, an OEM cascading compliance duty down its supply chain through contracts, is textbook supplier and contract management. The CRA is turning supplier governance from good hygiene into contractual necessity. 

So here is the through-line, and it is genuinely good news for a segment of readers. Organisations with mature, ITIL-based service governance are not starting the CRA journey from zero. They already own the operating disciplines the Act demands. What they need is to recognise the connection and re-point those disciplines at a regulatory obligation, rather than standing up a parallel “compliance project” beside the service management they already run. The failure mode is treating the CRA as something foreign. The winning move is treating it as an extension of how you already govern digital products across their lives. 

I want to be careful not to overclaim. The CRA is a product-security law, not an ITSM instrument, and full compliance will still demand genuine legal, engineering, and conformity-assessment work that no framework hands you for free. But the organising posture the Act requires, lifecycle ownership of digital products, is one the service-management profession has been rehearsing for years. That is not a coincidence worth ignoring. It is an advantage worth using. 

What This Means for CISOs: Guardrails in Procurement and the SBOM Lifecycle 

If you carry security accountability, the CRA is not a memo to file. The most exposed part of most organisations is not their own code; it is what they buy and embed. A CISO’s highest-leverage move is to put guardrails into the procurement and component lifecycle now, so that compliance is enforced by process rather than hoped for by goodwill. Practically: 

1. Make CRA status a procurement gate, not an afterthought. Add CRA conformity to supplier selection criteria before contracts are signed. Discovering that a critical supplier is non-compliant after signing is the expensive way to learn this lesson. Ask, up front, for evidence of secure-by-design practices, a documented vulnerability-handling process, and a stated support period. 

2. Insist on an SBOM as a contractual deliverable. Require suppliers to provide a machine-readable SBOM for every component and to keep it current. Your ability to meet the 24-hour reporting window depends entirely on knowing, quickly, whether a newly exploited vulnerability lives somewhere in your product. Without SBOMs from your suppliers, you are blind at exactly the moment the clock starts. 

3. Use back-to-back contract clauses. Align upstream supplier contracts with your downstream customer commitments, so obligations flow through the chain rather than stranding on you. Build in audit rights, timely vulnerability notification duties, cooperation obligations, and patch and update guarantees. If a customer expects CRA assurances from you, your suppliers must owe the equivalent to you. 

4. Connect vulnerability intelligence to your component inventory. The SBOM is static until it is continuously matched against vulnerability sources such as the NVD and the EU vulnerability database. Operationalise that matching so an actively exploited vulnerability in a dependency raises an alert against your specific products, automatically, in hours rather than weeks. 

5. Rehearse the reporting path before you need it. Establish, and test, the workflow that takes you from “we became aware” to “early warning filed” inside 24 hours: who classifies severity, who authorises the filing, who holds the ENISA Single Reporting Platform credentials, and how the national CSIRT route is determined for your establishment. A reporting process discovered for the first time during a live incident is a process that misses its deadline. 

None of these five is exotic. Each is procurement discipline, configuration management, supplier governance, and incident readiness, applied deliberately. Which is the point of this entire article. 

A Closing Reflection 

The 11 September 2026 deadline will pass, and the specific dates will eventually feel like history. The deeper signal will not. The Cyber Resilience Act marks the moment the European market decided, in law, that shipping a connected product and walking away is no longer acceptable. Whoever puts a product with digital elements on the market owns its security across its life. 

Whether an organisation experiences that as a crisis or as a natural next step depends almost entirely on one thing: whether it already treats digital products as things to be governed across a lifecycle, or as things to be sold and forgotten. The frameworks that answer to names like ITIL have argued for the former for twenty years. The CRA has now made the argument on their behalf, with the force of regulation behind it. 

So I will leave you with the question I keep asking the leaders I speak with. Is your organisation treating the Cyber Resilience Act as a compliance checkbox to be survived, or as a governance question you were, in truth, always meant to answer? I would be interested to hear what you are seeing, especially from those of you closer to the manufacturing and industrial side than to classic IT. 

A note on scope: This article is a practitioner’s commentary intended to prompt thinking, not legal advice. CRA obligations turn on the specifics of each product, role, and market position. For decisions with legal or financial consequences, consult qualified counsel and the official EU sources cited below. 

 

References 

• European Commission (2026). Cyber Resilience Act – Reporting obligations. Update of 8 June 2026. digital-strategy.ec.europa.eu 

• European Commission. The Cyber Resilience Act – Summary of the legislative text. digital-strategy.ec.europa.eu 

• Regulation (EU) 2024/2847 of the European Parliament and of the Council (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. 

• Hogan Lovells (2026). EU Cyber Resilience Act: Preparing for Vulnerability and Incident Reporting. hoganlovells.com 

• DLA Piper (2026). Cyber Resilience Act: the fine line between SaaS and digital products. dlapiper.com 

• Cranium (2026). What is the impact of the Cyber Resilience Act on your contracts and processes? cranium.eu 

• Honeywell (2026). EU Cyber Resilience Act – Supplier information. honeywell.com 

• ENISA. CRA Single Reporting Platform – FAQ. European Union Agency for Cybersecurity. 

About the Author 

Rajwardhan Purohit is an ITIL Master and a Global ITIL & DevOps Ambassador for PeopleCert, a Capability Architect, ITIL Maturity Consultant, and Accredited Tool Vendor Assessor associated with Ducis Management Consulting, one of end-to-end partners of  PeopleCert.  

He brings thirty years of enterprise IT experience spanning delivery leadership and pre-sales across organisations including the British Council, HCL, DXC, and IBM. He is the creator of the Capability as a Service (CaaS) framework and the author of the “Eight-Dimensional Framework for ITSM Tool Development,” published on itil.com by PeopleCert. He writes on the architecture of trust, resilience, and service management in an AI-native world. 

Views expressed are personal. All logo, trademarks, belong to respective owners. This is a technology assisted writeup.