A security patch helps only if the device can install it safely. Learn how to budget flash for OTA firmware updates, choose an A/B or staged update architecture, preserve recovery access, and test power-loss resilience—while separating the EU Cyber Resilience Act’s reporting deadlines from its broader requirements.
A connected product is not meaningfully patchable just because it can download firmware over the air. A recoverable OTA firmware update must do more: it must authenticate the update, survive interrupted installation, recognize when the new application is unhealthy, and recover without turning a remote security incident into a fleet-wide service visit.
The EU Cyber Resilience Act (CRA) makes that distinction especially relevant: its reporting obligations have applied since 11 September 2026, while its broader product-security and vulnerability-handling requirements apply from 11 December 2027. Those dates create different obligations—not a mandate for any particular bootloader or memory architecture—but they expose the same practical bottleneck: some shipped hardware has no safe path to accept a patch. [1][2]
Article 14 reporting concerns actively exploited vulnerabilities and severe incidents affecting the security of in-scope products with digital elements. It is not a requirement to report every bug or every vulnerability found during testing. ENISA describes an actively exploited vulnerability as one for which there is reliable evidence of exploitation by a malicious actor. [2]
The reporting timetable starts when the manufacturer becomes aware of a qualifying event:
| Reporting step | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Without undue delay, within 24 hours | Without undue delay, within 24 hours |
| More detailed notification | Without undue delay, within 72 hours | Without undue delay, within 72 hours |
| Final report | No later than 14 days after a corrective or mitigating measure becomes available | Within one month after the 72-hour notification |
Manufacturers submit these notifications through ENISA’s Single Reporting Platform, which became operational on 11 September 2026. Reporting also covers in-scope products placed on the market before 11 December 2027; it is not limited to newly launched hardware. [2]
The broader CRA obligations are a separate milestone. The supplied guidance identifies 11 December 2027 as the application date for the main manufacturer obligations and Annex I essential cybersecurity and vulnerability-handling requirements, generally covering products placed on the market from that date and earlier products substantially modified afterward. The September reporting milestone does not itself pull every legacy product into those later support-period requirements. [1]
Manufacturers also have obligations to inform affected users without undue delay and provide applicable mitigation or corrective measures. Reporting can remain relevant even when an in-scope product’s support period has ended. [1][6]
For engineering teams, the implication is operational rather than architectural: being able to describe an incident is different from being able to repair the affected product. A reporting process cannot compensate for insufficient flash, an inaccessible recovery interface, or an installer that erases its only working image before checking the replacement.
This article treats the hardware and firmware choices below as engineering recommendations, not as prescribed CRA compliance architectures.
“Supports OTA” is an incomplete requirement. It might mean only that the application can receive a binary over Wi-Fi, Ethernet, Bluetooth, or a gateway connection.
A useful update specification defines what happens when each stage fails:
The architectural goal is to preserve an authenticated path to useful operation—or to a deliberately limited repair environment—through every supported interruption.
The supplied update research describes this as protection, detection, and recovery, drawing on NIST SP 800-193. It also cites RFC 9019’s requirement that devices not fail because an update is disrupted, including by power loss. These are useful design principles; citing them does not establish that a particular implementation conforms to either document. [4]
Write the acceptance criteria before schematic capture. “Can resume installation after arbitrary power interruption” and “can recover after a signed application fails self-test” are different properties, and they may need different storage provisions.
The first flash-budget error is comparing the MCU’s advertised capacity with the current application’s .bin file. An update-capable product also needs room for its trust foundation, image metadata, persistent state, and future growth.
A planning model is:
F_total ≥ B + N × S + M + P + X
Where:
B is the protected boot and recovery region.N is the number of application slots in that memory device.S is the allocated size of each slot, including required image overhead.M is update-state storage, such as image trailers or a boot-state journal.P is persistent product data, including configuration and calibration.X is any scratch or working area required by the selected installation algorithm.Do not count trailers twice if the bootloader includes them inside each slot. Likewise, external staging changes which terms must fit internally; it does not make their storage requirements disappear.
The following is a hypothetical planning example, not a specification for a named MCU or bootloader. Here, 1 KiB means 1,024 bytes.
| Allocation | Assumed capacity |
|---|---|
| Protected boot and recovery region | 128 KiB |
| Application slot A | 896 KiB |
| Application slot B | 896 KiB |
| Persistent configuration and calibration | 64 KiB |
| Update-state journal | 32 KiB |
| Installation scratch area | 32 KiB |
| Total internal flash | 2,048 KiB |
If each slot reserves an illustrative 16 KiB for headers, signatures, alignment, and trailers, each can carry at most 880 KiB of application payload. An assumed 720 KiB application would therefore have 160 KiB of payload growth margin—not the much larger amount suggested by subtracting one application from total flash.
Every allocation must then be reconciled with the actual device’s erase geometry and the bootloader’s requirements. A nominal 32 KiB scratch allocation is not automatically sufficient: the selected algorithm may require a scratch region related to the largest relevant erase sector, or may use a different swap strategy altogether.
Before approving the MCU, review:
A delta update can reduce transferred bytes, but it does not inherently remove the need for a recoverable destination image. Budget the reconstructed firmware and the reconstruction workspace separately.
The important distinction is not simply internal versus external flash. It is which valid image survives, which component can execute after interruption, and how installation state is reconstructed.
| Architecture | Main advantage | Principal constraint | Recovery question |
|---|---|---|---|
| Internal A/B application slots | Keeps separate old and candidate images | Requires enough internal capacity and a compatible execution or swap scheme | Can the bootloader select or restore a valid image after every interrupted state change? |
| Hardware dual-bank flash | May support useful programming isolation or bank switching | Behavior depends on the exact MCU and flash configuration | Are remapping, boot selection, and bank operations themselves interruption-safe? |
| Internal execution plus external staging | Moves downloaded-image storage out of internal flash | Adds a memory device, bus dependencies, and installation logic | Can a protected installer resume if the internal application is partly overwritten? |
| External staging plus retained backup | Can preserve both candidate and previous firmware outside execution flash | Requires more storage and careful backup-state management | Is the backup complete, authenticated, and still allowed by security policy? |
| Single application plus protected local recovery | Can minimize application storage requirements | Recovery may require a cable, phone, technician, or local gateway | Can the recovery environment operate when the application is entirely unusable? |
These are engineering trade-offs, not a ranking of legal acceptability. A serviceable industrial controller and an inaccessible battery-powered sensor can reasonably need different recovery strategies.
Do not treat those terms as interchangeable.
A device can expose two physical flash banks without providing a complete trial-boot and rollback mechanism. Conversely, a bootloader can implement logical primary and secondary slots using copying or swapping rather than executing directly from either slot.
Check the exact MCU variant, reference manual, and errata. Establish whether code can execute while the other bank is programmed, whether interrupt vectors and constants remain accessible, and whether bank remapping changes assumptions about application addresses.
The supplied research describes MCUboot’s primary and secondary slots and its test-swap behavior: a candidate boots provisionally and reverts unless it is marked good. It also describes ESP-IDF application rollback, which uses at least two OTA application slots and requires a new application to confirm successful operation. Those are implementation-specific mechanisms, not evidence that every dual-bank MCU automatically provides rollback. [4]
External flash can store a candidate while the existing application continues to run. But if installation overwrites the only internal application, rollback is not automatically available.
There are two distinct promises:
A staging-only design may provide the first without the second. To promise rollback, retain the previous image somewhere or provide another known-good execution environment.
Treat external storage as untrusted. The bootloader should authenticate the image it is actually installing, not rely solely on an earlier application-level check. If staged content can change between verification and use, the design must prevent that change or detect it before modified code becomes executable.
At board level, review flash supply integrity, chip-select behavior during reset, shared-bus ownership, and power-domain sequencing. A recovery loader that cannot reliably communicate with its staging memory is not a recovery loader in practice.
Transport encryption and firmware authorization solve different problems. A secure connection helps protect delivery, but the device still needs to decide whether the received firmware is authorized to run.
The supplied research describes signed manifests and authenticated images, with confidentiality optional in the referenced update framework. This also allows the same authorized package to arrive through a phone, serial link, USB connection, or another offline delivery path. [4]
For a practical design, authenticate at least the information needed to bind the package to its intended use:
A signature over the payload alone is insufficient if unauthenticated metadata can redirect that payload into a protected region. Validate bounds and allowed destinations independently of signature verification, and make the parser reject malformed or ambiguous packages.
Protect the verification trust anchor against unauthorized replacement. A secure element can be one option, but it is not a substitute for protecting the boot path or enforcing the verification result. The research identifies protected trust-anchor storage and notes hardware-backed downgrade controls in MCUboot and ESP-IDF. [4]
Also plan key rotation. A product expected to receive updates after shipment needs a documented way to introduce replacement verification keys and retire compromised ones without accidentally invalidating every available recovery image.
An update is a state machine spanning resets, not a single function call.
A useful conceptual sequence is:
CONFIRMED → RECEIVING → VERIFIED → INSTALLING → TRIAL → CONFIRMED
Failure paths can return to the previous confirmed image or enter a restricted recovery environment. The exact states depend on the bootloader, but each transition needs a defined persistent representation.
For every state, answer:
Avoid designs that depend on one flash write behaving like an atomic database commit unless the device explicitly guarantees the required behavior. A common design approach is redundant records or an append-only journal with generation information and integrity checks, so an interrupted record can be rejected while an earlier complete record remains usable.
Those integrity checks do not automatically provide security. A checksum can detect accidental corruption; it cannot prevent an attacker from rewriting an otherwise unprotected boot-selection record. Protect policy-critical state according to the threat model.
When using an established bootloader, preserve its documented metadata and interruption model. An application that casually edits a bootloader trailer can break recovery even when its own download logic is correct.
Rollback answers: Can the device return to working firmware?
Anti-rollback answers: Can an attacker reinstall firmware that security policy has retired?
These goals conflict when the previous working image contains the vulnerability the update is intended to fix. A valid signature establishes authorization under a signing key; it does not establish that the image is still acceptable under current security policy.
The research describes MCUboot comparing an image security counter against trusted nonvolatile state, and ESP-IDF rejecting applications whose security version is below the chip’s programmed eFuse value. [4]
Use distinct concepts for:
This permits a policy in which several releases share an acceptable security epoch, while a later security fix retires all earlier epochs. Whether and how to do this depends on the selected bootloader and hardware.
It also prevents a misleading assumption: a monotonic version rule cannot, by itself, tell a long-offline device which release is globally newest. The supplied research explicitly describes the possibility of presenting a validly signed update that is newer than the installed firmware but older than the latest available release. [4]
Advancing an irreversible security floor too early can prohibit the only working fallback before the candidate has proved healthy. Advancing it too late can leave a window in which vulnerable firmware remains installable.
A possible policy is to verify the candidate, trial-boot it under controlled conditions, confirm required health checks, and then finalize the new security floor. But this is not a universal recipe: some threat models cannot tolerate temporary fallback to the vulnerable release, and some bootloaders impose their own sequencing.
Whatever the policy, specify what happens if power fails between recording confirmation and advancing the trusted counter—or in the reverse ordering. Once the floor rises, recovery must be possible using an image that satisfies the new floor.
A permanently preserved factory application is therefore not necessarily a valid permanent fallback. A narrow recovery loader that accepts current authorized firmware may be more useful than an old full-featured application with permanently retained vulnerabilities.
The candidate should not mark itself good simply because startup completed. It should establish that the functions required for continued operation and future repair work.
Candidate checks might include:
Keep checks bounded and separate device health from external availability. A healthy product should not necessarily roll back because a cloud endpoint is temporarily unavailable. Conversely, a firmware regression that prevents all future connectivity should not pass merely because a local status LED works.
The supplied research notes that ESP-IDF recommends performing first-boot self-tests quickly because power loss during that phase can trigger rollback. That highlights why the confirmation boundary must be a deliberate operational choice. [4]
Firmware rollback does not automatically reverse configuration changes.
If a candidate migrates settings into a format the old application cannot read, reverting the executable may still leave the product unusable. Consider copy-on-write migration, versioned records, or temporarily retaining an older compatible representation until the update is committed.
Apply the same reasoning to multi-component products. An MCU application, radio firmware, and attached coprocessor may have compatibility dependencies. Document which combinations can boot and recover if only part of the update completes.
A recovery strategy must survive both production security configuration and mechanical assembly.
Depending on the product and threat model, useful provisions may include:
Do not make field recovery depend on leaving unrestricted debug access enabled. Equally, do not permanently disable interfaces before verifying what service operations remain possible. Some device security settings may make recovery destructive or unavailable; resolve that trade-off before production provisioning.
Check the assembled product, not just the PCB rendering. Pads beneath a glued battery or inaccessible inside a sealed enclosure are manufacturing access, not necessarily practical field access.
A ROM loader also needs evaluation rather than assumption. Determine its authentication behavior, available interfaces, interaction with protection settings, and consequences for product secrets. Local recovery should not become an unauthenticated route around secure boot.
A few manual power cycles are a demonstration, not a recovery qualification plan.
Use a controllable power fixture to interrupt the device at targeted update events, supplemented by randomized interruptions. Record supply behavior and bootloader state so that a failed run can be reproduced.
Exercise at least these boundaries:
| Interruption point | Required outcome to verify |
|---|---|
| Candidate download | Partial data is not mistaken for an installable image |
| External-flash erase or program | Corrupt staging contents are rejected or safely replaced |
| Internal application erase or program | A protected path can resume installation or recover |
| Boot-selection metadata update | Reset selects a valid prior state or a recoverable new state |
| Trial boot | Unconfirmed firmware is handled according to the documented policy |
| Confirmation write | Success cannot be inferred from a torn record |
| Security-counter update | No prohibited image boots, and an authorized recovery path remains |
| Configuration migration | The selected firmware can interpret the surviving data |
Test abrupt removal, slow voltage collapse, and repeated brownout-like conditions. Review the actual MCU and memory specifications for programming voltage limits, reset thresholds, and behavior after interrupted operations. Do not assume that a brownout detector makes every in-progress flash operation complete safely.
If the design relies on hold-up capacitance, calculate the required energy from the relevant loads, permitted voltage drop, conversion losses, and worst-case operation duration. Prefer a recoverable transaction over relying exclusively on enough stored energy to finish an entire installation.
Include non-power failures as well: wrong hardware revision, invalid signature, forbidden security epoch, damaged staging memory, incompatible settings, an application reset loop, and an unavailable network.
The pass criterion is not merely “the board eventually boots.” It is that the board boots only permitted firmware, avoids unsafe output behavior, preserves required data, and remains repairable without undocumented intervention.
Manufacturers cannot manage a vulnerability response using only the fact that a package was uploaded to a server. They need to distinguish delivery from installation and installation from successful confirmation.
Useful device and release records include:
Preserve these records in a way that does not undermine flash endurance or leak sensitive information. Offline products need a local service route to retrieve equivalent evidence.
For already-shipped boards, start with an inventory of actual capabilities. Determine whether the bootloader can authenticate updates, whether spare storage exists, and whether a protected local repair path remains accessible. Do not label an in-place overwrite scheme recoverable simply because it has succeeded in the laboratory.
If hardware cannot safely accept the required firmware, the response may require constrained functionality, network-side mitigation, local service, or replacement. Those options should be evaluated by the relevant security, support, and legal teams; the ability to file a CRA report does not establish that any particular mitigation is sufficient. The reporting timetable remains distinct from the later broader vulnerability-handling obligations. [1][2]
Downloading firmware is not enough. The device must authenticate the update, survive interrupted installation, recognize when the new application is unhealthy, and recover—by resuming installation, reverting to an acceptable previous image, or entering a protected repair environment—without turning a remote security incident into a fleet-wide service visit.
No. Dual-bank flash is a hardware feature of some MCUs; A/B is an update policy. A device can expose two physical flash banks without a complete trial-boot and rollback mechanism, and a bootloader can implement logical primary and secondary slots by copying or swapping rather than executing directly from either slot. Check the exact MCU variant, reference manual, and errata.
Not automatically. External flash can hold a candidate image while the existing application keeps running, but if installation overwrites the only internal application, a protected installer may be able to resume the install without being able to roll back. To promise rollback, retain the previous image or provide another known-good execution environment—and treat external storage as untrusted.
Rollback asks whether the device can return to working firmware. Anti-rollback asks whether an attacker can reinstall firmware that security policy has retired. They conflict when the previous image contains the vulnerability being fixed, so release version, security counter or epoch, and confirmation state should be managed as separate concepts, with an explicit commit boundary for raising the security floor.
No. Neither CRA milestone prescribes a particular bootloader or memory architecture. Article 14 reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, with an early warning within 24 hours and a more detailed notification within 72 hours. The broader product-security and vulnerability-handling requirements apply from 11 December 2027. [1][2]
Treat it as a fault-injection campaign rather than a few manual power cycles. Use a controllable power fixture to interrupt the device at targeted update events—download, erase and program, boot-selection metadata, trial boot, confirmation, security-counter update, and configuration migration—supplemented by randomized interruptions, abrupt removal, slow voltage collapse, and repeated brownout-like conditions.
AI-driven electronics workflows such as IntelCAD.ai can help translate recoverability requirements into schematic-level design tasks: allocating external staging flash, identifying reset and boot-control connections, reserving service access, and organizing power-domain review questions. They can also help keep the memory-budget assumptions and hardware checklist visible as the design evolves.
The boundary is important: generated schematics and checklists do not prove secure boot or power-loss resilience. Those claims still require exact-part documentation, a reviewed bootloader configuration, and fault-injection results on production-representative hardware. The useful role of AI is to surface missing provisions early—before an otherwise patchable product becomes unrepairable because of a board-level omission.
Design your next board by describing it.
IntelCAD.ai turns plain-language requirements into schematics and PCBs.
Start Your Design