Secure Your Medical Device with Cybersecurity Controls

A control that isn't tied to a specific threat is decoration. I've reviewed enough cybersecurity packages to know that the controls section is where most teams hide their weakest thinking — long lists of generic security mechanisms (encryption at rest, authentication, audit logging) with no traceability back to the threats they're supposed to mitigate.

The four control categories most security teams use — preventative, detective, corrective, deterrent — are useful, but only after you've answered the question they're answering. Which is: for each threat in my model, what specific behavior do I need from the system to keep the threat below my acceptance threshold?

This post walks through how to choose controls deliberately, where to put each type for a medical device, and the failures I see most often when reviewers (or attackers) look closely.

The four categories, applied to a medical device

Generic security training teaches the four categories with banking and enterprise examples. The medical-device versions look different.

Preventative

Controls that stop a threat from being realized.

• Signed firmware images with anti-rollback. The boot loader will not execute an unsigned image and will not accept a downgrade to a known-vulnerable older version. Mitigates supply-chain tampering and rollback attacks.
• Mutual TLS on the device-to-cloud connection. Both endpoints authenticate with certificates issued from a controlled CA. Mitigates impersonation and man-in-the-middle on the back-haul.
• Disabled debug interfaces in production. JTAG, SWD, UART consoles either physically removed, electrically fused, or gated behind hardware authentication. Mitigates physical access attacks.
• Input validation at every protocol boundary. Especially HL7, FHIR, and DICOM, which have all had recurring parser bugs across implementations.

Detective

Controls that don't prevent the threat but ensure you'll know when it's been attempted or realized.

• Audit logs for authentication failures. A spike in failed admin authentications is something you want to see, not something to discover six weeks later.
• Integrity monitoring on the running image. Periodic re-verification of code regions against the signed manifest. Detects in-memory tampering on devices that have to operate connected to hostile networks.
• Telemetry on cryptographic operation failures. A sudden increase in TLS handshake failures or signature verification errors is often the first signal of a problem.

Corrective

Controls that limit damage after a failure or get the system back to a known-good state.

• Rollback to last-known-good after a failed update. If an update fails verification or fails post-install integrity checks, the device boots the previous image. The update path is one of the highest-impact attack surfaces a connected device has; assume something will go wrong eventually.
• Forced re-authentication after detection events. A detected integrity failure invalidates active sessions.
• Patch deployment mechanism with a defined SLA. When a vulnerability is found, you have an answer to "how fast can you push the fix" — and you've tested it.

Deterrent

Controls that make an attack less attractive without necessarily being technically harder.

• Tamper-evident enclosures. Don't stop a determined attacker but produce visible evidence that lowers the value of a stealth attack and supports post-incident analysis.
• Visible certifications and security claims in documentation. FIPS 140 validation, third-party penetration test summaries. Signal to a casual attacker that this is not the cheapest target on the floor.

The deterrent category is the smallest. Most of your engineering goes into the first three.

How to choose controls from your threat model

I prefer a simple decision flow for picking controls. Run it against every threat in the model, in order:

1. Can you eliminate the threat by changing the design? If yes, do that. A removed attack surface is the strongest control. Example: if your threat is "debug interface used for unauthorized firmware extraction," the design fix is to physically remove or permanently fuse the debug interface in production builds. No runtime control needed.

2. Can a single preventative control reduce the threat below the acceptance threshold? If yes, that's your primary mitigation. Document it. Note the residual risk explicitly.

3. If no single preventative control suffices, can you stack two independent controls? Defense in depth, not defense in repetition. "Two cryptographic signatures" is defense in repetition if both use the same key infrastructure. "Cryptographic signature plus hardware root of trust enforcement" is defense in depth — they fail differently.

4. Add a detective control alongside every preventative control. If the preventative control fails silently, you've shipped a vulnerability with a confidence display.

5. Add a corrective control for any threat whose impact crosses into patient safety. Detection without correction is observation. For safety-impacting threats, you need a defined recovery path.

The output of this flow is a row in your controls table for each threat: threat ID, primary control(s), detective control, corrective control, residual risk after mitigation, test case ID. That table is what reviewers want to see.

Where controls map to FDA reviewer expectations

A reviewer looking at your cybersecurity package will check, in this order:

• Are controls listed? Yes, in most packages.
• Are they tied to specific threats? Often no. This is the first place reviewers push back.
• Are they categorized? Preventative vs. detective vs. corrective is enough. Lists with no structure are a red flag.
• Are they tested? Each control should have a test case in the Cybersecurity Testing Report.
• Is residual risk documented after each control? With rationale, not just a number.
• Is there post-market monitoring for the controls? Especially the detective ones. A logging control that nobody reads is not a control.

If you can answer yes to every one of those, the controls section of your package will not generate AI requests. The FDA's 2023 premarket cybersecurity guidance and ANSI/AAMI SW96 both describe what the controls section should contain. Neither is prescriptive about specific technologies; both are prescriptive about traceability.

Implementation pitfalls

The patterns I see most often when controls turn out to be weaker than the documentation claims:

Controls described in design, missing in build. Signed firmware is in the architecture document. The CI pipeline doesn't actually sign the artifact. The unsigned binary ships. This is caught by a thorough penetration test, but not always — sometimes a tester checks "is signing present" and assumes a release artifact that boots successfully on a development board has been signed.

Same key everywhere. One signing key used for firmware, telemetry signing, and TLS certificate issuance. When that key leaks (and at some point it will — laptop loss, repo misconfiguration, ex-employee), the blast radius is the entire system. Separate keys per function, hardware-protected where it matters.

Detection without alerting. Audit logs are generated. Nobody monitors them. The detective control is technically present but operationally absent. Reviewers will ask how alerts are triaged.

No rotation plan. Cryptographic keys, certificates, shared secrets. All have lifetimes. If your design has no rotation procedure, the controls degrade over the device's operational life. The Cybersecurity Management Plan needs to address this explicitly.

Patch path that's never been exercised. The Cybersecurity Management Plan says "patches will be deployed within X days." The team has never deployed an actual patch end-to-end. The first real-world patch will surface every bug in the deployment path while the clock is running on a disclosed vulnerability.

At CyberMed we've seen

The most consequential control failure I've seen wasn't an attack. It was a key-management mistake: a single private key used to sign firmware, embedded in a build script committed to a public mirror of an internal repo during a contractor handoff. The vulnerability was discovered internally — the team caught it before any malicious use — but every device that had ever shipped with that signing chain needed a key-rotation and re-flash plan, and the post-market work cost more than the original development.

The lesson is operational, not technical: controls need lifecycle thinking from the moment they're designed. Who holds the keys, how they rotate, what happens when one is exposed, how the post-market plan handles the rotation. None of that is novel security work. All of it is what separates a real control from a documented one.

[NEEDS: anonymized control-failure pattern from Mohamad, if there's a more publishable example]

Where to go next

For the upstream work that controls map back to, see the FDA cybersecurity risk assessment rules and threat modeling for cloud-connected medical devices.

For verifying that the controls you've built actually work, medical device penetration testing is the service that exercises them under real attack conditions. If you need the full cybersecurity workstream done as a single engagement, the 30-day CyberSprint covers it.