Do resilience. Build simply.

2026-03-17T00:00:00+00:00

The upcoming standards for the EU Cyber Resilience Act (CRA) not only help shape the resilience of the European society but also offer manufacturers an opportunity to build genuinely better products. The standards promote simplicity as a core design principle, which successful products have already adopted. However, those real-world examples also remind us that building resilient products is hard, requiring focus and engineering excellence.</p>

</div>

Contributing to a resilient European society</a></h2>

It is easy to approach the CRA</a> as a compliance burden and focus only on deadlines, cost, and liability</a>. And while that is understandable, it misses the CRA’s main point, stated directly in Recital (1):</p>

Cyberattacks represent a matter of public interest as they have a critical impact not only on the Union’s economy, but also on democracy as well as consumer safety and health.</p> </blockquote>
The rise</a> in product security defects 1</a></sup> and product security-related incidents over the past decades is not a natural “law” or “phenomenon.” It is the result of an exploding number of connected products and technology that have outpaced security practices, a trend that is accelerated in the face of AI</a>. Recognising that these factors are human-made gives us the option to challenge and change them.</p>
Recital (1) reminds us that manufacturers 2</a></sup> help shape the resilience of the societies their products operate in. And I believe that they should embrace that responsibility, while seizing its opportunities.</p>
Building simple, secure, and successful products</a></h2>
In this article, I’m going to make the case that by reducing complexity</a> and instead striving for simplicity, organisations build better products that are likely to be more competitive.</p>
Complexity is the worst enemy of security.—Bruce Schneier (1999)</a></p> </blockquote>
The “Eierlegende Wollmilchsau,” a German term used to describe something that seems to satisfy all possible needs all at once, is not a recipe for success. Bloat leads to vast configuration options which may produce invalid, insecure, or unsafe states; and obscure features which might not be maintained rigorously and, therefore, have a higher risk of containing defects. Every feature and every line of code added creates new liability</a>. Even high-profile open-source projects such as OpenSSL</a> have defects that have gone unnoticed for decades. One can only conjecture how many defects are lurking in less visible and proprietary systems, something that recent AI-supported cybersecurity tools</a> might soon reveal at scale.</p>
So, what is the alternative? Simplicity and focus, which facilitate reasoning and reduce the risk of security defects. Apart from improving security, there is at least anecdotal evidence that products embracing focus and simplicity are genuinely superior. For example, the success of Apple and its products has at least partially been attributed to Steve Jobs’ mantra of focus and simplicity</a> (note this was before Apple became a trillion-dollar company</a>).</p>
Simplicity and the 41 CRA standards</a></h2>
The European Commission has requested</a> a total of 41 (!) standards</a> to be developed by CEN, CENELEC, and ETSI</a>: 15 horizontal standards that apply to all products in scope of the CRA, and 26 vertical standards that apply to specific product categories only. The vertical standards are expected to be harmonised</a></em>, enabling manufacturers to leverage the presumption of conformity</a> rule when demonstrating compliance, which is especially relevant for important Class I products.</p>
While I can see the motivation of the European Commission to split requirements into multiple standards, i.e., the mere breadth of products the CRA applies to, having to deal with 41 standards sounds neither focused nor simple. However, when looking closely at the 15 horizontal standards, they are mapped directly to the 15 essential requirements set out in Annex I of the CRA, which encode well-known security best practices.</p>
In the following, I will look at a selection of them, explain their intent, and discuss relevant real-world product examples.</p>
Secure-by-default configuration</a></h3>
Most users neither want nor know how to configure security controls. Secure-by-default configurations (Annex I, Part 1, (2b) of CRA) therefore mean reducing risky choices through user-centric onboarding, no default credentials, adopting deny-by-default access policies, and automatic security updates.</p>
A good example is Caddy</a>. It can deploy a production-ready HTTPS reverse proxy with a single command:</p>
$ caddy reverse-proxy --from example.com --to :9000 </code></pre>Behind the scenes, Caddy requests and renews the necessary TLS certificates via ACME</a> automatically, which reduces the chance of insecure deployment due to accidental misconfigurations.</p> Another interesting example is Apple’s robust configuration options for AirDrop</a>. By default, users can receive content from contacts only. They can temporarily allow content from anyone nearby, but the setting resets after 10 minutes automatically. The automatic reset demonstrates balancing usability with a secure default, which reduces users’ indefinite exposure from insecure settings</a>, just because they decided to share that selfie with an acquaintance during their last vacation.</p> Data minimisation</a></h3> The principle of data minimisation (Annex I, Part 1, (2g) of CRA) is simple: what is not there, cannot be leaked. In other words, products should only collect, store, or process the data they need to fulfil their purpose. Creating an inventory of what data is processed and why is the first step for improving data minimisation.</p> For example, the Signal</a> and Threema</a> messengers aim to minimise the data processed on their servers. In Signal’s case, cleartext messages remain exclusively on end-user devices, while the service stores only the users’ phone numbers and the time of their last online activity.</p> Failures of data minimisation are common in consumer products, from vacuum robots storing and uploading intimate pictures from homes</a>, voice assistants recording private conversations</a>, and, more recently, misconfigured AI tools leaking user data</a> and private conversations</a>.</p> Service availability</a></h3> Service availability (Annex I, Part 1, (2h) of CRA) depends on careful architectural and technological choices.</p> One positive example is Cloudflare’s use of anycast to deliver services globally under shared IP addresses. This provides automatic failover in case of local outages and typically improves latency at the same time.</p> Negative examples include IoT devices that depend on Internet connectivity or a vendor-operated cloud service to provide their core functionality. That core functionality becomes unavailable if the local Wi-Fi network fails, the cloud service is unavailable, or the operator shuts the service down permanently</a>. As a mitigation, products should offer (potentially degraded) core functionality through local interfaces such as physical controls, Wi-Fi, or Bluetooth.</p> Attack surface reduction</a></h3> Attack surface reduction (Annex I, Part 1, (2j) of CRA) means disabling or removing components that are not needed for the product to function. This includes physical interfaces such as debug ports, logical interfaces such as APIs, and unnecessary software dependencies or cloud integrations. This topic often triggers hard but important discussions.</p> One such discussion was triggered when researchers discovered</a> undocumented commands in the widely used ESP32 microchip. In response</a>, the manufacturer removed them via firmware updates.</p> Products such as Talos</a> and IncusOS</a> show how to reduce attack surface in practice: Both hypervisor operating systems feature immutable system images, which protect against persistent malware. Also, they disable local shells in favor of a web-based management API, which narrows the attack surface and allows development teams to focus on hardening a single API.</p> Simple ≠ easy</a></h2> Resilient products do not happen by accident. They require careful analysis of intended use and context. They require pairing domain knowledge with deep technical expertise. They require understanding design and technology intricacies, cutting through noise, and making informed decisions. This is true for all projects, on all levels and at all scales, from reusable software libraries and hardware components to fully integrated products and large-scale ecosystems.</p> Creating resilient products is hard. But they are necessary for a successful society. So, let’s build simply.</p> Former CISA director Jen Easterly prefers the term product defect</em> over vulnerability</em> to attribute responsibilities clearly</a>. ↩</a></p> </li> The CRA also has importers and distributors in scope. However, I’ll try to keep this article generally simple with respect to details, as there are other great resources</a> and articles</a> dissecting the intricacies of the CRA. ↩</a></p> </li> </ol> </section>

Milan Stute

Do resilience. Build simply.