“We’re not a tech company” is no longer a valid argument in 2026. For a long time, cybersecurity regulations were seen as something that primarily affected software vendors, automotive OEMs, or highly digital industries. Many organizations still assume that if they build physical products, integrate third-party components, or operate outside classic tech domains, these regulations do not apply to them.
What the CRA Actually Targets
The Cyber Resilience Act is a European Union regulation designed to strengthen cybersecurity standards for products with digital elements placed on the EU market. Its scope is intentionally broad. Rather than focusing on specific industries, it targets functionality. If a product contains software, connectivity, or any form of digital interface, it is likely within scope.
At its core, the CRA introduces baseline expectations for how products are built and maintained. These include secure development practices, structured vulnerability management, lifecycle support, and documentation that proves cybersecurity measures have been implemented. None of these concepts are entirely new. What is new is that they are becoming mandatory and enforceable. To understand why this shift matters in practice, it helps to look at how products themselves are changing.
Who is Actually Affected – A Reality Check
A useful way to understand the scope of the CRA is to stop thinking in industries and start thinking in products. Take something as simple as a water filter. Traditionally, this is a purely physical product. No one would associate it with cybersecurity requirements. But once that same water filter comes with a Bluetooth connection and a companion app – for monitoring usage, ordering replacements, or tracking quality – it becomes part of the Internet of Things (IoT).
And that is the turning point.
The moment a product becomes part of the IoT, it also becomes part of the cybersecurity problem. It is no longer just a physical device, but a connected system. One that processes data, communicates with other components, and introduces potential attack surfaces.
Under the CRA, this distinction is critical. The regulation does not care whether something looks like a simple household product. It only cares whether it behaves like a connected device. This is not a niche scenario. It reflects a broader shift: Connectivity is being added to products that were never originally designed with cybersecurity in mind.
For example:
- Smart hairbrushes
- Smart light bulbs
- Connected coffee machines
These types of consumer IoT devices may seem trivial at first glance, but they illustrate how quickly everyday products become part of a connected ecosystem.
The same pattern extends far beyond the smart home. Connected industrial components, gateways, and digitally enhanced add-ons all follow the same logic. What they have in common is not their industry, but the fact that they are part of an increasingly connected IoT ecosystem.
If a product communicates, receives updates, or exchanges data, it is no longer “just hardware.” Under the CRA, that shift brings it directly into scope . If this scope feels broad, that is because it is – and it raises an important follow-up question: Where does the CRA actually fit within the broader regulatory landscape?
Where the CRA Sits in the Bigger Picture
The CRA does not exist in isolation. It is part of a broader regulatory landscape that combines industry-specific and cross-sectoral requirements:
Vertical regulations, such as UNECE R155 in automotive or the Medical Device Regulation (MDR), define cybersecurity requirements for specific domains and typically take precedence within their respective industries.
The CRA, by contrast, acts as a horizontal baseline. It applies wherever no more specific regulation exists, covering a wide range of products across sectors. In practice, this creates a layered system: Some products are governed by domain-specific regulations, others fall directly under the CRA, and many organizations operate across both contexts at the same time.
For companies, the challenge is not just understanding a single regulation but identifying where their products sit within this structure.
The Supplier Misconception
The situation becomes less clear when looking at suppliers. A common assumption is, “We are just a supplier, so this does not directly affect us.” However, the CRA does not follow organizational boundaries – it follows the product and its placement on the market.
Depending on how a component is delivered and integrated, a supplier may effectively take on the role of a manufacturer under the regulation, or at least become part of a compliance chain in which evidence and transparency are required. Even where there is no direct legal obligation, expectations propagate through the value chain. OEMs and system integrators will increasingly require their suppliers to provide proof of cybersecurity measures. In practice, this makes indirect compliance unavoidable.
What This Means in Practice
At first glance, the CRA appears to be a documentation-heavy regulation: define requirements, document processes, provide reports, and achieve compliance.
But this is exactly where many organizations take a wrong turn. The real challenge is not understanding what should be in place – it is understanding whether it actually holds up in practice.
Documentation alone does not make a system secure. It describes intent, structure, and process. But it does not prove that a product can withstand real-world conditions, unexpected interactions, or targeted attacks. Attackers operate differently. They do not follow documentation — they look for weaknesses and exploit them, regardless of how well a system is described on paper.
What is required instead is validation − not as a one-time activity, but as an ongoing capability. Systems evolve, software changes, and connectivity continuously introduces new variables. Without verification, even well-documented systems can drift away from their original security assumptions.
This creates a critical gap between compliance and actual security.
Why This Matters Now
For many organizations, the key question is no longer whether they are affected, but to what extent and how prepared they are to deal with it.
Because being in scope is only the first step. Ensuring that a system is not just compliant, but actually resilient under real-world conditions, is a fundamentally different challenge – and one that cannot be solved through documentation alone. And this is where a common misconception begins: Many systems are compliant, but still vulnerable.
And with full CRA compliance required by the end of 2027, the window to move from documentation to actual, verifiable security is smaller than it may seem.
This article is part of our blog series “Cybersecurity Reality Check”, where we explore how cybersecurity regulations translate into real-world product security – and why testing plays a critical role. In the next article, we will take a closer look at why compliance does not equal security – and why checklists alone won’t protect your product.
