Security Risk Analysis Under AAMI SW96: A Worked Example on a Vital-Signs Bracelet. Part I. Analysis and Evaluation.

A walk-through of how we reason about medical-device security at the edge of hardware and software - the logic behind a SW96-aligned security risk analysis, illustrated on one deliberately ordinary device.

Most security writing lives comfortably on one side of a line. Either it's about software, such as web apps, APIs, and cloud misconfigurations - or it's about hardware: chips, buses, and side channels. Medical devices refuse to stay on one side. A modern connected device is a piece of firmware running on a constrained, radio-equipped board, communicating wirelessly with an app running on someone else's operating system, feeding numbers that a clinician will act on. The interesting risks live exactly on the seam between those worlds.

This article isn't a completed audit of a real product. It's a worked example - a walk-through of the method we apply when we perform a security risk analysis on a connected medical device, using a deliberately ordinary device to make the reasoning concrete. The point isn't a list of findings; it's the logic: the sequence of questions we ask, why the way you rate a risk matters as much as whether you find it, and how that reasoning maps onto what ANSI/AAMI SW96:2023 - the current normative standard for medical-device security risk management, recognized by the FDA — actually asks for.

The Device

Picture a vital-signs monitor built as a bracelet. It goes on a patient's wrist. There are no cables and no dock - it runs on a small battery and communicates wirelessly with a tablet at the nurses' station. Over that wireless Bluetooth Low Energy (BLE) link it sends a handful of values on a regular cadence:

• Battery level

• SpO₂ (blood oxygen saturation)

• Pulse rate (PR)

• Respiration rate (RR)

• Blood pressure, systolic and diastolic (sys/dia)

That's the whole system as far as the patient is concerned: a thing on the wrist, and a screen a nurse looks at. It is also, in regulatory terms, a cyber device - it contains software, it communicates wirelessly, and it can be updated.

Under the current FDA framework that is precisely the combination that puts cybersecurity on the

critical path to market:

1. Threats change over the time and vulnerabilities in target software, middleware, runtime and operating systems are discovered regularly. 

2. FDA cybersecurity compliance is required due to the target device (per FDA’s eSTAR) the following conditions are met:

   1. Has a network connection (active or not)

   2. Has wireless communication of any form

   3. Support software upgrades (including patches).

1 The Four Questions

Every security risk analysis we run, regardless of device, comes down to four questions asked in order:

1. What are we protecting? (assets)

2. How could it be reached or broken? (attack surface and threats)

3. How bad is it, and how reachable is it? (risk - the part most teams get half-right)

4. What do we change, and what's left over afterwards? (controls and residual risk)

The discipline is in keeping them separate. It's tempting to jump straight from "the link is unencrypted" to "add encryption," but skipping the middle two questions is how teams end up with a wall of controls that all look equally urgent and none of which are tied to a consequence anyone can explain to a reviewer.

2 Security Risk Analysis And Evaluation

The logic of this section is sequential: identify what must be protected, judge what losing it would cost, then work out how an attacker could reach it and how likely that is. Only risks established here justify the controls in Section 3 - so each step feeds the next, and nothing is mitigated that wasn't first shown to matter.

2.1 Attack Vectors Overview

Before assessing this specific device, we frame the threat landscape it sits in: what kinds of threats exist, who causes them, and how an attack typically unfolds. This vocabulary is the basis for the concrete assets and attack vectors analysed later - general picture first, so the specifics that follow have something to attach to.

Potential threat types:

• Malware/Virus: A computer program that can replicate itself, infect a computer without permission or knowledge of the user, and then spread or propagate to another computer. Software that compromises the operation of a system by performing an unauthorized function or process.

• D/DOS: A denial-of-service (DoS) or distributed denial-of-service (DDoS) attack is an attempt to make a machine or network resource unavailable to its intended users. Commonly used to shut down or interrupt a network

• Unauthorized access: Any access that violates the stated security policy.

• Others/Theft/Loss

Table 2.1 – Source of threats for the target assessed medical device

#	Source of threat	Example
TS.1	Users/Patients
TS.2	Manufacturer/Developer	Disgruntled/ex-employees
TS.3	Multi-Party Failures
TS.4	Incompatible Software	3rd party software that tries to communicate with device’s BLE GATT profiles
TS.5	Hacktivists
TS.6	Hackers

Not every source runs the full lifecycle. A skilled external hacker (TS.6) may move deliberately through all seven phases; a disgruntled insider (TS.2) often starts several phases in, already past reconnaissance and delivery; and unintentional sources - incompatible third-party software (TS.4), multi-party failures (TS.3) - don't follow the lifecycle at all, since there's no adversary pursuing an objective. The lifecycle therefore applies selectively, and the later threat scenarios (Section 2.7) show which phases each realistic threat actually involves.

Table 2.2 – Malicious threat lifecycle

Phase	Description	Explanation
Phase 1 - Reconnaissance	Adversary identifies and selects a target(s)	Device weaknesses are observed and researched
Phase 2 - Weaponize	Adversary packages an exploit into a payload designed to execute on the targeted computer/network.	Malicious code/software/virus developed
Phase 3 - Deliver	Adversary delivers the payload to the target system(s).	Package is delivered to the target through one or more devices
Phase 4 - Exploit	Adversary code is executed on the target system(s).	Software on device is executed or manipulated
Phase 5 - Install	Adversary installs remote access software that provides a persistent presence within the targeted environment or system.	Device or software on device is told what to do
Phase 6 - Command and Control	Adversary employs remote access mechanisms to establish a command and control channel with the compromised device.	Information is collected; device is compromised, shut down/broken
Phase 7 - Act on Objectives	Adversary pursues intended objectives (e.g., data exfiltration, lateral movement to other targets).

The lifecycle above assumes an adversary pursuing an objective. But several sources in Table 2.1 are not adversarial - multi-party failures (TS.3) and incompatible third-party software (TS.4) cause harm without intent, and so follow no attack lifecycle at all. Their threats arise from malfunction rather than pursuit, and take the following forms:

• Malfunction or unintentional consequence of design/code/software

  • Code is not properly written or conflicts with new code

• Device or information on device is compromised

  • Code does not save all the information

  • Misprints output directions

  • Instructs devices to perform unintended function

2.2 System Diagram

Having framed the threat landscape, we now fix the target: the diagram below defines the device's components and trust boundaries - the concrete system every later asset, attack vector, and threat refers back to.

Figure 2.1 - High-level device module diagram

The diagram's blocks are broken out below: each module, the subsystem it runs in, and the function it performs - the components every asset and attack vector in the following sections maps back to.

Table 2.3 – Module and component breakdown

Module #	Module	Function
Medical wearable device - Vital Signs Monitor
1	Device Vital Signs sensor readings module (DVSM)	Acquires raw sensor data and derives the reported vital-sign values - SpO₂, pulse rate (PR), respiration rate (RR), systolic/diastolic blood pressure (sys/dia) - and battery level; passes them to the BLE GATT module for transmission.
2	Device Firmware update module (DFM)	Receives firmware update packages over BLE and validates their authenticity and integrity before applying them to the device.
3	Device management module	Handles on-device configuration, operational state, and the pairing/session lifecycle; exposes management functions to the management application.
4	Device BLE GATT module	Implements the Bluetooth Low Energy GATT server; exposes the vital-signs, management, and firmware services and mediates all wireless communication between the bracelet and the Android applications.
Client application - nurse's tablet (Android, vital-signs client)
5	Client pairing module	Establishes and maintains the secure BLE pairing/session with the bracelet and manages client-side session credentials.
6	Client vital signs readings module	Subscribes to and reads vital-sign data from the bracelet's GATT profile and presents the readings (SpO₂, PR, RR, sys/dia, battery) to the clinician.
Service application (Android)
7	Service pairing module	Establishes and maintains the privileged BLE pairing/session used for device management operations.
8	Service firmware module	Orchestrates firmware update delivery to the bracelet, supplying signed update packages to the device firmware update module.

2.3 Example of Threats / Threat Analysis

Before analysing our own device, we look at what has already gone wrong elsewhere. The known incidents below are real medical-device security failures, and the threat classes they reveal are what the rest of the assessment tests our device against.

Table 2.4 – List of analyzed known cybersecurity incidents relevant for the assessment

#	Type	Description	Example
TC.1	Inadequate User Authentication	Weak or insufficient authentication mechanisms allow unauthorized users to access and manipulate medical device functions.	An unauthorized staff member accessed a medication dispensing system with weak password protection, leading to incorrect medication dosage.
TC.2	Outdated Software	Medical devices running on outdated software are vulnerable to known exploits and security breaches.	An MRI machine running on outdated software was exploited through a known vulnerability, causing system malfunction and data loss.
TC.3	Vulnerable Wireless Communication	Wireless communication channels in medical devices, like Wi-Fi or Bluetooth, can be exploited if not properly secured.	A wireless insulin pump was hacked through its Bluetooth connection, leading to unauthorized changes in insulin delivery.
TC.4	Insufficient Data Integrity Checks	Without proper verification, data integrity issues in medical devices can lead to incorrect patient treatment.	A blood analysis machine with compromised data integrity provided inaccurate results, leading to a misdiagnosis.
TC.5	Insecure APIs	Application Programming Interfaces (APIs) that lack security measures can be entry points for cyberattacks.	An insecure API in a patient monitoring system was exploited, leading to unauthorized data access.
TC.6	Unpatched Security Vulnerabilities	Medical devices without regular updates are at risk of exploitation through known vulnerabilities	A networked patient monitoring system was compromised using an unpatched security flaw, affecting patient data confidentiality
TC.7	Poor Network Segmentation	Inadequate network segmentation can lead to widespread impact in case of a cyber breach.	A ransomware attack spread across a hospital’s network due to poor segmentation, affecting multiple medical devices.
TC.8	Remote Access Vulnerabilities	Insecure remote access to medical devices can lead to unauthorized control and data breaches.	Hackers gained remote access to a telemedicine system, compromising patient consultations.
TC.9	Inadequate Incident Detection	Poor detection mechanisms can delay the response to a cyberattack, increasing its impact.	A slow response to a data breach in a radiology system caused extended exposure of sensitive patient data.
TC.10	Mobile Device Vulnerabilities	Mobile devices used in healthcare can be a weak link in cybersecurity if not properly managed.	A doctor’s compromised smartphone led to unauthorized access to a patient management app.
TC.11	Insecure Data Storage	Storing patient data insecurely on medical devices can lead to unauthorized access and data breaches.	A compromised server in a hospital leaked sensitive patient records due to inadequate data encryption.
TC.12	Insufficient Error Handling	Poor error handling in medical software can lead to information leaks and system crashes.	Improperly handled system errors in a diagnostic tool exposed sensitive debug information.
TC.13	Misconfigured Cloud Services	Incorrectly configured cloud services used by medical devices can expose data and systems to risks.	A misconfiguration in a cloud-based medical imaging service led to public exposure of patient images.
TC.14	Inadequate Access Controls	Weak access controls can allow unauthorized personnel to access sensitive medical device functions.	Lack of proper access controls enabled an unauthorized employee to access a drug dispensing system.
TC.15	Firmware Vulnerabilities	Vulnerabilities in the firmware of medical devices can be exploited for unauthorized access or control.	A firmware flaw in a ventilator system was exploited to alter its functionality.
TC.16	Inconsistent Patching Across Devices	Variations in patching across different devices can lead to security inconsistencies.	Inconsistent patching made some infusion pumps vulnerable to a known exploit.
TC.17	Lack of Device Authentication	Failure to authenticate communications between medical devices can lead to data interception and manipulation.	Non-authenticated communication between a blood glucose monitor and an insulin pump was exploited to deliver incorrect insulin dosages.
TC.18	Data Tampering	Altering data within medical devices can lead to incorrect diagnoses or treatments.	Data tampering in a digital health record system caused incorrect patient information to be recorded, leading to inappropriate treatment.
TC.19	Unauthorized Data Sharing	Inappropriate or unauthorized data sharing from medical devices can compromise patient confidentiality.	A connected patient monitoring device inadvertently shared sensitive health data with unauthorized third-party applications.
TC.20	Evolving Cyber Threat Landscape	The continuously changing nature of cyber threats poses a persistent challenge to the security of medical devices.	A healthcare provider struggled to keep pace with rapidly evolving ransomware tactics, resulting in repeated breaches of their medical devices.
TC.21	D-DoS Attacks	Distributed Denial of Service (DDoS) attacks can overwhelm healthcare networks, disrupting medical device functionality.	A DDoS attack on a hospital network rendered several networked medical devices inoperable.
TC.22	Eavesdropping and Interception	Eavesdropping on data transmissions from medical devices can lead to unauthorized access to sensitive information.	Cybercriminals intercept unencrypted patient data from a wireless medical device, leading to identity theft.

2.4 Security assets

We start by identifying the assets we need to protect. Assets include everything that is needed to keep the device operating effectively and safely, with appropriate patient privacy.

Table 2.5 – Security assets considered in the assessment

Asset ID	Asset	Description
Physical assets
PAS.1	Operating system (Client Android device)	Basic system image that defines runtime environment for the target client application software (Android base image)
PAS.2	Operating system (Management Android device)	Basic system image that defines runtime environment for the management client application software (Android base image)
PAS.3	Operating system (Medical device)	Basic system image that defines runtime environment for the target vital signs application software
PAS.4	Application software	Set of binaries needed for application function
PAS.5	Keys/Certificates	Data records and security credentials that define authentication and authorization policies for device access
PAS.6	Device resources	System resources such as CPU, RAM and available IOPS
PAS.7	Device telemetry	Files that store chronologically ordered records on system health checks and other critical telemetry event metadata occurring in the runtime environment
Information assets
IAS.1	Patient Vital Sign Readings	Readings from the sensors that represent the patient vital signs data
IAS.2	Session credentials (keys, tokens, etc.)	Active session records, files and identifiers
IAS.3	Diagnostic Logs	Files that store chronologically ordered records on system patient vital sign readings and accompanying diagnostic traces from the application software
IAS.4	Configuration Files	Configuration files of the operating system and application software that control operational device behavior
IAS.5	Update Files	Firmware update resources

2.5 Assets Evaluation

Each asset is evaluated for the potential impact to safety or privacy should that asset get compromised. Some impacts to consider include:

• Impact to operation – loss of device effectiveness, loss of device therapy, loss of availability

• Impact to the physical device, information, or communications

• Impact to individuals – physical injury or loss of life, inappropriate or suboptimal therapy, loss of PHI, and patient concern

• Impact to other organizations or the environment, including damage to property, damage to the environment, or to network connected systems

Let’s consider the following risk severity levels

Table 2.6 – Risk severity levels used for the assessment

Label	Potential Impact to Device Operations	Potential Impact to Business Operations	Potential Impact to Data / PHI	Potential Impact to Other Organizations or the Environment
Negligible	No negative effects	No negative effects	No negative effects	No negative effects
Minor	Insignificant loss of non-essential functions; temporary loss of device operation resulting in inconvenience	Customer complaints or limited damage to reputation	Loss of confidentiality of non-confidential data	Device reveals information about itself beyond what is necessary
Moderate	Significant loss of availability across a single or system communication can be tampered with	Loss of intellectual property; large damage to business reputation; minor legal issues	Loss of integrity of non-essential data; loss of confidentiality of a small amount of confidential data	Device becomes a vector to gather information about other systems on the same network
Serious	Significant loss of availability across multiple devices	Serious legal issues; inability to perform critical mission functions	Loss of integrity of essential data; loss of confidentiality of a large amount of confidential data	Device becomes a vector to attack other systems

Severity alone does not rank a risk. Because these threats are deliberate rather than random, we pair each asset's impact severity (Table 2.6) with its exploitability - the access, skill, and resources an attack actually requires - and read the two together on a risk matrix.

Table 2.6-A – Exploitability levels

Level	Description	Threat-source tier	Access required
Very High	Remotely/wirelessly reachable, no authentication, exploitable with available tools	Tier I	None
High	Within radio range or low-privilege position; known technique	Tier I–II	Proximity
Medium	Requires proximity plus moderate skill, or some credential/access	Tier III	Partial
Low	Requires physical possession or significant skill/resources	Tier IV	Physical
Very Low	Requires state-level resources or lab-grade extraction	Tier V–VI	Extraordinary

The initial (pre-control) risk of each threat is the intersection of its severity and exploitability.

Table 2.6-B – Security risk matrix (severity × exploitability)

Exploitability ↓ / Severity →	Negligible	Minor	Moderate	Serious
Very High	Low	Medium	High	Unacceptable
High	Low	Medium	High	High
Medium	Low	Low	Medium	High
Low	Low	Low	Low	Medium
Very Low	Low	Low	Low	Low

The resulting risk band determines what action is required, both for initial risk and for the residual risk remaining after controls

Table 2.6-C – Risk acceptability criteria

Risk band	Acceptability	Required action
Low	Acceptable	No further control required; record rationale.
Medium	Conditionally acceptable	Acceptable only with documented justification that risk is reduced as far as reasonably practicable.
High	Not acceptable	Additional controls required to reduce risk before release.
Unacceptable	Not acceptable	Must be reduced; if irreducible, requires a documented benefit-risk determination.

In the proposed threat model approach, we create a table that lists each asset and the associated impact due to loss of confidentiality, integrity, or availability. 

Assessment on the above, implies answering the following questions:

• Confidentiality: what is the impact if that asset’s confidentiality was compromised, and the information it contained was available to an attacker?

• Integrity: What is the impact if that asset’s integrity was compromised, and an attacker could change the information or software in a way that wasn’t immediately obvious to the user (clinician or patient)?

• Availability: What is the impact if that asset could be made unavailable?

2.5.1 Information Assets Evaluation

Applying the impact criteria from 2.5 to the first asset class: for each information asset, we ask what the loss of confidentiality, integrity, or availability would cost - and rate the severity accordingly.

Table 2.7 – Information assets evaluation for the assessment

Information Asset	Affected by Loss of	Adverse Impact Description	Impact Level
Patient Vital Signs Readings (IAS.1)	Confidentiality	Sensor readings are seen remotely by an unauthorized user (TC.11, TC.14, TC.17, TC.19)	Minor
	Integrity	Altered sensor readings, potential injury done based on wrong/malformed sensor readings (TC.17, TC.18)	Serious
	Availability	Sensor readings not available, vital signs readings loss. Denial of service (TC.21)	Serious
Session credentials (IAS.2)	Confidentiality	Sensor readings are seen remotely by an unauthorized user (TC.11, TC.14, TC.17, TC.19)	Moderate
		Unauthorized access to device management functions (TC.3, TC.5, TC.8, TC.20)	Moderate
	Integrity	Loss of access to sensor readings by the designated actors, vital signs readings loss (TC.21)	Serious
	Availability	Device communication with external Android client device(s) being not operational. Denial of service (TC.21)	Serious
Diagnostic Logs (IAS.3)	Confidentiality	Information on system intrinsics and historical patient vital signs readings is breached (TC.11, TC.14, TC.17, TC.19)	Minor
	Integrity	Tampered diagnostic logs prevent comprehensive forensic analysis. Inability to perform anomalies detection in the application software (TC.4, TC.18)	Moderate
	Availability	Inability to monitor and detect application failures and root cause analysis (TC.9)	Moderate
Configuration Files (IAS.4)	Confidentiality	Information on system intrinsics and device operational insights is breached as a result of configuration files breach (TC.14, TC.17)	Moderate
	Integrity	Application configuration files integrity loss. Device malfunction. Denial of service. (TC.21)	Moderate
	Availability	Application configuration files loss. Device malfunction. Denial of service. (TC.21)	Moderate
Update Files (IAS.5)	Confidentiality	Information on system intrinsics is breached as a result of update files breach (TC.14, TC.17)	Serious
	Integrity	Device malfunction or potential malicious code injection to the target device upon update files integrity breach. Denial of service (TC.1, TC.15, TC.21)	Serious
	Availability	Inability to update device firmware. Inconsistent patching across devices  (TC.2, TC.6, TC.16)	Moderate

2.5.2 Physical Assets Evaluation

The same confidentiality/integrity/availability lens, now turned on the physical assets - the operating systems, application binaries, keys, and device resources that the information assets depend on.

Table 2.8 – Physical assets evaluation for the assessment

Physical Asset	Affected by Loss of	Adverse Impact Description	Impact Level
Operating system (Client Android device), (PAS.1)	Confidentiality	Sensor readings breached. (TC.7, TC.10, TC.11, TC.14, TC.19, TC.20)	Moderate
		Client session keys breached. (TC.11, TC.14, TC.17, TC.19)	Moderate
	Integrity	Altered sensor readings, potential injury done based on wrong sensor readings displayed (TC.10, TC.17, TC.18)	Serious
	Availability	Sensor readings not available, vital signs readings loss. Denial of service (TC.10, TC.21)	Serious
Operating system (Management Android device), (PAS.2)	Confidentiality	Unauthorized access to device management functions (TC.3, TC.5, TC.8, TC.10, TC.19, TC.20)	Serious
		Management session keys breached. (TC.3, TC.5, TC.8, TC.10, TC.19, TC.20)	Serious
	Integrity	Device malfunction or potential malicious code injection to the target device. Denial of service (TC.1, TC.15, TC.21)	Moderate
	Availability	Inability to update device firmware and execute device management functions (TC.2, TC.6)	Moderate
Operating system (Medical device), (PAS.3)	Confidentiality	Sensor readings breached. Device software configuration and layout breached. (TC.1, TC.2, TC.3, TC.6, TC.8, TC.14, TC.15, TC.20, TC.22)	Serious
	Integrity	Device malfunction or potential malicious code injection to the target device. Denial of service (TC.1, TC.2, TC.3, TC.6, TC.8, TC.14, TC.15, TC.20, TC.22)	Serious
	Availability	Device malfunction or denial of service. (TC.21)	Serious
Application software (PAS.4)	Confidentiality	Application software configuration and layout breached (TC.1, TC.2, TC.4, TC.5, TC.6, TC.8, TC.14, TC.15)	Serious
	Integrity	Sensor readings tampered, vital signs readings loss, tampered or being not available. (TC.1, TC.2, TC.4, TC.5, TC.6, TC.8, TC.14, TC.15)	Serious
	Availability	Device malfunction or denial of service. (TC.21)	Serious
Keys/Certificates (PAS.5)	Confidentiality	Spoofed device identity (TC.1, TC.10, TC.14, TC.22)	Serious
	Integrity	Data security and encryption mechanisms compromised. Unauthorized access to device management functions (TC.3, TC.5, TC.8, TC.20)	Moderate
	Availability	Device malfunction or denial of service. (TC.21)	Serious
Device resources (PAS.6)	Confidentiality	N/A	N/A
	Integrity	Denial of service (TC.21)	Serious
	Availability	Device malfunction. Denial of service. (TC.21)	Serious
Device telemetry (PAS.7)	Confidentiality	Information on system intrinsics and historical device status readings is breached (TC.18)	Moderate
	Integrity	Tampered device telemetry logs prevent comprehensive forensic analysis. Inability to perform anomalies detection in the device hardware (TC.4, TC.18)	Moderate
	Availability	Inability to monitor and detect system and hardware failures and root cause analysis (TC.9)	Moderate

Together, 2.5.1 and 2.5.2 give the severity half of the risk picture: for every asset, how much its loss would hurt. The items rated Serious - tampered or unavailable vital signs, compromised keys and firmware - are where the threat assessment that follows concentrates, since severity is only actionable once paired with how reachable each threat is.

2.6 Attack Vectors

Let’s identify potential vulnerabilities and attack vectors. We start from establishing the trust boundaries. Trust boundaries are the boundary assumptions we can make in your system about the internal trustworthiness of interactions. The interfaces between trust boundaries are potential points of vulnerabilities or attack vectors.

Table 2.9 – Attack vectors considered for the assessment

#	Attack Vector	Attack description
AV.1	BLE	The vital signs readings data transferred is captured and read by unauthorized party Session credentials data transferred is captured and read by unauthorized party Update files transferred is captured and read by unauthorized party Public BLE GATT profile exposed to 3rd parties gets brute forced
AV.2	Android client device	Unencrypted PHI data AND/OR session keys stored on the Android client gets breached via known OWASP vulnerabilities gets stolen by having direct access to SD card of the Android device  Additionally may be caused by improper device disposal gets breached due to non-restricted debug/developer mode on the target Android device (over WIFI or USB OTG port)
AV.3	Android management client device	Unencrypted authentication data such as keys/certificates AND/OR session keys stored on the Android management client gets breached via known Android vulnerabilities gets stolen by having direct access to SD card of the Android device Additionally may be caused by improper device disposal gets breached due to non-restricted debug/developer mode on the target Android device (over WIFI or USB OTG port)
AV.4	Maintenance application	An unauthorized user gets access to a service/maintenance application with control over sensitive parameters and control functions
AV.5	USB / debug port	Not applicable to the target device: the enclosure is sealed and exposes no user- or service-accessible wired port in production; the manufacturing/debug interface (UART/JTAG) is disabled and/or physically inaccessible after assembly. Retained in the register for completeness and to document the design decision.

2.7 Security Risks Assessment

Now that we have the assets, impact, vulnerabilities, and threat sources, we are ready to assess the threats. The STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) methodology helps to consider the types of threats we should consider. Below is an example of STRIDE elements from the MITRE Playbook for Threat Modeling Medical Devices.

Below is an example of STRIDE elements from the MITRE Playbook for Threat Modeling Medical Devices.

Table 2.10 – STRIDE elements specification

STRIDE element	Description	Example
Spoofing	Tricking a system into believing a falsified entity is a true entity	Using stolen or borrowed credentials to log on as another nurse
Tampering	Intentional modification of a system in an unauthorized way	Changing patient data to incorrect values
Repudiation	Disputing the authenticity of an action taken	Denying that a prescribed treatment has been provided to the patient
Information Disclosure	Exposing information intended to have restricted access levels	Health data is sent over an unencrypted Bluetooth connection
Denial Of Service (DOS)	Blocking legitimate access of functionality of a system by malicious process(es)	A Bluetooth SpO2 sensor is flooded with bad pairing requests, preventing legitimate connections
Elevation of Privilege (EoP)	Gaining access to functions to which an attacker should not normally have access according to the intended security policy of the product	A patient uses a web portal vulnerability to see all patient data rather than their own

2.8 Threat Source Tiers

For adversarial threat sources, it’s required to consider the skill required to exploit the vulnerability. The threat source can be placed in one of 6 tiers (based on TIR57).

Table 2.11 – Threat source tiers considered for the assessment

Tier	Description
Tier I	Attackers that use available code and tools to exploit known vulnerabilities
Tier II	Attackers that can create tools to target known vulnerabilities
Tier III	Attackers who are technologically savvy and are adept at finding and exploiting vulnerabilities
Tier IV	Organized, highly technical, well-funded professionals working in teams
Tier V	State actors who perhaps create vulnerabilities in products to enable exploitation of networks and systems
Tier VI	States that use their military, intelligence, and vast resources to achieve a specific outcome

2.8.1 STRIDE Based Assessment

This is where assets, impacts, and attack vectors come together. Using the STRIDE categories (Table 2.10), we walk each asset against its applicable attack vectors, identify the concrete threat and scenario, and rate it - by severity and, per 2.5, by exploitability - to yield the risk each threat carries before controls.

2.8.1.1 Assessment on Informational Assets

We start with the information assets of 2.4 - the vital-signs readings, credentials, logs, configuration, and update files - assessing each against the threats reachable over its attack vectors.

Table 2.12 – STRIDE based assessment for the informational assets

Threat #	Asset	Adverse Impact	Impact Level	Threat Source	Threat Source Tier	Exploitability	Initial Risk	Threat	Threat Scenario
Attack vector: AV.1
TID.1	IAS.1	Sensor readings are seen remotely by an unauthorized user	Minor	Adversarial attacker (hacktivist/hacker)	III	High	Medium	Information disclosure	Threat actor  intercepts unsecured BLE communication between medical device and client Android device
TID.2	IAS.1	Altered sensor readings, potential injury done based on wrong/malformed sensor readings	Serious	Adversarial attacker (hacktivist/hacker)	III	High	High	Tampering	Threat actor discovers unsecured BLE GATT write service and finds a way to utilize it to tamper the vital readings
TID.3	IAS.1	Unauthorized elevation to a privileged BLE GATT service, granting write/command access to the vital-signs interface beyond the intended read-only level				Medium	High	Elevation of Privilege	Threat actor discovers that a privileged or hidden GATT service/characteristic (intended for management or firmware use) is reachable from the client BLE profile, and escalates from read-level vital-signs access to privileged write/control over the readings interface
TID.4	IAS.1	Sensor readings not available, vital signs readings loss. Denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Very High	Unacceptable	Denial of Service	Threat actor causes DOS attack by sending BLE pairing requests at a high rate
TID.5	IAS.2	Sensor readings are seen remotely by an unauthorized user	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Spoofing	Threat actor performs a successful replay attack using previously spoofed pairing traffic between medical device and client/management Android device
TID.6	IAS.2	Loss of access to sensor readings by the designated actors, vital signs readings loss	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Spoofing	Threat actor and their device takes over the communication with target medical device
TID.7	IAS.2	Device communication with external Android client device(s) being not operational. Denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Spoofing	Threat actor performs a successful DOS attack by executing replay attacks at high rate with previously spoofed credentials
TID.8	IAS.3	Information on system intrinsics and historical patient vital signs readings is breached	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Tampering, Elevation of Privilege	Threat actor steals historical vital signs log and accompanying application logs from the target compromised medical device
TID.9	IAS.3	Tampered diagnostic logs prevent comprehensive forensic analysis. Inability to perform anomalies detection in the application software	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Tampering, Elevation of Privilege	Threat actor modifies historical vital signs log and accompanying application logs on the target compromised medical device to hide malicious activity
TID.10	IAS.3	Inability to monitor and detect application failures and root cause analysis	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Tampering, Elevation of Privilege	Threat actor wipes out historical vital signs log and accompanying application logs from the target compromised medical device
TID.11	IAS.4	Information on system intrinsics and device operational insights is breached as a result of configuration files breach	Minor	Adversarial attacker (hacktivist/hacker)	III	Medium	Low	Elevation of Privilege	Threat actor steals application configuration files from the target compromised medical device
TID.12	IAS.4	Application configuration files integrity loss. Device malfunction. Denial of service.	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Elevation of Privilege	Threat actor modifies application configuration files on the target compromised medical device
TID.13	IAS.4	Application configuration files loss. Device malfunction. Denial of service.	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Elevation of Privilege	Threat actor wipes out application configuration files from the target compromised medical device
TID.14	IAS.5	Information on system intrinsics is breached as a result of update files breach	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Elevation of Privilege	Threat actor steals application firmware update files from the target compromised medical device
TID.15	IAS.5	Device malfunction or potential malicious code injection to the target device upon update files integrity breach. Denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Elevation of Privilege	Threat actor modifies application firmware update files and triggers malicious code setup on the target compromised medical device
TID.16	IAS.5	Inability to update device firmware. Inconsistent patching across devices	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Elevation of Privilege	Threat actor modifies/breaks application firmware update module to avoid legitimate updates to be provisioned after setting up own malicious code

2.8.1.2 Assessment on physical assets

The same STRIDE assessment applied to the physical assets of 2.4 - the operating systems, application binaries, keys, device resources, and telemetry that the information assets run on and depend on.

Table 2.13 – STRIDE based assessment for the physical assets

Threat #	Asset	Adverse Impact	Impact Level	Threat Source	Threat Source Tier	Exploitability	Initial Risk	Threat	Threat Scenario
Attack vector: AV.2
TID.17	PAS.1	Sensor readings breached	Moderate	Adversarial attacker (hacktivist/hacker)	III	Low	Low	Information Disclosure	Threat actor copies/steals client application data from the Android device (internal storage or SD card)
TID.18	PAS.1	Client session keys breached	Moderate	Adversarial attacker (hacktivist/hacker)	III	Low	Low	Information Disclosure
TID.19	PAS.1	Altered sensor readings, potential injury done based on wrong sensor readings displayed	Serious	Adversarial attacker (hacktivist/hacker)	III	Low	Medium	Tampering	Threat actor tampers client application data to malform vital signs readings on the compromised client Android device
TID.20	PAS.1	Sensor readings not available, vital signs readings loss. Denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Low	Medium	Denial of Service, Elevation of Privilege	Threat actor tampers client application data to corrupt vital signs readings and break application operation on the compromised client Android device
Attack vector: AV.3
TID.21	PAS.2	Unauthorized access to device management functions	Serious	Adversarial attacker (hacktivist/hacker)	III	Low	Medium	Elevation of Privilege	Threat actor copies/steals application data from the Android device (internal storage or SD card)
TID.22	PAS.2	Management session keys breached	Serious	Adversarial attacker (hacktivist/hacker)	III	Low	Medium	Information Disclosure
TID.23	PAS.2	Device malfunction or potential malicious code injection to the target device. Denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Low	Medium	Denial of Service, Elevation of Privilege	Threat actor tampers firmware update files with malicious code and facilitates firmware update procedure on the compromised management client Android device
TID.24	PAS.2	Inability to update device firmware and execute device management functions	Moderate	Adversarial attacker (hacktivist/hacker)	III	Low	Low	Denial of Service	Threat actor corrupts update files on the compromised management client Android device to break target medical device or firmware update process
Attack vector: AV.4
TID.25	PAS.3	Sensor readings breached. Device software configuration and layout breached	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Information Disclosure, Elevation of Privilege	Threat actor copies/steals historical sensor readings through compromised medical device due to a breach in its OS security controls
TID.26	PAS.3	Device malfunction or potential malicious code injection to the target device. Denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Denial of Service, Elevation of Privilege	Threat actor tampers application data/binaries to break application operation or convert the device into an attack vector on the compromised medical device due to a breach in its OS security controls
TID.27	PAS.3	Device malfunction or denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Denial of Service	Threat actor corrupts application data/binaries to cause DOS on the compromised medical device due to a breach in its OS security controls
Attack vector: AV.1
TID.28	PAS.4	Application software configuration and layout breached	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Information Disclosure	TBD
TID.29	PAS.4	Sensor readings tampered, vital signs readings loss, tampered or being not available	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Denial of Service, Elevation of Privilege	TBD
TID.30	PAS.4	Device malfunction or denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Denial of Service	TBD
TID.31	PAS.5	Spoofed device identity	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Spoofing	Threat actor prepares own device with duplicated identity parameters (MAC address, GATT services structure, keys/certificates) obtained via spoofing that mimics target spoofed medical device
TID.32	PAS.5	Data security and encryption mechanisms compromised. Unauthorized access to device management functions	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Spoofing	Threat actor performs a security/encryption keys utilizing successful replay attack between medical device and client/management Android device
TID.33	PAS.5	Device malfunction or denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Denial of Service	Threat actor removes security keys/certificates from the target compromised medical device
TID.34	PAS.6	Denial of service	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Denial of Service	Threat actor intentionally causes no free disk space on the target compromised medical device
TID.35	PAS.6	Device malfunction. Denial of service.	Serious	Adversarial attacker (hacktivist/hacker)	III	Medium	High	Denial of Service	Threat actor intentionally causes no free CPU resources on the target compromised medical device by executing fork bomb
TID.37	PAS.7	Information on system intrinsics and historical device status readings is breached	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Information Disclosure	Threat actor steals device telemetry logs from the target compromised medical device
TID.38	PAS.7	Tampered device telemetry logs prevent comprehensive forensic analysis. Inability to perform anomalies detection in the device hardware	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Tampering	Threat actor modifies device telemetry logs on the target compromised medical device to hide malicious activity
TID.39	PAS.7	Inability to monitor and detect system and hardware failures and root cause analysis	Moderate	Adversarial attacker (hacktivist/hacker)	III	Medium	Medium	Tampering	Threat actor removes wipes out device telemetry logs from the target compromised medical device

Here, in the Section 2 we moved from context to a rated risk picture: the assets worth protecting (2.4), the impact of losing each (2.5), the vectors by which they can be reached (2.6), and through the STRIDE assessment (2.7) - the specific threats each asset faces, now scored by severity and exploitability into an initial risk band. Those bands are the output that matters.

Every threat rated High or Unacceptable, together with the Medium risks requiring justification, carries forward into Section 3, where mitigation controls are applied and the residual risk remaining after them is evaluated against the acceptability criteria.

---

So far we've reframed the problem: the same five numbers on a patient's wrist can be read, forged, or silenced, and rating those threats by severity alone tells you everything is urgent - which is the same as knowing nothing. Pairing severity with exploitability is what turns a flat list into an ordered one.

But exploitability is only half of the harder question. We've been treating "Serious" as a security judgement, when for a device that drives clinical decisions it often isn't one at all - a forged reading isn't a data problem, it's a patient-safety problem, and that changes where the risk belongs and who owns it.

That's where Part 2 picks up: the bridge from security into safety, why a control almost never lowers severity, and what honest residual risk looks like when you admit some attacks can't be fully engineered away.

Continue to Part 2: The safety bridge, residual risk, and what survives the controls →