01 — Start With the Lifecycle
Don't Start With the OTA Server
First ask: How long will this product be deployed? Can it be physically serviced? How expensive is a failed update? Does it have reliable internet? Can users interrupt power? Does it contain safety-critical behavior? Can the hardware revision change? Update Architecture Begins With Product Lifecycle.
02 — Firmware Is a Product Configuration
A finished electronic product can be represented as:
PCB Revision
BOM Variant
Firmware
Bootloader
Configuration
Calibration
Security Credentials
Changing Firmware Changes the Product.
03 — Bootloader
The bootloader executes before the main application and determines: What Software Is Allowed to Run Next.
Depending on platform it may perform:
image discovery
image validation
selection
update
recovery
handoff.
The Bootloader Is the Software Gatekeeper of the Product.
04 — Bootloader Is More Than Startup Code
Startup code prepares:
for execution.
A production bootloader may additionally manage: Trust, Version, Image Slots, Recovery, Updates.
Startup Gets the Processor Running.
Bootloader Decides What It Should Run.
05 — Boot Chain
A typical chain might conceptually be: Hardware Reset → ROM Boot → Root-of-Trust Verification → First-Stage Bootloader → Second-Stage Bootloader where applicable → Application / Operating System
Every Stage Inherits Trust From the Stage Before It.
06 — Boot ROM
Many SoCs contain immutable Boot ROM.
It may establish:
boot source
initial verification
hardware-security state
depending on silicon. The First Trusted Code Should Be Difficult to Replace.
07 — Root of Trust
A hardware or immutable software root can anchor: Which Signing Authority the Device Trusts.
This may involve:
protected key hashes
fuses
ROM state
secure storage
depending on platform. Secure Boot Requires a Starting Point That the Attacker Cannot Simply Rewrite.
08 — Chain of Trust
Conceptually: ROM trusts Bootloader → Bootloader trusts Application → Application trusts later software/configuration.
Trust Should Be Extended — Not Assumed.
09 — Secure Boot
Secure Boot answers: Is This Software Authorized to Execute?
It typically combines: Integrity, Authenticity.
10 — Integrity
Has the software changed from the expected artifact? A cryptographic digest can provide evidence of content integrity. One Changed Bit Changes the Digest.
11 — Authenticity
Integrity alone does not answer: Who created this firmware?
Digital signatures can establish that the image was approved by an authorized signing authority.
Hash Says "Unchanged."
Signature Says "Authorized."
12 — Hash ≠ Signature
A hash stored beside an image can potentially be replaced together with the image if no stronger trust mechanism protects it.
Integrity Metadata Must Be Authenticated Too.
13 — Signing Architecture
Conceptually: Firmware Build → Hash → Authorized Signing Process → Signed Image / Manifest → Device Verification
Release Trust Begins Before Firmware Reaches the Device.
14 — Private Signing Key
The signing private key is extremely sensitive.
Because: Whoever Controls the Authorized Signing Key May Be Able to Create Software the Device Trusts. Therefore signing-key protection is a major product-security responsibility.
15 — Public Verification Key
The device generally needs trusted information enabling signature verification. Verification Authority Must Be Anchored in the Device.
16 — Signing Is Not Encryption
A signed firmware image may still be readable.
Authenticity ≠ Confidentiality.
RFC 9019 specifically distinguishes these properties: authentication and integrity protection are required elements of its architecture, while firmware confidentiality is optional.
17 — Firmware Encryption
Encryption may be useful where:
IP confidentiality
transport exposure
matters.
But: An Encrypted Malicious Image Is Still Malicious. Authentication remains fundamental.
18 — Encrypt-Only Is Not Secure Update
A device must know: Who Authorized the Image.
Not merely: Can I decrypt it?
19 — Manifest
A firmware image alone cannot answer every update question.
A manifest can describe:
The Manifest Describes the Meaning of the Update.
20 — IETF SUIT Architecture
RFC 9019 defines a transport-independent architecture for IoT firmware update, while RFC 9124 defines the information model that a secure update manifest needs to represent.
Delivery Method and Update Authorization Should Be Separate Concepts.
21 — Current SUIT Direction
As of August 2026, IETF SUIT work continues beyond RFC 9019/9124. The CBOR-based manifest serialization is in the RFC publication process, while update-management extensions remain active Standards-Track work rather than a finalized RFC.
For365PCB: Do Not Market Draft Work as a Final Standard.
But understand where secure-update architecture is heading.
22 — Manifest Version
The updater itself may evolve.
Therefore the device should know: Which Manifest Format It Is Parsing.
23 — Firmware Version
Software version answers: Which product release is this?
But security may need something stronger than ordinary semantic versioning.
24 — Security Counter
Trusted Firmware-M documents an anti-rollback architecture using an independent security counter rather than relying only on normal image version numbers.
Product Version and Security Version Are Not Necessarily the Same Thing.
25 — Why Separate Them?
Firmware: 3.5 may contain a critical security fix.
Later: 4.0 exists.
You may want to allow: 4.0 → 3.5 for functional recovery,
but never: 3.5 → 3.4, because 3.4 contains a known vulnerability.
Security History Needs Its Own Policy.
26 — Anti-Rollback
Anti-rollback prevents an attacker from installing an: Older but Correctly Signed Vulnerable Firmware.
27 — Signed Does Not Mean Safe Forever
An old firmware may have been genuinely signed when originally released.
Years later it may contain: Known Vulnerabilities.
Signature Authenticity Does Not Prove Current Security Acceptability.
28 — Monotonic Sequence
RFC 9124 includes a monotonically increasing sequence value specifically to support rollback protection in firmware-manifest architecture.
Time Moves Forward. Security State Should Be Able to Move Forward Too.
29 — Trusted Counter Storage
An anti-rollback counter must itself resist unauthorized rollback.
Otherwise: The Attacker Rolls Back the Counter First.
Implementation depends strongly on processor/security architecture.
30 — Independent Components
A sophisticated system can contain independently updateable: Bootloader, Secure Firmware, Application, Radio Firmware, FPGA, AI Model.
Each Software Component May Need Its Own Version and Security Policy.
31 — Multi-Image Update
Updating multiple images creates dependencies.
Example: Application v5
requires: Radio Firmware ≥ v3.
Software Compatibility Becomes a Dependency Graph.
32 — Dependency Manifest
The update system should know: Which components must exist before this one can run?
Update Order Is Architecture.
33 — Hardware Compatibility
Firmware intended for: Board Rev C
may be electrically wrong for: Rev A.
Securely Signed Wrong Firmware Is Still Wrong Firmware.
34 — Hardware Identifier
Update acceptance can include:
model
board revision
processor
peripheral variant
where required.
Authenticate Applicability — Not Only Authenticity
35 — Component Identifier
RFC 9124 includes the idea of a component identifier so an update manifest can indicate which software/storage component a payload targets.
The Device Must Know What Is Being Updated.
36 — Product Variant Compatibility
For example: Model Standard
and: Model Pro
may use the same MCU but different hardware. Shared Processor Does Not Mean Shared Firmware.
37 — Fail Closed
If image compatibility cannot be established: Don't Guess.
Reject or enter a controlled recovery path.
38 — Firmware Slot Architecture
One major architectural decision: How Many Firmware Copies Can the Device Store?
39 — Single-Slot Architecture
Simplest: Current Image is overwritten.
Advantages:
Disadvantage: Recovery becomes much harder if update is interrupted.
40 — A/B Architecture
Maintain: Slot A
and: Slot B.
One contains: Current Known-Good.
The other can receive: Candidate Update.
41 — Why A/B Is Powerful
Running A. Download B. Verify B. Boot B.
If healthy: Commit B.
If unhealthy: Return to A.
42 — Known-Good Image
This principle is foundational: Never Destroy the Last Known-Good Software Before the Replacement Has Proven Itself.
43 — Storage Cost
A/B consumes more flash/storage.
Reliability Costs Memory.
The correct trade depends on product consequence.
44 — Swap Architecture
Instead of executing directly from separate banks, some bootloaders swap images between:
regions. Update Layout Depends on Flash Architecture.
45 — MCUboot
MCUboot provides one mature reference architecture for secure boot/update on 32-bit microcontroller systems.
Its current design supports multiple image-management strategies and cryptographic validation.
Framework Choice Should Follow the Processor and Product Requirements.
46 — MCUboot Test Upgrade
One especially useful mechanism is: Test Boot.
MCUboot can install/select a new image temporarily.
The application then has the opportunity to prove: I Am Healthy.
47 — Image Confirmation
If the candidate firmware completes its required self-checks: Mark Image Confirmed.
Then it becomes permanent.
MCUboot explicitly supports this test → confirm flow.
48 — Automatic Revert
If the test image fails to confirm itself: MCUboot can return to the prior image on a later boot.
Failure to Prove Health Becomes a Rollback Trigger.
49 — Trial Boot
This concept should exist independent of any particular bootloader implementation: Install → Trial → Validate → Commit
or: Revert. Deployment Should Include a Probation Period.
50 — Boot Success Is Not Product Success
The processor reaches: main().
That does not prove:
sensor works
network works
configuration migrates
actuator works.
Boot Health Must Be Defined at Product Level.
51 — Health Confirmation
The new application may need to demonstrate selected: Critical Services Running, Configuration Valid, Memory Valid, Watchdog Healthy, Required Peripheral Ready, before commit.
"Healthy" Should Be a Defined Requirement.
52 — Don't Confirm Too Early
If firmware confirms immediately at startup:
then crashes 3 seconds later: Recovery Was Defeated by Premature Confirmation.
53 — Confirmation Window
The product should define a reasonable validation period or event set. Confirmation Timing Is Product-Specific.
54 — Boot Loop
Bad firmware may: Boot → Crash → Reset → Boot → Crash.
Endless Reset Is Not Recovery.
55 — Boot Attempt Counter
A boot architecture may count repeated failed attempts.
After threshold: Revert / Recovery.
56 — Reset Cause
The boot system should understand, where supported: Watchdog, Software Reset, Brownout, Power-On.
Why the Device Rebooted Changes Update Diagnosis.
57 — Watchdog During Trial
A watchdog reset shortly after new firmware installation may be strong health evidence.
Recovery Architecture and Watchdog Architecture Should Work Together.
58 — Safe State During Update
Before replacing software controlling physical hardware: What State Is the Product In?
Outputs may need controlled behavior depending on product.
59 — Updating While Operating
For some products: update can happen while normal operation continues.
For others: Update Requires Maintenance Mode.
60 — Maintenance Window
Industrial products may allow installation only during:
Update Timing Is an Operational Requirement.
61 — Download ≠ Install
Separate: Acquire Image
from: Activate Image.
Download at a Convenient Time. Install at a Safe Time.
62 — Background Download
A device may download while still running old firmware. Network Activity and Product Behavior Can Be Decoupled.
63 — Download Resume
If connection dies at: 87%
should the transfer restart from zero?
Not necessarily. Transfer Resumability Can Reduce Time and Energy.
64 — Chunked Transfer
Large payloads can be divided into controlled blocks.
Each block can be tracked according to architecture.
Network Failure Should Not Necessarily Destroy Previous Progress.
65 — Transport Integrity vs Artifact Integrity
TLS protects: The Connection.
Firmware signature protects: The Artifact.
Both solve different problems.
66 — CDN / Untrusted Distribution
An important secure-update property is: The Distribution Server Does Not Necessarily Need to Be Trusted With Firmware Authorization.
If the artifact itself is authenticated by the device, distribution and authorization can remain separate.
This transport-independent principle is central to the SUIT architecture.
67 — Offline Update
Not every product has cloud connectivity. Updates may arrive through:
local service channel
removable media
nearby gateway
depending on product. Secure Update Should Not Depend Exclusively on Internet Transport.
68 — Same Trust, Different Transport
Whether update arrives via: Network
or: Local Interface, the authorization policy should remain consistent. Transport Does Not Define Trust.
69 — Firmware Payload
RFC 9124 distinguishes a delivered payload from the final installed firmware because payloads can be:
compressed
encrypted
differential.
What Is Downloaded Is Not Always What Ultimately Executes.
70 — Compression
Firmware can be compressed to reduce: transfer size. But decompression requires:
RAM
compute
temporary storage.
Smaller Network Payload Can Require More Device Resources.
71 — Delta Update
A delta carries only differences between: Old
and: New, software.
Potential advantage: Less Network Traffic.
72 — Delta Update Complexity
Delta requires exact understanding of:
source version
transformation
final verification.
Smaller Payload Means More Dependency on Existing State.
73 — Final Image Must Still Be Verified
After applying delta: Verify the Resulting Complete Image.
Not merely: delta file downloaded correctly.
74 — Base Image Dependency
Delta intended for: v1.4
cannot automatically be applied to: v1.3.
Differential Update Has a Source-State Requirement.
75 — Full-Image Fallback
A mature architecture may retain a full-image path if delta update cannot apply. Optimization Should Not Remove Recovery Options.
76 — Flash Geometry
MCU update architecture is heavily influenced by:
erase size
· write size
· bank structure
· XIP constraints.
Flash Physics Shapes Bootloader Architecture.
77 — Erase Unit
Flash may erase in relatively large sectors.
Updating One Byte Can Require Erasing Much More Than One Byte.
78 — Write Alignment
Program operations may have alignment rules. Update Algorithm Must Match the Memory Device.
79 — Power Loss During Erase
Power disappearing during modification creates one of the most important failure cases. Update Must Be Designed Around Interruption.
80 — Interrupted Swap
MCUboot's swap architecture stores state so interrupted image swaps can resume rather than assuming uninterrupted power. Power Failure Should Be an Expected Event in Update Design.
81 — Atomicity
The product should move between: Known State A
and: Known State B
without becoming: Unrecoverable State 47%.
82 — Transactional Thinking
A robust firmware update behaves like a transaction: Prepare → Verify → Activate → Confirm → Commit.
Don't Commit Before Success Is Known.
83 — Persistent Update State
If reset occurs:
bootloader should know: What phase were we in?
Recovery Requires Durable State.
84 — Update Journal
Selected architectures preserve update-progress metadata. Update State Should Survive the Event It Is Designed to Recover From.
85 — Metadata Corruption
But update metadata can itself become corrupt. Recovery Metadata Needs Integrity Too.
86 — Redundant Metadata
Where reliability requirements justify it, critical update state can use redundancy or validation. Recovery Infrastructure Also Needs Recovery Thinking.
87 — Brownout
Marginal power during flash writes can be especially dangerous. Power Integrity Is Firmware Update Integrity.
88 — Power Preconditions
Battery devices may require: Sufficient Energy before installation begins.
89 — Battery State
A device at: 2% battery
may have enough energy to download but not safely complete installation. Download Readiness ≠ Installation Readiness. 90 — External Power Requirement
Some products may update only when:
charging
externally powered.
Update Policy Can Protect Against Energy Failure.
91 — Storage Precondition
Before downloading: Is enough storage available?
Do not discover shortage at 99%.
92 — RAM Precondition
Compressed/encrypted image processing may require temporary RAM. Update Resource Requirements Should Be Budgeted.
93 — Temperature Precondition
Storage programming and system stability can depend on the product's qualified operating conditions. Installation Should Respect the Product's Valid Operating Envelope.
94 — Product Activity Precondition
Don't update while:
critical operation
calibration
production cycle
requires continuity. Update Is a Product State Transition.
95 — OTA
OTA simply means: Update Delivery Occurs Remotely.
It does not automatically mean: Secure Update.
96 — OTA Control Plane
The server/fleet platform decides:
who gets update
when
which version.
Fleet Selection Is Part of Update Safety.
97 — OTA Data Plane
The image must actually reach the device.
Orchestration and Delivery Are Different Layers.
98 — Signed Release Artifact
Cloud deployment should reference: Controlled Release Artifacts.
Not developer folders containing: final_v7_really_final.bin.
99 — Release Manifest
A release should identify: Firmware Version, Security Counter, Supported Hardware, Build ID, Image Hash, Signing State, Dependencies.
Release Metadata Is Product Configuration Evidence.
100 — Build ID
Two builds both called: 2.1.0
should not be indistinguishable if binary content differs. Every Shipping Binary Should Be Uniquely Identifiable.
101 — Firmware Hash
Hash identifies exact artifact. Version Name Describes Release. Hash Describes Bytes.
102 — Reproducible Release
The engineering organization should be able to determine: Which source/configuration created this image?
Firmware Should Be Traceable Backward to Its Build Inputs.
103 — Version Control
Release should connect to:
source revision
toolchain
configuration.
Binary Without Source Identity Is Lifecycle Risk.
104 — Toolchain
Compiler changes can change: Binary.
Therefore: Toolchain Version Is Product Configuration.
105 — Build Environment
Automated, controlled build infrastructure reduces reliance on:
one engineer's laptop.
Release Engineering Is Security Engineering.
106 — Signing Environment
Ideally, software build and privileged signing authorization are controlled deliberately. Building Code and Authorizing Code Are Different Responsibilities.
107 — Release Approval
Not every successful CI build should automatically become: Authorized Field Firmware.
108 — Development Signing Key
Development units may trust a separate development key. Development Trust and Production Trust Should Be Intentionally Separated.
109 — Production Key
Production devices should not casually trust developer/debug credentials. Debug Convenience Must Not Define Product Trust.
110 — Key Separation
Potentially separate authorization domains for: Production, Recovery, Manufacturing, depending on threat model.
One Key Should Not Necessarily Control Every Privileged Operation.
111 — Key Rotation
Signing keys may eventually need replacement. Secure Boot Architecture Should Consider Trust Evolution Before the First Key Expires or Is Compromised.
112 — New Root Trust
A device may need a controlled method to trust: Future Authorized Keys.
113 — Trust Transition
Changing signing authority must itself be authorized by an already trusted authority. Trust Cannot Appear From Nowhere.
114 — Key Revocation
If an old signing key becomes compromised: Can Devices Stop Trusting It?
This is an architectural requirement, not merely a PKI problem.
115 — Multiple Signing Authorities
Large ecosystems may separate: Firmware Author
from: Device Operator.
RFC 9019 explicitly discusses architectures in which authorization can involve different actors rather than assuming one universal authority. Who Can Write Firmware and Who Can Authorize Deployment May Be Different Organizations.
116 — Separation of Duties
Engineering team creates software. Security/release process authorizes software. Operations deploys software. Different Responsibilities Can Reduce One-Account Catastrophe.
117 — Recovery Key
Some systems may include a separately controlled recovery authority.
Recovery Authority Should Be Powerful Enough to Recover — and Protected Accordingly.
118 — Recovery Image
A device may maintain minimal trusted software capable of:
Recovery Environment Should Be Smaller and More Stable Than the Main Application Where Practical.
119 — Recovery Partition
On larger systems: Main OS
and: Recovery Environment can be separated.
Repair the System From Outside the Broken System.
120 — Recovery Boot Trigger
Recovery can be entered due to:
repeated failures
explicit service request
invalid main image
depending on product. Recovery Entry Conditions Should Be Controlled.
121 — Physical Recovery
Some products retain a factory/service recovery path. Remote Recovery Is Valuable. Physical Recovery Can Be the Last Safety Net.
122 — Don't Depend on Broken Firmware to Repair Itself
If the main application is corrupted: The Update Mechanism Needed to Repair It Should Not Depend Entirely on That Application Remaining Healthy.
123 — Immutable Recovery
High-consequence products may benefit from a strongly protected minimal recovery component. Keep the Rescue Path Outside the Failure Domain Where Possible.
124 — Recovery Authenticity
Recovery mode should not mean: security disabled. Emergency Recovery Must Still Authenticate Software.
125 — Factory Image
Manufacturing may program an initial:
Security Configuration.
Factory Programming Creates the Initial Trusted State.
126 — Secure Provisioning
Manufacturing may also establish:
device identity
trust anchors
counters
debug policy.
The Secure Update Lifecycle Begins on the Production Line.
127 — Blank Device Trust
Ask: How does a blank MCU become a production-trusted device?
Manufacturing Provisioning Needs a Defined State Transition.
128 — Provisioning State Machine
Conceptually: Blank → Manufacturing → Keys / Trust Anchors Installed → Production Locked → Released.
Manufacturing Security Should Be Explicit.
129 — Provisioning Verification
After programming: Verify That the Intended Trust State Actually Exists.
130 — Production Boot Test
A finished unit should boot using: Its Production Trust Configuration. Not an engineering bypass.
131 — Debug Interface
Interfaces such as: JTAG / SWD
are extraordinarily useful during development. Production may need:
restriction
authentication
locking
depending on threat model. Debug Port Is an Alternate Firmware-Control Path.
132 — Secure Boot + Open Debug
Secure boot may lose much of its value if unrestricted debug access can rewrite or inspect critical device state. Security Architecture Must Consider Every Privileged Path.
133 — Serviceability vs Security
Permanently disabling all debug may make field failure analysis difficult. Security and Serviceability Need a Deliberate Trade-Off.
134 — Authenticated Debug Direction
Some modern platforms support controlled debug authorization. Production Debug Does Not Have to Mean Production-Wide Open Access.
135 — Bootloader Update
Eventually: The Bootloader Itself May Need an Update.
This is more dangerous than updating an ordinary application.
136 — Why Bootloader Update Is High Risk
If main application breaks: bootloader can repair it.
If bootloader breaks: Who Repairs the Bootloader?
137 — Bootloader Trust Transition
Bootloader update can change:
signature algorithms
key policies
image format.
Updating the Verifier Changes the Trust System Itself.
138 — Bootloader Update Compatibility
New bootloader must understand:
existing application
future application
existing recovery state.
Boot Infrastructure Needs Backward / Forward Planning.
139 — Two-Stage Bootloader
Some systems isolate a minimal immutable or highly protected first stage from an updateable second stage. Keep the Smallest Root of Trust as Stable as Practical.
140 — Minimize Trusted Computing Base
Every line of highly privileged boot code increases: Code That Must Be Trusted. Smaller Trusted Code Is Easier to Review.
141 — Crypto Algorithm Selection
Use established cryptographic mechanisms appropriate to:
processor
ecosystem
regulatory requirements.
Don't Invent a Proprietary Signature Algorithm.
142 — Crypto Agility
Products with long lifetimes should consider: What happens if today's algorithm must be replaced?
143 — Algorithm Identifier
Manifest/image architecture may need to know which validation mechanism applies. Crypto Versioning Is Lifecycle Architecture.
144 — Signature Size
On constrained MCUs:
signature size
verification time
matter.
Security Has Resource Cost.
145 — Verification Time
Secure boot may add startup latency. Security Performance Should Be Budgeted — Not Removed Because It Is Measurable.
146 — Hardware Crypto
Suitable SoCs may accelerate:
hashing
signature verification.
Hardware Acceleration Can Reduce Security Cost.
147 — Security Peripheral Dependencies
If verification depends on hardware crypto:
clock
power
hardware initialization
must be trustworthy enough to use it. Secure Boot Is Still Hardware/Software Co-Design.
148 — Secure Storage
Trust anchors and security counters require suitable protection. A Trusted Counter Stored in Unprotected Ordinary Flash May Not Be Trusted Enough for Every Threat Model.
149 — Secure World
Platforms supporting isolated execution environments may perform selected boot/security services inside more privileged domains.
Put High-Value Security Decisions Behind Hardware Boundaries Where Appropriate.
150 — Secure vs Non-Secure Firmware
A TrustZone-style platform may have: Secure Firmware
and: Non-Secure Application. Updating One Can Affect Compatibility With the Other.
151 — Independent Secure Image
If Secure and Non-Secure images update separately: Version Dependencies Become Critical.
Trusted Firmware-M's anti-rollback design explicitly discusses independently updateable software needing independent security-counter policy.
152 — FPGA Firmware
Modern products may also update: FPGA bitstreams.
Firmware Update Is Not Limited to MCU Code.
153 — FPGA Authenticity
A malicious or incompatible FPGA image can completely change hardware behavior.
Programmable Logic Is Executable Product Configuration.
154 — Wireless Module Firmware
Wi-Fi/Bluetooth/cellular modules may carry independent firmware. One PCB Can Contain Several Update Lifecycles.
155 — Peripheral MCU
A large system can contain: Main CPU, BMS MCU, Motor MCU, Radio MCU.
Product Update May Become Distributed Update.
156 — Distributed Firmware Compatibility
Application v8 may expect: Motor MCU protocol v3.
Multi-Controller Products Need Compatibility Matrices.
157 — Coordinated Update
If several controllers need updates: Which One Goes First?
158 — Partial Update Failure
Suppose: Controller A updated
but: Controller B failed.
Is the Mixed Version Safe?
This must be defined before field deployment.
159 — Compatibility Window
One solution is designing components so consecutive versions can coexist temporarily. Upgrade Paths Need Intermediate Valid States.
160 — Two-Phase Product Update
Conceptually: Stage Compatible Components → Verify → Activate Coordinated Version.
Distributed Updates May Need Transaction Semantics Across Devices.
161 — Gateway-Orchestrated Update
A Linux gateway may manage several subordinate MCU updates. Update Authority Can Be Hierarchical.
162 — But Leaf Device Still Verifies
Gateway authorization should not necessarily replace device-level artifact authentication. Defense in Depth.
163 — OTA Fleet Campaign
For connected products, the device bootloader is only one end. Cloud side must coordinate:
targeting
rollout
monitoring.
Secure Device Update + Safe Fleet Deployment Are Different Problems.
164 — Canary Deployment
Start with: Internal / Small Cohort
before entire fleet. The First Validation Unit Should Not Be the Entire Customer Base.
165 — Staged Rollout
Example concept: 1% → 5% → 25% → 100%.
Exact strategy depends on fleet/product. Increase Exposure With Evidence.
166 — Rollout Health Metrics
Observe:
boot success
rollback
crash
connectivity
product-specific health.
OTA Progress Should Be Health-Gated.
167 — Automatic Campaign Pause
If failure rate exceeds allowed threshold: Stop. Do not keep shipping the same problem.
168 — Hardware Cohort
Deploy first to: Hardware Rev C
before Rev B if architecture differs. Fleet Metadata Is Update Safety Infrastructure.
169 — Geographic Cohort
Some products may stage by:
region
site
customer group.
Rollout Strategy Should Match Operational Risk.
170 — Update Scheduling
Avoid updating: all devices simultaneously
when availability matters. Fleet Availability Is Scheduling Architecture.
171 — Fleet Capacity
Millions of devices downloading simultaneously create:
load. OTA Is Distributed Systems Engineering.
172 — Download Backoff
Devices can avoid synchronized retry storms. Recovery Traffic Should Not Create a Second Outage.
173 — Firmware Availability Notification
Device may:
depending on architecture. Update Discovery and Update Transfer Are Different Phases.
174 — Device-Initiated Pull
Device requests artifact when ready. Device Can Retain Control of Installation Timing.
175 — Server-Orchestrated Update
Cloud tells selected device: update available / begin process. Remote Control Still Requires Local Validation.
176 — Status Reporting
Fleet operator needs to know: Pending, Downloading, Verified, Installing, Trial, Confirmed, Failed, Rolled Back.
Update State Should Be Observable.
177 — Current SUIT Work
The IETF SUIT working group is actively extending the ecosystem toward update-management controls and secure update-status reporting. As of mid-2026 those documents are still in the standards-development/publication process rather than completed final RFCs.
Secure Updating Is Becoming a Full Management Protocol — Not Just a Manifest Format.
178 — Failure Reason
"Update Failed" is not enough.
Possible causes:
Network
Storage
Signature
Compatibility
Anti-Rollback
Install
Boot
Health Check
Failure Classification Accelerates Field Diagnosis.
179 — Update Telemetry
Track:
elapsed time
retries
rollback
reason.
Update System Should Diagnose Itself.
180 — Audit Trail
For business-critical deployments: Who released which firmware to which devices when?
Remote Firmware Change Needs Accountability.
181 — Release Approval Audit
Record: artifact, authorization, deployment cohort.
Software Change History Is Product History.
182 — Security Incident Response
When a critical vulnerability is found: How Quickly Can the Fleet Reach a Patched State?
This is a real product capability.
183 — Update Coverage
A security patch released does nothing for: Devices That Never Receive It.
184 — Offline Device
A device may return after six months offline. It Still Needs a Secure Upgrade Path From Its Old Version.
185 — Upgrade Path Testing
Don't test only: v9 → v10.
Field fleet may contain: v4 → v10.
Lifecycle Creates Long Upgrade Paths.
186 — Sequential Migration
Sometimes device must pass through: v4 → v6 → v10
because storage/schema changes require intermediate migration. Update Graph May Not Be One Direct Edge.
187 — Configuration Migration
Firmware changes may alter persistent configuration format. Code Upgrade + Data Migration Must Be Coordinated.
188 — Transactional Configuration Migration
Do not destroy the only valid old configuration before new one is validated. The Known-Good Principle Applies to Data Too.
189 — Rollback + New Data
A difficult problem:
New firmware writes: New Database Format.
Then firmware rolls back.
Can old firmware still understand the data? Software Rollback and Data Rollback Are Different Problems.
190 — Forward-Compatible Data
Where appropriate, design data structures to survive adjacent software versions. Persistent Data Can Limit Rollback Freedom.
191 — Calibration
Firmware update should not accidentally erase:
Software Image and Unit-Specific Calibration Have Different Lifecycles.
192 — Device Identity
Likewise: Update Must Preserve Product Identity.
193 — Credentials
Firmware installation should not casually overwrite:
certificates
private identity.
Product Software Is Replaceable. Product Identity Is Usually Persistent.
194 — Protected Partitions
Architect storage according to lifecycle:
Boot
Application
Configuration
Calibration
Identity
Update Slot
Different Data Needs Different Protection.
195 — Factory Reset ≠ Firmware Update
A Firmware update should not automatically imply: Customer Data Reset.
Separate lifecycle operations.
196 — Recovery Reset
Sometimes recovery does require clearing corrupted state. Data Destruction Should Be an Explicit Recovery Policy.
197 — Secure Erase Direction
Decommissioning may require removal of selected credentials/data. End-of-Life Is Part of Security Lifecycle.
198 — Boot Time
Secure verification adds work.
Measure:
ROM
Bootloader
Hash
Signature
Application Start.
Secure Boot Should Meet Product Startup Requirement.
199 — Large Image Verification
Larger images take longer to hash. Image Size Affects Boot Architecture.
200 — Cached Verification?
Optimization should never undermine required trust. Performance Optimization Must Preserve Security Property.
201 — XIP
Execute-in-place platforms execute code directly from flash. Update Slot and Execution Address Architecture Matter.
202 — RAM Load
Other systems copy/load images before execution. Boot Strategy Changes Validation and memory requirements.
203 — Direct-XIP Revert
MCUboot's current design also supports a revert model for direct-XIP and RAM-load configurations, illustrating that trial/revert behavior is not limited to one swap topology.
Recovery Policy Can Be Independent of One Flash-Copy Algorithm.
204 — Image Trailer / State
MCUboot stores update-state metadata used to decide:
behavior and to resume interrupted operations. Bootloader Needs Persistent Knowledge of Previous Update Decisions.
205 — Image Header
Firmware metadata can contain:
and similar information depending on format. Binary Needs Context.
206 — Payload Digest
RFC 9124 requires payload digest information in its manifest information model. Verify the Artifact You Actually Received.
207 — Whole-Image Integrity
Verify the complete intended image region as appropriate to architecture. Unverified Tail Data Should Not Become Executable Surprise.
208 — Signature Failure
If signature fails: Do Not Execute.
But also preserve enough diagnostic state to understand:
corrupted transfer?
wrong signing authority?
wrong artifact?
209 — Version Failure
If anti-rollback policy rejects image: Report Policy Rejection Clearly.
Don't report generic: invalid image.
210 — Compatibility Failure
Wrong hardware revision should produce: Compatibility Rejection rather than boot-looping.
211 — Storage Failure
If flash write fails: Do Not Mark Update Successful.
212 — Verification Before Reboot
Where architecture permits: verify downloaded candidate before reboot. Reject Bad Image While Known-Good Application Is Still Running.
213 — Verification Again at Boot
Secure boot may verify again before execution. Download Validation and Execution Authorization Are Distinct Trust Checkpoints.
214 — Defense in Depth
Cloud verifies.
Device application verifies.
Bootloader verifies.
One Missed Check Should Not Automatically Become Arbitrary Code Execution.
215 — Bootloader Threat Model
Ask:
Can attacker modify flash?
Can attacker control network?
Can attacker access debug?
Can attacker physically access product?
Secure Update Should Match the Actual Threat Model.
216 — Physical Attack
Not every consumer or industrial product requires defense against sophisticated invasive laboratory attacks.
Security Depth Should Follow Product Risk.
217 — Remote Attack
For connected products, remote compromise is often especially important because: One Vulnerability Can Reach Many Devices.
218 — Supply-Chain Threat
Could unauthorized software enter during:
factory
distributor
service?
Secure Boot Can Extend Trust Through the Supply Chain.
219 — Signing-Pipeline Compromise
A perfect bootloader cannot save you if an attacker legitimately obtains: The Production Signing Authority.
Device Security and DevSecOps Security Are One System.
220 — Secure Build Pipeline
Protect:
Source
CI
Artifacts
Signing
Release Metadata
Firmware Trust Begins Upstream of the Device.
221 — Artifact Repository
Release artifacts should be:
immutable
identifiable
controlled
according to engineering process. Don't Replace an Artifact While Keeping the Same Version Name.
222 — SBOM
Firmware releases increasingly need visibility into included:
third-party libraries
versions.
You Cannot Patch a Vulnerability You Cannot Locate.
223 — SBOM + Firmware Version
Map: SBOM
to: exact firmware artifact.
Component Inventory Should Describe What Actually Shipped.
224 — Vulnerability → Fleet
When library X becomes vulnerable:
query:
Which firmware versions contain it?
Then:
Which physical devices run those versions?
SBOM + Fleet Inventory Turns Vulnerability Data Into Action.
225 — Security Update Priority
Security patch may need accelerated release.
But:
Urgency Does Not Remove Validation.
A rushed bricking update is not a security success.
226 — Emergency Release
Maintain a process capable of: Build → Review → Sign → Canary → Deploy
rapidly but safely. Incident Response Should Be Practiced Before an Incident.
227 — Long-Term Support
Firmware update mechanism must remain useful even years later. The Updater Itself Is Long-Lived Infrastructure.
228 — Certificate / Key Lifetime
A 15-year product cannot assume: Today's entire trust system remains unchanged for 15 years.
229 — Crypto Migration
Future migration may require:
new algorithms
keys
bootloader support.
Long-Lived Security Requires Planned Evolution.
230 — Root-Key Transition
If the root key must change: How Will Already-Deployed Devices Learn the New Trust Anchor?
This should be considered early.
231 — Product EOL
At End of Life:
Product Support Policy Is Part of Update Architecture.
232 — Vendor Disappearance Risk
RFC 9019 even highlights availability of security fixes after product discontinuation/vendor failure as an ecosystem concern.
Update Infrastructure Has Organizational Lifetime Too.
233 — Field Service
Authorized service technicians may need controlled:
Serviceability Should Not Require Bypassing Product Trust.
234 — Repair Mainboard Replacement
New PCB may have:
Hardware Replacement Needs Secure Re-Provisioning.
235 — Refurbishment
Returned product may require:
ownership reset
credential changes
software qualification.
Refurbishment Is Another Lifecycle State.
236 — Bootloader Diagnostics
Useful information can include:
Boot Reason
Selected Slot
Image Version
Validation Result
Rollback Reason
Bootloader Should Explain Its Decision.
237 — Recovery Diagnostics
If device reverted: cloud/service system should know:
Why.
238 — Failure Evidence
Preserve selected information before destroying the failed image/configuration. Recovery Should Not Erase the Root Cause.
239 — Crash After Upgrade
Correlate:
New Firmware
Crash Context
Reset Cause
Hardware Revision
Update Failure Analysis Is Product Failure Analysis.
240 — Hardware Interaction
New firmware may increase:
CPU
radio duty cycle
power load.
Suddenly hardware becomes unstable. Software Update Can Expose Hidden Hardware Margin.
241 — Power Interaction
New code increases current peaks. Weak PDN causes resets. A Firmware Regression Can Be an Electrical Regression.
242 — Thermal Interaction
New algorithm increases sustained CPU load. Product begins throttling or overheating. Update Validation Must Include Physical Product Behavior.
243 — RF Interaction
New radio firmware changes:
duty cycle
transmit behavior.
Software Can Change EMC / RF Behavior.
244 — Certification Interaction
Certain firmware changes may affect a product's existing compliance assumptions. Software Change Can Become Regulatory Change. Project-specific review may therefore be required.
245 — Functional Regression
Secure signature only proves: Authorized Software.
It does not prove: Correct Software.
246 — Security Validation ≠ Functional Validation
Need both: Cryptographic Validation
and: Product Validation.
247 — Release Test
Before signing/deploying:
functional tests
regression
update/rollback tests.
Signing Should Authorize a Qualified Release — Not Create Qualification.
248 — Update Path Test
Test: Old → New
not only: Fresh Flash → New.
Real Customers Upgrade From History.
249 — Downgrade Test
Where rollback is allowed: Test It.
Where forbidden: Test Rejection.
250 — Power-Loss Test
Controlled validation should interrupt power at multiple update stages. Prove Recovery — Don't Merely Read the Code and Assume It.
251 — Reset Injection Test
Unexpected resets can occur during:
download
verify
install
trial.
Every Phase Should Have Defined Restart Behavior.
252 — Corrupted Image Test
Device should reject corrupted image. Error Path Is a Product Feature.
253 — Wrong-Key Test
Correctly formatted but unauthorized image should not execute. Authentication Should Be Tested Negatively.
254 — Wrong-Hardware Test
A valid image for another product should be rejected. Applicability Is Part of Update Security.
255 — Rollback Attack Test
Older valid signed image should be rejected when security policy forbids it. Anti-Rollback Needs Verification.
256 — Low-Battery Test
Verify update policy under insufficient energy condition. Preconditions Should Actually Prevent Unsafe Installation.
257 — Network Failure Test
Drop connectivity repeatedly. Download Should Recover Without Corrupting Product State.
258 — Storage-Full Test
If no space exists: Fail Before Damaging Current Software.
259 — Boot-Loop Test
Release intentionally faulty test image in engineering environment.
Verify: Device returns to known-good.
This is an important recovery validation concept.
260 — Health-Check Failure Test
New image boots but intentionally fails one required product check. Does the system refuse confirmation?
261 — Multi-Image Failure Test
One component update succeeds, another fails. Verify the designed compatibility/recovery policy.
262 — Long-Duration Update Test
Repeatedly update: A → B → A → B
in validation.
Update System Itself Has Endurance.
263 — Flash Endurance
Boot metadata and counters may be written frequently. Update Architecture Should Respect Nonvolatile Memory Endurance.
264 — Wear
Do not rewrite the same metadata location unnecessarily. Recovery Metadata Is Still Flash Data.
265 — Manufacturing Variation
Test across multiple production units. One MCU Sample Does Not Prove Flash / Power Margin for Every Unit.
266 — Environmental Validation
Update behavior may need qualification across required product:
conditions. Field Update Happens Outside the Engineering Lab.
267 — HIL
Hardware-in-the-loop can automate:
power cycles
network loss
update states.
Update Recovery Can Be Regression-Tested Automatically.
268 — CI Integration
Every release candidate can automatically exercise:
Install
Boot
Confirm
Rollback
on real hardware where infrastructure permits. OTA Reliability Should Be a Continuous Test.
269 — Production Test Firmware
Factory firmware may differ from shipping firmware. The Bootloader Must Know Which Images Production Units Are Authorized to Run.
270 — Final Production Transition
Before shipment: Factory Mode → Production Firmware → Production Trust Policy
Shipping State Should Be Deliberate.
271 — Firmware Programming Verification
After production flash: Verify the intended artifact.
272 — Serial + Firmware Correlation
Production record: Serial Number → PCB Rev → Bootloader → Firmware Hash
Every Unit Should Know What Software It Was Born With.
273 — Fleet Correlation
Later cloud records: Serial → Current Firmware → Update History
Manufacturing Traceability Can Continue Into Field Software Lifecycle.
274 — Field Failure Correlation
Suppose firmware v6 causes failures only on: PCB Rev B.
Fleet + Manufacturing Data Can Reveal Hardware/Software Interaction.
275 — This Is Where 365PCB Becomes Different Again
A cloud company sees: Update failed.
A firmware company sees: Watchdog reset.
A PCB company sees: Board passed production.
An integrated ODM can ask:
Firmware?
Bootloader?
Flash?
Power?
Hardware Revision?
Component Lot?
Thermal?
Update Reliability Is a Whole-Product Property.
276 — Product Recovery Is Hardware + Software
If the device cannot power reliably during Flash programming: Perfect OTA Software Cannot Save It.
277 — Update Architecture Should Influence PCB Design
Before PCB release, consider:
OTA Requirements Are Hardware Requirements.
278 — Flash Size
If A/B is required: Allocate Storage Before Hardware Freezes.
Do not discover after PCB completion: We need twice the flash.
279 — Secure Element / Security Hardware
If product needs stronger trust anchoring: Plan It During Architecture.
Not after EVT.
280 — Recovery Interface
If field service requires a physical recovery channel: The Connector / Test Pads May Need to Exist on the PCB.
281 — Boot Pin Security
SoC boot-mode pins can sometimes create alternate boot paths. Hardware Boot Configuration Is Part of Secure Boot Architecture.
282 — Manufacturing Straps
Factory boot mechanisms should not accidentally remain exploitable in production configuration. Manufacturing Convenience Needs a Production Exit Strategy.
283 — DFM / DFT Connection
Production must be able to:
Program
Verify
Provision
Test
without weakening shipping security. Security Is a Manufacturing Process Requirement.
284 — EVT
EVT asks: Does the complete boot/update architecture work on the real hardware?
Validate:
boot
flash layout
signature
recovery
diagnostics.
285 — EVT Observability
Development builds should expose enough information to understand:
image choice
validation
reset.
You Cannot Engineer Recovery Blindly.
286 — DVT
DVT asks: Can the device survive realistic update failures?
Test:
power loss
network failure
corrupted image
rollback
different hardware.
287 — Security DVT
Verify:
Unauthorized Image Rejected
Old Vulnerable Image Rejected
Production Trust Enforced
Security Requirements Need Behavioral Test Evidence.
288 — PVT
PVT asks: Can production reliably create the correct trusted software state on every unit?
Validate:
programming
keys
hardware ID
firmware version
boot policy.
289 — Production Audit
Spot-check or automate verification of:
signing authority
security state
bootloader
firmware.
Trust Should Be Manufactured Repeatably.
290 — Field Lifecycle
After shipment: Update → Monitor → Patch → Recover → Evolve Trust
Secure Update Is a Multi-Year Product Service.
291 — What Does World-Class Bootloader, OTA & Secure Firmware Update Engineering Look Like?
At the highest level: Product Lifecycle Requirements → Threat Model → Hardware Root of Trust → Boot ROM → Bootloader Architecture → Trust Chain → Image Format → Firmware Manifest → Cryptographic Digest → Digital Signature → Hardware Applicability → Security Counter → Anti-Rollback → Flash / Partition Architecture → A/B or Swap Strategy → Candidate Download → Candidate Verification → Power-Failure-Safe Installation → Trial Boot → Product Health Check → Confirmation → Commit → Automatic Revert → Recovery Environment → Key Rotation → Bootloader Update Strategy → Multi-Image Dependencies → Configuration Migration → Factory Provisioning → Production Trust Lock → Release Signing → Fleet OTA Campaign → Canary Rollout → Health Monitoring → Campaign Pause / Rollback → Field Diagnostics → Vulnerability Response → Long-Term Trust Evolution → Recoverable Product Software Lifecycle
That is the difference between: Downloading Firmware
and: Engineering Secure Update.
Typical Bootloader, OTA & Secure Firmware Update Deliverables
Depending on project scope, a 365PCB ODM secure-update program may include:
Boot Architecture Requirements
Firmware Update Requirements
Threat-Model Inputs
Hardware Root-of-Trust Inputs
Boot ROM Review
Bootloader Architecture
First-Stage Bootloader Inputs
MCUboot Integration
Custom Bootloader Inputs
Boot Flow Definition
Chain-of-Trust Architecture
Secure Boot Architecture
Image Authentication
Image Integrity Validation
Firmware Signature Integration
Image Header Definition
Firmware Manifest Architecture
SUIT Architecture Feasibility Inputs
Firmware Versioning
Security Counter Architecture
Anti-Rollback
Hardware Compatibility Rules
Product Variant Compatibility
Component Identifier Strategy
Multi-Image Architecture
Software Dependency Management
Flash Partition Architecture
Single-Slot Feasibility
Dual-Slot / A-B Architecture
Swap-Based Update Architecture
Direct-XIP Update Inputs
RAM-Load Boot Inputs
Candidate Image Storage
Update State Metadata
Power-Fail-Safe Update
Interrupted Update Recovery
Update Atomicity
Trial Boot
Image Confirmation
Health-Confirmation Architecture
Automatic Revert
Boot-Attempt Counter
Boot-Loop Protection
Reset-Cause Integration
Watchdog / Boot Integration
Known-Good Image Strategy
Recovery Image
Recovery Partition Inputs
Service-Recovery Architecture
Firmware Payload Download
Chunked Download
Resume Support
Compressed Update Inputs
Delta Update Feasibility
Full-Image Fallback
Final-Image Verification
Offline Update Inputs
Local Update Inputs
OTA Integration
Device Update State Machine
Download / Install Separation
Update Preconditions
Battery / Power Preconditions
Storage Preconditions
Maintenance-Window Inputs
Firmware Signing Workflow
Release Authorization Workflow
Signing-Key Architecture Inputs
Development / Production Key Separation
Key Rotation Inputs
Key Revocation Inputs
Recovery-Key Inputs
Crypto-Agility Inputs
Secure Storage Inputs
Trusted Counter Inputs
Secure / Non-Secure Image Integration
TrustZone / TFM Inputs
Debug-Port Policy Inputs
Secure Debug Inputs
Bootloader Update Architecture
Bootloader Recovery Strategy
FPGA Image Update Inputs
Wireless-Module Update Inputs
Peripheral-MCU Update Inputs
Distributed Firmware Update
Cross-Component Compatibility Matrix
Firmware Release Manifest
Firmware Build ID
Firmware Hash Traceability
Reproducible-Build Inputs
CI / Release Pipeline Inputs
Secure Artifact Repository Inputs
SBOM Linkage
Vulnerability-to-Firmware Mapping
OTA Campaign Architecture
Fleet Targeting
Staged Deployment
Canary Deployment
Rollout Gates
Campaign Pause / Abort
Fleet Update Monitoring
Update Status Reporting
Update Failure Classification
Fleet Rollback Inputs
Configuration Migration
Persistent Data Compatibility
Calibration Preservation
Identity / Credential Preservation
Firmware Update Logging
Update Audit Trail
Field Recovery
Credential Lifecycle Inputs
Long-Term Security Maintenance
Firmware Lifecycle Planning
Bootloader Lifecycle Planning
Firmware Update Unit Tests
Corrupted-Image Testing
Wrong-Signature Testing
Wrong-Hardware Testing
Anti-Rollback Testing
Power-Loss Testing
Reset Injection
Network-Failure Testing
Storage-Failure Testing
Trial-Boot Failure Testing
Automatic-Revert Testing
Boot-Loop Testing
Multi-Image Failure Testing
Update Endurance Testing
HIL OTA Testing
Automated Hardware Regression
Production Programming Inputs
Production Secure Provisioning
Initial Trust Establishment
Production Firmware Verification
Hardware / Firmware Traceability
EVT Bootloader Validation
DVT Secure Update Validation
PVT Provisioning Validation
Field Update Diagnostics
Secure Firmware Update Architecture Documentation
The actual engineering depth should follow: Processor + Flash Architecture + Security Threat + Product Consequence + Connectivity + Hardware Variants + Fleet Size + Service Life + Recovery Requirement.
Bring Us the Product Lifecycle — Not Just the Firmware File
You can begin with: MCU / SoC, Existing Bootloader, Existing Firmware, Flash Architecture, Hardware Revision, Current OTA System, Secure Boot Requirement, Existing Signing System, Product Lifecycle, Fleet Size, Recovery Requirements, Current Bricking Problem.
or simply: Tell Us What Software Must Be Allowed to Run — and What the Product Must Do When a New Version Fails.
365PCB can help translate: Hardware Root of Trust → Bootloader → Firmware Authentication → Safe Installation → Recovery → Manufacturing → Fleet Lifecycle.
Don't Just Download the Firmware.
Define the Trust Root.
Authenticate the Image.
Verify the Complete Artifact.
Check Hardware Compatibility.
Prevent Unauthorized Rollback.
Preserve the Known-Good Image.
Design for Power Loss.
Trial the New Firmware.
Verify Product Health.
Confirm Only After Success.
Revert Automatically When Necessary.
Protect the Signing Keys.
Plan Key Rotation.
Control the Bootloader.
Protect Persistent Data.
Preserve Calibration and Identity.
Test Every Failure Path.
Provision Trust Correctly in Manufacturing.
Stage Fleet Deployment.
Monitor the Rollout.
Maintain the Update System for the Product Lifetime.
365PCB Bootloader, OTA & Secure Firmware Update engineering connects:
Hardware + Root of Trust + Bootloader + Firmware + Cryptography + Recovery + Manufacturing + IoT + Fleet Operations
English
