Secure Your Medical Device with Cybersecurity Controls

If a control isn't tied to a specific threat, think of it as decoration.

That's right. Here's the deal. We've reviewed enough cybersecurity packages to know that the controls section is where most teams hide their weakest thinking. The easy part is writing down a long list of cybersecurity controls for a medical device.

Encryption, authentication, audit logging. They all sound good. But the real challenge is explaining the specific threats these controls address.

OK. This is something we see a lot of when reviewing medical device cybersecurity documentation. On the one hand, manufacturers have done a good job of having the right security measures in place, but on the other, they really haven't drawn the lines to the risks they're intended to reduce.

Need an approach? Try this. Your team should start with your threat model to implement cybersecurity controls effectively. Don't be afraid to get it started by jumping in the trenches and looking at each identified threat. Then ask yourself what you need to do to detect a problem, prevent an attack, or even recover if something goes wrong.

Then turn to the four traditional control categories (preventive, detective, corrective, and deterrent) to help organize the work.

Why is it important to choose the right medical device cybersecurity controls? Take our word for it. This tells FDA reviewers volumes. For one, it shows you understand where the cybersecurity controls belong. It also goes a long way in demonstrating you know that the controls are working correctly.

This article was designed to help you select as well as implement medical device cybersecurity controls. Establishing cybersecurity controls traceability is also covered. And, most importantly, learn how to avoid common mistakes that can leave your device vulnerable.

The four categories, applied to a medical device

Most cybersecurity training explains security controls using examples from banking or corporate IT systems. But medical devices are different. You're protecting sensitive information, certainly, but you're also dealing with equipment that may directly affect patient care.

When you're deciding which medical device cybersecurity controls to implement, it helps to understand the four basic categories: preventative, detective, corrective, and deterrent.

Each serves a different purpose, and most devices need a combination of them.

Preventative

Preventative controls are designed to stop an attack before it succeeds.

Here are four examples that apply directly to medical devices:

• Signed firmware images with anti-rollback. Your device's boot loader checks that firmware has a valid signature before running it. It also prevents someone from installing an older version with known vulnerabilities. This protects against supply chain tampering and rollback attacks.
• Mutual TLS on the device-to-cloud connection. Both the device and cloud server authenticate each other using certificates from a controlled certificate authority (CA). This helps prevent impersonation and man-in-the-middle attacks on the connection.
• Disabled debug interfaces in production. Interfaces such as JTAG, SWD, and UART can give attackers access to sensitive device functions. Manufacturers can physically remove them, permanently disable them with electrical fuses, or protect them with hardware authentication.
• Input validation at every protocol boundary. Medical devices often exchange information using HL7, FHIR, or DICOM. Because implementations of these protocols have experienced recurring parsing vulnerabilities, devices need to validate incoming data before processing it.

These controls don't eliminate every possible threat. But they can make it considerably harder for someone to compromise your device.

Detective

Detective controls help you recognize when someone has attempted an attack or when a security problem has occurred.

Think of them as your early warning system.

• Audit logs for authentication failures. If someone repeatedly tries to access an administrator account, you want to know about it immediately. You don't want to discover those failed login attempts six weeks later.
• Integrity monitoring on the running image. A device can periodically check portions of its running code against a signed manifest. This can help detect unauthorized changes to code in memory, particularly when the device operates on an untrusted network.
• Telemetry on cryptographic operation failures. A sudden increase in TLS handshake failures or signature verification errors could be an early indication of an attack or configuration problem.

The important thing is making sure someone or something actually monitors these signals.

Collecting logs that nobody reviews doesn't provide much protection.

Corrective

Corrective controls help contain damage and restore the device to a trusted state after something goes wrong.

For medical devices, recovery needs to account for both cybersecurity and patient safety.

• Rollback to last-known-good after a failed update. If a software update fails verification or doesn't pass integrity checks after installation, the device returns to its previous trusted version. Because software updates are an important attack surface, manufacturers need a recovery plan. The rollback mechanism must also prevent attackers from reinstalling known-vulnerable firmware.
• Forced re-authentication after detection events. If the system detects an integrity failure, it can invalidate active sessions and require users to authenticate again.
• Patch deployment mechanism with a defined service-level agreement (SLA). When someone discovers a vulnerability, you need to know how quickly your team can develop, test, and deploy a fix. Just as importantly, you need evidence that the process works.

A corrective control isn't simply a written procedure. Your team needs to know that it can actually perform the recovery when necessary.

Deterrent

Deterrent controls are intended to discourage attacks, even when they don't make an attack technically impossible.

Two examples are:

• Tamper-evident enclosures. These may not stop a determined attacker from opening a device, but they can leave visible evidence of interference. That can discourage covert tampering and help investigators understand what happened.
• Visible certifications and security claims in documentation. Information about FIPS 140 validation or third-party penetration testing may discourage opportunistic attackers by signaling that the manufacturer has invested in security. These claims should be accurate and supported by evidence.

Of the four categories, deterrent controls generally receive the least engineering attention.

Most of your effort will go toward preventative, detective, and corrective protections.

How to choose controls from your threat model

One of the biggest mistakes manufacturers make is choosing security controls before they've fully evaluated the threats.

If you're learning how to implement cybersecurity controls, your threat model should guide those decisions.

We recommend working through five questions for every threat you've identified.

1. Can you eliminate the threat by changing the design?

Start here because removing an attack surface is often better than trying to protect it.

For example, suppose your threat model identifies a debug interface that someone could use to extract firmware without authorization.

Instead of adding software protections, you might physically remove the interface or permanently disable it in production devices.

If the attack surface is gone, you may not need a runtime control for that particular threat.

2. Can one preventative control reduce the risk to an acceptable level?

Sometimes a single control provides enough protection.

If that's the case, document the control, explain how it addresses the threat, and record the residual risk.

Remember, residual risk is what remains after you've implemented the protection.

3. If one control isn't enough, can you combine two independent controls?

This is where defense in depth becomes important.

But two controls aren't necessarily better if they depend on the same underlying mechanism.

For example, requiring two cryptographic signatures may provide limited additional protection if both rely on the same compromised key infrastructure.

A cryptographic signature combined with hardware root-of-trust enforcement provides stronger defense in depth because the protections can fail in different ways.

4. Have you added a detective control?

A preventative control may fail without anyone realizing it.

That's why it's useful to pair preventative protections with monitoring that can identify attempted attacks or control failures.

For example, authentication controls can restrict access, while audit logs help identify repeated unauthorized login attempts.

5. Do you have a corrective control for threats that could affect patient safety?

If an attack could compromise patient safety, detecting the problem isn't enough.

You need a defined response and recovery process.

That might involve restoring trusted firmware, invalidating compromised sessions, or applying a security patch.

The recovery process must also preserve the device's essential clinical functions.

Once you've answered these questions, document the results in a controls table.

For each threat, include:

• Threat ID
• Primary security control or controls
• Detective control
• Corrective control
• Residual risk after mitigation
• Associated test case ID

This is where cybersecurity controls traceability becomes especially important.

Your documentation should make it easy to follow the connection from an identified threat to its mitigation and then to the testing that verifies the control works.

Our book chapter on security control implementation explains how to build this documentation.

Where controls map to FDA reviewer expectations

When FDA reviewers examine your cybersecurity documentation, they want to understand more than which protections you've installed.

They need to see why those controls were selected, what risks they address, and whether you've verified their effectiveness.

Here are six questions your documentation should answer.

• Have you identified the controls? Most manufacturers can provide a list. That's the easy part.
• Can you connect each control to a specific threat? This is where documentation often falls short. Reviewers need to understand what each protection is supposed to accomplish.
• Have you organized the controls? Identifying preventative, detective, and corrective controls helps explain their roles in your security strategy.
• Have you tested them? Each control should have appropriate verification evidence. Appendix 4 of FDA's premarket cybersecurity guidance identifies cybersecurity testing as part of the recommended submission documentation.
• Have you documented residual risk? Explain what risk remains after implementing the control and why that risk is acceptable. A numerical score without supporting rationale isn't enough.
• Do you have a postmarket monitoring plan? This is particularly important for detective controls. If your device generates security logs, explain how those logs will be reviewed and how suspicious activity will be handled.

Answering these questions clearly can help reduce the likelihood of an FDA Additional Information (AI) request.

For more guidance, see our book section on security controls documentation for eSTAR submissions.

Both FDA's premarket cybersecurity guidance (February 2026) and ANSI/AAMI SW96:2023 provide important direction on selecting, documenting, and verifying cybersecurity risk controls.

Neither requires every manufacturer to use the same security technologies. The important thing is demonstrating that your chosen controls appropriately address the risks associated with your device.

There's another important consideration: the FDA security control categories.

Section V.B.1 of FDA's guidance identifies eight categories manufacturers should consider when developing an adequate set of controls:

1. Authentication
2. Authorization
3. Cryptography
4. Code, Data, and Execution Integrity
5. Confidentiality
6. Event Detection and Logging
7. Resiliency and Recovery
8. Updatability and Patchability

These aren't the same as the four traditional categories discussed earlier.

The preventative detective corrective controls framework helps explain what a security measure does. FDA's eight categories help manufacturers evaluate whether they've addressed the necessary areas of cybersecurity.

A practical approach is to add a column to your controls table identifying the applicable FDA category.

If one of the eight categories isn't represented, document why it doesn't apply to your device.

That gives reviewers a clearer picture of your security strategy and helps your own team identify potential gaps.

Implementation pitfalls

Even when manufacturers select appropriate controls, problems can arise during implementation.

We've seen situations where the documentation describes strong security protections, but the actual device doesn't deliver what the documentation promises.

Here are five problems worth watching for.

Controls described in design, missing in build

Your architecture document says every firmware image must be digitally signed.

But when you examine the continuous integration (CI) pipeline, you discover that the signing step isn't actually being performed.

The result? An unsigned firmware image can make it into a production build.

A thorough penetration test should identify this weakness, but it can be missed if the tester simply checks whether firmware signing is supported rather than verifying that production devices enforce it.

The lesson is simple: Don't assume a control works because it's described in the design documentation.

Same key everywhere

Using one cryptographic key for multiple functions creates unnecessary risk.

Suppose the same key is used for firmware signing, telemetry signing, and TLS certificate issuance.

If that key is exposed through a lost laptop, repository misconfiguration, or former employee, several critical security functions could be compromised at once.

Separate keys according to their purpose and use hardware-backed protection where appropriate.

Detection without alerting

Your device generates audit logs, but nobody monitors them.

Technically, the detective control exists. Operationally, it isn't doing much.

You need a process for reviewing security events, identifying suspicious activity, and responding when something requires attention.

FDA reviewers may also want to understand how security alerts are evaluated and escalated.

No rotation plan

Cryptographic keys, certificates, and shared secrets don't last forever.

They may expire, become compromised, or need replacement as security requirements change.

If your design doesn't include a practical rotation procedure, your protections may become harder to maintain over the device's operational life.

Your Cybersecurity Management Plan should explain how these changes will be handled.

Patch path that's never been exercised

Your Cybersecurity Management Plan promises that security patches will be deployed within a specified number of days.

That sounds reassuring.

But has your team actually tested the complete process?

Can you develop a patch, verify it, distribute it, install it, and confirm that the device continues operating correctly?

If the first end-to-end test happens during an actual security incident, you're likely to discover problems at the worst possible time.

Testing the patch deployment process before you need it can prevent expensive delays later.

A control failure we've seen

Sometimes the biggest cybersecurity problems don't begin with an attack. They begin with a mistake that nobody catches until much later.

One particularly costly example involved a manufacturer using a single private key to sign firmware.

During a contractor handoff, that key ended up in a build script that was committed to a public mirror of an internal code repository.

Fortunately, the team discovered the exposure before anyone was known to have used the key maliciously.

But the damage was already significant.

Because the key was part of the firmware signing process, the manufacturer had to develop a plan to rotate the key and reflash every affected device that had shipped with that signing chain.

The postmarket remediation work ended up costing more than the original development effort.

What makes this example important isn't the technical complexity of the mistake. It's how easily the problem could have been avoided with better key management.

When you design medical device cybersecurity controls, you also need to think about how they'll be maintained throughout the product's life.

Who has access to signing keys? Where are those keys stored? How will they be rotated? What happens if one is compromised?

And if a problem affects devices already in clinical use, how will you correct it without disrupting patient care?

Those questions belong in your security planning from the beginning.

A control isn't truly effective just because it works when the device ships. It also needs to remain manageable, testable, and secure throughout the device's operational life.

Where to go next

Choosing and implementing cybersecurity controls starts with understanding your device's risks.

If you need help with that foundation, our articles on FDA cybersecurity risk assessment rules and threat modeling for cloud-connected medical devices explain how to identify threats and evaluate their potential impact.

Once you've implemented your controls, the next step is verifying that they work.

CyberMed's medical device penetration testing services help manufacturers identify weaknesses and evaluate how their protections perform against realistic attack scenarios.

If you need help with the entire cybersecurity process, our 30-day CyberSprint brings the work together in a single engagement.

Need help with your cybersecurity controls and the traceability behind them? 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
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers. https://array.aami.org/doi/book/10.2345/9781570208621