Secure embedded development
Protect the product from first boot to final retirement: define trust, minimise attack paths, verify controls and retain the ability to update and recover safely.
After this module, you should be able to:
- Model assets, threats and trust boundaries
- Select controls appropriate to embedded constraints
- Design secure boot, update and recovery paths
- Maintain security evidence and vulnerability response
Study guide · Updated · About 9 minutes reading + 20–30 minutes practice
Before you start: Read TEA-101 and TEA-104. Understand product modes, communications and software update concepts.
Security protects dependable behaviour against intentional misuse.
Embedded security begins with the system: what must be protected, from whom, through which access paths and with what consequence if protection fails. Safety and security analyses should connect where a malicious action can create hazardous physical behaviour.
Establish trust before granting authority.
| Control area | Purpose | Embedded design questions |
|---|---|---|
| Identity and roots of trust | Anchor decisions in protected device, signer or service identities. | Where are keys created, stored, used, rotated, revoked and destroyed? |
| Secure boot | Execute only authorised code from a known chain of trust. | Which stages verify the next, and what happens when verification fails? |
| Least privilege | Limit the authority and impact of each component. | Can privilege levels, an MPU, separated tasks or dedicated controllers contain compromise? |
| Interface protection | Validate origin, permission, integrity, freshness and structure. | Are commands authenticated, authorised, bounded and safe in the current state? |
| Secret protection | Prevent extraction or unauthorised use of credentials. | Can secrets be unique per device and kept out of source, logs and test images? |
| Update and recovery | Correct vulnerabilities without creating an easier attack path. | How are packages signed, versions controlled, failures recovered and rollback governed? |
| Debug and service | Retain necessary support while controlling powerful access. | Who may unlock access, how is it audited and how is production state restored? |
Layer controls so that one defect does not grant complete authority. A signed image protects authenticity, but memory protection, input validation, safe command rules and independent physical protections still limit what vulnerable code can do.
Build security into every engineering decision.
- Prepare the organisation. Define roles, secure environments, protected repositories, approved tools and supplier expectations.
- Model threats early. Identify assets, entry points, trust boundaries, abuse cases and safety consequences.
- Specify and design controls. Make security behaviour, failure handling and verification criteria explicit.
- Develop defensively. Apply coding rules, reviews, static analysis, dependency control and protected build practices.
- Verify adversarially. Challenge malformed input, privilege, replay, downgrade, resource exhaustion and fault recovery.
- Release a known product. Retain binary identity, provenance, SBOM, configuration, signing and approval evidence.
- Monitor and respond. Receive vulnerability reports, assess exploitability and impact, communicate and deliver controlled updates.
Worked example: resilient firmware update
A service tool installs firmware while power can be removed at any point. The design must prevent both unauthorised code and an unrecoverable device.
The bootloader remains separately protected. Anti-rollback rules prevent installation of a vulnerable release, but an authorised recovery image remains available. A failed trial boot returns to a known-good version, records the reason and never bypasses signature verification.
Maintain a defensible security case as the product changes.
Assets, actors, interfaces, trust boundaries, threats, misuse cases and risk decisions.
Testable prevention, detection, response, recovery, update and logging behaviour.
Implemented mechanisms, assumptions, residual exposure and verification references.
Software components, versions, suppliers, build identity and known-vulnerability assessment.
Analysis, scanning, code review, penetration, fuzz, update and recovery results.
Intake, triage, exploitability, impact, remediation, disclosure and release decisions.
Common failure patterns
One extracted credential compromises every manufactured device and is difficult to rotate.
Authenticity is checked, but interruption, downgrade, compatibility and recovery are not controlled.
Development access remains available in production without strong authorisation or audit.
Components are listed, but nobody monitors vulnerabilities or decides whether the product is affected.
Model authority across the complete product
List assets that influence behaviour: executable images, configuration, calibration, commands, results, credentials and availability of essential functions. Trace who can read or change each asset during manufacture, installation, use, service and retirement. A local service port is still a trust boundary.
Separate identity from permission. Authenticating a technician does not mean every command is permitted in every operating state. A service action may require a stopped mechanism, an authorised role and a bounded parameter range. Validate these conditions at the component that owns the physical effect.
Consider attacks on resources as well as data. Valid but excessive traffic can consume CPU, queues, storage or battery. Bound parsing and cryptographic work, and preserve essential control under load. Test the interaction between security controls and safety responses, including lockout and loss of connectivity.
Design update integrity and recoverability together
An update package needs a trustworthy origin and integrity check, but a valid signature alone does not establish hardware compatibility or safe installation. Define image identity, permitted target, version policy and required configuration migration. Do not enable the new application until its installation state is coherent.
Plan power interruption at each durable step. The device should recover to an approved image or a controlled service state through a mechanism whose trust is preserved. Anti-rollback policy must coexist with a legitimate recovery route; a broken new image should not force acceptance of an arbitrary old vulnerable image.
Control signing and device-identity keys separately. Their compromise has different consequences. Define access, rotation, revocation and the procedure for devices that remain offline. NIST SP 800-193 provides a useful protect, detect and recover perspective for platform firmware; applicability to a specific embedded architecture needs explicit assessment.
Close the loop from a vulnerability to field status
A component inventory should identify the version and build configuration actually shipped. When a vulnerability is reported, establish whether affected functionality is present, reachable and able to violate a product security property. A package-name match is a starting point, not the complete assessment.
Track remediation through verification, release, installation and remaining exposure. Offline devices, incompatible hardware and end-of-support products need a defined disposition. Learn from root cause so the next release improves the development process as well as removing the immediate defect.
| Asset or boundary | Engineering question |
|---|---|
| Calibration | Can an unauthorised change alter a physical decision? |
| Update | Who can authorise an image and how is interruption recovered? |
| Service port | Which operations remain possible without normal user access? |
| Device identity | Can one compromised credential affect the whole fleet? |
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Review an update that passes signature verification
A signed update is compatible with board revision C but can be installed on revision B. Power loss during configuration migration leaves the application unable to start.
- Explain why signature verification does not resolve either defect.
- Specify compatibility checks and a recoverable migration sequence.
- Define negative tests and the evidence needed before release.
Show the worked answer
The signature establishes that a package was authorised by a trusted signer and was not altered under the chosen scheme. It does not prove suitability for this board or atomic migration. Bind the approved hardware and prerequisite versions to authenticated package metadata and check them before any destructive action.
Design migration so interruption cannot leave the only usable configuration irrecoverable. Depending on the architecture, use versioned records, validated staging and a durable commit indication, with a trusted recovery path. Test wrong hardware, altered metadata, obsolete images and power cuts across migration stages. Verify physical output defaults during recovery and retain the final software, configuration and board compatibility evidence.
Review criteria
- Authenticity, compatibility and installation safety are distinct checks.
- Recovery preserves trust and valid configuration.
- Tests include interrupted and rejected updates.
Check your understanding
Does a signed image prove it contains no vulnerabilities?
No. Signing supports provenance and integrity. Security assurance also needs design, implementation, verification and lifecycle response.
Why assess fleet-wide effects?
Shared keys, common remote services or identical weaknesses can make one compromise affect many devices, changing impact and response priorities.
Further learning
- NIST SP 800-218: Secure Software Development FrameworkSecure development practices that can be integrated into different lifecycle models.
- NIST SP 800-193: Platform Firmware Resiliency GuidelinesProtection, detection and recovery for platform firmware and critical data.
- CISA Secure by DesignPrinciples for making security a core product requirement and manufacturer responsibility.
Trust must be established, limited and renewable.
Secure embedded development joins threat-informed architecture, controlled authority, resilient updates and active vulnerability management across the entire product life.