In our previous blog posts on cybersecurity, we’ve explored the gap between compliance with cybersecurity regulations and actual product security. Documentation, risk assessments, and vulnerability management processes provide an important foundation, but they cannot demonstrate whether a product can actually withstand an attack. The next question is therefore where these attacks are likely to come from.
The Hidden Side of the Attack Surface
For connected and embedded products, the answer is often less obvious than expected. Their attack surface extends beyond the interfaces and components that are visible during normal operation. Development functionality, maintenance interfaces, firmware, hardware access, update mechanisms, and third-party components can all provide potential entry points. Some of these may never have been intended to be accessible outside development or servicing.
The Functionality Nobody Looks For
A product specification usually provides a relatively clear picture of how a device is supposed to communicate. There may be Ethernet or Bluetooth connectivity, a mobile application, an API, or a connection to a backend service. These interfaces naturally receive attention during security assessments because they are known and externally visible. Embedded devices, however, often contain additional functionality that exists for entirely different reasons. A Bluetooth service may have been introduced for debugging, a network service may listen on a port that is irrelevant during normal operation, or maintenance functionality may expose commands intended only for trusted technicians.
When Additional Functionality Expands the Attack Surface
None of these functions are inherently vulnerabilities. The problem begins when they remain accessible in a production system, when their protection is weaker than assumed, or when they provide capabilities that were never considered in the original threat model. The resulting attack surface can therefore be considerably larger than the functionality visible to a normal user.
Where the Real Blind Spots Are
Every product is different, but several areas consistently deserve closer attention when assessing the security of connected and embedded systems. What makes them particularly relevant is that they can easily be overlooked when security testing focuses primarily on documented functionality and externally visible communication.
1. Firmware
Firmware can contain weaknesses that are difficult to identify from the outside. Insecure configurations, hard-coded information, outdated libraries, undocumented functionality, or flaws in custom implementations may only become visible once the firmware itself is analyzed.
Firmware is also easily treated as a trusted part of the product rather than an attack surface in its own right. For an attacker who gains access to a firmware image, however, it can provide detailed insight into how a device works, which functionality it contains, and where further weaknesses may exist. Product security therefore cannot be limited to testing externally reachable services.
2. Field updates
A product that was thoroughly tested before release does not remain unchanged. Firmware is updated, configurations change, dependencies receive new versions, and additional functionality is introduced. Field updates are essential for maintaining products and fixing vulnerabilities, but every update also changes the system that was originally assessed.
A new firmware version can introduce another dependency, alter an existing configuration, expose additional functionality, or reintroduce a weakness that had already been resolved. Security validation therefore has to consider not only the initial product, but also changes that occur throughout its lifecycle.
3. Hardware interfaces
Embedded devices frequently contain interfaces that were introduced for development, manufacturing, diagnostics, or maintenance rather than normal product operation. JTAG and other debug interfaces are typical examples. During development, they provide valuable low-level access to the device, and similar access may also be required for manufacturing, servicing, or troubleshooting.
The security problem begins when these interfaces remain accessible on production devices or when the mechanisms intended to protect them can be bypassed. Physical access can then expose capabilities that would never be available through the product's intended communication interfaces. Assessing these interfaces requires an understanding of embedded hardware, debugging mechanisms, and the interaction between software and hardware.
4. Physical and side-channel attacks
Some weaknesses only become visible when the physical behavior of the device itself is considered. Side-channel analysis can use characteristics such as power consumption, timing, or electromagnetic emissions to gain information about internal operations, while fault injection techniques actively manipulate a system to provoke unintended behavior. One example is voltage glitching, an area that has also been part of the academic work of co-founder and Senior Manager Dr. Enrico Pozzobon from dissecto.
The relevance of such techniques goes beyond the physical attack. As Enrico explains:
“While hard to reproduce at scale, physical attacks are often used as an entry point to expose other hidden software vulnerabilities that can be exploited through more classical means.”
This makes physical attacks particularly relevant when assessing the real attack surface of an embedded product. Even if an attack such as voltage glitching is difficult to perform at scale, it can reveal weaknesses or bypass assumptions that would otherwise remain hidden. Once exposed, the underlying software vulnerability may provide a much more accessible attack path. Physical security testing therefore does not exist in isolation from software security, but can help uncover weaknesses that conventional testing alone might miss.
5. CVEs and known vulnerabilities
Known vulnerabilities present a different kind of blind spot. As discussed in the previous article, an SBOM provides valuable transparency into the software components contained in a product. Combined with vulnerability information, it can help identify components associated with known common vulnerabilities and exposures (CVE). But knowing that a CVE exists does not automatically determine what it means for the actual product.
Whether a vulnerability can be exploited depends on how the affected component is used, configured, and integrated into the overall system. At the same time, the absence of known CVEs does not demonstrate that an implementation is secure. Product-specific weaknesses, insecure configurations, or unexpected interactions between components may never appear in a vulnerability database at all. CVE monitoring is therefore an important part of vulnerability management, but it does not replace technical validation of the actual product.
Why Product Security Differs from IT Security
These blind spots also illustrate why approaches developed for traditional IT security cannot simply be transferred to connected and embedded products. IT environments typically consist of comparatively standardized operating systems, applications, networks, and infrastructure, supported by mature tooling for vulnerability scanning, monitoring, and patch management.
Embedded products are considerably more heterogeneous. They combine custom hardware and firmware with specialized operating systems, proprietary protocols, physical interfaces, and product-specific functionality. Testing these systems therefore requires product-specific security expertise. Security researchers may need to analyze firmware, understand diagnostic protocols, identify undocumented services, interact with debug interfaces such as JTAG, or investigate the physical behavior of a device. This becomes particularly important for weaknesses that are not already described in vulnerability databases or anticipated by existing security requirements.
From Individual Findings to Continuous Validation
A penetration test or security assessment can uncover exactly these kinds of weaknesses, but it still represents the state of a product at a specific point in time. As firmware, configurations, and components change, previously resolved vulnerabilities can return and new ones can emerge.
Once a weakness has been identified and understood, however, the corresponding security check can be turned into a reproducible test. This is where HydraVision extends individual security activities into an ongoing validation process. The Security Test Environment allows security tests and workflows to be automated and reused across product versions and systems. Findings from manual analysis, penetration testing, or known vulnerabilities can therefore become repeatable security tests instead of remaining isolated results in a report. You do not even have to start from scratch: HydraVision already includes 150+ preconfigured test cases that you can leverage right from the beginning.
HydraVision does not replace the expertise required to discover previously unknown attack paths. Instead, it provides a way to preserve and reuse the resulting security knowledge: New findings can become new tests, while existing tests verify that known weaknesses do not return as the product evolves.
Why This Matters for the CRA
This is also where technical product security and the Cyber Resilience Act come together. The CRA requires manufacturers to address cybersecurity risks throughout the lifecycle of products with digital elements. Yet a risk assessment, an SBOM, or a documented security requirement cannot by itself reveal an undocumented debug interface, an unnecessary open port, a physical attack path, or a weakness introduced through a later firmware update.
Technical security testing complements these activities by validating their assumptions against the actual product. For connected and embedded devices, this means looking beyond the obvious interfaces and considering software, firmware, communication protocols, hardware, and lifecycle changes together.
The attack surface of a product is not limited to what is intended to be exposed, and it does not remain unchanged after release. Understanding and continuously validating that attack surface is therefore an important part of moving from documented cybersecurity to actual product security.
This article is part of our blog series Cybersecurity Reality Check, where we explore how cybersecurity regulations translate into real-world product security. How the above mentioned continuous validation is achieved in practice, and which technologies, testing methods, and security expertise make it possible, will be explored throughout the remainder of this series.
