Understanding the work
What does an embedded software development company do?
An embedded software development company designs, writes, tests, and maintains software that runs on dedicated hardware: firmware for microcontrollers, real-time operating system applications, embedded Linux platforms, device drivers and board support packages, bootloaders and update systems, and the interfaces that connect devices to apps and cloud services.
Embedded software has constraints that business software does not. Memory and processing power are limited, timing can be safety-critical, and a bug may require a field recall rather than a quick redeploy. The work happens on lab benches with oscilloscopes, debug probes, and prototype boards as much as on laptops.
Embedded software development is the design, implementation, verification, and maintenance of software that runs on a dedicated hardware device to control its functions, often under real-time, power, memory, safety, and security constraints, and usually for a product life measured in years.
How this differs from related roles
Electronics design firms create schematics and circuit boards. Contract manufacturers build the hardware. App and cloud developers build the companion software that talks to devices. An embedded software development company works at the boundary of hardware and software, and the best results come when it is involved during hardware design rather than after boards are frozen. For engagement models and contract basics across all project types, see our software development company guide.
Types of embedded software work
Common embedded work includes bare-metal firmware, RTOS-based applications, embedded Linux platforms, drivers and board support packages, bootloaders and over-the-air update systems, connected device stacks, and human-machine interfaces. Effort depends on the hardware platform, real-time and safety requirements, connectivity, security features, and how many hardware variants the software must support.
| Type | Examples | What drives effort |
|---|---|---|
| Bare-metal firmware | Sensor nodes, motor control, battery-powered devices | Timing, power budgets, tight memory, hardware quirks |
| RTOS applications | Medical pumps, industrial controllers, automotive modules | Task scheduling, determinism, safety certification of the RTOS |
| Embedded Linux | Gateways, kiosks, infotainment, smart cameras | Custom builds with tools such as Yocto, boot time, kernel maintenance, license compliance |
| Drivers and BSPs | Board bring-up, peripheral drivers, power management | Datasheet gaps, silicon errata, early prototype instability |
| Bootloaders and OTA updates | Secure boot chains, A/B partitions, delta updates | Key management, rollback safety, recovery from failed updates |
| Connected devices | Wi-Fi, Bluetooth Low Energy, cellular, and LoRaWAN products | Radio certification, provisioning, cloud protocol design, battery life |
| HMI | Touch displays on equipment, appliances, and vehicles | Graphics performance on limited hardware, usability, localization |
Scroll the table sideways to see all columns.
Hardware and software co-design
Many embedded cost overruns trace back to decisions made before software engineers were involved: a microcontroller with too little memory for secure updates, a missing debug header, or a sensor with a poorly documented interface. Bring firmware engineers into part selection and board reviews, and ask them to confirm that the chosen parts support secure boot, have long availability commitments, and come with usable toolchains.
Standards and security
Safety and coding standards for embedded software
The main safety standards are IEC 62304 for medical device software, ISO 26262 for road vehicles, DO-178C for airborne software, and IEC 61508 for general functional safety. Coding standards such as MISRA C:2025 and MISRA C++:2023 support them. Each requires documented processes, traceability, verification evidence, and often qualified tools.
| Standard | Domain | What it asks for |
|---|---|---|
| IEC 62304 | Medical device software | Software lifecycle processes scaled by safety class; current edition 2006 with Amendment 1:2015 |
| ISO 26262:2018 | Road vehicles | Functional safety lifecycle scaled by Automotive Safety Integrity Level (ASIL) |
| DO-178C | Airborne systems | Objectives scaled by software level, with certification authority review |
| IEC 61508 | General electrical, electronic, and programmable safety systems | Safety lifecycle scaled by Safety Integrity Level (SIL); basis for several sector standards |
| MISRA C:2025, MISRA C++:2023 | Coding rules for C and C++ | Rules and directives that limit risky language use, with documented deviations |
Scroll the table sideways to see all columns.
Evidence and tool qualification
Certification bodies and regulators look for evidence: requirements traced to design, code, and tests; static analysis reports; coverage results; reviews; and records of deviations from coding rules. Several standards also require confidence in the tools themselves, such as compilers, static analyzers, and test frameworks, through tool qualification or classification. Ask an embedded software development company to show a sample traceability matrix and a MISRA compliance summary from past work, with client details removed.
This is general information, not legal or regulatory advice; confirm scope and obligations with your regulatory team and counsel.
Device cybersecurity rules and practices
Device cybersecurity is increasingly regulated. The EU Cyber Resilience Act sets duties for products with digital elements, UNECE R155 and R156 cover vehicle cybersecurity and software updates, and FDA expects cybersecurity content in medical device submissions. Core practices include secure boot, signed updates, SBOMs, vulnerability handling, and secure provisioning.
Regulations and guidance
- EU Cyber Resilience Act: entered into force Dec 10, 2024. Reporting of actively exploited vulnerabilities and severe incidents applies from Sept 11, 2026, and the main obligations apply from Dec 11, 2027. It covers products with digital elements sold in the EU, including those made by US companies.
- UNECE R155 and R156: require vehicle makers to run a cybersecurity management system and a software update management system, and suppliers are expected to support both. ISO/SAE 21434:2021 describes automotive cybersecurity engineering that supports R155.
- FDA medical device cybersecurity: the current guidance on cybersecurity in medical devices, updated in February 2026, covers secure design, threat modeling, SBOMs, and premarket submission content.
- NIST IR 8259 Rev. 1: finalized in April 2026, it describes foundational cybersecurity activities for IoT product manufacturers.
- US Cyber Trust Mark: the FCC's voluntary IoT security label was still in development as of October 2026.
Engineering practices
- Secure boot that verifies each stage, rooted in hardware where the chip allows it.
- Signed firmware updates with rollback protection and a safe recovery path.
- A software bill of materials (SBOM) for every release, including open source and vendor libraries.
- Unique device credentials provisioned securely in the factory, with no shared default passwords.
- A vulnerability intake and disclosure process that can meet reporting deadlines.
- Debug ports locked or disabled on production units.
Devices rarely stand alone. The cloud services they report to need their own protection; our guide to cloud security managed services covers monitoring and response for that side.
This is general information, not legal advice; confirm with counsel, as these rules continue to change as of October 2026.
Decisions
Long product lifecycles, obsolescence, and long-term support
Embedded products often stay in service for many years, far longer than typical apps. Plan for component obsolescence, operating system and library updates, security patches, and regulatory reporting across that whole period. A long-term support agreement should define patch timelines, supported hardware revisions, and what happens when the original engineers move on.
- Choose parts with published longevity commitments and identify second sources early.
- Keep the full build environment reproducible, including compiler versions, so firmware can be rebuilt years later.
- Plan for last-time buys and redesigns when a chip reaches end of life.
- Track kernel, RTOS, and library support windows, and budget for upgrades.
- Define how long security updates will be provided, and tell customers.
Ask any embedded software development company how it keeps product knowledge when engineers leave, and whether it will rebuild old firmware on request.
How an embedded software development company delivers and tests
Embedded projects follow hardware milestones: requirements and architecture, board bring-up on early prototypes, feature development, integration, hardware-in-the-loop and environmental testing, certification, manufacturing support, and field updates. Testing needs lab equipment, test fixtures, and automated rigs, not only unit tests on a laptop.
- Requirements and architectureCapture functional, timing, power, safety, and security requirements, and allocate them between hardware and software.
- Board bring-upGet the processor, memory, clocks, and peripherals working on first prototypes, and report hardware issues early.
- Feature developmentBuild drivers, middleware, and application logic in increments, with continuous integration that cross-compiles every change.
- Hardware-in-the-loop testingRun automated tests on real boards connected to simulated sensors, loads, and networks.
- Verification and certificationProduce the evidence your safety or regulatory pathway needs, and support lab and agency reviews.
- Manufacturing supportDeliver factory programming, provisioning, and end-of-line test software.
- Field updates and supportRun staged OTA rollouts, monitor failures, and patch vulnerabilities.
Ask what lab equipment a vendor has: debug probes, logic analyzers, oscilloscopes, power analyzers, RF test gear, and environmental chambers, or partner labs for radio and safety testing. Remote teams should have identical hardware setups to yours.
What drives the cost of embedded software development
Major cost drivers are safety classification and certification evidence, hardware maturity, the number of hardware variants, connectivity and security features, test infrastructure, toolchain and RTOS licenses, and the length of long-term support. Late hardware changes and unclear requirements cause the most expensive rework in embedded projects.
| Driver | Why it matters |
|---|---|
| Safety level | Higher safety classes require more process, reviews, coverage, and documentation |
| Hardware maturity | Unstable prototypes slow bring-up and cause repeated debugging |
| Hardware variants | Each board revision or product variant multiplies build and test work |
| Security features | Secure boot, key provisioning, OTA, and SBOMs add design and factory work |
| Test infrastructure | HIL rigs, fixtures, and lab equipment are real line items |
| Licenses | Commercial compilers, certified RTOSs, static analyzers, and qualification kits carry fees |
| Certification | Lab testing, agency reviews, and responses to findings take time and effort |
| Long-term support | Years of patches, obsolescence redesigns, and regulatory reporting |
Scroll the table sideways to see all columns.
Ask each embedded software development company to list tool and license costs separately from engineering, and to state which hardware revisions its estimate assumes.
IP ownership, toolchain licenses, and contracts
Embedded contracts should assign you the firmware source, build scripts, test code, and documentation; list any vendor libraries licensed rather than assigned; state who holds signing keys; cover open source license compliance; and transfer or name the owners of toolchain and RTOS licenses so you can rebuild and patch the product without the original vendor.
- Firmware source, build environment, and test assets assigned to you, in repositories you control.
- A list of vendor-owned libraries or reference designs, with perpetual license terms if you depend on them.
- Signing keys and provisioning secrets generated and stored under your control.
- Toolchain, RTOS, and analyzer licenses held in your name, or a plan to transfer them.
- Open source compliance, including GPL obligations in embedded Linux products.
- A long-term support agreement with patch timelines and response targets.
- Rules on AI-assisted code, since purely AI-generated material without enough human authorship may not be protected by copyright.
Whichever embedded software development company you hire, the contracts section of our software development guide covers statements of work, acceptance, and exit terms in more depth.
How to choose an embedded software development company
Choose an embedded software development company with shipped products on similar hardware, experience in your safety or regulatory domain, a working lab with HIL testing, secure update and provisioning experience, and a support model that matches your product life. Ask for sample evidence documents, meet the engineers, and confirm IP and key ownership in writing.
Selection criteria
- Platform fitExperience with your processor family, RTOS or Linux build, and radio technologies.
- Domain standardsPast work under IEC 62304, ISO 26262, DO-178C, or IEC 61508 as relevant.
- Security practiceSecure boot, signed OTA, SBOM generation, and vulnerability handling in production products.
- Lab and testHIL rigs, equipment, and automation that match your product.
- LongevityAbility to support the product for years, with documented knowledge transfer.
Questions to ask an embedded software development company
- Which products like ours have you shipped, and are they still supported?
- How do you handle a failed OTA update on a device in the field?
- What will you need from our hardware team, and when?
- How will you help us meet Cyber Resilience Act reporting duties?
- Which tools would need qualification for our safety level, and who pays for kits?
- Who owns the signing keys and build environment at the end of the project?
Red flags
- No hardware lab, or testing only on development kits.
- Firmware updates without signatures or rollback protection.
- Claims of "MISRA compliant" with no deviation records or analysis reports.
- Toolchain licenses or keys held only by the vendor.
- No plan for support after launch.
Embedded devices often feed plant and business systems; see our manufacturing software development guide for MES and IIoT, and our healthcare software development guide for medical device context. The general checklist in our software development company guide also applies.
Reference
Embedded software development company FAQs
What does an embedded software development company do?
It writes and maintains software that runs on dedicated hardware: microcontroller firmware, RTOS applications, embedded Linux builds, drivers, bootloaders, over-the-air update systems, and device interfaces. It also tests on real hardware and produces the evidence that safety and security standards require.
What is the difference between firmware and embedded software?
The terms overlap. Firmware usually means low-level software stored in a device's non-volatile memory that controls the hardware directly. Embedded software is the broader term and can include firmware, operating systems, middleware, and applications running on a dedicated device.
Does the EU Cyber Resilience Act apply to US companies?
Yes, if they place products with digital elements on the EU market. The Act entered into force Dec 10, 2024, reporting obligations apply from Sept 11, 2026, and the main obligations apply from Dec 11, 2027. Confirm scope and product classification with counsel.
Which safety standard applies to our device?
It depends on the market. IEC 62304 covers medical device software, ISO 26262 covers road vehicles, DO-178C covers airborne systems, and IEC 61508 covers general electrical and programmable safety systems. Many sector standards build on IEC 61508.
Do we need MISRA compliance?
Not always, but it is common in automotive, medical, industrial, and aerospace projects, and safety assessors often expect it. MISRA C:2025 and MISRA C++:2023 are the current editions. Compliance means documented rule checks and justified deviations, not only a clean static analysis run.
Who should own the firmware signing keys?
You should. Signing keys control which software your devices will accept, so they belong under your control, ideally in a hardware security module, with documented procedures. A vendor can operate signing on your behalf, but ownership and the ability to revoke access should stay with you.
How long should embedded software be supported?
For as long as the product is in use and sold, which is often many years. Plan for security patches, component obsolescence, and regulatory reporting over that period, and define support duration and patch timelines in a long-term support agreement.
Sources and further reading
Standards, regulations, and guidance referenced in this guide come from the following primary sources.
- IEC, IEC 62304:2006 Medical device software: Software life cycle processes
- IEC, IEC 61508-1:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems
- ISO, ISO 26262-1:2018 Road vehicles: Functional safety, Part 1: Vocabulary
- ISO, ISO/SAE 21434:2021 Road vehicles: Cybersecurity engineering
- RTCA, DO-178C Software Considerations in Airborne Systems and Equipment Certification
- MISRA, MISRA C and MISRA C++ guidelines
- European Commission, Cyber Resilience Act
- UNECE, UN Regulation No. 155: Cyber security and cyber security management system
- NIST, IR 8259 Rev. 1: Foundational Cybersecurity Activities for IoT Product Manufacturers
- U.S. Food and Drug Administration, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions
- CISA, Software Bill of Materials (SBOM)
- NIST, SP 800-218: Secure Software Development Framework (SSDF) Version 1.1
- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability
About this guide
This guide is published by Crecso as an independent educational resource and is part of our software development guide. It names platforms, standards, and regulations as examples only, is not affiliated with any software vendor, chip maker, or development firm, and does not describe services offered by Crecso. It is not legal, regulatory, or medical advice.
Last reviewed on . If you spot something that has changed, please let us know through our contact page.