What is embedded software? Definition, examples, trends, and how it gets built

Most software people encounter runs on a computer they can see: a laptop, a phone, a server. Embedded software runs on the computers people cannot see, inside the thermostat, the insulin pump, the car door, the factory robot, the router, and the smartwatch. There are tens of billions of these devices in service, and almost every physical product with a power switch now contains one.

This article explains what embedded software is, how it differs from the application software most teams are used to, where it shows up, how the field is changing in 2026, and how a project actually moves from a hardware idea to a shipped device. It is written for product and engineering leaders deciding whether and how to build a connected product, not for firmware engineers who already live in this world.

It also names the failure patterns, because embedded projects fail differently from app projects. The same software engineering discipline applies, but the cost of a late-discovered defect is measured in recalled units rather than a hotfix, and that one difference changes how the work should be planned.

What is embedded software, precisely?

Embedded software is software written to run inside a device whose primary purpose is something other than general computing. The device has a specific job, controlling a motor, reading a sensor, managing a battery, displaying a reading, and the software exists to do that job within the physical limits of the hardware it lives on. The term covers everything from a few kilobytes of bare-metal code on an eight-bit microcontroller to a full Linux distribution on a multi-core automotive processor, and the common thread is not size but constraint.

Four constraints define the category. Resources are fixed: the memory, processing power, and energy available are decided when the hardware is designed and cannot be scaled up later. Timing often matters absolutely: an airbag controller that computes the correct answer a few milliseconds late has failed. Updates are hard: some devices can never be updated after shipping, others only through a physical connection, and even connected devices face bricking risk if an update goes wrong. Consequences are physical: a defect can burn out a component, damage what the device controls, or injure a person.

Firmware is a closely related term and the two are often used interchangeably. Strictly, firmware is the lowest layer of embedded software, stored in non-volatile memory and responsible for initializing hardware and providing the most basic services. On a small microcontroller the firmware is the entire program. On a larger system the firmware boots the device and hands control to an operating system and applications, and the whole stack is embedded software.

Embedded software against application software

Dimension	Application software	Embedded software
Hardware	General purpose, abundant, scalable	Specific, constrained, fixed at design time
Timing	Fast is nice	Deadlines are often correctness requirements
Memory	Gigabytes, garbage collected	Kilobytes to megabytes, often manually managed
Power	Wall or large battery	Coin cell to years on one charge in some products
Updates	Continuous, minutes to deploy	Difficult, risky, sometimes impossible
Failure	An error message, a retry	Physical damage, safety incident, recall
Testing	Automated on any machine	Requires the target hardware or an accurate simulation of it

The differences are constraints, not capabilities. An embedded engineer can do anything an application engineer can, within a budget the hardware fixed months earlier.

Where does embedded software run? Examples across industries

Automotive is the largest single market and the one with the most demanding mix of requirements. A modern car contains dozens to over a hundred electronic control units running embedded software: engine and battery management, braking and stability, airbags, infotainment, driver assistance, body electronics. The industry has its own functional safety standard, ISO 26262, and is in the middle of a shift from many small controllers to a few powerful zonal computers, which is changing what embedded software in a car looks like.

Medical devices are the most tightly regulated corner. Infusion pumps, pacemakers, ventilators, glucose monitors, and diagnostic instruments all run embedded software whose defects can directly harm patients, and regulators require documented development processes, risk analysis, and verification evidence under IEC 62304 and national device rules. Industrial automation, from programmable logic controllers to robot arms to the sensors on a production line, sits nearby with its own standards and a long product life that can stretch to decades.

Consumer electronics and the Internet of Things are the highest-volume categories: wearables, smart home devices, appliances, cameras, routers, and the trackers on shipping containers. Constraints here are cost and power rather than safety, and the engineering challenge is doing something useful on a chip that costs a dollar and a battery that has to last a year. Fleet telematics is a concrete example this site covers in depth: the connected sensors in fleet management are embedded systems whose firmware decides what to sample, what to store, and when to transmit, and whose design determines the data quality of everything downstream.

Terms you will meet in an embedded project

MCU (microcontroller)

A single chip with processor, memory, and peripherals. Runs bare-metal code or a real-time operating system. Kilobytes to a few megabytes of memory.

MPU or SoC (application processor)

A more powerful processor, usually with external memory, capable of running Linux or Android. Used where a rich interface or heavy computation is needed.

RTOS (real-time operating system)

A small operating system that guarantees tasks run within known time bounds. FreeRTOS, Zephyr, and ThreadX are common examples.

Bare metal

Software running directly on the hardware with no operating system. Maximum control, minimum abstraction.

BSP (board support package)

The drivers and configuration that make an operating system run on one specific board. Often the hidden schedule risk.

OTA (over-the-air update)

Updating device software remotely. Requires a secure bootloader, a rollback path, and careful power-failure handling.

HIL (hardware-in-the-loop)

Testing embedded software against real hardware or simulated signals driven by a test rig, so the timing and electrical behavior are real.

The embedded software stack: bare metal, RTOS, and embedded Linux

Embedded software has historically been described as three tiers. Bare-metal code runs directly on a microcontroller with no operating system, giving total control over timing and memory at the cost of writing every service yourself. A real-time operating system adds task scheduling, timers, and communication primitives with guaranteed timing, and is the default for anything that has to do several things at once with deadlines. Embedded Linux brings a full operating system with networking, file systems, and a vast library ecosystem, at the cost of larger hardware, longer boot times, and no hard real-time guarantees without additional work.

The 2026 reality is that these tiers coexist on a single product. A smart appliance might run Linux on an application processor for its touchscreen and cloud connection while a separate microcontroller running an RTOS handles the motor and safety interlocks. Automotive zonal computers pair a Linux or Android instance for infotainment with a real-time core for vehicle functions, isolated by a hypervisor. Even single chips now ship with heterogeneous cores intended for exactly this split. The architecture question is no longer which tier, but how the tiers talk to each other and where the safety boundary sits.

Choosing the stack follows the requirements. Hard timing, low power, and low cost push toward a microcontroller with an RTOS or bare metal. A rich user interface, complex networking, or heavy computation pull toward Linux on an application processor. Safety requirements often mandate isolating the critical functions on their own controller regardless of what the rest of the product runs, because certifying a small RTOS image is tractable and certifying a Linux distribution is not.

Choosing a tier by requirement

	Bare metal	RTOS	Embedded Linux
Hard real-time deadlines	Yes	Yes	Partial
Sub-milliwatt sleep power	Yes	Yes	No
Rich graphical interface	No	Partial	Yes
Full TCP/IP, TLS, cloud SDKs	No	Partial	Yes
Safety certification tractable	Yes	Yes	No
Unit cost under a few dollars	Yes	Yes	No
Large third-party library ecosystem	No	Partial	Yes

Languages: why C still dominates and why Rust is displacing it

C has been the language of embedded software for four decades, and it still runs most of the devices in service. It compiles to small, predictable machine code, maps directly onto hardware registers, has a toolchain for every processor ever made, and is what the existing drivers, RTOS kernels, and vendor SDKs are written in. C++ is common where the product is large enough to want abstraction, particularly in automotive and industrial systems. Neither is going away: the installed base and the vendor ecosystem guarantee that C and C++ skills remain central to embedded work for years.

The problem with C is that the bugs it permits, buffer overflows, use-after-free, null dereferences, data races, are exactly the bugs that dominate embedded security advisories and a large share of field failures. Static analysis, coding standards like MISRA, and disciplined review reduce them but do not eliminate them, and the cost of a memory-safety defect in a device that cannot be patched is severe. Rust addresses this class of bug at the language level: its compiler rejects programs that could exhibit them, without a garbage collector and with performance and footprint comparable to C.

Rust in embedded is no longer experimental. The embedded working group has stable support for the mainstream ARM Cortex-M and RISC-V microcontrollers, the Linux kernel accepts Rust drivers, major silicon vendors ship Rust HALs, and automotive and aerospace suppliers have production Rust code in flight. The realistic 2026 posture for a new product is C for the vendor-supplied layers you do not want to rewrite, and Rust for new code that handles untrusted input, parses protocols, or manages memory in ways where a mistake would be expensive. The transition cost is real, because Rust has a learning curve and the embedded ecosystem is smaller, but the cost of the alternative shows up in recall notices.

The trends reshaping embedded software in 2026

Over-the-air updates have gone from a differentiator to a baseline expectation, and they change the economics of the whole category. A device that can be updated has a security story, can receive features after purchase, can be fixed without a recall, and can support a subscription model; a device that cannot is a liability from the moment a vulnerability is found. Doing OTA well is a serious engineering problem: a secure bootloader that verifies signatures, an A/B partition scheme or equivalent so a failed update rolls back, resilience to power loss mid-write, and a fleet management backend that stages rollouts and watches for failures.

Machine learning inference is moving onto the device. Keyword spotting, gesture recognition, vibration-based anomaly detection, and simple image classification now run on microcontrollers using frameworks designed for kilobytes of memory, and application processors handle considerably more. The motivation is latency, privacy, bandwidth, and the ability to work offline. The limits are equally real: model size, power, and the difficulty of updating a model in the field, which loops back to OTA. Edge AI is best understood as a new kind of sensor processing rather than as cloud AI relocated.

Security regulation has arrived. The EU Cyber Resilience Act, national IoT security laws, and sector rules in automotive and medical now impose concrete obligations: no default passwords, a vulnerability disclosure process, security updates for a defined support period, and secure-by-default configuration. For many product companies this is the first time embedded security has been a legal requirement rather than a best practice, and it makes the update path a compliance question. Alongside these, the shift to Rust, the consolidation onto Zephyr and other open RTOS platforms, the rise of RISC-V as a credible alternative to ARM, and the automotive move to zonal architectures and software-defined vehicles round out the picture of a field changing faster than it has in decades.

Three trends, three practical consequences

OTA Updates are the security and revenue story Design the bootloader, rollback, and fleet backend before the first unit ships. Retrofitting OTA is close to impossible.

Edge AI Inference on the device, narrowly scoped Keyword spotting, anomaly detection, simple vision on microcontrollers. Larger models still need an application processor or the cloud.

Regulation Security is now a legal requirement EU Cyber Resilience Act and national IoT laws: no default passwords, disclosure process, defined support period for updates.

How embedded software gets built: hardware and software as one program

The defining feature of an embedded project is that the hardware is being designed at the same time as the software, and each constrains the other. Requirements have to cover both: what the device does, how fast, how long on a battery, in what environment, under what safety and regulatory rules. Architecture then partitions the work: which functions go on which processor, what operating system each runs, how they communicate, where the safety boundary sits, and how updates will work. Getting this wrong is expensive because changing a board after it is fabricated costs weeks and money, so the early architecture phase carries more weight than in application software.

Development proceeds in parallel tracks that must synchronize. Hardware engineers design and fabricate prototype boards in a series of revisions. Firmware engineers begin on development kits and simulators, then move onto the first boards as they arrive, and the board support package, the layer that makes the software run on this specific hardware, is often where the schedule slips, because it depends on both tracks and is nobody's favorite job. Application logic, connectivity, and any cloud or mobile companion software proceed alongside, and the mobile or web companion app frequently turns out to be a larger codebase than the firmware itself.

Testing is where embedded differs most from application software. Unit tests run on the host machine for portable logic. Integration tests run on the target hardware, because timing, peripherals, and electrical behavior cannot be faked. Hardware-in-the-loop rigs drive the device with simulated sensor signals and check its outputs, and are essential for anything safety-related. Environmental testing covers temperature, vibration, and power variation. Certification testing, for radio emissions, electrical safety, and any sector rules, runs at the end and cannot be rushed. A project plan that puts testing on real silicon in the final month has scheduled its own failure.

An embedded product program, phase by phase

1. Requirements and feasibility4 to 8 weeks

   Function, timing, power, environment, regulatory scope, unit cost target. Processor and connectivity shortlist.

   Done when Signed requirements and a costed architecture with the safety boundary drawn.

2. Architecture and first board8 to 14 weeks

   Partition across processors, choose OS per core, design the update path, fabricate revision A boards. Firmware starts on dev kits.

   Done when Revision A boards power on and run a bring-up image.

3. Firmware and integration12 to 24 weeks

   BSP, drivers, application logic, connectivity, companion software, OTA. Revision B and C boards fix what A taught.

   Done when Feature-complete build on near-final hardware passing integration tests.

4. Verification and certification8 to 16 weeks

   HIL, environmental, security review, radio and safety certification, pilot units in the field.

   Done when Certificates in hand, field pilot stable, production build frozen.

5. Production and sustainmentProduct lifetime

   Manufacturing test, fleet monitoring, security updates for the committed support period.

   Done when End of support communicated and honored.

Durations are typical for a connected consumer or industrial device of moderate complexity. Safety-certified products run longer at every phase.

Where embedded projects fail, and how experienced teams avoid it

The first failure pattern is treating hardware and software as separate projects with a handoff between them. Firmware written against a specification rather than a board meets reality late, and the reality includes a pin that was mislabeled, a peripheral that behaves differently from its datasheet, and a power rail that sags under radio transmission. Teams that avoid this put firmware engineers in the hardware reviews, get bring-up code running on the first board revision within days of its arrival, and treat the board support package as a first-class deliverable with its own owner.

The second is testing that touches real hardware only at the end. Host-side unit tests are valuable but cannot catch timing, interrupt, and peripheral bugs, which are the bugs embedded systems actually have. Continuous integration that flashes every build onto a rack of real devices and runs the integration suite there is the norm on healthy projects, and hardware-in-the-loop rigs for safety functions are not optional. The third is deferring security and updates: a product designed without a secure bootloader, a signed update path, and a rollback mechanism cannot acquire them later without a hardware change, and the regulatory environment now makes that omission a compliance failure as well as a technical one.

The fourth is underestimating sustainment. Embedded products live for years, sometimes decades, and the software has to be maintained for that period: security updates, component end-of-life substitutions that require driver changes, toolchain updates, and certification renewals. The team that built the product will move on; the documentation, reproducible build environment, and test rigs they leave behind determine whether the product can be maintained at all. Experienced teams archive the exact toolchain in a container, keep a hardware library of every board revision, and write the sustainment plan into the original contract.

What separates shipped embedded products from canceled ones

Do this

• Firmware on board revision A within daysBring-up code is the first integration test. Every week of delay hides hardware problems.
• CI that flashes real devicesA rack of target boards runs the integration suite on every build. Timing bugs surface daily, not at certification.
• Secure boot and OTA designed firstSigned images, A/B rollback, power-loss safety. These are hardware decisions and cannot be retrofitted.
• Toolchain archived in a containerThe product will outlive the laptops it was built on. A reproducible build is the sustainment plan.

Not this

• Firmware written to the spec, not the boardMeets the mislabeled pin and the sagging power rail in the final month.
• Host-only testing until the endCatches logic bugs, misses every interrupt, timing, and peripheral bug the device actually has.
• Security as a later phaseA device without a secure bootloader cannot get one by software update. Now a legal problem too.
• No sustainment budgetA ten-year product with a one-year engineering plan is a recall waiting for its vulnerability.

Buying embedded engineering: what to ask a partner

Embedded engineering is a specialist discipline and the skill set is scarcer than application development, so many product companies engage a partner for some or all of the work. The questions that separate capable partners from generalists are concrete. Which processor families and operating systems have they shipped on, in production, recently. Can they show a board support package they wrote, and how they tested it. What does their continuous integration look like, and does it flash real hardware. How have they implemented secure boot and OTA, and what happened when an update failed in the field. What safety or regulatory standards have they worked under, with evidence.

The division of labor matters as much as the partner. Hardware design, firmware, cloud backend, and companion apps are four disciplines, and a partner strong in one is not automatically strong in the others. A common and sensible arrangement is a hardware specialist for the electronics, an embedded team for firmware and BSP, and a software team for the cloud and the mobile app, with one party owning the integration and the system-level test plan. Ambiguity about who owns integration is the most reliable predictor of schedule slip.

Contracts for embedded work should address intellectual property in firmware and hardware designs explicitly, reproducibility of the build environment as a deliverable, the sustainment period and who provides it, and the certification responsibilities. Fixed-price bids on embedded projects are notoriously unreliable before the first board revision has been tested, because the largest unknowns are in the hardware and software interaction that no one has seen yet. A phased engagement that fixes price per phase after the previous phase has retired its risks is the structure experienced buyers use.

• Ask for shipped products: processor families, operating systems, and standards, with production evidence, not slides.
• Ask about the BSP and CI: a board support package they wrote and a pipeline that flashes real devices on every build.
• Ask about the failed update: every experienced team has one. How it was contained tells you more than any success story.
• Name the integration owner: one party owns the system-level test plan across hardware, firmware, cloud, and app.
• Phase the price: fix cost per phase after the previous one has retired its risks; fixed-price before board revision A is a guess.

Frequently asked questions

When the connected product needs a software partner who owns the integration, AgileTech is an AI native software development company in Vietnam delivering firmware, cloud, and companion apps as one program.