Ensuring Secure Software Updates for Medical Devices

There's no shortage of challenges when you're developing a medical device.

It's easy to focus on protecting the device itself and give less thought to how you'll update its software once it's in the field.

But keep this in mind. That important update process can become a significant security vulnerability headache if it isn't designed the right way.

Why is that? Look at it this way. Sending software updates gives a medical device instructions that can change how it operates. It also gives an attacker an opening to slip malicious firmware into the process. If your device accepts the update, the attacker could gain control of the software that your other security protections depend on.

Here's a basic rule your secure software update for medical devices needs to start with:

Never run firmware of software that hasn't been verified as coming from your authorized signing infrastructure.

Your objective is to have a secure boot medical device design that helps enforce that protection, while anti-rollback firmware controls prevent someone from reinstalling an older, vulnerable version.

As it turns out, this is also an important part of medical device firmware update security under FDA expectations. The agency's February 3, 2026, premarket cybersecurity guidance identifies firmware and software updates as a security control category in Appendix 1. Section V.B.2.

It also calls for an FDA updatability and patchability view showing how updates move through your system from beginning to end.

The focus of this article is on how you can build a secure update process. This includes how to protect it from common attacks. And, last but not least, you will learn about documenting the safeguards FDA expects to see.

The foundation: root of trust

Before you can make software updates secure, you need to know that your device can be trusted to run only authorized code.

That's where a hardware root of trust comes in.

Think of it as the starting point for your device's security. If an attacker can replace the boot loader, they may also be able to bypass the protections that verify software updates.

For a secure boot medical device, that initial verification process needs to be protected at the hardware level.

Here's what that involves:

• Boot ROM that can't be changed. The first code your processor runs should be stored in mask ROM, protected by one-time programmable (OTP) fuses, or held in hardware-locked flash memory. Once the device is manufactured, that code shouldn't be modifiable.
• A trusted public key. The boot ROM needs access to the manufacturer's public key, or a way to derive or verify it, so it can authenticate the next stage of the boot process. A common approach is to store a hash of the public key in OTP memory during manufacturing.
• Verification before execution. Before running the next stage, the boot ROM checks its cryptographic signature against the manufacturer's public key. If verification fails, the device must not execute that code.
• Protected debug interfaces. Interfaces such as JTAG can allow someone to interfere with the boot process. They need to be physically disabled or protected with cryptographic authentication so an attacker can't bypass signature verification.

There's another detail manufacturers sometimes overlook.

Many processors include developer modes or special access features intended for factory programming and testing. Those features need to be permanently disabled before the device ships.

This often involves burning one-time fuses during manufacturing. It's a production step, not a setting you can safely leave for later.

Once you've established a trusted boot ROM, it verifies the second-stage boot loader. That boot loader then verifies the application image.

Each stage checks the next one before allowing it to run.

The application software can often reside in external flash memory because the boot ROM's signature verification protects its integrity.

But there's an important distinction: integrity isn't the same as confidentiality.

Signature verification helps establish that firmware hasn't been altered. If you also need to prevent someone from reading the firmware, you'll need additional protections, such as encrypted boot.

The update sequence

Once your device has a trusted boot process, you can focus on how updates are delivered and installed.

For secure software updates medical devices manufacturers can rely on, the process needs to protect three things: where the update comes from, whether the update itself is authentic, and what happens when the device installs it.

Each step matters. A weakness in any one of them can undermine the entire update process.

1. Download from a trusted source

The first step is making sure your device is communicating with the correct update server.

You don't want it downloading firmware from a server controlled by an attacker.

Transport Layer Security (TLS) provides an encrypted connection and allows the device to verify the server's certificate.

For medical devices, mutual TLS is a strong baseline because both sides authenticate each other.

Here's how it works.

Your device receives its own certificate during manufacturing. When it connects to the update server, the server uses that certificate to verify the device's identity.

The device also checks the server's certificate against a trusted certificate authority (CA) configured in the device.

That way, neither side has to assume the other is legitimate.

There are three additional details worth checking:

• CA pinning. Don't rely solely on generic TLS certificate validation. Restrict which certificate authorities your device trusts for update delivery. Otherwise, a certificate issued through an unexpected authority could create an opportunity for impersonation.
• Certificate revocation. You need a way to invalidate a device certificate if it's compromised. Options include Online Certificate Status Protocol (OCSP), short-lived certificates, or a revocation list that devices retrieve at defined intervals.
• Verification before storage. Authenticate the connection before allowing update data to be written to persistent storage. This helps prevent untrusted data from entering the update process.

These protections help establish a trustworthy connection.

But a secure connection alone doesn't guarantee that the firmware being delivered is legitimate.

That's why the next step is essential.

2. Cryptographic verification of the update

Even when an update arrives through a trusted connection, your device still needs to verify the update package itself.

The firmware should carry a digital signature created using the manufacturer's signing key.

Before installing the update, the device should:

• Calculate a cryptographic hash. Use SHA-256 at minimum, with SHA-384 or SHA-512 preferred where appropriate.
• Verify the digital signature. Compare the signature against the manufacturer's trusted public key.
• Check the firmware version. Confirm that the update meets the device's minimum permitted version requirements. This is an important part of anti-rollback firmware protection.
• Confirm device compatibility. Check the update manifest to make sure the firmware is intended for that particular device class.

Why are these checks necessary if you're already using TLS?

Because the update may pass through systems you don't completely control.

A load balancer, reverse proxy, or content delivery network (CDN) could be involved in delivering the package. If one of those components is compromised, an authenticated connection alone may not protect the firmware.

The digital signature provides an independent way to verify that the update came from your authorized signing infrastructure.

There's also the question of protecting the signing key.

Don't store production firmware-signing keys on developer laptops.

Those keys should be protected using hardware security modules (HSMs), with access restricted to authorized signing operations.

If someone obtains your signing key, they may be able to create firmware that your devices recognize as legitimate.

That's a much bigger problem than a compromised update server.

3. Application with integrity binding to subsequent boots

Once the device has verified the update, it can install the new firmware.

But the security checks shouldn't stop there.

You also need to make sure the installation completes correctly and that the device continues running trusted software afterward.

Four protections are especially important.

• Atomic installation. The update should either install completely or fail without leaving the device in an unpredictable state. A partially installed firmware image can make the device unusable.
• Protected hash storage. Store the installed image's hash in nonvolatile memory, either signed or protected against unauthorized modification. During subsequent boots, the boot loader should verify the image against the trusted hash or signed manifest.
• Recovery after a failed update. If the new firmware fails its integrity check or doesn't pass a defined health check after installation, the device should return to the last known good image. This helps prevent a failed update from permanently disabling the device.
• Anti-rollback enforcement. Once a new firmware version has been accepted, the device should reject older versions that fall below its permitted version threshold.

That last point deserves particular attention.

An older firmware image may still carry a perfectly valid manufacturer signature.

But if it contains a known vulnerability, allowing someone to reinstall it could expose your device to an attack you've already addressed.

That's why medical device firmware update security needs both signature verification and anti-rollback protection.

One confirms that the firmware is authentic. The other helps prevent attackers from exploiting vulnerabilities in outdated versions.

Failure modes we look for

Even when manufacturers understand how secure updates should work, implementation mistakes happen.

And some of the most serious problems aren't complicated attacks. They're small oversights that make otherwise strong protections ineffective.

When reviewing an update system, these are eight problems we look for.

Failure mode	Why it matters	What to do about it
Unsigned hotfix path	A developer override left enabled in production allows the device to install unsigned firmware.	Remove the override from production builds and verify the protection through penetration testing.
Single signing key for multiple functions	If one key handles firmware signing, telemetry signing, and TLS certificates, a compromise can affect several critical security functions.	Use separate keys for different purposes, with hardware-backed protection where the risk justifies it.
No anti-rollback protection	An attacker may be able to install an older, legitimately signed firmware version containing known vulnerabilities.	Enforce minimum-version requirements during every installation.
Boot loader doesn't verify every boot	Checking firmware only during installation may allow unauthorized modifications to go undetected later.	Verify the running image against its trusted hash or signed manifest during every boot.
Debug interfaces enabled in production	An exposed JTAG interface may allow attackers to bypass the boot verification process.	Permanently disable the interface during manufacturing and verify the result through physical inspection and quality assurance.
No key rotation plan	If a signing key is compromised, devices already in use may have no reliable way to establish trust in a replacement.	Design key rotation into the architecture and test the process before launch.
Update channel uses one-way TLS only	The server authenticates itself to the device but doesn't verify the device's identity. Unauthorized devices may be able to request updates intended for specific units.	Use mutual TLS with individual device certificates provisioned during manufacturing.
Patch deployment process never tested	The first real security patch may expose problems in the update system when the manufacturer is already facing a deadline.	Deploy a harmless test update through the production update process before launch.

If your design addresses these problems, you're in a much better position to demonstrate that your update mechanism is secure.

If it doesn't, those weaknesses could become issues during FDA review or, worse, vulnerabilities discovered after devices are already in use.

The important thing is finding and fixing them before that happens.

How this maps to the cybersecurity package

Building a secure update mechanism is one part of the job. You also need to document how it works.

For an FDA submission, that means connecting the update architecture to your cybersecurity risk management activities and supporting it with testing evidence.

Most of the technical design belongs in your Security Architecture Views and Cybersecurity Controls documentation.

That includes how firmware is authenticated, how the update process is protected, and what happens when verification fails.

Your FDA updatability and patchability view should show the complete update process, including the components involved and the security protections applied along the way.

Other information belongs in the Cybersecurity Management Plan.

For example, how often will you issue patches? How will you rotate cryptographic keys? What happens if a signing key is compromised after devices have been deployed?

These are lifecycle questions that need answers before the product reaches the market.

Our book section on cybersecurity management plan documentation explains what to include.

You'll also need evidence in your Cybersecurity Testing Report.

And that testing should go beyond confirming that a legitimate update installs successfully.

You should also test what happens when someone tries to install unauthorized firmware, interrupt an update, or bypass version restrictions.

When FDA reviewers examine your update mechanism, they should be able to find answers to five questions:

1. How do the device and update server authenticate each other?
2. What signs the update package, and how is the signing key protected?
3. How does the device prevent installation of older, vulnerable firmware?
4. What happens if an update fails or the device can't boot correctly afterward?
5. How will cryptographic keys be rotated throughout the device's operational life?

Each answer should connect to a documented security control and the testing performed to verify it.

That's what makes the documentation useful to reviewers.

Instead of simply stating that your device supports secure updates, you're showing exactly how the protections work and providing evidence that they've been tested.

Clear documentation can also help reduce the likelihood of an FDA Additional Information request.

What goes wrong in the field

Some of the most expensive software update problems don't become obvious until a device is already on the market.

We've seen manufacturers develop update systems that appear secure during testing but become difficult to maintain once devices are deployed.

Consider a situation where firmware updates are digitally signed, but the signing process depends on a developer's computer.

The private key is stored in a configuration directory on that machine.

Everything works until the computer is lost, replaced, or becomes unavailable.

Suddenly, the manufacturer may no longer have access to the key needed to sign new updates.

The device was secure when it shipped, but the manufacturer now has a serious problem maintaining it.

This is why secure software updates for medical devices require more than a reliable installation process.

You also need to think about how the system will be maintained over the device's entire operational life.

A better approach is to generate and protect signing keys using an HSM.

Firmware signing should take place through a controlled continuous integration (CI) process rather than on individual developer computers.

Our book chapter on secure build and release processes explains how to organize this work.

You should also establish and test a key rotation procedure before shipping the first production device.

That way, if a key is lost or compromised, your team already knows how to recover.

The manufacturers that plan for these situations early are much less likely to find themselves scrambling during a security incident.

Where to go next

A secure software update process is an important part of protecting medical devices, but it needs to fit into your broader cybersecurity program.

If you're still working through the regulatory requirements, our article on FDA cybersecurity requirements for medical devices explains what manufacturers need to consider.

You can also read our guide on how to implement cybersecurity controls to see how update protections fit into a larger security strategy.

For devices already on the market, our book section on developing and deploying patches covers the planning and implementation considerations involved in delivering security fixes.

And if you'd like an experienced team to review your updated architecture before launch, CyberMed can help.

Our services page explains the different ways we work with manufacturers, including reviews of firmware update security and related cybersecurity controls.

Need help with secure software updates or your cybersecurity documentation? Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• Federal Food, Drug, and Cosmetic Act, Section 524B, Ensuring Cybersecurity of Devices (21 U.S.C. 360n-2). https://www.law.cornell.edu/uscode/text/21/360n-2