← Back to the learning library
Before you begin: Read TFA-105 on bootloaders and secure updates and TFA-107 on cybersecurity. Sketch the memory regions and boot sequence of a device you know.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Publication basis: NIST SP 800-193, Platform Firmware Resiliency Guidelines, May 2018. The publication addresses platform firmware. The MCU examples here adapt its protection, detection and recovery concepts; they do not establish conformance for every embedded product.
Learning objectives
By the end of this module, you should be able to:
- Identify the trust boundaries that support firmware protection, detection and recovery.
- Separate image authentication from compatibility and successful operation.
- Analyse interrupted updates, rollback controls and recovery dependencies.
- Define evidence for a device-specific resilience claim.
Lesson 1
1. Start with the platform and the threat
NIST SP 800-193 organises platform firmware resilience around protection against unauthorised change, detection of corruption and recovery to an authentic state. Applying these concepts begins with a clear platform boundary. Identify the firmware, hardware and critical configuration needed to boot and operate the device.
For a fictional industrial recorder, include the first executable boot code, application image, update metadata, security settings and any external storage that influences execution. Consider an attacker controlling the host connection, a damaged flash region and a failed power supply during installation. Different threats require different evidence. A signature check addresses image authority; it does not demonstrate that an interrupted metadata write leaves the device recoverable.
Lesson 2
2. Establish a trust anchor that the protected code cannot replace
Draw the chain from the initial trusted execution point to the application. For each step, identify what is verified, which key or policy authorises it, and what prevents an untrusted later stage from changing that decision. Record the relevant hardware configuration and manufacturing provisions. “Secure boot enabled” is too vague if the accepted keys or debug settings are unknown.
For the recorder, examine whether application code can overwrite the verifier, its trust data or recovery entry conditions. Also inspect service paths and alternate boot sources. Protecting the normal boot route is insufficient if an accessible service command can install arbitrary executable code. The protection mechanism must match the actual hardware capabilities and threat assumptions.
Lesson 3
3. Validate a complete update decision
Before accepting an image, evaluate the properties required by the product: authenticity, structural validity, permitted target, version policy and compatibility with retained data. Bind security-relevant metadata to the authenticated package. Treat parsers and length calculations as exposed code even when signatures are used; malformed data can arrive before authentication succeeds.
A correctly signed image can still target the wrong board or contain a software defect. Separate the authority to install from the decision that the product is fit to return to service. In the recorder, a candidate image remains provisional until defined startup checks succeed. Those checks cover critical storage and acquisition functions, not merely arrival at the application entry point.
Lesson 4
4. Design interruption handling as a state machine
List the durable states of installation and the permitted transitions between them. Define which image and metadata are authoritative after a reset at every write boundary. Include flash erase granularity and interrupted-write behaviour from the device documentation. Two image slots do not automatically make an update atomic.
| Illustrative state | Reset behaviour to define | Evidence to retain |
|---|---|---|
| Downloading candidate | Continue or discard without harming the accepted image | Partial-download and invalid-length tests |
| Candidate authenticated | Do not assume it has passed operational checks | Image identity and verification outcome |
| Trial boot pending | Bound retries and select a controlled fallback | Reset tests around trial-state changes |
| Candidate confirmed | Commit image and compatible persistent state coherently | Confirmation and migration interruption tests |
This is an example design discussion, not a prescribed NIST state model. The real transitions depend on the memory layout and update mechanism.
Lesson 5
5. Detect failure without trusting the failed component
Decide which failures are detected before execution and which require runtime observation. Boot-time integrity verification cannot discover every behaviour defect in an authentic release. A health mechanism should demonstrate the progress relevant to the product, with a failure response that remains available when the application is unresponsive.
For the recorder, a periodic heartbeat from a communications task does not prove that acquisition and storage are functioning. Define health criteria and the authority that confirms a trial image. Protect the health state against accidental or malicious misuse where required by the threat model. Avoid recovery loops that repeatedly start the same failing image without a bounded policy or a useful service diagnosis.
Lesson 6
6. Reconcile recovery, rollback protection and retained data
Recovery needs an authentic usable image and a mechanism capable of selecting or restoring it. Identify dependencies on network availability, external services, credentials and writable metadata. A recovery image stored in the same writable region as the application may share the very failure being addressed.
Rollback prevention and operational fallback require a joint design. Advancing a protected version counter too early may prevent return to the accepted image after a failed trial. Advancing it too late may leave an unintended downgrade route. Define a transaction and compatibility policy appropriate to the platform. Include persistent data: an old image may be authentic but unable to interpret a schema already changed by the candidate. Test the combined image, metadata and data states.
Lesson 7
7. Verify the recovery claim on the supplied configuration
Build a test campaign around the update state machine and trust boundaries. Include unauthorised packages, wrong-target images, invalid metadata, interrupted erase or programming, repeated resets and failed trial health checks. State the observation method and how the resulting device state is assessed. Random power interruption is useful exploration, but it does not show that every critical transition was exercised.
Record bootloader and application identities, hardware revision, security provisioning and relevant flash characteristics. Define the expected availability and recovery outcome for each scenario. If physical access or invasive attacks are outside the design scope, state that boundary in the engineering argument. Evidence should establish the specific resilience claim rather than implying immunity to all forms of compromise.
Decision guide
Which part of the resilience argument is missing?
| Observation | Unanswered question | Engineering response |
|---|---|---|
| Only signed images execute | Can an authorised image fail operationally? | Add defined trial health and recovery decisions |
| A second image slot exists | Does a reset leave selection metadata coherent? | Analyse and test each durable transition |
| Old versions are blocked | Can a failed trial still recover safely? | Coordinate version policy and confirmation |
| A recovery command works in the lab | Does it depend on the failed application or network? | Inspect dependencies and test adverse conditions |
Worked example
Worked example — a signed update that breaks fallback
A recorder installs a signed candidate, updates its minimum accepted version and migrates stored configuration. The candidate then fails to initialise acquisition. The old image is still present but is rejected by the version policy and cannot read the migrated configuration.
The team models image selection, version policy and data migration as one recovery problem. It defines provisional operation and a compatible migration strategy, then specifies when confirmation makes the new state authoritative. The solution is checked against the actual hardware counter and flash constraints; a software flag is not assumed to reverse an irreversible operation.
Release evidence now covers failed startup and interruption around confirmation and migration. The claim identifies which recovery paths remain available after each irreversible transition, including any deliberate limit on returning to an older version.
Engineering evidence
What should the work produce?
Boot and recovery trust map
Identifies trusted code, key material, writable regions and alternate entry paths.
Update transition specification
Defines authoritative state and reset behaviour at each durable step.
Compatibility and rollback policy
Connects version acceptance, trial confirmation and persistent-data handling.
Resilience verification record
Connects fault injection and invalid-input scenarios to observed recovery outcomes.
Common failure patterns
What goes wrong?
- Treating two image slots as proof of recoverability.
- Assuming authentication demonstrates operational correctness.
- Committing an irreversible version change before evaluating its recovery consequences.
- Depending on the failed application to authorise or perform its own recovery.
Applied exercise · approximately 25 minutes
Assess the claim “power-fail safe update”
A device uses two image slots and verifies signatures. Its team has successfully interrupted five downloads. The same team claims that any power loss during installation is recoverable, although image selection is stored in one rewritable flash record.
- Explain why the existing tests do not establish the claim.
- Identify the state transitions and hardware information needed next.
- Propose an acceptance criterion for a bounded recovery claim.
Review a suggested approach
The tests exercise interrupted transfer, but provide no evidence about selection-record erase, programming, trial boot or confirmation. Obtain the flash interruption behaviour, record format and boot selection algorithm. Identify the state after each possible incomplete update of the record and whether the bootloader can interpret it without trusting corrupted fields.
Define and test transitions with controlled interruption and relevant invalid metadata. An example product-specific criterion is that each tested interruption at a specified installation boundary leads to either the previously accepted image or a verified candidate under the documented trial policy, with no unauthorised execution. Add data compatibility and recovery time criteria if the product requires them. Limit the claim to the analysed mechanism and supported hardware rather than extrapolating five successful tests to every power-loss scenario.
Completion criteria
- Transfer tests are distinguished from installation-state evidence.
- Metadata, hardware behaviour and boot decisions are considered together.
- The acceptance claim has explicit scope and observable outcomes.
This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.
Practical check
Questions for your next design review
- Can untrusted code alter the verifier, trust data or recovery policy?
- Does every interrupted transition have a defined next boot state?
- Are version policy and data migration compatible with the promised fallback?
- Were the relevant security settings and hardware configuration recorded in testing?
A resilient firmware update preserves a justified path to authentic operation across failures in the image, installation process and retained state.
References and further reading
- NIST SP 800-193 — Platform Firmware Resiliency Guidelines
- MCUboot — Design documentation, a practical implementation reference
- TFA-105 — Bootloaders & Secure Updates
- TFA-309 — Secure Development Using NIST SSDF
Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.