The complexity trap in cybersecurity

This article is a translation of the original German version published on Netzwoche.ch.

In 2025, the cybersecurity landscape seems more intricate than ever before. Organisations continue to embrace digital transformation, systemic dependency risks concentrate on a small number of very powerful organisations, the interconnectedness of systems is constantly growing, and geopolitical stability and order are declining. While these circumstances stimulate a forced growth in efficiency and innovation, they also bring a critical challenge – growing complexity. From a cybersecurity perspective, complexity is often the main enemy of security. This article provides examples of unnecessary complexity, explores why our world has become overly complex, and outlines solutions to address this trend.

What’s the issue with high complexity?

Complex systems inherently expand the attack surface because of the interplay of their components, their nonlinearity, interdependencies, and a reduced visibility overall. Moreover, complex systems often comprise non-mainstream functionality that is only used in rare situations, under particular circumstances but may carry powerful functionality or even vulnerabilities that an adversary can exploit. The more components, integrations, and dependencies a complex system has, the harder it becomes to manage, monitor, and secure.

In the following paragraphs, I’ll provide examples of unnecessary or at least questionable complexity. Before that, here are some numbers that illustrate the growth in complexity.

• A single web or mobile transaction now crosses an average of 35 different technology systems or components, compared to 22 just five years ago.
• The number of operations errors causing application outages has risen by 800% since 2000.
• The annual volume of new vulnerabilities in the CVE system increased from 18 per day in 2016 to 134 per day in 2025, which is over 7 times more in 9 years.
• The average number of hacking incidents reported by enterprises increased from 9 per year in 2020 to 37 in 2021.

The anomaly of cheap complexity

Back in 2018, Thomas Dullien presented the ‘anomaly of cheap complexity’, a phenomenon in modern computing where complex devices are often cheaper to produce than simpler ones. This concept challenges the historical norm where more complex devices were typically more expensive to build. Key aspects of this anomaly include the ability of general-purpose computers to simulate any other machine through software (universal computation) and the exponential growth in transistor density on chips, leading to increasingly powerful and cheap processors (Moore's Law).

Paradoxically, it's often more cost-effective to use a complex, general-purpose CPU and simulate simplicity through software than to build a simpler, specialised device with limited capabilities. This trend is fraught with risk. Why? If software running on unconstrained, general-purpose hardware is compromised, attackers could gain full access to powerful and interconnected systems – making it much easier to exploit them. The damage would naturally be limited to cut-to-size hardware devices. Consequently, this trend has led to an increased number of vulnerabilities and security challenges in modern IT infrastructure.

Software engineering complexity

A similar argument applies in software complexity. The ease of adding features in modern software development, particularly with support of AI-powered copilots, has led to questionable features and thus unnecessary complexity, simply because it has become almost free to add new features. Many overly feature-rich software applications include numerous functionalities that most users never touch, leading to bloated interfaces and slower performance, but also higher complexity.

When cost is no longer a limiting factor, we need novel mechanisms to avoid digital obesity and ‘featuritis’. The only effective approach to improving security and reliability of systems is through stringent control of their inherent complexity—something that must become a consciously developed form of common sense at both the engineering and management levels.

Here are some examples of overly complex applications:

• The Microsoft Office Suite: many users only use a fraction of the features, thereby overloading most of the users. Let me ask, who uses recursive lambda calculus in Excel? Who uses macros in Word for legitimate purposes? Most of this extra functionality is beneficial for attackers to run malware or to execute tasks such as gathering and exfiltrating data.
• Smart TVs: come loaded with apps and features that users rarely access, complicating the interface, potentially slowing down the system, and increasing the attack surface for cyber criminals to steal credentials or mine cryptocurrencies. 

Speculative execution: execute before you know what you need

In 1995, as part of the push to increase computation power beyond the physical limits of silicon architecture constraints, chip manufacturers introduced ‘speculative execution’. This method has been widely implemented as an optimisation technique in modern CPU design. Modern pipelined microprocessors implement speculative execution to reduce the cost of conditional branch instructions. This allows for predicting execution paths based on the branch history and thus for improving the overall system performance by addressing performance bottlenecks in modern processors.

This optimisation comes with significant drawbacks as widely demonstrated by the Spectre and Meltdown vulnerabilities in 2018. The attack surface of billions of devices using Intel, AMD, and ARM processors is increased because of the opportunities for side-channel attacks, exposing sensitive data during speculative operations through covert channels. This design violates established security mechanisms such as process separation, containerisation, and just-in-time compilation. The authorisation of an execution step is often only validated after its execution – too late.

Unfortunately, mitigation is nearly impossible in retrospect. Addressing speculative execution vulnerabilities often requires changes to processor designs and instruction set architectures, making it challenging to implement comprehensive fixes which leaves billions of existing systems vulnerable. The central judgment lies in the trade-off made between performance gains through added complexity and security risks taken.

The USB standard

The design of the USB standard, while revolutionising convenience and device interoperability, has inadvertently created a complex attack surface that malicious actors regularly exploit due to its wide range of powerful functionalities. For example, attackers have exploited USB ports to exfiltrate data from devices connected for battery charging. Moreover, USB devices can mimic human interface devices such as keyboards or other input peripherals, enabling attackers to exploit the relationships between computers and these devices and then inject malicious commands as keystrokes into systems without the user realising it.

The USB standard also allows for firmware reprogramming, which can turn ordinary devices into covert attack tools, a vulnerability that was publicly disclosed in 2014 at the Black Hat security conference. There are no built-in safeguards to prevent these unauthorised modifications. Finally, it is reported that 26% of all malware infections of Windows systems are due to the auto run feature in Windows. These threats — data exfiltration, command injection, firmware reprogramming — highlight the unintended vulnerabilities introduced by a standard designed for convenience.

Mitigations could come in the form of dedicated charging ports without data transfer (probably more costly and less convenient) or restricted permissions so that data access and identification as peripheral devices is prohibited by default. Additional functionality would only be unlocked after the user has actively requested it.

The CrowdStrike incident

Limiting the functionality might also have prevented the CrowdStrike incident of July 2024, where a faulty update caused widespread and simultaneous problems for roughly 8.5 million Windows machines that crashed and were unable to restart properly. The faulty update was applied to a kernel-level driver that has unrestricted access to core system functions. A single bug can lead to catastrophic system crashes and render entire systems suddenly inoperable. With fewer permissions or more fine-grained permissions of kernel-level modules, the severity of negative consequences would be reduced. An illustrative analogy is the early days of the smartphone era, when mobile apps had virtually no permission management and every app had unrestricted access to all sensors and metadata.

HTML rendering with JavaScript

HTML code is typically rendered with full JavaScript functionality, even in cases where static HTML would suffice. This often-unnecessary inclusion of JavaScript interpreters opens the door to malicious code execution, which is particularly notable since JavaScript is known to be an ambiguous and security-unfriendly language. An interesting parallel is the Log4J vulnerability, where excessive functionality led to widespread exploitation, underscoring the risks of enabling unnecessary features in systems.

Log4Shell

The vulnerability in Log4j, known as Log4Shell, is a prime example of a component being too powerful. The open-source logging framework is used in thousands of products worldwide and allowed attackers to execute arbitrary code on vulnerable systems. The critical remote code execution (RCE) flaw was discovered in late 2021. By submitting a specially crafted request, an attacker could take full control of a system, stealing information or launching ransomware attacks. The vulnerability was trivial to exploit, as it involved sending a simple, specifically crafted string to a vulnerable system that would process the input in its log systems using Log4j.

This issue highlighted the risks of unnecessary complexity in software – specifically, the inclusion of dynamic features such as JNDI lookups that were rarely needed but significantly increased the attack surface. It also highlighted the dangers of trusting user input and failing to properly validate or sanitise it.

Features that are outdated, unnecessary, or hidden

In addition to the above examples, there are more patterns widely used. For instance, the invocation of legacy components as software that retains outdated features can become a security liability. These components may not receive regular updates and may not even be used by legitimate users. Yet, they leave the users vulnerable to exploitation by criminal actors.

A similar argument can be made for unused libraries since including unnecessary libraries or modules in software increases the potential attack surface. Each additional component can introduce its own set of vulnerabilities. Some modern programming languages, such as Go, do not allow the inclusion of unused libraries.

Finally, there is the phenomenon of undocumented commands. As reported to the research community in March 2025, the ubiquitous ESP32 microchip, believed to be used in over 1 billion devices, contains undocumented commands that could be exploited for cyberattacks, such as spoofing trusted devices, unauthorised data access, pivoting to other devices on the network, and potentially establishing long-term persistence. Such undocumented commands add unnecessary power and complexity, creating an inherent risk that is hard to detect and mitigate.

Solutions to address the complexity trap

Reducing complexity doesn't mean compromising capability. Instead, it means designing systems with simplicity and security in mind. In addition to the suggestions provided above, here are more ideas on how organisations can avoid the complexity trap.

1. Plan for diversity and redundancy: Critical systems should be built with variations in the tech stack so that all deployed components don’t fail at the same time due to a single bug, flaw, or attack. Such artificially introduced diversity will drive up costs in the short term but will increase resilience in the long term.
2. Adopt modern security concepts such as zero-trust architectures: Zero-trust principles emphasise minimal access and continuous verification, simplifying access controls and reducing lateral movement within networks. So even if exploits are successful and the attacker manages to move laterally, they may be caught at the next hop.
3. Embrace secure-by-design principles: Designing systems with security as a core requirement ensures fewer vulnerabilities and reduces the need for reactive fixes. Additionally, a need-to-have principle may lead to a reduction of unnecessary features from the very beginning.
4. Invest in training and awareness: Simplifying systems is not enough; users and administrators must understand and properly use their tools and environments to maintain security. Also, they should be made aware of the growing attack surface scaling with every additional feature.
5. Focus on prioritisation: Organisations should identify critical assets and focus resources on protecting them, rather than attempting to secure every element of their environment equally. Threat modeling, attack trees, and risk matrices are helpful approaches.
6. Slowdown of deployment and avoiding a hasty market launch: Ultimately, a sustainable strategy that’s optimised for the long-term should include deliberate ‘breathing spaces’, instead of trying to penetrate the market as quickly as possible with semi-finished products (Compare with e-collecting or slowdown mechanisms such as proof-of-work in blockchain applications, or with Apple’s rater late deployment of Apple Intelligence.)

Critics may say that some of the above negate innovation, economic considerations, and practical constraints. I don't think so. Short-term, maybe. Long-term, no. Apple has been doing this successfully for some time now, without anyone accusing the company of not innovating.

Conclusions

In 2025, cybersecurity is no longer just about deploying the latest tools or complying with regulations; it’s about managing complexity. By embracing simplification, organisations can reduce vulnerabilities, enhance incident response, and build resilient systems that withstand the ever-evolving threat landscape. After all, in the battle against cyber threats, simplicity is not a limitation — it is a strength. We should focus more on implementing the absolutely needed core functionality, and making this excellent, instead of integrating more and more features into our products and infrastructure. The overly powerful feature used by regular users in only 1% of the cases might be the one exploited by the attackers in nearly 99% of the time.

The examples shown above demonstrate how the pursuit of versatility and efficiency can lead to systems that are more complex or powerful than practical for their intended use. Consider a soldier who might prefer a simple knife and bottle opener over a sophisticated blown-up Swiss Army knife. Victorinox’s Swiss Champ features 73 tools, including a magnifying glass, pliers, and even a fish scaler. While impressive, many of these tools are rarely used in everyday situations, adding unnecessary weight and bulk. Similarly, digital users often benefit more from streamlined, focused designs rather than overly complex or powerful systems. And organisations will not benefit from the short-sighted pursuit of profit, but rather from sustainable investments in strengthening the security of their products, which will be cheaper in the long run.