Knowing which software components exist inside a medical device does not automatically reveal how an attacker could abuse them. In the same way, mapping possible threats without reliable component details can leave important risks unnoticed. The STRIDE threat modeling methodology helps you examine potential attacks across the device and its connected environment, while an SBOM provides visibility into the software included in a particular build. Interest in that visibility continues to grow.
One industry survey found that 81% of respondents viewed SBOMs as important or essential when assessing medical devices, and 35% would exclude devices that lacked one.
Bringing these two sources of insight together gives your team a clearer foundation for evaluating medical device cybersecurity risks and preparing stronger evidence for FDA review.
Key Takeaways
- STRIDE becomes useful only when it is applied to the actual medical device architecture.
- An SBOM must represent a specific released build. Accurate component identity, dependency data, configuration details, and binary evidence are necessary for reliable vulnerability analysis.
- A CVE match is only the starting point. Manufacturers must confirm whether the affected code is present, reachable, enabled, and capable of influencing device safety or operation.
- Medical device findings should be prioritised according to real exposure and clinical consequence rather than CVSS Base score alone. Active exploitation, essential performance, fleet impact, and recovery constraints can change urgency.
- Threat models, SBOM records, VEX decisions, controls, and test results should remain traceable and current as software, interfaces, suppliers, deployment conditions, and vulnerability intelligence change.
What STRIDE Threat Modeling and SBOM Analysis Do in Medical Device Cybersecurity
STRIDE Threat Modeling
The STRIDE methodology in threat modeling helps your team identify potential threats across device components, interfaces, data flows, external systems, and trust boundaries. It defines possible attack scenarios, but it does not independently identify every vulnerability, confirm exploitability, assess patient harm, or prove that security controls work.
FDA does not require manufacturers to use STRIDE exclusively. You should select a systematic approach that suits the device and document how the method supports cybersecurity risk analysis.
Medical Device SBOM Analysis
A medical device SBOM records the software components and dependency relationships within a particular product build. It can include manufacturer-developed code, commercial and open source software, operating system packages, firmware libraries, and direct or indirect dependencies.
SBOM analysis verifies these components and compares them with vulnerability information. Your team then reviews how each component is configured and used before documenting whether the device is affected. A component linked to a CVE does not automatically mean the released product contains an exploitable weakness.
What FDA Requires and Recommends for Threat Models and SBOMs
Section 524B sets legal requirements for qualifying cyber devices. FDA guidance provides broader recommendations for meeting and documenting those requirements.
| Section 524B requires | FDA guidance recommends |
| A plan for monitoring and addressing postmarket vulnerabilities and exploits | Cybersecurity threat modeling throughout product development |
| Processes that support secure device design and maintenance | Analysis of the complete medical device system |
| Regular updates and patches, with urgent action for critical risks | Traceability among threats, risks, the SBOM, controls, and testing |
| An SBOM covering commercial, open source, and off-the-shelf software | A maintained, machine-readable SBOM supported by configuration management |
Section 524B does not prescribe STRIDE, require one SBOM format, or state that every vulnerability match needs an immediate patch. FDA expects manufacturers to select a suitable methodology and explain how it supports the device risk assessment.
FDA issued its current premarket cybersecurity guidance on February 3, 2026, replacing the June 27, 2025 version. Formats such as CycloneDX and SPDX can support SBOM management, but FDA does not mandate either as the universal format.
Medical Device STRIDE Threat Modeling Methodology
Begin with a documented architecture. Each scenario should connect an attacker, entry point, action, affected asset, and possible consequence.
1. Define the Complete Medical Device System
Record the device’s purpose, users, clinical setting, essential functions, connectivity, service life, update routes, maintenance access, and retirement process. Confirm whether the product meets the Section 524B cyber device definition.
Set boundaries that include the device, firmware, software, communication interfaces, connected applications, cloud platforms, update systems, service tools, healthcare networks, and external services. Missing a supporting system can leave a relevant attack path outside the assessment.
2. Create Architecture, Data Flow, and Trust Boundary Views
A clear STRIDE Framework for Medical Devices uses separate views for system context, deployment, data flows, trust boundaries, software updates, and shared services. FDA recommends architecture diagrams that show interfaces, communication paths, security boundaries, and controls.
For each flow, record what moves between systems, where it travels, which protocol is used, and how access and communication are protected. Mark points where identity, privilege, ownership, or trust changes, including cloud connections, maintenance access, update delivery, and separation between patients or tenants.
3. Identify Assets and Security Objectives
Identify anything an attacker could steal, alter, disable, or misuse. Relevant assets include therapy settings, patient measurements, device credentials, firmware, update files, audit records, calibration data, algorithms, and recovery functions.
Next, define the required protection for each asset. Patient information needs confidentiality. Commands and therapy settings require integrity and authorization. Firmware updates need a trusted source. Safety functions must remain available or enter a safe state during disruption.
4. Apply STRIDE to Components, Flows, and Boundaries
1. Spoofing
Spoofing means presenting a false identity as legitimate. An attacker could use forged or stolen credentials to appear as a trusted user, device, application, or service.
Assess whether someone could impersonate:
- A patient, clinician, administrator, or service engineer
- A medical device, sensor, or consumable
- A mobile application or cloud service
- An update server or hospital system
Review the controls used to confirm identity. Pay particular attention to insecure pairing, shared accounts, stolen credentials, weak certificate checks, and poorly protected account recovery.
2. Tampering
Tampering occurs when someone alters data, code, or configuration without permission. It threatens integrity and can change how a medical device behaves.
Assess whether an attacker could modify:
- Firmware, software, or update packages
- Therapy settings, commands, or measurements
- Configuration, logs, or calibration values
- Cloud records, time sources, or stored data
Review local and remote access as well as physical interference, compromised suppliers, and weaknesses in the update process. Each scenario should explain what could be changed and how that change could affect device operation or patient safety.
3. Repudiation
Repudiation occurs when someone performs an action and later denies responsibility. Weak records can prevent your team from proving who made a change or issued a command.
Assess whether an actor could deny:
- Changing therapy settings
- Sending remote commands
- Using an override or service mode
- Approving an update
- Recovering an account
- Exporting device or patient data
Review user attribution, shared accounts, trusted timestamps, log retention, and protection against audit record deletion or alteration. FDA also recommends secure logging that supports the investigation of security events.
4. Information Disclosure
Information disclosure occurs when sensitive information becomes accessible to someone without permission. Within a medical device system, review possible exposure of:
- Protected health information and patient identifiers
- Credentials or cryptographic keys
- Clinical measurements and device identifiers
- Debug details and crash dumps
- Configuration backups and network metadata
Trace these risks across stored data, network communications, logs, companion applications, cloud platforms, and diagnostic interfaces.
5. Denial of Service
Denial of service aims to make a system unavailable or reduce its ability to operate when needed. In a medical device, even a temporary disruption can affect care.
Assess attacks that could interfere with:
- Therapy delivery, monitoring, or alarms
- Device setup and communications
- Battery life, storage, CPU, or memory
- Software updates and recovery functions
- Cloud platforms or shared fleet services
For each scenario, determine whether the device enters a safe condition, how quickly service can be restored, and whether the interruption could delay or stop treatment.
6. Elevation of Privilege
Elevation of privilege occurs when a user, process, or code gains capabilities it was not authorised to have. The access does not always move upward to an administrator role. Crossing into another protected role, process, or tenant also qualifies.
Assess whether an attacker could move from:
- Patient access to clinician functions
- Clinician access to administrator controls
- Standard access to service mode
- Application access to cloud administration
- Network access to device control
- A restricted process to operating system control
- Unsigned code to trusted execution
- One cloud tenant into another
5. Write Complete Threat Scenarios
Convert each finding into a connected attack narrative. State the attacker’s access, the weakness used, the hostile action, and the final consequence.
A single scenario can fall into more than one STRIDE category. When an attack depends on several connected stages, use an attack tree to show the route from initial access to the final objective. FDA recognises attack trees as a useful threat modeling method for examining how several actions can lead to an unwanted outcome.
Medical Device SBOM Analysis Methodology
The purpose is not to produce an inventory or count CVE matches. You need to confirm that the SBOM accurately represents the released build before deciding whether reported vulnerabilities affect the device.
1. Generate and Validate the SBOM for Each Build
Create a separate SBOM for every releasable software or firmware build. Link it to the product version, build identifier, release date, generation time, tool details, supplier, and configuration record.
Validate that it captures all software delivered with or required by that build, including internal code, purchased components, operating system packages, nested dependencies, companion applications, containers, and relevant cloud software. FDA recommends maintaining SBOM information through configuration management so it remains connected to the correct device version.
2. Check SBOM Quality and Completeness
Review the SBOM for gaps that automated generation can overlook:
- Forked or supplier-modified components
- Vendored source code and statically linked libraries
- Packages loaded only during runtime
- Components compiled into the product but not used
- Build tools incorrectly classified as released software
- Missing container or firmware layers
- Licensing and support lifecycle details
- Declared gaps in dependency information
File hashes and binary evidence can help confirm that uncertain components belong to the released software. Document any unresolved gaps rather than presenting the inventory as complete. CISA guidance supports checking SBOM completeness and clearly identifying known unknowns in the dependency tree.
3. Normalise Component Identities
Different tools and suppliers can label the same component in different ways, leading to missed vulnerabilities or incorrect matches. For example, OpenSSL could appear as OpenSSL, openssl, libssl, or a supplier-maintained fork.
Create one canonical internal record for each component. Reconcile package ecosystem, Package URL, CPE, hashes, repository details, supplier advisories, and patch status against available binary evidence.
Keep the original values from every source so reviewers can trace how the final identity was determined. Package URL and CPE provide structured identifiers, but accurate matching still depends on correct component and version data.
4. Match Vulnerability and Exploit Intelligence
Compare each validated component with:
- CVE records and supplier advisories
- NVD and CISA’s Known Exploited Vulnerabilities Catalog
- Coordinated disclosure and internal security findings
- Results from code analysis, binary testing, software composition analysis, and penetration testing
- Relevant healthcare threat intelligence
Do not rely on one database alone. Sources can differ in product naming, affected versions, patch details, and evidence of active exploitation.
CISA’s catalog, for example, identifies vulnerabilities with confirmed exploitation, while NVD adds technical and scoring information to CVE records.
5. Determine Applicability, Reachability, and VEX Status
A CVE match requires technical review before you decide that the device is affected. Confirm that the correct component and version exist in the released build. Then, examine whether the vulnerable code is present, enabled, reachable, and exposed under the required attack conditions.
Also consider supplier patches, product configuration, authentication controls, segmentation, required privileges, and potential effects on safety-related functions or multiple devices.
Assign one supported VEX status:
- Affected
- Not affected
- Fixed
- Under investigation
Document the product build, component, vulnerability, technical rationale, supporting evidence, controls, owner, review date, and reassessment trigger. A “not affected” decision must explain why exploitation cannot occur. The label alone does not provide sufficient support.
How to Prioritise Findings Based on Medical Device Risk
Do not treat the CVSS Base score as the final priority. It reflects the inherent characteristics of a vulnerability, while medical device decisions also depend on current exploitation and the potential effect on patient care. CVSS v4.0 Threat and Environmental metrics can add useful context, but they remain inputs to the wider security and safety risk process.
Give greater urgency to findings that:
- Threaten essential performance or clinical continuity
- Affect many patients or connected devices
- Appear in the CISA KEV Catalog or have public exploit evidence
- Cannot be contained through effective temporary controls
- Require complex deployment across the installed fleet
A remotely reachable vulnerability that could interrupt therapy deserves faster action than a higher-scoring local flaw located in unused code. CISA likewise recommends using confirmed exploitation as an input when setting remediation priorities.
How Qualysec Can Help Validate Medical Device Security Controls
Qualysec tests medical devices and connected systems across firmware, hardware interfaces, communication protocols, applications, APIs, cloud environments, and networks. Manufacturers can provide architecture details, priority threat scenarios, and relevant SBOM findings to guide the scope.
What You Receive
- Manual testing supported by automated techniques
- Evidence for confirmed vulnerabilities
- Clear remediation recommendations
- Consultation and retesting support
The assessment helps verify whether security controls resist realistic attacks. Regulatory, clinical, quality, and safety decisions remain the manufacturer’s responsibility.
Contact Qualysec to plan a focused penetration test for your device and its connected environment.
Conclusion
Software changes. Attack methods change. A STRIDE threat modeling methodology and SBOM analysis that matched the last release can quickly fall behind the medical device now in use.
Review both whenever code, interfaces, suppliers, cloud services, or vulnerability information changes. Keeping them aligned with the current build helps your team make defensible security decisions before submission and after the device enters the market. FDA guidance also treats cybersecurity as an ongoing product lifecycle responsibility rather than a single premarket task.
FAQs
1. Does FDA require medical device manufacturers to use STRIDE?
No. FDA expects manufacturers to use a systematic threat modeling method that suits the device and to explain their choice. STRIDE is an accepted option, but it is not the only framework manufacturers can use.
2. Does Section 524B require a threat model?
Section 524B directly requires qualifying cyber device submissions to include an SBOM and specified cybersecurity plans and processes. Threat modeling is recommended in FDA guidance rather than named in the statute’s minimum submission requirements.
3. How does an SBOM support medical device threat modeling?
An SBOM shows which software components are present in a particular build. Teams can use that information to identify where a vulnerable component operates and whether it changes an existing attack scenario or introduces a new one.
4. Does every CVE matched to an SBOM require a patch?
No. A match must be investigated before action is chosen. The review should confirm the component version and determine whether the vulnerable code is present, enabled, reachable, and capable of affecting the released device.
5. What is VEX in medical device cybersecurity?
VEX records whether a known vulnerability affects a specific product. Common statuses include affected, not affected, fixed, and under investigation. A decision should include enough technical evidence to explain how the status was reached.
6. Is penetration testing a substitute for threat modeling?
No. Threat modeling considers how attacks could occur and which safeguards are needed. Penetration testing examines the implemented device to determine whether those safeguards withstand realistic attack attempts. FDA treats threat analysis and security testing as connected parts of cybersecurity risk management.
7. How often should a medical device threat model and SBOM be updated?
Review both after changes that could alter the software inventory or attack surface. Triggers include new builds, replaced components, modified interfaces, supplier updates, security incidents, test findings, new vulnerabilities, and changes to the deployment environment.
