Medical Device Cybersecurity

STRIDE is a threat-modeling methodology originally developed at Microsoft and later popularized by security researcher Adam Shostack. It gives engineering teams a structured way to walk through a system's architecture and ask, systematically, what could go wrong — instead of relying on intuition or a generic checklist. The name is an acronym for six threat categories:

• Spoofing — an attacker impersonates a legitimate user, device, or component (e.g. a rogue mobile app pretending to be the device's paired companion app).
• Tampering — data or code is modified without authorization (e.g. a firmware update package altered in transit).
• Repudiation — an action is taken and the system can't prove who performed it, due to missing or unreliable audit trails (e.g. a dosage change with no verifiable log of who issued it).
• Information Disclosure — sensitive data is exposed to parties who shouldn't see it (e.g. patient data sent over an unencrypted channel).
• Denial of Service — the system's availability is degraded or blocked (e.g. a wireless interface flooded so legitimate commands can't get through).
• Elevation of Privilege — an attacker gains capabilities they shouldn't have (e.g. bypassing authentication to issue a command reserved for clinicians).

Applied to a data-flow diagram of the device — its processes, data stores, external entities, and the trust boundaries between them — STRIDE surfaces concrete, device-specific threats early, before a single test is run against a real build.

Threat modeling and penetration testing answer different questions, and the order matters. Threat modeling is a design-time, architecture-level exercise: it asks what could go wrong based on how the system is built, before it's fully built. Penetration testing is implementation-time: it tries to actually break a running system. Running threat modeling first is standard secure-development practice, reflected in guidance like NIST's secure software development framework and OWASP's own testing guides, for a few concrete reasons:

• It scopes the pentest. Without a threat model, a pentest tends to probe generically; with one, testers can target the specific attack paths the architecture makes possible — BLE pairing, a specific API endpoint, a firmware update mechanism — instead of guessing.
• It catches design flaws while they're cheap to fix. A trust-boundary mistake found on a whiteboard costs a design change; the same mistake found in a pentest report after implementation costs a rework.
• It's what regulators expect to see. FDA's premarket cybersecurity expectations for medical devices call for a documented threat-modeling process as part of a secure product development framework — a pentest report alone isn't treated as equivalent evidence.
• It gives the pentest a completion criterion. Without a threat model, it's hard to say a pentest was thorough; with one, testers can check off each identified threat as tested, mitigated, or accepted.

Before threats can be identified, the system has to be described precisely. That starts with a data-flow diagram: what data moves where, through which processes, and where it's stored. Trust boundaries are drawn wherever data crosses from one level of trust to another — for example, from the device's BLE radio into its application logic, or from a mobile app into a cloud backend. Every trust boundary is a place an attacker could try to cross, so it's also where security controls belong: authentication, authorization, encryption, and integrity checks.

Mapping this out for a real device also defines its attack surface — the complete set of points (BLE interface, debug port, mobile app, cloud API, firmware update mechanism) an attacker could target — so nothing gets missed simply because it wasn't on anyone's mental list.

Bluetooth Low Energy is the most common wireless interface on connected medical devices, and it has known, well-documented weak points if not configured carefully:

• Pairing — BLE supports several pairing methods (Just Works, Passkey Entry, Numeric Comparison, Out-of-Band). Just Works, the simplest and most common on devices without a screen or keypad, provides no protection against an active man-in-the-middle during pairing — a real constraint that has to be designed around, not assumed away.
• Encryption — once paired, BLE Secure Connections encrypts the link using AES-CCM as defined by the Bluetooth Core Specification. Encryption protects data in transit, but only from the point pairing succeeds — which is exactly why the pairing step itself needs scrutiny.
• Command authorization — link-layer encryption is not the same as authorization. A device should verify that a connected peer is actually allowed to issue a given command (e.g. changing a therapy setting) at the application layer, not just that the link is encrypted.
• Proximity and relay attacks — BLE's range is limited, but not a guarantee: relay and man-in-the-middle attacks that extend effective range have been demonstrated against real BLE products, which is why proximity shouldn't be treated as a security control on its own.

Most connected medical devices ship with a companion mobile app and a backend API, and both are in scope for a security review.

• OWASP MASVS (Mobile Application Security Verification Standard) is the reference standard for mobile app security, covering areas like local data storage, cryptography, authentication and session management, network communication, platform interaction, and resilience against reverse engineering. It gives a concrete checklist to verify against, instead of a vague sense that "the app should be secure."
• OWASP IoT Top 10 lists the most common classes of vulnerability found in connected/IoT devices — weak or hardcoded credentials, insecure network services, insecure ecosystem interfaces, lack of a secure update mechanism, use of insecure or outdated components, insufficient privacy protection, insecure data transfer and storage, lack of device management, insecure default settings, and lack of physical hardening. It's useful specifically because it's built from real-world IoT incidents, not theoretical risks.

Cybersecurity isn't a separate workstream from the rest of a device's compliance — it plugs directly into the same processes already in place for safety.

• IEC 62304 governs the software lifecycle. Security requirements and the controls that implement them are handled as software requirements and software risk controls within that same lifecycle, not bolted on at the end.
• ISO 14971 is the risk-management standard already used to evaluate safety hazards, and it's the same framework used to evaluate security risks — a threat that could let an attacker cause patient harm is a risk like any other, assessed for severity and probability and addressed with risk controls.
• FDA's premarket cybersecurity expectations for connected (“cyber”) devices, in effect since 2023, ask manufacturers to submit a plan for identifying and addressing vulnerabilities, a software bill of materials (SBOM), and evidence of a secure product development framework — which includes a documented threat-modeling process.

Just like a safety requirement in IEC 62304 needs to be traceable to its verification evidence, a security control needs to be traceable to the threat it mitigates. That means documenting, for every identified threat: the requirement or control that addresses it, how that control was verified (review, test, or analysis), and the residual risk that remains afterward. This is what lets a reviewer, auditor, or notified body follow the chain from "here's a threat we identified" to "here's proof it's handled" without taking it on faith.

• Developing threat models and security architectures for connected medical devices (IoT / Software as a Medical Device)
• Auditing and improving firmware verification processes, including identifying vulnerabilities introduced by gaps in test coverage
• BLE security testing using sniffing and traffic-analysis tooling