Cybersecurity is no longer a technical feature. It is a matter of resilience. And that means modular system design is no longer optional.
Europe is operating in an environment shaped by geopolitical tensions, targeted cyberattacks and increasing pressure on critical infrastructure. Digital systems control factories, energy grids, transportation networks and medical equipment. When these systems fail due to vulnerabilities, the consequences are not theoretical. They are operational, financial and, in some cases, even safety-critical.
Stronger cybersecurity requirements are therefore not a burden. They are necessary.
With Regulation (EU) 2024/2847, the European Union has introduced the Cyber Resilience Act (CRA), establishing mandatory cybersecurity requirements for products with digital elements placed on the EU market. The Regulation entered into force in December 2024 and will fully apply from December 2027.
Yes, the CRA is already in force!
The ambition is clear: raise the cybersecurity baseline of digital products across Europe.
But once you move from policy intent to practical implementation, important questions arise - especially for the industrial and embedded market, where long lifecycles and complex supply chains are the norm.
And this is where misunderstandings begin, and interpretation becomes critical
At first glance, the Cyber Resilience Act appears straightforward: improve cybersecurity, define responsibilities, increase transparency. But once companies begin reviewing their own portfolios, the regulation quickly becomes more complex than expected. In my discussions across the industry, I repeatedly encounter three fundamental misunderstandings. They sound minor. They are not. Each of them has significant implications for lifecycle management, legacy products and long-term customer commitments.
Let’s look at them one by one.
Misconception 1: “The CRA only applies to internet-connected devices”
One of the most common assumptions I encounter is that the Cyber Resilience Act primarily targets consumer IoT devices or products connected to the public Internet.
That assumption is understandable. But it is not what the CRA says.
Article 2(1) of the Cyber Resilience Act defines the scope as follows:
“This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.”
There is no reference to the Internet. The decisive trigger is the existence of a direct or indirect logical or physical data connection to a device or network. This significantly broadens the scope. It means the CRA may also apply to:
-
Devices connected to local industrial networks
-
Systems with maintenance or service interfaces
-
Embedded platforms communicating with other digital systems
-
Products operating in closed environments
Consider a typical industrial controller installed in a production machine. It may never be connected to the public Internet. However, it is connected to a local factory network. It may have an Ethernet interface for commissioning. It may allow remote diagnostics through a service laptop. From a practical point of view, this is an “offline industrial system”. From a legal point of view, it includes a logical or physical data connection to a device or network. And that is sufficient to potentially fall within the scope of the CRA. For the industrial and embedded sector, this is not a minor detail. It changes how companies must assess their portfolio exposure. Before asking “Is this device connected to the Internet?”, the more relevant question is:
Does this product have any form of logical or physical data connection to another device or network? If the answer is yes, the CRA may apply.
Misconception 2: “We can continue selling as long as we don’t change the product”
This is, in my view, the most underestimated risk in the Cyber Resilience Act.
Many companies assume that existing products can continue to be sold after 11 December 2027 as long as they are not technically modified. This interpretation often refers to Article 69(2) on transitional provisions, which states:
“Products with digital elements that have been placed on the market before 11 December 2027 shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification.”
At first glance, this sounds reassuring. But the decisive legal concept here is not “modification”. It is “placed on the market”.
To understand the implications, we must distinguish between two key terms used in EU product law: “placing on the market” and “making available on the market”. Section 2.3 of the EU Blue Guide on the implementation of Union harmonisation legislation explains:
A product is placed on the market when it is made available for the first time on the Union market. According to Union harmonisation legislation, each individual product can only be placed once on the Union market.
Products made available on the market must comply with the applicable Union harmonisation legislation at the moment of placing on the market. Any subsequent supply of that same product is considered making available on the market.
As for ‘making available’, the concept of placing on the market refers to each individual product, not to a type of product, and whether it was manufactured as an individual unit or in series
Placing on the market happens once per individual unit. Making available can happen multiple times for that same unit as it moves through the distribution chain. This distinction is critical. If a manufacturer supplies a specific device to a distributor before 11 December 2027, that individual unit has been placed on the market before the deadline. If the distributor sells that same unit to an end customer in 2028, that is making it available, not a new placing. However, producing a new unit of the same product in 2028 and supplying it for the first time would constitute a new placing on the market. That new unit would therefore need to comply fully with the CRA.
Product A with serial number 1111111 was placed on the market during the transition period, before 11 December 2027. This individual unit does not have to comply with the full CRA requirements, unless it is substantially modified after that date. Product A with serial number 2222222 was placed on the market after the transition period. This unit must comply fully with the CRA, even if it is technically identical to earlier versions.
Now consider a third situation. Product A with serial number 1111111, originally placed on the market before the deadline, is substantially modified after the transition period. From the moment of substantial modification, it also becomes subject to the CRA requirements.
This illustrates the central principle: Compliance is not determined by the product name, the hardware revision, or the product family. It is determined by the individual unit and the moment it is placed on the market, combined with whether it undergoes substantial modification.
The European Commission confirms this interpretation in its official Cyber Resilience Act Frequently Asked Questions. The FAQ explicitly states that Union harmonisation legislation, including the CRA, applies to individual products, not product types. Only individual products that have been placed on the market before 11 December 2027 benefit from the transitional provision. If you want to verify this yourself, I strongly recommend reviewing the official FAQ published by the European Commission: Cyber Resilience Act Implementation Frequently Asked Questions.
The regulation therefore does not provide a transition mechanism for product families. It provides a transition mechanism for individual units placed on the market before the applicable date. That difference is fundamental!
Misconception 3: “I only have to support my product while it is on my roadmap”
This assumption sounds practical. It is also dangerous.
Many companies assume that support obligations are aligned with internal product strategies. Once a product leaves the roadmap or reaches end of sales, support gradually phases out.
The CRA does not follow that logic.
Under the Regulation, manufacturers must ensure vulnerability handling and security updates for a defined support period. That period must reflect the expected product lifetime and shall be at least five years, unless the expected use time is shorter.
The key point is this: The obligation is linked to products placed on the market. Not to product families. Not to development generations. Not to marketing roadmaps. Just like the placing on the market concept, the support obligation effectively operates per individual unit.
Let us apply the same serial number example. During the availability phase, multiple individual units are placed on the market at different points in time:
-
Serial number 1111111 is placed early in the lifecycle.
-
Serial number 2222222 is placed later.
-
Serial number 3333333 is shipped close to the end of sales.
Each of these units triggers its own support timeline. When the product reaches end of life at time T1, availability stops. No further units are placed on the market. However, support obligations do not stop at T1. Instead, each serial number continues into its defined support period, calculated from the moment it was placed on the market. The result is what we can call support stacking. Even after end of sales, support obligations continue for the last shipped units until time T2, which marks the end of the defined support period for the final unit placed on the market. In practical terms:
-
Product availability may end.
-
Regulatory support obligations may continue for years beyond that date.
For embedded and industrial markets, this is a structural challenge. Industrial systems often operate for 10 to 15 years or more. Component suppliers may discontinue chipsets earlier. Security update capabilities depend on long-term ecosystem stability. This creates a tension between regulatory timelines and industrial lifecycle realities. Understanding this early is essential. Support is no longer purely a commercial service decision. It becomes a regulated obligation linked to the placement date of each individual product.
And this has a broader consequence. In practice, regulatory support obligations combined with technology evolution will lead to shorter effective lifecycle windows in the embedded market. If vulnerability management, update capability and long-term security maintenance must be guaranteed per individual unit, the economic pressure to keep aging platforms in the field increases significantly. This will inevitably force more regular platform updates.
If your system architecture already follows a modular approach, such as the COM concept, you are structurally better positioned. Modular architectures allow regular technology refreshes without redesigning the entire system. Processor generations can be updated. Security capabilities can evolve. Performance can scale.
If your architecture is monolithic and tightly integrated, the regulatory pressure introduced by the CRA becomes much harder to manage. In that case, this regulation should be seen as a strategic signal.
-
Now is the time to introduce modularity.
-
Now is the time to increase flexibility.
-
Now is the time to design systems that can evolve over time instead of being locked into a single hardware generation.
The CRA is not only a compliance exercise. It is a catalyst for architectural decisions.
From legal detail to strategic direction
Taken individually, each of these misconceptions may appear manageable.
-
A broader scope than expected.
-
A stricter interpretation of placing on the market.
-
Support obligations tied to individual units rather than product roadmaps.
But taken together, they redefine how digital products must be planned, placed and maintained in the European market. The CRA does not merely introduce additional documentation requirements.
-
It reshapes lifecycle logic. It connects regulatory compliance with architecture decisions.
-
It links supply chain stability with cybersecurity capability.
-
It turns support strategy into a legally relevant obligation.
This is why the CRA should not be treated as a late-stage compliance exercise handled shortly before 2027. It is a structural shift. And structural shifts require early and deliberate preparation.
Now is the time to act
The Cyber Resilience Act will shape the future of digital products in Europe. Waiting is not a strategy.
I encourage every organization placing products with digital elements on the EU market to:
-
Read the Regulation carefully.
-
Review the official CRA FAQ and guidance documents.
-
Assess the impact on your portfolio and lifecycle model.
-
Evaluate whether your architecture is flexible enough to handle continuous security obligations.
In addition, there is currently an important opportunity to actively shape the interpretation of the regulation. The European Commission has published the Draft Commission Guidance on the Cyber Resilience Act and opened a public feedback process. The consultation is open only until 31 March 2026. This is a critical window for industry to raise practical concerns, highlight real-world challenges and contribute constructive input. If you are affected by the CRA, consider participating in the consultation!
Cybersecurity regulation is necessary. But successful implementation requires clarity, preparation and alignment with industrial reality. The companies that engage early, assess strategically and contribute to the discussion will not only ensure compliance. They will help shape the framework under which the European digital industry will operate for the next decade.
Important notice
This article reflects my personal interpretation of Regulation (EU) 2024/2847 based on the regulation text, the EU Blue Guide, the European Commission FAQ and available guidance documents at the time of writing. It does not constitute legal advice. Regulatory guidance may evolve, delegated acts may follow, and legal interpretations may differ. Companies should seek independent legal assessment tailored to their specific situation.
Related Content
