Why Is Embedded Security So Hard to Get Right?

Embedded security is often considered one of the toughest challenges in cybersecurity. Unlike traditional IT security, where updates, patches, and monitoring are routine, embedded systems have long lifecycles, limited computational resources, and are often deployed in environments where security was an afterthought.

We've encountered these challenges firsthand in our work across industries—whether securing IoT devices, assessing vulnerabilities in SCADA systems, or working with defense clients to harden mission-critical embedded components. In this article, we'll break down the core difficulties in embedded security and share real-world lessons learned.

1. Embedded Systems Are Designed for Functionality, Not Security

Most embedded systems are engineered with a primary focus on performance, power efficiency, and reliability—security often takes a back seat. Unlike IT systems where software patches and security updates are the norm, embedded devices are built to perform specific tasks for years, sometimes decades, with minimal maintenance.

This is particularly problematic because security vulnerabilities often emerge over time. While an IT system can regularly update its defenses to mitigate newly discovered threats, embedded systems are often left with outdated protections. Additionally, many of these devices operate in environments where regular updates are difficult or impossible due to operational constraints, such as continuous industrial processes or medical applications where downtime is unacceptable.

Case Study: Industrial Control Systems (ICS)

In one of our projects, we assessed an industrial automation setup where programmable logic controllers (PLCs) had been running for over 15 years. The manufacturer had never released a firmware update, leaving the devices vulnerable to known exploits. When we tested these PLCs, we found that with minimal effort, we could inject malicious commands remotely—something an attacker could easily exploit to disrupt production lines. The issue? Security had never been a design priority, and updating the firmware required taking critical systems offline, something the company had avoided for years.

2. Limited Resources Make Traditional Security Measures Unfeasible

Many embedded devices operate with constrained processing power, limited memory, and low-bandwidth communication channels. Implementing traditional security measures like encryption, secure boot, or endpoint protection can be difficult due to these limitations.

Because of these constraints, embedded devices often rely on lightweight security mechanisms that may be outdated or insufficient against modern attacks. For example, many manufacturers implement weak encryption algorithms or fail to incorporate hardware security modules (HSMs) due to cost and resource limitations. Additionally, secure update mechanisms are often ignored or implemented poorly, leaving devices vulnerable to firmware attacks.

Case Study: Medical Devices

We were engaged to assess a wearable medical device that continuously transmitted patient data. The manufacturer had implemented encryption, but due to the device's limited processing power, it was using an outdated encryption algorithm that could be cracked in minutes. When we proposed an upgrade, we hit another wall—updating the firmware required physical access to each device, and the company had thousands of them deployed globally. The lesson here? Security needs to be built into the design from the start, rather than being bolted on later.

3. Embedded Systems Are Often Part of Complex, Legacy Infrastructure

Many embedded systems are not standalone devices but part of a larger ecosystem, often including legacy components with little to no security in place. Adding security to one part of the system does not necessarily secure the entire network.

Legacy infrastructure poses a significant risk because these systems were often designed at a time when cybersecurity threats were less sophisticated or even nonexistent. Many industrial and critical infrastructure environments rely on outdated communication protocols that lack authentication or encryption, making them easy targets for attackers. Even if security is improved on new components, attackers can still exploit older, insecure parts of the system to gain entry.

Case Study: Transportation Security

During a penetration test of a transportation system, we identified that a single compromised embedded device in a sensor network could be leveraged to manipulate traffic signals remotely. The system had modernized parts but still relied on legacy communication protocols that lacked authentication. The operators had assumed that physical security (restricting access to networked components) was enough, but once we gained access to one vulnerable device, we could pivot through the entire infrastructure. This case demonstrated how embedded security isn’t just about securing individual devices—it’s about securing the entire ecosystem.

4. The Supply Chain Problem: Third-Party Components and Firmware

Most embedded systems are built using third-party hardware and software components. Many vendors do not provide transparency regarding security vulnerabilities in their products, and even when they do, updating firmware is often difficult or impossible.

The complexity of the supply chain introduces hidden risks. Manufacturers often integrate third-party firmware, libraries, and components without fully understanding their security implications. If a security flaw is discovered in one of these components, manufacturers may struggle to patch the issue—especially if the supplier is slow to release updates or no longer maintains the software. This lack of control creates systemic vulnerabilities that can affect entire product lines.

Case Study: Consumer IoT Devices

We analyzed a smart home security system that relied on a third-party firmware stack for its wireless communication. During our assessment, we discovered an unpatched vulnerability in the firmware that allowed an attacker to eavesdrop on communications and replay authentication tokens to gain unauthorized access. The manufacturer was unaware of this issue because they did not have visibility into the third-party code. This highlights a common problem: security risks in embedded devices often originate from components outside the direct control of the manufacturer.

5. Security and Usability Are Often at Odds

Users and manufacturers often prioritize ease of use over security. Default passwords, hardcoded credentials, and insecure update mechanisms are still rampant in embedded devices because security measures are often seen as an inconvenience.

Security controls need to be practical and integrated in a way that does not hinder usability. If security features are too cumbersome, users will find workarounds that compromise security. For instance, complex authentication mechanisms might lead users to write down passwords, and difficult update processes might result in outdated firmware being left vulnerable.

Case Study: Embedded Security in Defense Projects

In a defense-related engagement, we were tasked with improving the security of an embedded system used in field operations. The existing authentication mechanism required operators to manually enter complex passcodes before each use, which led to complaints about usability. During our assessment, we found that operators were informally sharing passcodes to simplify their workflow, making it easier for unauthorized users to access the system. Additionally, in response to ongoing complaints, the authentication mechanism was altered, and the password complexity criteria were lowered. As a result, users opted for weak and easily guessable passwords, significantly increasing the risk of unauthorized access. This change, while improving usability, ultimately weakened the system’s security posture. This highlights the need to balance security with operational practicality, ensuring that security controls do not create friction that leads users to adopt insecure practices.

Lessons Learned and Best Practices

So, what can we do to improve embedded security?

• Secure by Design – Security should be a design priority from the beginning, not an afterthought.

• Regular Updates and Patch Management – Manufacturers must create mechanisms for safely updating firmware, even in resource-constrained environments.

• Supply Chain Security – Vendors must demand transparency and security assurances from third-party suppliers.

• Defense in Depth – Secure communication protocols, strong authentication, and physical security should all be part of the security strategy.

• Balancing Security with Usability – Security measures should be designed with real-world usability in mind to avoid workarounds that weaken protection.

Embedded security is hard to get right, but as these real-world examples show, failing to address it can have serious consequences. At MottaSec, we’ve seen firsthand how these challenges manifest in different industries. If you're working on securing embedded systems and want to ensure that security isn’t an afterthought, we’re here to help.

Let’s talk about how we can make your embedded systems more resilient—before attackers do.