Why Medical Device Cybersecurity Has to Start Before the Pen Test

‍

Most conversations about medical device cybersecurity start with the same list: encryption, authentication, secure boot, firmware signing. These are real, necessary controls, and teams are right to invest in them. But they can also create an assumption that cybersecurity is a set of features added to a device and checked off during development.

‍

That assumption breaks down once you follow a vulnerability all the way to its consequences.

‍

Consider an implantable medical device whose electrode voltage can be configured over BLE. An attacker gains elevated privileges and sends an unauthorized voltage value to the implant. The first failure is cybersecurity: the attacker has bypassed the intended authorization boundary and altered a safety-relevant parameter. If the implant applies that value, the consequence is no longer confined to the communication interface. The implanted device itself can behave in a way that contributes to a hazardous situation for the patient.

‍

Cybersecurity in medical devices is not a feature added at the end. It must shape requirements and architecture, even as those decisions can still change.

‍

Security risk and safety risk remain separate analyses, but they cannot be isolated from each other. If a cybersecurity threat can alter device behavior, the analysis has to continue beyond the security consequence and evaluate whether that behavior can contribute to a hazardous situation. When a cybersecurity finding has safety relevance, that relationship needs to be identified and traced so it can be evaluated within the safety risk-management process rather than ending at “integrity compromised.”

‍

Late Cybersecurity Becomes a Design Problem

‍

A vulnerability does not necessarily start with an attack. It can start as a weakness introduced through source code, architecture, configuration, an interface, or a design decision.

‍

If the first security review happens during penetration testing, many findings may no longer be simple software fixes. They may expose architectural assumptions: trusted interfaces without authentication, excessive privileges, accessible debug paths, or update mechanisms designed without considering misuse.

‍

At that point, the team is no longer deciding how the system should be designed. It is deciding how much of an established design can still be changed.

‍

This is why security questions need to enter the project while requirements and architecture are still being defined.

‍

Threat Modeling Has to Influence the Architecture

‍

Threat modeling requires understanding what the system consists of and what needs protection: components, assets, interfaces, data flows, trust relationships, and external connections.

‍

One method for structuring that analysis is STRIDE:

‍

• Spoofing: pretending to be a trusted entity
• Tampering: modifying data or code
• Repudiation: performing an action the system cannot later attribute
• Information Disclosure: exposing information to unauthorized parties
• Denial of Service: preventing legitimate access to a function or service
• Elevation of Privilege: gaining permissions beyond those intended

‍

The point is not to complete a STRIDE table for the documentation package. The point is to identify design assumptions that need to change while changing them is still practical.

‍

A threat model written after the architecture is complete but that does not influence the architecture has limited engineering value.

‍

Legitimate Functionality Can Create Attack Surfaces

‍

For devices that support Firmware Over-the-Air (FOTA) updates, the update path provides a way to maintain software and address vulnerabilities after release. But the same mechanism deliberately allows new executable software to enter the device.

‍

That raises design questions: Who can authorize an update? How is the image authenticated? How is its integrity verified? Can a device be rolled back to a version with a known vulnerability? What happens if the update is interrupted? Which interfaces are available during the process?

‍

The update path therefore needs its own threat analysis.

‍

The same reasoning applies to BLE, USB, debug ports, service interfaces, mobile applications, and other paths into the system. An interface does not become secure because its intended use is legitimate. You must also consider its behavior under misuse.

‍

Security Findings Have to Become Engineering Work

‍

Once threats are identified, they need to become requirements, controls, and verification evidence.

‍

A security requirement that cannot be verified is not yet a useful engineering requirement.

‍

Security verification also needs more than a final penetration test. Static analysis can identify secure-coding violations while implementation is still changing. Fuzz testing can exercise interfaces with malformed or unexpected inputs that functional tests may never generate. Penetration testing then provides another layer of assessment at the integrated-system level.

‍

Security requirements and implemented controls also need traceability into verification activities. Finding a threat is only the start; the engineering process needs to show what was done about it and whether the resulting control works.

‍

‍

Cybersecurity Does Not End at Release

‍

An SBOM identifies the third-party components and versions used in a product, but the inventory itself is only useful if it supports action. When a new vulnerability is disclosed in a dependency, the manufacturer needs to determine whether the device is affected, assess the associated risk, and decide whether remediation is required.

‍

This is where software transparency, traceability, and secure update mechanisms come together. The SBOM helps identify exposure, the risk-management process determines its significance, and mechanisms such as FOTA can provide a path to deploy a fix when one is needed.

‍

A lifecycle approach to cybersecurity therefore has to account not only for how vulnerabilities are prevented before release, but also for how they will be identified, assessed, and addressed after the device is in use.

‍

Regulation Is Making the Evidence More Explicit

‍

FDA cybersecurity expectations have become more explicit over time. The June 2025 final premarket cybersecurity guidance expanded the level of detail expected around security risk management, architecture, testing, software transparency, and planning for post-release vulnerabilities. The February 2026 revision is the current version and aligns the guidance with the Quality Management System Regulation (QMSR).

‍

IEC 81001-5-1 adds security activities across the software lifecycle in a way that maps naturally onto lifecycle processes familiar from IEC 62304.

‍

The result is not simply more documentation. The evidence needs to show that security decisions were made, implemented, traced, and verified.

‍

What This Means for Our Work at Focus

‍

For us at Focus, incorporating cybersecurity does not mean creating a parallel development process. It means extending disciplines we already use in medical-device development: requirements, architecture, risk management, coding standards, static analysis, verification, traceability, and regulatory documentation.

‍

Cybersecurity adds another set of questions to that process: How can this interface be abused? Which assets need protection? Where does the architecture assume trust? Which threats could affect safety? What controls are required? How will those controls be verified?

‍

The practical step is to integrate those cybersecurity questions into the same engineering process used to bring a medical device toward commercialization, so that security requirements, controls, and evidence evolve together with the product.

‍

The useful question is not “What security features does this device have?” but “At what point in development did cybersecurity start influencing its requirements and architecture?”

‍

If you are developing a medical device and want to integrate cybersecurity from the beginning, talk to our team.

‍

‍