HARDWARE · 5th November 2026
Patchable by Design: The Medical Device Cybersecurity Decisions You Make at the PCB Stage
Cybersecurity arrives in most device programmes as a document request. Someone from regulatory asks for the software bill of materials and the postmarket vulnerability plan, usually a few months before submission, and the team starts writing.
By then, several of the answers have already been decided, in copper. Whether the device can accept a signed firmware update at all, whether it can fall back if an update fails, where the keys live, whether the radio stack can be patched independently: these are board-level choices made early, often by someone who had no idea they were making a regulatory commitment.
This is written for hardware and firmware leads, and for the founders who approve their architecture. It covers what the FDA actually asks for, and which parts of it stop being negotiable once the board is laid out.
What the rules require, briefly
Section 524B of the FD&C Act applies to devices meeting all three parts of its cyber-device definition: sponsor-authorised software, the ability to connect to the internet, and technological characteristics that could be vulnerable to cybersecurity threats. Relevant submissions must include a vulnerability-monitoring and response plan, processes supporting cybersecurity throughout the device's life including appropriate updates and patches, and a software bill of materials. Check the complete system and the applicable submission requirements, including any companion app.
FDA reissued its premarket cybersecurity guidance on 3 February 2026, aligning it with the new Quality Management System Regulation and replacing the June 2025 version. That reissue added no new mandates, but it did move cybersecurity firmly inside the quality system rather than alongside it. The guidance asks submissions to demonstrate five security objectives: authenticity, authorisation, availability, confidentiality, and secure and timely updatability and patchability.
That last objective is the one with hardware consequences, and it is the subject of the rest of this article.
Decision 1: Can the device verify what it runs?
Secure boot means the processor checks a cryptographic signature before executing firmware. Reviewers expect firmware signing and verification on the update path described end to end, not asserted in a sentence.
The hardware consequence is that component selection constrains the available protections. Compare the processor's boot features, protected storage, provisioning and recovery options against the product's risks. Some protections need hardware support; adding them late can require a redesign. No single processor feature or layout is prescribed for every device.
Ask early: how is the boot process protected, how are verification keys stored, and how will authorised keys be changed or revoked if needed? Define who controls provisioning at the factory and how the device can recover from a failed update.
Decision 2: Is there room for a second copy of the firmware?
An interrupted update must leave the device in a defined, safe state. Two firmware slots, A and B, are one common approach: prepare the new image while retaining the existing one, verify it, and switch only when the required checks pass. Other architectures may use protected recovery code or external storage. Choose and test the recovery method for the product's risks.
An A/B design reserves space for two application images plus the bootloader and metadata. Other recovery methods have different storage needs. Budget for expected software growth and the selected recovery method before layout. External storage can add capacity, but also adds board area, power use and security considerations.
Before layout, estimate the supported firmware size over the product's planned life and confirm that the memory map supports updates, recovery, metadata and reasonable headroom.
- Processor and boot
- Choose how the device checks the software it is allowed to run.
- Memory and recovery
- Reserve space for the chosen update and recovery method; paired slots are one option.
- Protected keys
- Plan secure storage, factory provisioning and the key lifecycle together.
- Connected components
- Check how radio and other supplier firmware will be maintained.
Illustrative component layout, not a board design or a prescribed FDA architecture.
Decision 3: How does an update physically reach the device?
A wearable that connects only through a phone app inherits the phone's constraints. Update size matters when the transport is Bluetooth Low Energy and the patient has to stay in range. Power matters, because writing flash and holding a radio link is one of the most demanding things the device will do, and an update that fails at 20 percent battery is a field failure waiting to happen.
Decide where the update is authenticated, whether the phone app is trusted or merely a pipe, how an interrupted transfer resumes, and what the device does if the user walks away mid-update. Each of those has a hardware dimension: battery headroom, flash write endurance, and whether the radio module's own firmware can be updated separately from the application.
Decision 4: Which parts of the device can you actually patch?
A software bill of materials identifies the software components in a released build. Keep it matched to the relevant version and define how component vulnerabilities are monitored and addressed. A general promise to update libraries does not explain who will do that work or how it will be tracked.
Supplier choice matters when a radio module or sensor includes firmware the team cannot change itself. Check the vendor's security-update support, authenticated firmware, vulnerability notification and support period before selecting the part. If support ends, the manufacturer still needs a way to manage the resulting risk.
Decision 5: Where do the secrets live, and who puts them there?
Update signing, encryption and device identity require suitable key management. Describe how the chosen controls work, including how keys are generated, protected, used, changed and retired. A cryptographic algorithm name alone does not explain the implementation.
In hardware terms: is there a secure element or a protected region in the processor? Who generates the keys, and at what point in manufacturing are they injected? Can the manufacturing line read them afterwards? These questions reach into the production process, which is another reason design transfer should not be treated as the final step.
On client programmes, we manage the firmware-signing keys on the client's behalf, under the client's supervision and agreed procedures.
- Authenticate
- Check the source and integrity of the update package.
- Check the conditions
- Confirm power, compatibility and transfer requirements before switching.
- Keep a recovery route
- In this A/B example, retain the previous working image while preparing the new one.
- Verify the result
- Check the running device and recover if the new image fails its checks.
A/B is one example. The recovery method must fit the product risks and be tested, including interrupted transfers and low battery.
The cost of finding out late
Late gaps can mean a board redesign, additional submission questions or action on deployed devices, depending on the risk. A redesign adds cost and delay; the duration and the appropriate remedy depend on the actual problem.
None of that requires heroics to avoid. It requires asking five questions while the schematic is still a draft.
A short checklist for your next design review
- Does the processor support the chosen boot protections, and are key storage, authorised key changes and recovery addressed?
- Does the memory map support the selected update and recovery method, with headroom for growth?
- Is there a defined, tested recovery path if an update fails midway?
- Is there enough power budget to complete an update, including a policy for low-battery states?
- Can every connected component with its own firmware be updated, and has the supplier committed to that in writing?
- Where are keys generated and injected, and can the production line read them afterwards?
- Does the SBOM process produce a version matched to each released build?
How this fits the rest of the programme
Cybersecurity sits alongside the other workstreams between a prototype and a filing. If you are mapping those out, the seven workstreams article covers the sequence, and if you are still choosing who will do the engineering, the nine questions to ask a development partner covers that.
At Avantari we treat patchability as an architecture question, which is why it comes up in our first conversations about a connected device rather than in the month before submission. Our work spans PCB and embedded hardware design through firmware and embedded AI, on products including connected wearables. You can read how we approach regulated products on our medical wearables page.
Alongside the hardware and firmware architecture, we help clients prepare and maintain the software bill of materials.
Frequently asked questions
Does FDA require secure boot on medical devices?
The guidance does not mandate one specific technology. Explain and justify the controls chosen for the product's risks, including authenticity, update integrity and recovery. Secure boot is one common building block, but it is not a substitute for the complete design.
What counts as a "cyber device" under section 524B?
The statutory definition has three conditions: sponsor-authorised software, the ability to connect to the internet, and technological characteristics that could be vulnerable to cybersecurity threats. Check the complete system, including any companion app, against all three.
What changed in the February 2026 cybersecurity guidance?
FDA reissued its premarket cybersecurity guidance on 3 February 2026 to align with the Quality Management System Regulation. It introduced no new mandates; the substantive requirements from the June 2025 version remain, now framed as part of the quality system rather than separate from it.
How much flash do we need for over-the-air updates?
The required space depends on the update and recovery design. A/B slots need room for two application images plus boot code and metadata. Other designs can use protected recovery code or external storage. Allow for expected growth and test the chosen recovery path.
Who is responsible for vulnerabilities in a third-party radio module?
You are, as the manufacturer, in the eyes of the regulator. That is why supplier agreements should cover patch timelines, signed firmware and vulnerability notification before the part is designed in.
Can we add patchability after the hardware is finished?
Sometimes, in a limited way, and usually not well. Secure boot support, flash capacity and key storage are properties of the parts you chose. Adding them afterwards generally means a respin.
Ask us the awkward question early
If you have a connected device in architecture or already on a board, send us the processor, the radio and the memory map. We can review the update architecture, identify likely gaps and agree what needs testing. Talk to Avantari.
