How to choose an embedded software platform for connected devices
A practical definition for product teams
An embedded software platform is the reusable foundation that allows a hardware product to boot, control peripherals, communicate, update securely and stay maintainable throughout its field life. It may include an RTOS or embedded Linux distribution, board support packages, drivers, middleware, security services, build tooling, test automation and long-term maintenance processes. For connected devices, the right platform is the one that fits the product’s timing, memory, power, safety, security and lifecycle constraints with the least hidden engineering risk.
This definition matters because teams often compare platforms too narrowly. A microcontroller SDK can be the fastest route to a prototype, while a full embedded Linux stack can be attractive for networking and application flexibility. Neither choice is automatically right for production. The decision should reflect what the device must prove after launch: deterministic control, secure connectivity, auditable updates, hardware portability, certification evidence, supplier continuity and years of vulnerability handling. For more context on related platform categories, see our embedded platforms coverage.
Why the platform decision has become more strategic
Embedded devices now ship into environments where software is expected to change after sale. Industrial gateways, smart home hubs, medical monitors, EV chargers, asset trackers and building automation controllers may all need security patches, protocol updates and, in some cases, feature updates long after the PCB has been finalized. That turns platform evaluation from a firmware-only question into a lifecycle question.
Recent industry data points in the same direction. The Eclipse Foundation’s 2024 IoT and Embedded Developer Survey, released in December 2024, reported that connectivity was the top developer concern at 48%, while security rose to 35%. The same survey reported that communication security, over-the-air updates and secure boot were leading security strategies among respondents. Its constrained-device operating system findings also showed a mixed market rather than a single default choice, with Linux, FreeRTOS, Zephyr and Eclipse ThreadX all appearing as relevant options.
Regulation is adding pressure as well. The EU Cyber Resilience Act entered into force on December 10, 2024. Its main obligations apply from December 11, 2027, while manufacturer reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 11, 2026. For hardware and software products with digital elements placed on the EU market, platform decisions now need to support vulnerability handling, secure-by-design processes and documented support periods. Teams outside Europe may also be affected if their products, suppliers or customers participate in global markets.
Match the platform type to the device architecture
The first useful filter is product architecture, not brand name. A battery-powered sensor, a motor controller, a gateway and a software-defined vehicle controller have different workload profiles. The table below gives a practical starting point.
| Platform approach | Typical fit | Strengths | Watch-outs |
|---|---|---|---|
| Bare metal plus vendor SDK | Simple control loops, cost-sensitive MCUs, fixed-function devices | Small footprint, low overhead, direct hardware access, quick bring-up on supported chips | Scaling drivers, networking, updates and portability can become expensive as products grow |
| RTOS-based platform | Connected MCUs, real-time control, low-power devices, multi-sensor products | Scheduling, drivers, middleware, isolation options and repeatable structure without full Linux overhead | Board support quality, certification evidence and long-term maintenance vary by ecosystem and vendor |
| Embedded Linux platform | Gateways, HMIs, edge devices, products needing rich networking, containers or complex applications | Large software ecosystem, process isolation, mature networking, strong tooling for custom images | Boot time, storage, patching, attack surface and image reproducibility require disciplined engineering |
| Mixed MCU plus Linux architecture | Products combining deterministic control with high-level connectivity or UI | Separates real-time workloads from application workloads; can improve maintainability | Interprocessor communication, update coordination and system testing become core design tasks |
Yocto Project is a common example of the embedded Linux platform path. It is not a finished Linux distribution; it provides tools and metadata for creating a custom Linux-based system for embedded products. Zephyr is a common example of the RTOS platform path. Its documentation highlights broad board support, application APIs, driver models, device tree use, security considerations, safety topics and long-term support planning. These examples show why “platform” is broader than kernel selection.
Evaluation criteria that prevent expensive redesigns
Hardware support and portability
Start with the board support package, supported SoCs, driver maturity and upstream contribution model. A platform that supports a reference evaluation board may still require significant work on a custom PCB. Check whether the platform already supports the exact peripherals, clocks, power states, wireless modules, boot chain and debug interfaces your product uses. If the roadmap includes multiple hardware variants, portability should be treated as a first-order requirement, not a future optimization.
Real-time behavior and resource limits
Measure the constraints that matter for the product: interrupt latency, scheduling behavior, memory footprint, boot time, power modes, storage writes, thermal limits and recovery behavior after brownout or network failure. A gateway with gigabytes of storage and Ethernet has very different platform economics from a wearable device that wakes briefly on a coin cell. The right platform should leave enough headroom for security features, diagnostics and future protocol updates, not only the launch feature set.
Security architecture
Security should be part of the platform baseline. Look for secure boot support, hardware root-of-trust integration, signed firmware or image updates, rollback protection, secrets storage, secure debug configuration, vulnerability disclosure processes and a practical way to generate or maintain a software bill of materials. NIST’s Secure Software Development Framework, published as SP 800-218 in February 2022, is a useful reference because it frames secure development as practices that can be integrated into existing software lifecycles rather than added as a separate activity at the end.
Update and recovery model
For connected products, update design is platform design. Teams should understand whether the platform supports A/B updates, delta updates, verified boot, staged rollout, local recovery, factory reset, offline update and rollback after failure. The recovery path matters as much as the normal update path. A field device with a weak update system can turn a routine security patch into a truck roll, a warranty event or a safety risk.
Build, test and release reproducibility
Embedded software releases need traceability. The platform should support versioned manifests, repeatable builds, automated unit and integration tests, hardware-in-the-loop testing where needed, static analysis, artifact signing and release notes tied to known dependencies. In embedded Linux, reproducible image builds and layer management are especially important because a product image may combine a bootloader, kernel, drivers, user-space packages, middleware and applications from many sources.
A decision matrix for comparing real options
Instead of asking which embedded software platform is most popular, use a scoring matrix that connects product requirements to evidence. A simple 1-to-5 score can work if each score is backed by artifacts, not opinions.
| Criterion | Evidence to request or produce | Why it matters |
|---|---|---|
| Target hardware fit | Supported board list, BSP status, driver coverage, custom board porting estimate | Reduces bring-up risk and avoids late hardware-software mismatches |
| Lifecycle support | Release cadence, LTS policy, maintainer activity, supplier support terms | Connected products need security and maintenance after launch |
| Security baseline | Secure boot design, update mechanism, SBOM process, vulnerability handling workflow | Supports regulatory, procurement and customer security expectations |
| Real-time and performance fit | Latency tests, memory maps, boot-time data, stress results on target hardware | Prevents selecting a platform that only works in demonstrations |
| Developer productivity | Debug tools, CI integration, documentation quality, onboarding time, sample quality | Platform complexity affects every sprint and every future maintenance release |
| Certification and compliance path | Safety manuals, security documentation, process evidence, third-party assessment needs | Some markets require proof, not just working code |
The strongest option is rarely the one with the highest score in every row. A safety-critical controller may prioritize determinism, traceability and certification evidence. A consumer gateway may prioritize networking, update reliability and the application ecosystem. A long-life industrial device may put more weight on LTS policy, supplier continuity and the cost of maintaining legacy hardware. See also: device architecture.
Common mistakes when selecting an embedded software platform
Treating the prototype as the platform. A vendor SDK can be excellent for early validation, but production needs may include secure updates, diagnostics, factory provisioning, manufacturing tests and component tracking. If these capabilities are bolted on late, the product architecture can become fragile.
Ignoring the support period. Many embedded products remain in the field for five, ten or more years. The platform must have a credible plan for security patches, dependency updates and toolchain maintenance across that period. A short initial development schedule does not justify an unsupported runtime.
Underestimating compliance documentation. Regulations and customer procurement processes increasingly ask for evidence: what components are included, how vulnerabilities are handled, how updates are delivered and how security was considered during development. The platform should make that evidence easier to produce.
Confusing open source with zero maintenance. Open source can reduce vendor lock-in and improve transparency, but it still requires engineering ownership. Teams need a policy for upstream tracking, license review, patch intake, vulnerability monitoring and contribution strategy.
Choosing too much platform. A full Linux stack may be unnecessary for a small deterministic controller. Extra packages, services and storage requirements increase the attack surface and maintenance burden. The platform should be large enough for the product roadmap, but not so large that it creates operational risk.
How to run a platform selection process
- Write the production requirements first. Include boot time, memory, power, connectivity, update, security, diagnostics, certification and expected support period.
- Build a representative spike on target hardware. Do not rely only on a development kit if the final board changes clocks, memory, radios or power design.
- Test failure modes early. Simulate interrupted updates, corrupt storage, network loss, low battery, peripheral failure and rollback scenarios.
- Review lifecycle evidence. Check release history, maintainers, long-term support policies, known vulnerability handling and supplier commitments.
- Score the options with engineering and product stakeholders. A platform decision affects bill of materials, roadmap flexibility, compliance work, support cost and time to market.
This process helps teams move beyond preference-based platform debates. It also creates an audit trail for why a platform was selected, which can be useful when customers, regulators or internal quality teams ask how product risk was assessed.
Frequently asked questions
Is an RTOS an embedded software platform?
An RTOS can be part of an embedded software platform, but it is not always the whole platform. A production platform also includes board support, drivers, middleware, build tooling, testing, update logic, security configuration and maintenance practices.
When should a product use embedded Linux instead of an RTOS?
Embedded Linux is often a better fit when the product needs rich networking, complex user-space applications, high-level language runtimes, containers, advanced file systems or gateway functions. An RTOS is often more suitable for constrained MCUs, deterministic control, fast startup and low-power operation.
Does platform choice affect cybersecurity compliance?
Yes. Platform choice affects secure boot, update delivery, SBOM generation, vulnerability handling, logging, dependency tracking and support-period planning. These capabilities are increasingly relevant to regulations, customer audits and procurement requirements.
Can one product use more than one platform?
Yes. Many connected devices combine an MCU running an RTOS for real-time control with a Linux-based processor for connectivity, analytics or user interface functions. This can be effective, but it requires careful design of interprocessor communication, coordinated updates and system-level testing.
What is the most important selection factor?
The most important factor is fit to the product lifecycle. Performance and developer convenience matter, but the chosen embedded software platform must also support secure updates, maintainability, hardware evolution and evidence needs for the expected life of the device.
