Devices live for years in places you do not control. What embedded security means, how it differs from IT security, which EU rules apply as of October 2026, and the controls to design in from the start.
In short
Embedded security is the protection of devices that run firmware on dedicated hardware, such as sensors, controllers and consumer IoT products, across their whole life. It rests on a hardware root of trust, secure boot, signed updates, no default passwords, encrypted communication and a plan for vulnerabilities. In the EU, the Radio Equipment Directive and the Cyber Resilience Act now make much of this mandatory.
A server can be patched tonight. A sensor in a ship's engine room or a heat pump in a basement may run the same firmware for ten years. This explainer is written by Devies, a Gothenburg-based product and engineering consultancy, for CTOs, product managers and hardware and firmware leads at companies that make connected products. It covers what embedded security is, what makes it different, the main threats and controls, and the regulations that apply.
What is embedded security?
Embedded security is the discipline of protecting embedded systems, their firmware, data and communication, against attack throughout the life of the device, from manufacturing to decommissioning.
Some definitions set the scene:
- Embedded systems are computers built into a larger product to perform dedicated functions, usually with constrained memory, processing power and energy, and often without a screen or a user who logs in.
- IoT security (in Swedish, IoT-säkerhet) is the protection of internet-connected devices together with the apps, cloud services and networks they depend on. Every IoT device is an embedded system, but not every embedded system is connected.
- A hardware root of trust is a small, immutable component, such as boot ROM or a secure element, that the rest of the security chain relies on.
- Secure boot is a process where each stage of start-up verifies the cryptographic signature of the next before running it.
It helps to separate embedded security from things it is often confused with:
Concept
What it covers
How it differs from embedded security
IT security
What it covers
Office systems, servers, user accounts
How it differs from embedded security
Assumes patching, monitoring and admins; devices often have none of these
OT security
What it covers
Industrial control systems and networks in a plant
How it differs from embedded security
Focuses on the operator's site; embedded security is the manufacturer's product
Functional safety
What it covers
Preventing harm from random faults
How it differs from embedded security
Deals with accidents, not deliberate attackers, though the two interact
Cloud security
What it covers
The backend services a device talks to
How it differs from embedded security
Part of the IoT whole, but cannot fix a device that trusts any server
What makes connected devices hard to secure?
Connected devices are hard to secure because they are physically accessible, resource-constrained, long-lived and produced in large identical batches, so one flaw is repeated across every unit.
Specific challenges:
- Physical access. An attacker can buy the device, open it, read the flash memory and probe debug ports such as JTAG or UART.
- Constrained resources. Small microcontrollers limit which cryptography and protocols are practical.
- Long life and slow updates. Devices often stay in the field far longer than the software components inside them are maintained.
- Shared secrets. A key or password identical across all units turns one teardown into access to every device.
- Complex supply chains. Chip vendors' SDKs, real-time operating systems, radio stacks and open-source libraries all ship inside your firmware.
- Safety coupling. In vehicles, marine systems or fire safety, a security flaw can become a safety problem.
Which controls matter most?
The controls that matter most build a chain of trust from the hardware upwards and keep the device updatable for its whole life.
- Unique identity per device. Provision unique keys or certificates at manufacturing, ideally in a secure element or protected storage.
- Secure boot and signed firmware. The device runs only firmware signed by you, with protection against rollback to vulnerable versions.
- Secure over-the-air updates. Signed, encrypted where needed, resilient to power loss, with a recovery path.
- No universal default passwords. Unique credentials per device or a forced change at set-up.
- Encrypted and authenticated communication. Current TLS or equivalent, with certificate validation and mutual authentication for device-to-cloud traffic.
- Locked debug interfaces. Disable or authenticate JTAG and serial consoles in production units.
- Minimal attack surface. Close unused ports and services, and remove test code before release.
- Component inventory. Keep an SBOM for every firmware build, including vendor SDKs.
- Vulnerability handling. A public contact for reports, a disclosure policy and a way to ship fixes.
Where to start depends on your product, so begin with a threat model of the device, its app and its cloud; see how to run a threat modelling workshop. NIST IR 8259A offers a useful core baseline of device capabilities: identification, configuration, data protection, logical access, software update and cybersecurity state awareness.
Which rules apply to connected products in the EU?
As of October 2026, three overlapping instruments shape embedded security for products sold in the EU, and the Cyber Resilience Act will become the main one from December 2027.
Instrument
Scope
Status as of October 2026
Radio Equipment Directive, Delegated Regulation (EU) 2022/30
Scope
Internet-connected radio equipment, including many consumer IoT devices
Status as of October 2026
Cybersecurity requirements apply since 1 August 2025; EN 18031 harmonised standards cited in January 2025
Cyber Resilience Act, Regulation (EU) 2024/2847
Scope
Almost all products with digital elements
Status as of October 2026
Reporting duties since 11 September 2026; essential requirements and CE marking from 11 December 2027
ETSI EN 303 645
Scope
Consumer IoT devices
Status as of October 2026
Voluntary European standard, widely used as a baseline
The RED delegated act covers network protection, personal data and protection from fraud. ETSI EN 303 645 sets 13 groups of provisions, where the first three are no universal default passwords, a vulnerability disclosure policy and keeping software updated. The UK has made similar baseline rules mandatory through its product security regime, relevant if you also sell there.
The Cyber Resilience Act adds secure-by-default design, a defined support period, vulnerability handling and an SBOM. For the timeline and steps, read the Cyber Resilience Act for product companies. Industrial and maritime products often add sector frameworks too: IEC 62443 for industrial automation and IACS UR E27 for onboard systems on ships.
How do you build security into embedded development?
Build security into the existing development process rather than adding a separate security track, because firmware teams already have reviews, test rigs and release gates you can extend.
Practical moves:
- Add security requirements to hardware selection: secure boot support, protected key storage and crypto acceleration are hard to retrofit.
- Run static analysis and dependency checks on firmware in CI, and keep a hardware-in-the-loop test for update and rollback paths.
- Track which firmware version runs on which units, so you can assess impact when a vulnerability appears.
- Decide the support period early and budget for updates across it.
Devies saw the value of this approach in its cybersecurity work with Consilium Safety Group, which makes fire, flame and gas safety systems for marine, energy, rail and building sectors. Devies helped interpret and implement IEC 62443, UR E27 and NIS2, and Consilium highlights that existing processes were adapted rather than replaced. For the wider engineering picture, see embedded systems development explained.
Keep reading
From our work
Client Case: ZenseactHow Devies helped Zenseact make cybersecurity a natural part of developing safety-critical software for driver assistance and autonomous driving.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is the difference between embedded security and IoT security?
Embedded security covers any device with dedicated firmware and hardware, connected or not, and focuses on the device itself: boot, keys, debug ports and firmware integrity. IoT security covers connected devices together with their apps, cloud services and networks. In practice they overlap heavily, because most new embedded products are connected and an insecure device undermines a secure cloud, and the other way round.
Do the RED cybersecurity requirements apply to our product?
They apply to radio equipment that can communicate over the internet, directly or via other equipment, and to certain categories such as toys, childcare equipment and wearables that process personal data, as set out in Delegated Regulation (EU) 2022/30. As of October 2026 the requirements have applied since 1 August 2025. Check the exact scope and exceptions with your notified body or conformity assessment adviser.
What is secure boot and do we need it?
Secure boot is a start-up process in which each stage verifies the cryptographic signature of the next stage before running it, anchored in a hardware root of trust. It ensures that only firmware you signed runs on the device. For any connected product that receives updates, it is a basic control, because without it an attacker who can modify the firmware can take full control of the device.
How long must we support a connected product with security updates?
Under the Cyber Resilience Act, the support period must reflect how long the product is expected to be in use, and should normally be at least five years unless the expected use is shorter. The requirement applies from 11 December 2027. Many industrial and marine products are in use far longer, so plan hardware, components and update infrastructure for the full expected life.
Sources
- Commission Delegated Regulation (EU) 2022/30 (Radio Equipment Directive, cybersecurity), EUR-Lex
- ETSI, Consumer IoT security (EN 303 645)
- NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline
- UK Government, The UK Product Security and Telecommunications Infrastructure (Product Security) regime
- European Commission, CRA reporting obligations
- Devies, Consilium and Devies cybersecurity
