Ensuring Secure Software Updates for Medical Devices

The update path is the attack surface most teams underestimate. It's a privileged code-execution capability that you ship to every device in the field. If an attacker can convince a device to install firmware that you didn't sign, every other control on the device is irrelevant — the attacker now controls the platform those controls run on.

So before talking about update mechanics, the design constraint to lock in is this: the device must refuse to execute any code that did not come from your signing infrastructure, regardless of how it got onto the device. That constraint shapes every architectural decision below.

This is also what FDA expects in the cybersecurity package — both the 2023 and 2025 premarket guidance treat update mechanisms as a cybersecurity-relevant subsystem, not a convenience feature.

The foundation: root of trust

Everything starts with a hardware root of trust. Without it, "secure" software update is theater — an attacker who can replace the boot loader can also replace whatever verifies subsequent updates.

A workable root of trust for a medical device has these properties:

• Boot ROM is immutable. Mask ROM, OTP fuses, or hardware-locked flash regions. The first code that runs on the processor cannot be modified after manufacture.
• The boot ROM holds, or knows how to derive, the public key (or hash of it) used to verify the next stage. Burning the public key hash into OTP at manufacture is the common pattern.
• The boot ROM verifies the next stage before executing it. Cryptographic signature check against the manufacturer's public key. Failure means halt, not "boot anyway and log."
• Debug interfaces affecting boot are physically or cryptographically gated. JTAG that lets an attacker single-step through the verification check makes the rest of the architecture pointless.

Many processor vendors include "developer mode" or backdoor mechanisms intended for factory programming. These must be permanently disabled before product is shipped. The fuses to disable them are typically one-shot. Burning them is part of the production process, not a runtime configuration.

With the boot ROM trusted, it verifies a second-stage boot loader, which verifies the application image. This forms the cryptographic root of trust the rest of the system relies on. The next-stage software can usually live in external flash, since the boot ROM's signature check makes external storage as trustworthy as internal storage — but only for integrity. If you need confidentiality of the firmware as well, that's a separate problem requiring encrypted boot.

The update sequence

A secure update has three steps. Each one has cryptographic primitives at specific points; weakness in any one of them collapses the whole chain.

1. Download from a trusted source

The device contacts an update server. Before accepting anything from that server, the device must verify it's talking to the real one. The standard primitive is TLS with server certificate verification — but for medical devices, mutual TLS is the right baseline. Both sides authenticate. The device's certificate, provisioned at manufacture, is what the server uses to verify it's talking to a legitimate device. The server's certificate, anchored to a CA whose root is provisioned into the device, is what the device uses to verify the server.

Watch for:

• CA pinning, not just generic TLS validation. A device that trusts any public CA is a device that trusts any CA an attacker can get a cert from.
• Revocation handling. If a device certificate is compromised, you need a path to invalidate it. OCSP, short-lived certificates, or an explicit revocation list pulled at a defined cadence.
• Time-of-check vs. time-of-use. Verify the channel before any bytes of the update touch durable storage.

2. Cryptographic verification of the update

The update payload itself must be signed by the manufacturer's signing key. The device verifies the signature before applying anything. Specifically:

• Compute a cryptographic hash of the payload (SHA-256 minimum, SHA-384 or SHA-512 preferred).
• Verify the signature on that hash against the manufacturer's signing public key.
• Verify the manifest version is greater than or equal to the currently installed version (anti-rollback).
• Verify the manifest's target device class matches this device.

A common mistake is to perform the channel authentication (step 1) but skip the payload signature (step 2), trusting the channel. Don't. The channel might be terminated by a load balancer, a reverse proxy, or a compromised CDN node that the manufacturer doesn't fully control. The payload signature is what binds the bytes to the manufacturer, regardless of how they got to the device.

A second common mistake is to use the same signing key as for production code-signing on developer laptops. Code-signing keys live in HSMs. Developer laptops are not HSMs.

3. Application with integrity binding to subsequent boots

Once the update is verified, the device writes it to storage and re-anchors the chain of trust:

• Atomic install. The new image either fully replaces the old one or fully fails. A partial install leaves the device in an undefined state.
• Hash storage. Store the hash of the installed image in non-volatile storage, signed or in a write-protected region. Next boot, the boot loader re-verifies the running image against this stored hash.
• Rollback to last-known-good on first-boot failure. If the new image fails integrity check on first boot, or fails a defined health check after first boot, automatically revert. Otherwise a corrupted update bricks the device.
• Anti-rollback enforcement. Once an updated image is committed as the new known-good, the device refuses to install older versions. The reason this matters: an attacker who can present an older, still-signed image containing a known vulnerability has a viable attack if anti-rollback isn't enforced.

Failure modes I look for

When I review an update implementation, this is the checklist I run through. Each item is a real failure I've seen.

Failure mode	Why it matters	Mitigation
Unsigned hotfix path	A "developer override" left enabled in production accepts unsigned images.	Remove the override entirely from production builds. Verify in pen test.
Single signing key for all functions	One key compromise affects firmware signing, telemetry signing, TLS certs.	Separate keys per function. Hardware-backed where impact is high.
No anti-rollback	Attacker installs an older, signed-but-vulnerable image.	Enforce minimum-version check on every install.
Boot loader doesn't re-verify on each boot	A one-time install check doesn't catch in-place tampering.	Re-verify the running image hash against signed manifest on every boot.
Debug interface enabled in production	Attacker bypasses the entire chain through JTAG.	Fuses burned at manufacture. Physical inspection in QA.
No key rotation plan	Keys leak eventually. Field devices then have no path to recover.	Design rotation into the architecture before launch. Test the rotation.
Update channel uses one-way TLS only	Server doesn't authenticate the device; arbitrary devices can fetch updates intended for specific units.	Mutual TLS with per-device certificates provisioned at manufacture.
Patch path never exercised	First real-world patch surfaces every bug under deadline pressure.	Deploy an inert update through the live channel before launch. Treat it like a fire drill.

If your design handles every row in that table, you have a defensible architecture. If it doesn't, the row that's missing is also the failure mode that will eventually become an FDA Additional Information request or, worse, a post-market disclosure.

How this maps to the cybersecurity package

Most of the update architecture lives in the Security Architecture Views and the Cybersecurity Controls section. The lifecycle pieces — key rotation, patch cadence, incident response when a key is compromised — live in the Cybersecurity Management Plan. The Cybersecurity Testing Report should include test cases that exercise the update path under adversarial conditions, not just under happy-path conditions.

A reviewer looking at the update mechanism will ask:

• How is the device authenticated to the server, and the server to the device?
• What signs the update payload, and what protects that signing key?
• How is the device protected against rollback to an older signed image?
• What happens on a failed update? On a corrupted post-install boot?
• How are keys rotated over the device's operational life?

Each question maps to a specific control and a specific test case. Answering them concretely is the difference between a clean cybersecurity package and a long AI request.

At CyberMed we've seen

The update mechanism is the single design area where small architectural compromises cost the most in the field. I've seen teams ship products where the update path was technically signed but the signing was done on a developer machine with the key in a ~/.config directory — the moment that machine was lost or replaced, the team had no path to issue a new update. The product was secure on day one and unmaintainable by day ninety.

The fix is not technically complex. Generate signing keys in an HSM. Sign update payloads in CI, never on a developer machine. Have a tested rotation procedure on paper before the first production unit ships. The teams that get this right at launch don't think about it again. The teams that get it wrong rediscover it under deadline pressure during a security incident.

[NEEDS: anonymized example from Mohamad on a specific update-path failure, if appropriate to publish]

Where to go next

For the surrounding work that makes secure updates part of a complete cybersecurity package, see FDA cybersecurity requirements for medical devices and how to implement cybersecurity controls.

If you want a second set of eyes on your update architecture before launch, our services page lists the engagement models we use. Update-path review is one of the most common scopes we get asked for.