Invisible Attack Surfaces: Why Embedded Security Is Your Next Executive Risk
Presented by Jorn Lapon, Research Manager for Secure Software at the KU Leuven DistriNet Research Unit,, at BE-CEC on June 23, 2026 in Auberge du Pêcheur , Sint-Martens-Latem.
At Belgium’s Cybersecurity Executives Conference (BE-CEC), Jorn Lapon delivered a compelling keynote that challenged a common assumption among security leaders: that the enterprise attack surface is limited to laptops, servers, and cloud infrastructure. It isn’t.
Increasingly, the most dangerous entry points into corporate environments are devices most executives rarely think about—embedded systems quietly operating in offices, production sites, and facilities. From smart TVs and printers to HVAC systems, industrial controllers, cameras, elevators, and solar inverters, these devices are expanding the attack surface faster than most organizations can track.
Lapon, Research Manager for Secure Software at the KU Leuven DistriNet Research Unit, framed the issue in business terms rather than purely technical ones: embedded security is no longer just an engineering problem—it is now a governance problem.
The Attack Surface You Cannot See
A central message of the presentation was simple: you cannot secure what you do not know exists.
Most organizations have reasonably mature visibility into traditional IT assets. They know their endpoints, their servers, and often their cloud workloads. But embedded devices live outside those standard management processes.
Many security teams cannot answer four basic questions about these devices:
-
What devices are connected?
-
Where are they located?
-
Who manages them?
-
Are they secure and patched?
That lack of visibility creates what Lapon calls an invisible attack surface.
Unlike traditional endpoints, embedded systems usually do not run antivirus, EDR agents, or telemetry tools. Security teams often rely on indirect methods such as network fingerprinting to infer software versions and map them to known vulnerabilities (CVEs). But even that provides only partial visibility.
This blind spot is increasingly attractive to attackers.
Recent ransomware campaigns have shown how unmanaged systems and remote access tools become ideal pivot points. Attackers are no longer only targeting user workstations; they are exploiting the weakest and least monitored device in the environment.
Hidden Connectivity: The New Risk Multiplier
One of Lapon’s strongest warnings focused on remote connectivity.
In the past, remote access to embedded devices usually depended on port forwarding and firewall configuration. Security teams at least had visibility into which connections were allowed.
Today, many vendors use cloud relays and proxy services to simplify remote maintenance and support. Brands such as Siemens, Ricoh, KONE, and Hikvision increasingly rely on such architectures.
That convenience comes with risk.
What appears to security teams as an outbound connection may in reality enable bidirectional communication through an external relay. The implication is significant: third-party vendors effectively become extensions of the enterprise attack surface.
As Lapon put it, “What you see is not what you get.”
This creates difficult operational challenges:
-
TLS inspection becomes ineffective
-
Security teams lose visibility into who is accessing the device
-
Vendor compromise can become customer compromise
In other words, supply chain risk now extends beyond software into operational connectivity itself.
Regulation Helps—But It Won’t Solve the Problem
The keynote also explored the regulatory dimension.
Security leaders are already familiar with frameworks such as NIS2 Directive and General Data Protection Regulation. But Lapon highlighted another increasingly relevant framework: the Cyber Resilience Act (CRA).
The CRA introduces important requirements for connected products:
-
Security by design
-
Vulnerability reporting
-
Software Bill of Materials (SBOM)
-
Accountability across the product lifecycle
-
Longer security support obligations
This is a major step forward for Europe’s embedded security ecosystem.
But Lapon emphasized an important nuance: regulation creates a baseline—not immunity.
Even compliant products can still be exploited.
The CRA improves vendor incentives and increases transparency, but it does not eliminate technical complexity, legacy systems, or operational weaknesses.
For CISOs, the takeaway is clear: compliance should not be mistaken for resilience.
Why “Better Devices” Are Not Enough
One of the most striking parts of the session was Lapon’s comparison between traditional IT, operational technology (OT), and consumer IoT.
Security maturity differs dramatically across these domains. Traditional IT vendors such as Microsoft have decades of security engineering experience. OT vendors often prioritize reliability and uptime. Consumer IoT manufacturers frequently optimize for cost and speed to market.
That difference matters.
Embedded security problems often originate upstream—in how devices are designed and built.
An embedded system is not a single piece of software. It is a stack of components:
-
Hardware
-
Firmware
-
Operating system
-
Libraries
-
Applications
-
Third-party dependencies
Every component introduces risk.
The scale of this challenge is enormous.
Lapon illustrated this using Linux kernel vulnerability data. The number of reported kernel CVEs has grown sharply over the past decade, reflecting increasing software complexity.
In one example, a clean embedded Linux base image contained:
-
94 ignored vulnerabilities
-
577 unpatched vulnerabilities
-
16,744 patched vulnerabilities
This demonstrates a difficult reality: modern embedded devices inherit vast vulnerability exposure before organizations even deploy them.
There is another structural problem: lifespan mismatch.
A laptop might be replaced every 3–5 years.
An industrial controller or building management device may remain operational for 10–30 years.
Meanwhile, software support—such as Linux Long-Term Support—typically lasts around five years. After that, devices can outlive their security support entirely. If the vendor exits the market or discontinues the product, patching may stop permanently.
This is why Lapon urged executives to adopt a sobering assumption:
Treat embedded devices as insecure by default.
What Executives Should Do Now
The session concluded with practical guidance for security leaders.
The first priority is visibility.
Organizations need complete asset inventories that include embedded and IoT devices—not just traditional IT. Security teams should understand what is connected and maintain SBOM-based insight where possible.
Second, segmentation is essential.
Rather than allowing embedded devices broad network access, organizations should isolate them into dedicated zones with tightly controlled communication paths. Micro-segmentation limits lateral movement and reduces blast radius during compromise.
Third, monitoring must evolve.
Because EDR agents cannot run on most embedded devices, detection must become behavior-based. Security teams should monitor outbound traffic, relay connections, and vendor advisories to detect suspicious activity.
Finally, organisations must manage the full lifecycle:
-
Commission devices securely
-
Change default credentials
-
Maintain patching and compensating controls
-
Decommission properly by wiping and revoking access
Too many organisations focus only on deployment and forget retirement, leaving orphaned devices behind.
The Executive Takeaway
Lapon closed with a message every board and CISO should internalise:
The device itself is often the cheapest part. The security risk around it is not.
A smart sensor may cost only a few hundred euros. But if compromised, it can trigger operational disruption, data loss, regulatory consequences, and reputational damage costing millions.
The age of invisible attack surfaces has arrived.
For executives, embedded security can no longer remain buried inside engineering teams or procurement decisions. It must become part of enterprise risk management, governance, and cyber strategy.
Because the next breach may not begin in the cloud, on a laptop, or in a data center. It may begin with a coffee machine, a camera, or a thermostat nobody remembered was online.
