Introduction to Embedded Systems Security

Embedded systems security is one of the fastest-growing disciplines in both IoT and industrial engineering, yet it remains poorly understood by many of the engineers who build these devices. This article covers what embedded systems are, why they are uniquely difficult to secure, where real attacks have caused measurable damage and what threat categories you need to plan for at design time. It is written for anyone from a hobbyist building their first ESP32 project to a professional engineer shipping firmware at scale.

Table of Contents

1. What Are Embedded Systems?
2. Components of an Embedded System
3. Where Embedded Systems Are Used
4. Why Embedded Security Is Different from General Computing
5. Hardware Constraints That Directly Affect Security
6. Design and Operational Challenges
7. Real-World Attack Cases You Should Know
8. The Four Categories of Attack Impact
9. Security vs Performance, Cost and Convenience
10. Getting Started with Embedded Systems Security
11. Conclusion

What Are Embedded Systems?

An embedded system is a specialized computer built to perform one specific function inside a larger device. Unlike a general-purpose laptop that can run any application, an embedded system is designed from the ground up to do one job reliably and efficiently. The thermostat on your wall, the anti-lock braking controller in your car, the glucose monitor a diabetic wears on their wrist and the PLC (Programmable Logic Controller) managing a factory production line are all embedded systems.

Four characteristics define almost every embedded system:

• Dedicated function: The software is purpose-built. There is no general application layer to install arbitrary programs.
• Real-time operation: The system must respond to external events within a defined time window. A braking system that takes two seconds to react is not just slow, it is dangerous.
• Resource constraints: Processors run at MHz not GHz, RAM is measured in kilobytes not gigabytes, and flash storage is similarly limited.
• Long lifespan: Many embedded devices run for 5 to 20 years in the field without replacement. A medical infusion pump deployed in 2012 may still be in clinical use today.

These characteristics are not incidental. They are deliberate engineering trade-offs. They also create the security conditions that make embedded systems a growing target for attackers.

Components of an Embedded System

Understanding security starts with understanding what you are protecting. A typical embedded device contains the following hardware layers, each of which introduces its own attack surface:

Microcontroller or Processor

This executes your firmware. Common choices include ARM Cortex-M series (STM32, nRF52), Xtensa LX6/LX7 (ESP32), AVR (Arduino) and RISC-V variants. The processor determines what hardware security features are available: memory protection units (MPU), hardware crypto accelerators, secure boot ROM and trusted execution environments (TEE).

Memory

Embedded systems use multiple memory types with different security properties:

• Flash: Non-volatile storage for firmware. Can be read-protected via option bytes (STM32) or eFuse settings (ESP32). Default: fully readable.
• RAM: Volatile runtime memory. Holds stack, heap and global variables including any secrets that are decrypted at runtime.
• ROM/OTP: One-time programmable memory used for bootloaders and root keys. Once written, cannot be changed.
• EEPROM: Small non-volatile storage often used for configuration and calibration data. Frequently overlooked during security reviews.

Sensors and Actuators

Sensors collect data from the physical world. Actuators change it. Both are potential attack vectors: a spoofed temperature reading can force a cooling system into an unsafe state; a maliciously commanded actuator can open a valve or release a lock.

Communication Modules

These are where most network-level attacks begin. UART (Universal Asynchronous Receiver-Transmitter), SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit), USB, Ethernet, WiFi, Bluetooth Low Energy (BLE), Zigbee, LoRa and cellular modems each introduce a distinct attack surface. Most embedded designs include at least three of these.

Power Supply

Power delivery is less obvious as a security concern but matters for fault injection and side-channel attacks where an attacker manipulates supply voltage to bypass security checks or leak cryptographic keys through power consumption patterns.

Where Embedded Systems Are Used

Over 30 billion connected embedded devices are projected to be in operation worldwide by 2030. They appear in every industry sector, which means a security failure in one category has a completely different consequence profile than a failure in another.

Consumer and Smart Home

Smart speakers, thermostats, security cameras, door locks, baby monitors and home routers. These devices are commonly in networks with personal laptops and phones. A compromised camera can provide persistent surveillance access. A compromised router is a foothold into every device on the network.

Automotive

Modern vehicles contain between 50 and 150 electronic control units (ECUs). These handle engine management, transmission, ABS (Anti-lock Braking System), ADAS (Advanced Driver Assistance Systems), infotainment and telematics. The CAN (Controller Area Network) bus connecting them was designed for reliability, not security. There is no authentication between ECUs on a standard CAN bus.

Healthcare

Insulin pumps, pacemakers, infusion pumps, patient monitors and hospital asset-tracking systems. A compromised medical device is not just a data breach, it is a patient safety event. The US FDA (Food and Drug Administration) issued mandatory cybersecurity guidance for medical devices in 2023 precisely because this threat is real and growing.

Industrial and Critical Infrastructure

PLCs, SCADA (Supervisory Control and Data Acquisition) systems, RTUs (Remote Terminal Units) and DCS (Distributed Control System) components control water treatment plants, power grids, gas pipelines and manufacturing lines. The Stuxnet worm (2010) demonstrated that embedded industrial systems can be physically destroyed through software. The Ukrainian power grid attack (2015) demonstrated that 230,000 people can lose power through embedded system compromise.

Telecommunications and Networking

Home and enterprise routers, cellular base stations, optical network terminals and DNS resolvers all run embedded software. These devices handle enormous data volumes and are high-value targets for nation-state actors and botnet operators alike.

Why Embedded Security Is Different from General Computing

Embedded systems security is not simply “normal security applied to small computers.” It is a fundamentally different discipline with different constraints, threat models and tooling. If you approach it expecting to apply the same controls you use on a Linux server, you will fail.

You Cannot Install a Security Agent

On a general-purpose system, you add antivirus software, an intrusion detection agent, a log shipper and a vulnerability scanner. On a microcontroller with 256 KB of flash and 64 KB of RAM, there is no space for any of that. Every security control must be native to the firmware, lightweight and carefully measured for overhead.

Patching Is Not Routine

On a server, patching is a scheduled task. On an embedded device, it may require physically visiting the device, connecting over a proprietary protocol, validating a signed firmware image and then hoping nothing goes wrong during the flash write. Many devices in the field have no over-the-air (OTA) update capability at all. Once deployed, their firmware is effectively frozen.

Physical Access Is Common

A server sits in a locked data centre. An embedded device may be mounted on an exterior wall, bolted to a utility pole, installed in a rental car or shipped to a consumer’s home. Physical access is not the exceptional threat it is in traditional IT security, it is the default assumption. An attacker with physical access and basic electronics skills can often extract firmware in under an hour using exposed JTAG (Joint Test Action Group) or UART debug ports.

Attacks Have Physical Consequences

Compromising a database server risks data. Compromising an embedded system in a physical environment risks infrastructure, equipment and human safety. This raises the stakes and the regulatory scrutiny significantly.

Real-Time Requirements Conflict with Security Operations

A security operation that delays a network packet by 50ms is invisible on a web server. The same delay in a real-time control loop can cause a motor controller to overshoot, a safety system to fail to engage in time or a communication window to be missed entirely. Security controls must be measured for timing impact, not just correctness.

Hardware Constraints That Directly Affect Security

Security engineers coming from enterprise backgrounds consistently underestimate how much the hardware limits what is possible. These constraints are not negotiable. You design around them.

Memory: Less Than You Think

A common mid-range microcontroller like the STM32F103 has 20 KB of RAM and 128 KB of flash. TLS 1.3 (Transport Layer Security) with a full handshake requires roughly 16 to 32 KB of RAM for buffers alone. SHA-256 is manageable. AES (Advanced Encryption Standard) with hardware acceleration is practical. RSA with 2048-bit keys is borderline. RSA with 4096-bit keys is often impossible.

This forces real choices. You use elliptic-curve cryptography (ECC) instead of RSA because the key sizes are smaller for equivalent security. You use symmetric encryption for bulk data and asymmetric only for key exchange. You choose ChaCha20-Poly1305 over AES-GCM on processors that lack AES hardware acceleration because it is faster in software.

Processing Power: Clock Speed Is Not the Only Factor

A 72 MHz ARM Cortex-M3 without hardware crypto acceleration will take roughly 2.5 seconds to perform a single RSA-2048 private key operation in software. The same operation on a Cortex-M33 with a hardware crypto engine takes under 10 milliseconds. Choosing a microcontroller with the right hardware features is a security decision, not just a performance one.

Storage: No Room for Verbose Logging

Forensic investigation and security monitoring depend on logs. An embedded device with 512 KB of flash has little room for a logging subsystem after the application takes its share. Circular log buffers, remote log shipping over MQTT (Message Queuing Telemetry Transport) and selective event logging (authentication failures, firmware updates, configuration changes only) are common approaches.

Power: Cryptography Costs Energy

On battery-powered devices, every computation shortens battery life. A handshake with a TLS server can be 100 to 1000 times more expensive than sending a raw UDP packet. DTLS (Datagram Transport Layer Security) session resumption, PSK (Pre-Shared Key) modes and lightweight protocols like OSCORE (Object Security for Constrained RESTful Environments) exist specifically to reduce this overhead.

Cost: Security Features Add Unit Cost

A microcontroller with a hardware secure element costs more than one without. At 10,000 unit production volumes, a $0.50 difference per unit is $5,000 in BOM (Bill of Materials) cost. At a million units, it is $500,000. Product managers push back on security hardware features because the cost is immediate and visible while the breach risk is probabilistic and future. Engineers who cannot quantify security ROI will lose this argument repeatedly.

Design and Operational Challenges

Beyond raw hardware limits, embedded security faces structural challenges that emerge from how these devices are built and deployed.

Legacy Code and Long Development Cycles

Embedded firmware often contains code that was written 10 to 15 years ago, in C, without security in mind. The original developers may have left the company. The code may use unsafe standard library functions (strcpy, sprintf, gets) throughout. Refactoring it is expensive and risky because any change can introduce regressions in a system where automated testing coverage is typically low.

Diverse Hardware Targets

A firmware security fix may need to be validated and re-flashed across dozens of hardware revisions, multiple PCB variants and units running different bootloader versions. This makes patching operationally complex even when a fix exists.

No Standard Update Mechanism

Unlike Android or iOS where OS-level security updates reach hundreds of millions of devices within days, embedded firmware updates have no standard delivery mechanism. Depending on the device, a security patch may require a service technician visit, a manufacturer-issued USB tool or a cloud-based OTA system that the device’s original firmware may not support.

Physical Exposure After Deployment

A device you ship is a device you no longer control physically. Smart meters are installed on building exteriors. Industrial sensors are mounted in remote locations. Consumer devices end up on eBay, in repair shops and in the hands of researchers. All of these represent physical access scenarios where an attacker can use a soldering iron, a logic analyzer or a JTAG adapter to attack the hardware directly.

Lack of Monitoring

Most embedded deployments have no runtime security monitoring. There is no SIEM (Security Information and Event Management) ingesting device logs. There is no EDR (Endpoint Detection and Response) agent watching for anomalous process execution. If a device is compromised, the operator may not find out for months or years, if ever.

Real-World Attack Cases You Should Know

Embedded systems security is sometimes dismissed as a theoretical concern. These three cases demonstrate that it is not.

Mirai Botnet (2016)

The Mirai botnet infected over 600,000 IoT devices including IP cameras, DVRs and home routers by scanning for devices with factory-default Telnet credentials. The attack required no zero-day vulnerability. The root cause was entirely operational: devices shipped with username “admin” and password “admin” or “password”, and users never changed them. Mirai used these devices to launch a DDoS (Distributed Denial of Service) attack against Dyn, a major DNS provider, taking down Twitter, Netflix, Reddit, GitHub and dozens of other major services for hours.

What it demonstrates: You do not need sophisticated exploitation to cause massive impact. Default credentials in production embedded devices is a critical vulnerability that scales to catastrophic levels at internet deployment sizes.

Jeep Cherokee Remote Hack (2015)

Security researchers Charlie Miller and Chris Valasek demonstrated remote control of a Jeep Cherokee’s steering and brakes over a cellular connection while the vehicle was traveling at highway speed. The attack chain exploited a combination of an internet-exposed Uconnect infotainment unit and a lack of isolation between the entertainment CAN bus and the vehicle’s safety-critical CAN bus. No authentication was required to send CAN messages from the infotainment system to the ABS controller.

What it demonstrates: Network segmentation between embedded subsystems is a safety-critical requirement, not a nice-to-have. The absence of authentication on CAN bus is a systemic embedded industry problem that automotive OEMs are only beginning to address with standards like Autosar SecOC (Secure Onboard Communication).

Ukrainian Power Grid Attack (2015)

Attackers used spear-phishing emails to gain access to Ukrainian power distribution company networks, then pivoted to SCADA systems and ICS (Industrial Control System) workstations that controlled embedded RTUs and substation equipment. They opened 30 substations remotely, cutting power to approximately 230,000 customers in the middle of winter. They also overwrote firmware on serial-to-Ethernet converters at substations to prevent remote recovery, forcing manual physical restoration at each site.

What it demonstrates: Embedded system attacks in critical infrastructure can have immediate humanitarian consequences. Firmware overwrite as a persistence and sabotage mechanism is a real technique that has been used in anger. Air-gap assumptions in OT (Operational Technology) networks are no longer valid.

The Four Categories of Attack Impact

In classical information security the CIA triad (Confidentiality, Integrity, Availability) describes the three dimensions of impact. For embedded systems, a fourth dimension is essential: physical consequences. Understanding all four helps you prioritize which threats deserve the most design attention for a given device.

Confidentiality Loss

Private data is exposed. For an IoT sensor this might mean health data, location data or usage patterns. For an industrial device it might mean proprietary process parameters or safety system logic. Confidentiality attacks often target firmware extraction (via JTAG or flash chip reading) to find hardcoded credentials, API keys or proprietary algorithms.

Example: A security researcher extracts firmware from a popular smart lock via an exposed JTAG interface and finds the master unlock code stored in plaintext in flash memory. Every lock of that model can now be opened with that code.

Integrity Violation

Data or commands are modified without authorization. Integrity attacks on embedded systems include: replacing legitimate firmware with a backdoored version, injecting malicious CAN messages to alter sensor readings, modifying configuration parameters to change device behavior, and replaying old command packets to trigger already-executed actions.

The absence of message authentication is the root cause in most integrity attacks. If your firmware processes commands without verifying a signature or HMAC (Hash-based Message Authentication Code), an attacker on the same network can forge any command the device accepts.

Availability Disruption

The system stops functioning. This can be caused by DDoS flooding a device’s network interface, sending malformed packets that trigger a crash, exploiting a memory corruption bug to cause a fault, or physically interfering with power. Availability attacks on safety-critical systems are particularly dangerous: a smoke detector that has been crashed by a network flood does not detect smoke.

Physical Consequences

This is the dimension that makes embedded security uniquely serious. A compromised server loses data. A compromised embedded system can open a valve, overheat a motor, disable a safety interlock, unlock a door, modify a drug dosage or disable a vehicle’s braking system. The overlap between cybersecurity failures and physical safety incidents is one reason regulatory bodies including the FDA, ENISA (European Union Agency for Cybersecurity) and NIST (National Institute of Standards and Technology) are developing mandatory embedded security requirements.

Security vs Performance, Cost and Convenience

Security in embedded systems never exists in isolation. Every control you add has a cost: in code size, in execution time, in power consumption, in BOM cost or in development time. Understanding these trade-offs is what separates embedded security engineers from checkbox compliance exercises.

The Encryption Tax

Consider a sensor that samples temperature every 10 seconds and transmits the reading over MQTT. Without encryption, the transmission takes roughly 50 bytes and 2ms of radio time. With TLS 1.3 you add a handshake (roughly 3 to 5 round trips at connection time), a RAM overhead of 16 to 32 KB and a 16-byte authentication tag on every packet. On a battery-powered device sampling every 10 seconds, this can reduce battery life by 15 to 40% depending on processor speed and whether TLS sessions are resumed or renegotiated.

This does not mean you skip TLS. It means you make the cost explicit, design for session resumption, choose DTLS or OSCORE for UDP-based protocols and justify the power budget in your design review.

The Patching Dilemma

Adding an OTA firmware update system costs 8 to 16 KB of code space for a basic implementation, requires a dual-bank flash layout (so you always have a valid fallback), needs a signature verification routine (another 2 to 4 KB) and requires a cloud infrastructure to host and deliver updates. For a $2 microcontroller in a price-competitive product, some of these may be non-starters. But a device that cannot be patched is a device that will remain vulnerable to any bug you ship forever.

The Default Credentials Problem

Shipping every device with a unique, printed credential is more expensive than shipping a universal default. It requires a provisioning step at the factory, a label printing process and a customer onboarding flow where the user sets up credentials. The Mirai botnet existed entirely because manufacturers repeatedly chose the cheaper option. Regulators in the UK (PSTI Act 2024), the EU (Cyber Resilience Act) and the US (IoT Cybersecurity Improvement Act) are now making unique-by-default credentials a legal requirement rather than a best practice.

Getting Started with Embedded Systems Security

If you are new to this domain, the following sequence provides a structured entry point without overwhelming breadth.

Start with Your Threat Model

Before writing a line of security code, ask: who would attack this device, what do they want and how would they get it? A hobbyist weather station connected to a home WiFi network has a completely different threat model than a cardiac monitor connected to a hospital network. Your security investments should match your threats. Applying hospital-grade security to a weather station is wasteful. Applying weather-station-grade security to a cardiac monitor is dangerous.

A minimal threat model for any embedded device should answer:

1. What data does this device collect, store or transmit?
2. What physical interfaces does it expose (JTAG, UART, USB, BLE)?
3. What happens if an attacker takes control of this device?
4. Who is motivated to attack this device and what resources do they have?
5. What is the device’s expected operational lifetime and patch delivery mechanism?

Lock Down the Debug Interface Before Shipping

The single most common embedded security failure is shipping devices with JTAG or UART debug interfaces enabled. On STM32 microcontrollers, flash read protection (RDP) is set via option bytes. On ESP32, JTAG disable is set via eFuse. Both operations are irreversible by design. On most Cortex-M devices, the following option byte configuration should be validated before production sign-off:

# Example: STM32 - read flash protection level using st-flash
# Level 0 = fully open (debug access allowed) - NEVER ship in this state
# Level 1 = read protected (firmware cannot be read back via debug)
# Level 2 = full lock (irreversible, disables JTAG permanently)
st-flash --connect-under-reset read 0x1FFFF800 4
# The returned value indicates current RDP level:
# 0xAA = Level 0 (open)
# 0xBB = Level 1 (read protected)
# 0xCC = Level 2 (fully locked)

Never Store Credentials in Firmware

Hardcoded WiFi passwords, API keys, cloud endpoint tokens and device certificates embedded in firmware binaries are routinely extracted by security researchers (and attackers) using tools like binwalk and strings. Use a provisioning flow that loads credentials into a protected flash region or secure element at factory time, separate from the main firmware image. At minimum, store them in a region with hardware read protection enabled.

# binwalk is the standard tool for firmware analysis
# This is what an attacker or researcher runs against your firmware binary
# Install: pip install binwalk
binwalk -e firmware.bin

# The -e flag extracts identified file systems and archives
# strings can then be run on extracted files to find plaintext credentials:
strings extracted_filesystem/etc/config | grep -E "(password|key|token|secret)"

Use Authenticated Encryption for All Communications

Plain encryption without authentication (such as AES-CBC (Cipher Block Chaining) without a MAC (Message Authentication Code)) protects against passive eavesdropping but not against active manipulation. An attacker can modify encrypted bytes in predictable ways without decrypting the message, a class of attack called a bit-flipping attack. Always use an AEAD (Authenticated Encryption with Associated Data) cipher: AES-GCM (Galois/Counter Mode), AES-CCM or ChaCha20-Poly1305. All three provide both confidentiality and integrity in a single pass.

Plan for the Full Device Lifetime

If you are shipping a device today that will be in service in 2035, you need to plan for cryptographic algorithms that will still be considered secure in 2035. SHA-256 and AES-128 are expected to remain secure. RSA-2048 is already considered marginal by some standards bodies for long-lived key pairs. NIST (National Institute of Standards and Technology) finalized the first post-quantum cryptography standards in 2024 (ML-KEM, ML-DSA, SLH-DSA). For devices with 10+ year lifetimes, you should be evaluating whether your hardware can support hybrid classical/post-quantum key exchange now, even if you do not implement it immediately.

Conclusion

Embedded systems security is not a feature you add at the end of a project. It is a design constraint that shapes every decision from component selection and memory layout to communication protocol choice and update delivery architecture. The core challenges are not going away: resource constraints will always create trade-offs, physical access will always be a threat vector and the gap between device lifetimes and software security lifetimes will always require long-horizon planning. What changes is how well-equipped you are to navigate those challenges. The starting points are concrete: model your threats before writing code, disable debug interfaces before shipping, never embed credentials in firmware, use authenticated encryption for all communications and build OTA update capability into every new design from day one. The rest of this course builds on exactly these foundations.