28 July 2026
8 MIN.
CRA: When Security and Machine Go Separate Ways
The Problem Space: CRA and Its Consequence
Three risks hit machine builders at the same time:
Market Access – CE Marking as a Condition
Without CRA compliance there is no CE marking for machines with digital elements from December 2027. No market access in the EU.
After-Sales Revenue – Retrofit Subject to CRA
Substantial modifications to installed machines trigger CRA obligations. Non-compliant retrofits cost service business.
Patch Debt – 13 Years of Security Obligations
The CRA requires security patches across the expected product lifetime. For special-purpose machinery under German depreciation tables that means up to 13 years (Art. 13(8)).
And the clock is running faster than many plan for. From September 2026, the 24-hour reporting obligation to ENISA for actively exploited vulnerabilities already applies – 14 months before full compliance is required. Penalties reach up to EUR 15 million or 2.5 percent of global turnover per infringement (Art. 64).
What matters is the nature of the obligation: CRA compliance is not a project with an end date. The following requirements run for as long as the machine is in the field:
- Create and continuously maintain an SBOM
- Monitor vulnerabilities continuously
- Run a risk assessment per CVE
- Deliver security updates without delay
- Complete conformity assessment
- Run regular security testing
- File ENISA notifications at 24 hours, 72 hours and 14 days
- Operate a coordinated vulnerability disclosure policy
- Retain technical documentation for at least 10 years or the full support period
The scale: the European Commission estimates manufacturer compliance costs across the EU at EUR 29 billion (Impact Assessment SWD(2022) 282). A survey of industrial equipment manufacturers expects product development budgets to rise by up to 20 percent per year (Risto et al., ARES 2025).
The OEM business model does not carry this. It is built on one-time sales, revenue through features and service, and engineering focused on customer value. The CRA forces the opposite: continuous vulnerability handling for up to 13 years, security patches provided free of charge, tied to scarce and expensive specialists. Patch debt consumes exactly the engineering capacity that should go into product and customer value.
The Key Term: “Exploitable”
This is where the decisive misunderstanding, and the decisive opportunity, lies.
The CRA does not require zero CVEs. Annex I, Part I, point 2(a) requires products “without known exploitable vulnerabilities”. The benchmark is exploitability, not the mere existence of a vulnerability. And the trigger is risk: Annex I, Part II, point 2 requires vulnerabilities to be addressed “in relation to the risks posed” without delay. Not a patch for every CVE.
The distinction matters in practice:
Vulnerability – A documented weakness in software. It exists regardless of whether it is reachable at all in a given deployment.
Exploitable Vulnerability – The same weakness that can actually be exploited under real operating conditions. Three factors make the difference: reachability, a practicable attack path, and an effective protective measure.
The CVSS score alone does not decide this. A vulnerability with CVSS 9.8 in a library function reachable only through physical access to an isolated, non-networked fieldbus segment is not exploitable in the CRA sense. A vulnerability with CVSS 6.5 in a remotely reachable management interface with a known, working attack path certainly is.
The numbers behind it: 119 new CVEs per day (BSI Situation Report 2025), of which roughly 1.1 percent are ever exploited in the wild (VulnCheck, 2014–2023). That is around 1.3 per day. Prioritising by exploitability rather than by volume means working on an entirely different set.
Exploitability Has a Location
This leads to the real architectural question: where do you mitigate exploitability?
A vulnerability does not become exploitable in every line of code, but at the machine’s point of access. Placing mitigation in the functional software means updating every release and every generation individually: assess, patch, test for side effects, regressions and breaking changes, release, communicate. Per vulnerability. Per version.
Placing it at the point of access requires one location. Implemented once, effective across all machines and generations.
“where technically feasible, new security updates shall be provided separately from functionality updates”
— Annex I, Part II, point 2 CRA
Separating security from function is therefore not one option among several, but the logical consequence of the concept of exploitability, and it is written into the CRA itself.
The Principle: Going Separate Ways
Concretely, this means a dedicated security layer that is identical on every machine and maintained independently. The function differs per machine, the security layer never does. Security updates flow only into the layer, functional updates only into the machine software. Neither touches the other.
Three effects follow:
Security stays current – without downtime
Security patches with no functional impact mean low risk and no full retest of the machine application.
Functional scope stays with the manufacturer
The functional update plan follows customer needs, not security urgency. The customer decides whether and when to adopt a release.
The attack surface shrinks
Security functions are extracted from the machine software and executed in isolation within a hardened layer. What is not deployed cannot be attacked.
And a strategic question arises: does every machine builder have to build this layer themselves and maintain it for 13 years, or is there a shared approach for the industry? Pooled security capability relieves each individual OEM without requiring them to become security specialists.
edge.PSL: Our Implementation of This Principle
edge.PSL is TRIOVEGA’s Protective Security Layer, shipped as an inseparable software component with the machine, at a fraction of the cost compared to building it in-house.
| edge.PSL is | edge.PSL is not |
|---|---|
| A component that mitigates the exploitability of vulnerabilities, legally inseparable from the machine, technically maintainable independently | A replacement for the OEM’s machine software development |
| Part of the machine, shipped by the OEM, with the CE declaration remaining with the machine builder | A complete standalone CRA compliance solution |
| Updatable independently of the machine software, security patches without touching function | A replacement for operator-side solutions (that is edge.SHIELDOR) |
| Configurable via a blueprint per machine that deploys only the required subset | An outsourcing of manufacturer responsibility |
TRIOVEGA supports monitoring, triage, patch delivery as well as SBOM and documentation over 13+ years, with an Emergency Lane for active exploitation and regular scheduled releases.
edge.PSL makes CRA compliance economically viable. edge.PSL alone does not make CRA-conform. The OEM retains responsibility for secure software development, physical interface security, overall risk assessment, CE marking and end-of-support decisions.
The Foundation
edge.PSL is built on TRIOVEGA’s patented edge.SHIELDOR technology, which already protects over a hundred production lines. Software AirGap and L7 protocol termination are the core technologies: no traffic passes directly between the IT and OT interface. Same technological basis, different market role. edge.SHIELDOR protects the plant operator, edge.PSL keeps the machine builder market-ready.
Three Takeaways
“Exploitable” is the lever. Not every CVE counts, but its exploitability does. Understanding this drastically reduces patching effort — and keeps you legally compliant.
Separating security from function makes CRA compliance economically viable. It is not a design option but the logical consequence of the concept of exploitability — and it is written into the CRA itself.
December 2027 is fixed. Those who start now still have room for a structured rollout. Those who wait do not.
Take the First Step
Book a call to explore how edge.PSL makes your machines CRA-compliant. without touching your machine software. We will answer your questions and assess together what a deployment could look like for you.
More on CRA and requirements for connected products in our earlier articles: Cyber Resilience Act – New Challenges in the Development of Connected Products and Mastering CRA Compliance: For a Strong Manufacturing Industry. To find out where your organisation stands today, feel free to book a no-obligation consultation with our team.
Author: Benjamin Pieritz
Benjamin Pieritz has over 20 years of experience in industrial software and knows production from the shopfloor up. In 15 years with Werum IT Solutions, the global market leader in pharma manufacturing IT (MES), he equipped hundreds of pharma plants worldwide, from engineering through product management to Executive Vice President & General Manager of Werum America. The acquisition by Körber AG added deep insight into machine building. Since 2021 he has led TRIOVEGA and its transformation into an OT security product company.
You want to know more about our products
and solutions?
edge.SHIELDOR
Holistic OT security for industrial plants that enables data connectivity and sustainably reduces costs
service.factoryINSIGHTS
Discover potential and optimize production processes effectively with our data science expertise
This might also interest you:
- Two years of trust, one backdoor: what the XZ-Backdoor teaches us about supply chain risks
Two years of unremarkable contributions, then a backdoor with root privileges. The XZ-Backdoor case shows how vulnerabilities reach production through routine updates, and which CRA obligations then apply. - CRA: When Security and Machine Go Separate WaysThe CRA does not require zero CVEs. The benchmark is exploitability. Understanding this, and separating security from function, makes CRA compliance economically viable for machine builders.
- CRA Update for Machine Manufacturers: What’s Due Now
The first CRA deadlines are no longer abstract – they are now. Why machine manufacturers face a different calculation, and which three drivers for action matter most.
