What embedded software is, how it differs from app development, and which decisions product companies should make before the hardware is frozen.
In short
Embedded systems development is the design of software that runs on dedicated hardware inside a product, such as a sensor, a machine controller or a vehicle unit. It differs from app development because memory, power, timing and safety limits shape every decision, updates are harder to ship, and the software must last as long as the product.
Embedded systems (inbyggda system) sit inside almost every physical product that is sold today: heat pumps, forklifts, medical devices, boats and door locks. This explainer is written by Devies, a Gothenburg-based product and engineering consultancy, for product owners, CTOs and engineering managers at companies that make physical products and need to understand what the software inside them really involves. It covers the vocabulary, the differences from web and app work, the early decisions that are expensive to change, and the cybersecurity rules that now apply to connected devices.
What are embedded systems?
An embedded system is a computer built into a product to perform one dedicated function, with its hardware and software designed together for that job. The user rarely sees it as a computer: they see a thermostat, a pump or a dashboard in a vehicle.
A few definitions make the rest of the discussion precise:
- Firmware is the software stored on the device that controls the hardware directly. It starts when the power comes on and usually runs until it goes off.
- A microcontroller (MCU) is a single chip that combines a processor, memory and peripherals such as timers and radio interfaces. Many run with tens or hundreds of kilobytes of memory, not gigabytes.
- A real-time operating system (RTOS) is an operating system that schedules tasks so that they respond within defined time limits. The open-source Zephyr project describes its kernel as designed for resource-constrained and embedded systems, from simple sensors to smartwatches.
- Embedded Linux is a trimmed Linux distribution running on a more capable application processor, common in gateways, displays and industrial controllers.
Embedded systems are often confused with neighbouring terms. The table separates them.
Term
What it is
Where it runs
Typical constraint
Embedded system
What it is
Dedicated computer inside a product
Where it runs
MCU or application processor on the product's own board
Typical constraint
Memory, power, timing, hardware cost
Firmware
What it is
The software layer on that device
Where it runs
Flash memory of the device
Typical constraint
Must update safely without bricking the device
IoT product
What it is
An embedded system that is connected to a network or cloud
Where it runs
Device plus cloud service plus often an app
Typical constraint
Security, connectivity, fleet management
App or cloud software
What it is
General-purpose software on phones, browsers or servers
Where it runs
Commodity hardware
Typical constraint
User experience, scale, release speed
The practical consequence is that an IoT product is never only embedded work. It is firmware, a cloud backend and usually a companion app, and each part has to agree with the others.
How does embedded development differ from app development?
Embedded development differs from app development because the hardware is fixed, resources are scarce and a software fault can stop a machine or harm a person rather than just break a screen. Five differences matter most to a product company.
- Constraints. Code must fit the chip that was chosen for cost and battery life. Adding a feature can mean removing another or changing the hardware.
- Timing. A motor controller that answers late is as wrong as one that answers incorrectly. Real-time behaviour has to be designed and tested, not assumed.
- Hardware dependency. Firmware and electronics are developed in parallel. Early boards change, drivers must be written for new components, and a bug may sit in the schematic rather than the code.
- Testing. Much of the logic can be unit tested on a laptop, but timing, power and radio behaviour need hardware-in-the-loop rigs, where real or simulated hardware is driven by automated tests. Our guide to a test automation strategy covers how to decide which layer each test belongs in.
- Lifetime. A web app may be rewritten after five years. A machine controller is often supported for a decade or more, so the toolchain, the components and the people who understand them must be available for that long.
Safety-critical domains add formal requirements on top. Functional safety standards such as IEC 61508 for industrial systems and ISO 26262 for road vehicles demand documented requirements, traceability and specific verification methods, which affects both cost and schedule.
Which decisions should product companies make early?
The decisions that are hardest to reverse in embedded systems are the ones tied to hardware, because changing them after production starts means new boards, new certification and field updates. Make these choices deliberately, with both hardware and software people in the room:
- Processor class. A microcontroller is cheap and frugal; an application processor running Linux gives more room for features and connectivity but costs more and draws more power.
- Operating approach. Bare metal (no operating system), an RTOS or embedded Linux. The choice decides which libraries, tools and skills you can use.
- Connectivity. Bluetooth Low Energy, Wi-Fi, cellular, CAN or wired fieldbus. Each brings its own certification, power budget and security work.
- Update strategy. Plan secure boot, signed over-the-air updates and a way to roll back a failed update before the first unit ships. A product that cannot be updated cannot be patched.
- Interfaces to cloud and app. Write down message formats, versioning and who owns them. Most integration bugs in connected products appear at these boundaries.
- Component and software inventory. Track every chip, library and licence from day one, so you can answer when a component reaches end of life or a vulnerability is published.
- Test rig and pipeline. Budget for automated builds and a hardware-in-the-loop rig early. Retrofitting them after launch is far more expensive.
These choices belong inside your wider product development process, not in a separate hardware track that hands over a finished board.
What do the EU cybersecurity rules mean for embedded products?
Most connected embedded products sold in the EU now fall under cybersecurity rules: the radio equipment requirements already apply, and the Cyber Resilience Act is being phased in. As of October 2026, the timeline is:
- Radio Equipment Directive.Delegated Regulation (EU) 2022/30 has applied since 1 August 2025 to radio equipment that can communicate over the internet, with requirements on network protection, personal data and fraud.
- Cyber Resilience Act (CRA). According to the European Commission, the CRA entered into force on 10 December 2024. Reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, and the main obligations apply from 11 December 2027.
For embedded teams this turns good practice into obligation: secure defaults, a working update mechanism, vulnerability handling throughout the support period and a software bill of materials. Our explainer on embedded and IoT security goes deeper into the technical measures.
Devies saw how much depends on building security into everyday development at Zenseact, which develops safety-critical software for driver assistance and autonomous driving. The work there included threat modelling, turning cybersecurity requirements into development tasks and a vulnerability and dependency tracking solution (SBOM) integrated into the CI/CD pipeline, without adding parallel processes beside development.
How should you organise an embedded product team?
An embedded product needs firmware, electronics, cloud, app and test skills working as one team, because most failures appear between those disciplines rather than inside them. Splitting the work across separate suppliers with no one owning the interfaces is the most common cause of late integration surprises.
A workable setup has one technical owner for the whole product, shared interface definitions under version control, and a joint demo every sprint that runs on real hardware. Firmware engineers write code close to the hardware; backend developers build the device management and data services; app developers build the companion app; and testers own the rigs that tie it together. Security is a shared responsibility with a named lead, not a review at the end.
Ask any partner how they test against real hardware, how they ship updates, and how they will hand over knowledge for a product that must be supported for ten years. The answers say more than a list of programming languages.
Devies
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 systems and IoT?
An embedded system is a dedicated computer inside a product that performs one function, such as controlling a motor. An IoT product is an embedded system that is also connected to a network, usually with a cloud service and an app. Every IoT device contains an embedded system, but many embedded systems, such as an offline appliance controller, are not connected at all.
Which programming languages are used for embedded software?
C remains the most common language for firmware on microcontrollers, with C++ widely used on larger devices. Rust is increasingly chosen for new projects because it prevents many memory errors at compile time. Embedded Linux devices also run higher-level languages such as Python for tooling and services. The right choice depends on the chip, the toolchain support and the skills you can retain over the product's lifetime.
Does the Cyber Resilience Act apply to our embedded product?
The CRA covers hardware and software products with digital elements placed on the EU market, which includes most connected embedded products. As of October 2026, reporting obligations apply from 11 September 2026 and the main requirements from 11 December 2027. Some sectors, such as medical devices and vehicles, are covered by their own legislation instead, so check the scope for your product category.
How long does embedded development take compared with app development?
Embedded projects usually take longer because firmware and hardware are developed in parallel, prototypes go through several board revisions, and radio and safety certification add fixed lead times. A simple app can reach users in weeks, while a new connected product often needs many months before production. Reusing a proven hardware platform and module shortens the timeline considerably.
