Embedded Software Development Services: Firmware, RTOS and Embedded Linux, Connectivity and OTA Updates

Updated September 2026 · Written and maintained by the Progression Agency strategy team

Embedded software development services design, write and verify the software that runs inside a physical product: firmware on microcontrollers, embedded Linux on application processors, the drivers between code and hardware, the wireless stacks that connect a device, and the update mechanism that keeps it secure after it ships. Progression Agency provides them to hardware startups, device manufacturers and product teams, together with the cloud services and companion apps a connected product needs. Progression Agency is based in New York City and works with clients across the United States and worldwide.

What do embedded software development services include?

Everything between the silicon and the cloud: firmware, operating system configuration, drivers, connectivity, security features, the update mechanism and the tests that prove each one on real hardware. Software development embedded in a physical product works under constraints web teams rarely meet, such as kilobytes of memory, tight battery budgets and code that must run for years without a restart.

Embedded systems software development is judged on hardware, not in a simulator alone: a feature is done when it passes its tests on the target board, inside its memory, power and timing budgets. That is why we plan every engagement around the client’s hardware milestones.

Software vs firmware: where the line sits

Firmware is software that lives in a device’s hardware and controls it directly; ‘software’ usually means code that runs on a general-purpose computer or phone. The NIST glossary cites the CNSSI 4009 definition of firmware as computer programs and data stored in hardware, typically in read-only memory or programmable read-only memory, such that they cannot be dynamically written or modified during execution.

Why the difference matters when you ship updates

That definition dates from ROM chips. Modern devices keep firmware in rewritable flash, which is what makes over-the-air updates possible and also what makes firmware an attack surface. NIST’s Platform Firmware Resiliency Guidelines (SP 800-193) frame the job as protecting firmware against unauthorized changes, detecting changes that occur, and recovering rapidly and securely.

Software engineer or embedded engineer?

Most connected products need both. An embedded engineer reads schematics and datasheets, writes code against registers and peripherals, and works within tight memory and power budgets; a software engineer builds the cloud services, APIs and apps the device talks to. We staff both against one interface specification, so the device and the cloud agree on every message.

Bare metal, an RTOS or embedded Linux?

The hardware and the product decide: bare metal for the simplest, lowest-power microcontroller products; a real-time operating system when several tasks, radios and timing guarantees share a microcontroller; embedded Linux when an application processor runs networking, displays, storage and third-party software.

Bare-metal firmware

A main loop with interrupts is still the right design for many sensors, wearables and simple controllers. It is easy to reason about and simple to analyze, but every added feature adds timing analysis, so we move to an RTOS once concurrency grows.

FreeRTOS

FreeRTOS is a real-time operating system for microcontrollers and small microprocessors, distributed under the MIT license and maintained by AWS, with one code base for more than 40 processor architectures and more than 15 toolchains. Its long-term support libraries receive security updates and critical bug fixes for two years, which suits products that must stay patched without constant rework.

Zephyr

The Zephyr RTOS is built on a small-footprint kernel for resource-constrained and embedded systems and is licensed under Apache 2.0. It supports Arm Cortex-M, Cortex-A and Cortex-R, RISC-V, x86, Xtensa and several other architectures, and includes a native networking stack, Bluetooth Low Energy support, devicetree hardware description, and memory protection with stack-overflow detection.

Embedded Linux with Yocto or Buildroot

On application processors we build custom Linux images. The Yocto Project helps developers create custom Linux-based systems regardless of the hardware architecture, and Buildroot is a simpler tool that generates embedded Linux systems through cross-compilation. Yocto suits product families with many variants and long support lives; Buildroot suits smaller, fixed-function devices.

Drivers and board bring-up

Bring-up is the first contact between firmware and a new board: power rails, clocks, memory and debug access, then each peripheral in turn. Drivers come out of that work one interface at a time, each with a test that proves it on the real hardware.

From schematic to first boot

We review the schematic and bill of materials before boards arrive, write a bring-up plan for each interface, and prepare minimal test firmware, so the first boards can be checked quickly and hardware faults are separated from software faults early. A typical bring-up order:

1. Power rails and current draw at idle, measured before any firmware runs.
2. Clocks, reset and the debug connection.
3. Internal and external memory, with a pattern test.
4. Console output and a heartbeat, so later steps can report results.
5. Each peripheral bus in turn: I2C, SPI, UART, USB and the rest.
6. Radios and sensors, each with a standalone test firmware.
7. Low-power states, wake sources and the measured current in each.

Devicetree and hardware abstraction

Zephyr and Linux both describe hardware in devicetree, so a board revision or a second product variant becomes a configuration change rather than a code change. On bare metal and FreeRTOS, a thin hardware abstraction layer gives the same separation.

Power, timing and memory budgets

Budgets are measured, not estimated: current draw in each power state, worst-case interrupt latency, stack and heap high-water marks, and flash headroom for the next update. Each budget has a test that fails when a change breaks it.

Connectivity: Bluetooth LE, Wi-Fi, Matter, cellular and MQTT

Pick the radio from range, power, data rate and who sets the device up, then give reconnection, pairing and provisioning as much design time as the happy path. A connected product is judged by how it behaves when the link drops.

Bluetooth Low Energy

Bluetooth LE suits battery-powered products that talk to a phone. The Bluetooth Core Specification, now at version 6.3, defines the technologies required to create interoperable Bluetooth devices; we design the GATT services, pairing and bonding, and the firmware update path over BLE together with the companion app.

Wi-Fi and Matter

Mains-powered home and office devices usually connect over Wi-Fi. For smart-home products, Matter, the Connectivity Standards Alliance’s open protocol, runs on Wi-Fi and Thread network layers and uses Bluetooth Low Energy for commissioning, and its certification program checks that devices work reliably together.

Cellular links

Devices that move, or sit far from any Wi-Fi network, use cellular modules. Data plans, power-save modes, carrier certification and module firmware updates then become part of the firmware plan, so we select modules with those constraints in view.

Getting data to the cloud with MQTT

MQTT 5.0, an OASIS Standard since March 7, 2019, is a lightweight client-server publish/subscribe protocol suited to constrained environments such as machine-to-machine and IoT links. Cloud services such as AWS IoT Core accept MQTT, MQTT over secure WebSockets, HTTPS and LoRaWAN, so the protocol follows the device’s power and network constraints.

Over-the-air updates that do not brick devices

A safe update path needs a secure bootloader, signed images, a spare slot and a tested way back. We design it before the first feature ships, because a product without a reliable update path cannot fix its own bugs or vulnerabilities after sale.

A secure bootloader and signed images

MCUboot is a secure bootloader for 32-bit microcontrollers that defines a common flash layout and enables software upgrades; it supports image signing and key management through its imgtool utility, supports encrypted images, and runs with Zephyr, Apache Mynewt, Apache NuttX, RIOT and several vendor platforms. On Linux devices the equivalent is a verified boot chain with signed images.

Two slots and a way back

The new image is written to an inactive slot and verified before the bootloader switches to it. The application must confirm it is healthy after boot; if it does not, the bootloader reverts to the previous image. In testing, power is cut at every stage of the process to prove the device always comes back.

Staged rollouts

Updates go to internal devices first, then a small share of the fleet, then everyone, with telemetry checked at each stage. A rollout that raises crash or reset rates stops automatically.

Protect, detect, recover

NIST SP 800-193 organizes firmware resiliency around protecting firmware from unauthorized changes, detecting changes that happen and recovering securely. We map the update design to those three headings, so a security reviewer can see each control and its test.

Device-to-cloud services and companion apps

A connected product is three pieces of software that must agree: the firmware, the cloud services and the companion app. We design them from one interface specification, covering messages, APIs and the data model, so each piece can change without breaking the others.

The cloud side

Device registry, identity and certificates, message ingestion, commands, update orchestration and data storage. Custom software development for IoT is mostly this plumbing, and it has to scale to the whole fleet from day one. Our API development and cloud app development teams build it, and dashboard development covers the operational views.

The companion app

Buyers who search for an iot app development company are often looking for the phone app alone; our IoT app development page covers that iot app development service in depth, from Bluetooth pairing to dashboards. Here the app matters as the other end of the firmware: provisioning, updates, offline behavior and error states are designed together with the device.

One team or several?

Some manufacturers want a single iot software development company for firmware, cloud and app; others keep firmware in-house and buy iot software development services for the cloud and the app. Both work if one interface specification governs all three and each team tests against the others’ builds.

Safety and quality standards buyers ask about

The standard follows the industry the product serves: IEC 62304 for medical device software, ISO 26262 for road vehicles, IEC 61508 for industrial and general functional safety, DO-178C for airborne software, with MISRA C often required for the code itself. Progression Agency does not hold certifications under these standards and does not certify products; we work inside the client’s safety and quality process and produce the records it requires.

IEC 62304: medical device software

The IEC’s description says IEC 62304 defines life cycle requirements for medical device software and applies whether the software is itself a medical device or an embedded part of one; it does not cover validation and final release of the device. The consolidated edition combines the 2006 first edition with Amendment 1 of 2015, and ISO lists the standard as reviewed and confirmed in 2023. Requirements scale by software safety class A, B or C. A committee draft of a second edition would replace the three classes with two process rigor levels, according to IEC subcommittee SC 62A’s change rationale for that draft, and the IEC webstore lists 2028 as the current edition’s stability date. The FDA recognizes IEC 62304 as a consensus standard, recognition number 13-79.

ISO 26262: road vehicles

ISO 26262 addresses hazards caused by malfunctioning safety-related electrical and electronic systems in series production road vehicles. Part 6, ISO 26262-6:2018, sets requirements for product development at the software level, from software safety requirements and architectural design through unit verification, integration and testing of the embedded software. Part 9 covers safety analysis oriented to Automotive Safety Integrity Levels (ASILs), including the decomposition of requirements. ISO lists Parts 6 and 9 of the 2018 edition as due for revision, with new drafts under development.

IEC 61508: functional safety across industries

The IEC describes the IEC 61508 series as a horizontal functional safety standard for the life cycle of electrical, electronic and programmable electronic systems, applicable across a wide range of sectors, with four safety integrity levels that express the degree to which a system will meet its specified safety functions. Part 3 covers software, including the support tools used to build it, such as language translators and testing and debugging tools.

DO-178C: airborne software

The FAA’s Advisory Circular 20-115D, issued July 21, 2017, recognizes RTCA DO-178C, dated December 13, 2011, as an acceptable means of showing compliance for the software aspects of airborne systems in type certification or TSO authorization, together with supplements on tool qualification, model-based development, object-oriented technology and formal methods. The system safety process assigns each function a minimum development assurance level from the severity of its failure conditions, which sets the DO-178C software level and the rigor that goes with it.

MISRA C: rules for the code itself

MISRA C is the guideline set its publisher calls the de facto standard for developing software in C where safety, security and code quality are important. The current edition, MISRA C:2025, was published in March 2025 and supports C11 and C18 as well as earlier versions of the language. We enforce the rules with static analysis in the build and record every approved deviation with its justification.

Working inside your quality system

In regulated products, the process evidence matters as much as the code. We follow the client’s procedures for requirements, design reviews, configuration management and change control, and deliver the records those procedures call for.

Requirements traced to tests

Every software requirement links to its design element and to the tests that verify it, and every test result links back. A traceability matrix generated from the tools, rather than maintained by hand, keeps that chain accurate as the code changes. For US medical device makers, FDA’s Quality Management System Regulation, effective February 2, 2026, incorporates ISO 13485:2016 by reference, so our records are shaped to fit that kind of quality system.

Configuration and change control

Every released image is built by CI from a tagged commit with a recorded toolchain, so it can be rebuilt exactly. Changes after release go through the client’s change process, with an impact assessment and regression tests.

Third-party and open-source components

Operating systems, stacks and libraries are listed with versions, licenses and known vulnerabilities. That list feeds both the software bill of materials and, in medical work, the evaluation of the off-the-shelf components IEC 62304 calls SOUP, software of unknown provenance.

FDA cybersecurity expectations for connected medical devices

If a medical device includes software and can connect to the internet, FDA expects cybersecurity to be designed in and documented in the premarket submission. The central references are section 524B of the Federal Food, Drug, and Cosmetic Act and FDA’s premarket cybersecurity guidance.

What makes a device a cyber device

Under section 524B, a cyber device includes software validated, installed or authorized by the sponsor, can connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. FDA’s cybersecurity FAQ says sponsors must submit a plan to monitor, identify and address postmarket vulnerabilities and exploits, maintain processes that provide reasonable assurance the device and related systems are cybersecure, and provide a software bill of materials covering commercial, open-source and off-the-shelf components. The requirements have applied to premarket submissions since March 29, 2023.

The premarket cybersecurity guidance

FDA’s guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, updated in February 2026, covers cybersecurity device design, labeling and the documentation FDA recommends for devices with cybersecurity risk, including its recommendations on section 524B. We produce the engineering inputs that documentation draws on, such as architecture descriptions, threat models, the SBOM and security test results.

Documentation levels for device software

Separately, FDA’s June 14, 2023 guidance Content of Premarket Submissions for Device Software Functions replaced the 2005 software guidance with two documentation levels. Enhanced Documentation applies where a failure or flaw of a device software function could present a hazardous situation with a probable risk of death or serious injury; Basic Documentation applies otherwise. The same guidance lets sponsors provide a declaration of conformity to specified clauses of IEC 62304 for development, maintenance and configuration management practices.

NIST, EU and FCC rules for connected products

Outside medical devices, the reference points for connected-product security are NIST’s IoT publications in the United States, the EU Cyber Resilience Act for products sold in Europe, and the FCC’s voluntary U.S. Cyber Trust Mark for consumer devices.

NIST IR 8259A: six device capabilities

NIST IR 8259A, the IoT Device Cybersecurity Capability Core Baseline published in May 2020, lists six capabilities a device should provide: device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness. We use it as a design checklist for firmware.

NIST IR 8259 Rev. 1: activities for manufacturers

In April 2026, NIST published IR 8259 Rev. 1, Foundational Cybersecurity Activities for IoT Product Manufacturers, superseding the 2020 edition. It recommends that manufacturers improve the securability of their products and give customers the cybersecurity information they need before products reach the market.

The EU Cyber Resilience Act

The Cyber Resilience Act sets mandatory cybersecurity requirements for manufacturers of products with digital elements, covering planning, design, development and maintenance, including handling vulnerabilities over the product’s life. It entered into force on December 10, 2024; reporting obligations apply from September 11, 2026 and the main obligations from December 11, 2027.

The FCC’s U.S. Cyber Trust Mark

The U.S. Cyber Trust Mark is a voluntary FCC cybersecurity labeling program for wireless consumer IoT products. The FCC adopted its rules in March 2024 and, as of its September 28, 2026 notice recognizing accreditation bodies, was still standing the program up. Makers of consumer devices that want the label should design toward its criteria now.

Embedded software development tools

The toolchain is part of the product: the compiler, build system, static analyzers, debuggers and emulators decide which defects are caught and when. We use the client’s approved tools where a quality system names them, and otherwise set up a reproducible toolchain in CI from the first week.

Choosing an embedded software development tool chain

A single embedded software development tool rarely decides a project; the combination does. We prefer tools that run headless in CI, produce machine-readable reports and remain available to the client after handover, so no result depends on one engineer’s workstation.

Emulation before hardware

QEMU is a generic, open-source machine emulator and virtualizer, and Renode is Antmicro’s open-source framework for emulating CPUs, peripherals, sensors, interconnects and whole multi-node systems. Both let firmware run in CI long before boards are plentiful.

Unit testing in C

Unity, a unit-test framework written in ANSI C, is built to run on anything from 8-bit microcontrollers to 64-bit machines, which makes it practical to run the same module tests on a development machine and on the target.

Static analysis as a gate

Static analysis is most useful when it blocks merges rather than filling a report nobody reads. We configure the checkers against the client’s coding standard, MISRA C or otherwise, and treat each new finding as a build failure.

How is embedded software tested?

In layers, from the fastest and cheapest tests to the slowest and most realistic: host-based unit tests, emulated integration tests, hardware-in-the-loop tests, then field telemetry after launch. Each layer catches defects the others cannot.

Host-based unit tests

Modules with hardware access abstracted away are tested on a development machine in seconds, on every commit. This is where most logic defects should be found, because it is the cheapest place to find them.

Hardware-in-the-loop rigs

A rig connects production-representative boards to controllable power supplies, sensor simulators, radios and measurement equipment, and runs the release tests unattended every night. Results land in the same report as the unit tests.

Fault injection and power-loss testing

We cut power during flash writes and updates, corrupt images, flood radios with malformed packets and fill storage, because devices meet all of these in the field sooner or later.

Field telemetry

After launch, devices report crash logs, reset reasons, update outcomes and battery health, within the privacy limits the product sets. Telemetry closes the loop between field behavior and the next release.

What do embedded software development services cost?

Scope, hardware maturity and certification drive the cost. We plan embedded work against the custom software and app ranges we publish, and an embedded software development service engagement is quoted after a written scope, because board revisions, test rigs and safety evidence change the effort more than feature lists do.

The software and app figures are planning ranges from our software development company and app development agency pages, not quotes. Firmware for a new board, certification evidence and hardware-in-the-loop rigs are scoped individually, since the hardware schedule sets the pace. Custom iot software development services for the cloud and app follow the same ranges.

Those bids, from Ubersuggest for the United States in September 2026, show how much a single qualified inquiry is worth to the firms competing for it.

From prototype board to production firmware

Firmware work runs alongside the hardware schedule, one board build at a time. The sequence below is how we run it; the calendar comes from your hardware milestones.

AI answers: how hardware teams ask assistants for an embedded partner

Engineering managers and founders describe their constraints when they ask ChatGPT, Claude, Perplexity, Gemini, Microsoft Copilot or Google’s AI Overviews for help: the chip, the RTOS, the radio, the standard and the deadline. A firm gets named when its pages answer those constraints in text an assistant can quote.

1. “Which embedded software development company can port our firmware from FreeRTOS to Zephyr on an nRF52?”
2. “Recommend firmware developers in the US who have worked inside an IEC 62304 process.”
3. “Who builds secure OTA updates with MCUboot for a fleet of battery-powered sensors?”
4. “Find a team to build embedded Linux with Yocto for a gateway, plus the companion app.”
5. “Compare embedded development firms that work to MISRA C for an automotive supplier.”

Where the answers come from

Assistants that search the web draw on what a search returns. For ’embedded software development services’ in September 2026, that meant agency service pages, a company profile on LinkedIn and a ‘best embedded systems development companies’ roundup; standards questions pull from ISO, IEC, FDA and NIST pages. Perplexity’s crawler, PerplexityBot, exists to surface and link websites in its answers (Perplexity crawler documentation), and Anthropic’s Claude-SearchBot works to improve the relevance of Claude’s search results (Anthropic’s crawler article).

What gets an embedded team cited

Assistants quote the page that answers the constraint in one sentence. For embedded work, the pages that earn citations tend to share these traits:

• Named silicon, RTOSes and build systems, not ‘all major platforms’.
• Standards explained accurately, with a plain statement of what the firm does and does not certify.
• Update and security designs described in enough detail to judge them.
• Planning prices and a phase plan tied to hardware milestones.
• Engineers’ names on talks, papers and open-source contributions to projects such as Zephyr.
• Crawler access for OAI-SearchBot (OpenAI), PerplexityBot, Claude-SearchBot and Bingbot, which feeds Microsoft Copilot.

We build that kind of evidence for our own practice and for clients through our answer engine optimization agency work.

How to choose an embedded software development company

Ask for evidence tied to your hardware, your standard and your update plan. The table lists what to require from an embedded software development company and how to check it before you sign.

Related services

Embedded products need software on every layer; these pages cover the rest of it.

• Manufacturing software development: plant-floor, production-tracking and quality software for manufacturers.
• Custom software development: everything we build, with our published planning ranges.
• API development: the device-facing and customer-facing APIs a connected product needs.
• IoT app development: companion apps and dashboards for connected devices.
• Wearable app development: Apple Watch, Wear OS and custom wearable device apps.
• Healthcare software development: software for regulated health products and providers.
• Cloud app development: the device cloud behind a connected product.
• Dashboard development: fleet operations and customer-facing data views.
• React Native app development: cross-platform companion apps.
• DevOps services: CI pipelines, infrastructure and monitoring for device clouds.
• Telecom software development: network-side software for connectivity-heavy products.
• Python development company: data pipelines and machine learning on device data.

Frequently asked questions