Costa Rica MedTech

Who this guide is for

This guide is for MedTech founders, product managers, systems engineers, software leads, cybersecurity engineers, QA/RA professionals, clinical engineering leaders, supplier-quality teams, and project managers.

This guide moves from regulatory context to patient-safety impact, then into a practical threat-modeling workflow, a connected infusion pump example, attack modeling, DFD + STRIDE analysis, and risk assessment.

Introduction: why threat modeling matters now

Connected medical devices are no longer single products; they are ecosystems. They operate through companion applications, hospital networks, cloud services, update infrastructure, service tools, third-party software, identity systems, and supplier-controlled components. A cybersecurity weakness in any part of that ecosystem can affect privacy, clinical performance, availability, post-market maintenance, or patient safety.

The EU Cyber Resilience Act (CRA) is part of a broader regulatory shift: connected products are expected to be designed, updated, monitored, and maintained so that cybersecurity risk is managed across the product lifecycle. For MedTech, that message reinforces existing MDR/IVDR, MDCG 2019-16, FDA, IEC 81001-5-1, and IEC 62304 expectations.

The practical question is not only whether the medical device itself is inside or outside the CRA. The practical question is whether the connected ecosystem is understood, controlled, verified, and monitored.

Threat modeling provides that bridge because it forces the team to connect architecture, clinical use, attack paths, controls, and evidence in one traceable record. It turns regulatory expectations into a structured evidence chain:

To make the method concrete, this article uses a connected infusion pump ecosystem as a running example. The example is illustrative, not a complete threat model.

Cybersecurity risk does not stop at the device boundary

The CRA is a horizontal EU regulation for products with digital elements. The European Commission describes it as a rulebook intended to ensure that hardware and software products are designed, updated, and maintained to protect users from cybersecurity threats^[3]. The CRA entered into force in December 2024 and full CRA enforcement starts December 11, 2027, with vulnerability-reporting obligations beginning before full application (September 11 2026).^[12]

For medical devices, the scope is more nuanced. MDR- and IVDR-regulated medical devices are currently excluded from the CRA’s direct scope because they are already covered by sector-specific EU legislation^[6][14][15]. That exclusion preserves the need for strong medical-device cybersecurity governance. The medical-device sector already has cybersecurity obligations under MDR/IVDR, MDCG 2019-16, IEC 81001-5-1, and related standards and guidance already connect cybersecurity to safety, performance, risk management, and user information^[9][10][11].

⚠️ The current CRA exclusion for MDR/IVDR-regulated medical devices should not be treated as permanent. The European Commission may revisit the scope of the exclusion over time.

The practical risk is ecosystem fragmentation. The regulated medical-device core, companion software, cloud services, update systems, and suppliers may sit under different obligations while sharing the same cybersecurity risk chain. Legal classification determines regulatory scope. Threat modeling determines cybersecurity risk scope.

A medical device may be excluded from CRA, while surrounding components may not be:

• a companion mobile app that is not itself a medical device,
• a cloud dashboard,
• an update server,
• a remote data-processing service,
• a gateway,
• a hospital integration component,
• an analytics platform,
• a device-management tool,
• a non-medical wearable or accessory.

For medical devices the question is:

Why cybersecurity is patient-safety evidence

Cybersecurity impact in MedTech can originate anywhere in the connected ecosystem and propagate to patient safety, product performance, and lifecycle maintenance.

Medical-device cybersecurity differs from generic product cybersecurity because a security failure can become a clinical failure. Connected medical devices create cybersecurity challenges that can affect patient safety, clinical workflow, healthcare infrastructure, and the manufacturer’s ability to maintain the product safely over time^[5]. MDCG 2019-16 already places cybersecurity risk within the broader medical-device risk framework, where risk is tied to probability and severity of harm ^[9][10].

The table below shows why MedTech cybersecurity evidence must translate security failures into clinical, operational, privacy, and lifecycle consequences.

In medical devices, cybersecurity impact connects directly to clinical performance and patient safety. A generic IT threat model may identify “tampering.” A MedTech threat model must ask:

That answer is key with modern MedTech devices where cybersecurity evidence must explain more than whether a control exists. It must explain why the control is needed, where it belongs in the ecosystem, how it reduces risk, how it was verified, who maintains it, and how the residual risk is monitored after release.

Threat Modeling as the Evidence Bridge

For medical-device manufacturers, cybersecurity regulation becomes operational only when it is translated into evidence. Auditors, notified bodies, FDA reviewers, customers, and incident investigators evaluate the practical record:

Show how threats were identified, why controls were selected, how controls were verified, what residual risk remains, and how the product is monitored after release.

Threat modeling provides that evidence pathway. It helps teams show:

• what the product does,
• what assets need protection,
• where data, commands, software, or credentials cross trust boundaries,
• how the system could be attacked,
• which failures could affect safety, privacy, performance, or availability,
• which controls reduce those risks,
• which tests verify that the controls work,
• what residual risk remains.

Cybersecurity compliance in MedTech cannot be an exercise where every product receives the same controls. A low-risk wellness app, a hospital-connected diagnostic platform, and a connected infusion pump do not need the same cybersecurity architecture. The right level of protection depends on the product’s intended use, clinical context, connectivity, data sensitivity, software architecture, and possible patient-safety impact.

That is what proportionality means: the manufacturer selects controls that are appropriate to the actual cybersecurity risk. Threat modeling helps make that decision defensible. It shows:

• what the product does,
• what assets need protection,
• where data, commands, software, or credentials cross trust boundaries,
• how the system could be attacked,
• which failures could affect safety, privacy, performance, or availability,
• which controls reduce those risks,
• which tests verify that the controls work,
• what residual risk remains.

Threat modeling also makes proportionality defensible. A low-risk wellness app, a hospital-connected diagnostic platform, and a connected infusion pump do not need the same cybersecurity architecture. Higher-risk functions, interfaces, and assets require deeper analysis, stronger controls, and more evidence.

Threat modeling shows why each cybersecurity control is appropriate to the device, clinical use, risk level, and residual risk.

Security controls should not be selected because they are fashionable or technically impressive. They should be selected because the threat model and risk assessment show that they are needed. In software in medical devices, controls such as secure boot, secure communications, memory protection, key storage, random number generation, secure enclaves, and secure elements are most defensible when tied to identified threats, assessed risk, and verification evidence.

Practical Workflow for MedTech Teams

Use this workflow to build a cybersecurity risk plan and evidence chain:

1. Define product and ecosystem scope
   • Identify the medical device, accessories, companion software, cloud services, update infrastructure, gateways, service tools, suppliers, and non-medical digital components. Map which team or external party owns each major component, control, and lifecycle responsibility. (see example)
2. Define intended use and clinical context
   • Capture patient population, users, use environment, essential performance, clinical workflow, and foreseeable misuse. (see example)
3. Create architecture and data-flow diagrams
   • Model processes, data stores, external entities, interfaces, and trust boundaries. (see example)
4. Identify protected assets
   • Include patient data, credentials, cryptographic keys, firmware, models, therapy parameters, logs, configurations, drug libraries, update packages, and SBOM-managed components. (see example)
5. Build the attack model (see section Attack Modeling)
   • Identify attacker objectives, entry points, attack paths, attack patterns, known vulnerabilities, threat actors, and misuse scenarios. (see example)
6. Perform threat modeling and classify with STRIDE
   • Threat modeling goal is giving proportionality to the work. The greater the risk the greater the work. (see section Threat Modeling)
   • Classify threats by spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. (see example)
7. Connect threats to medical-device risk
   • Translate security failures into possible clinical, safety, privacy, availability, performance, accountability, or lifecycle consequences. (see example)
8. Prioritize through risk assessment
   • Consider likelihood, exploitability, vulnerability severity, asset criticality, clinical severity, detectability, environment of use, CVSS, and known vulnerabilities. (see example)
9. Select security controls
   • Choose controls such as authentication, encryption, secure boot, signed updates, logging, key protection, segmentation, monitoring, and vulnerability response. (see example)
10. Verify and validate controls
    • Use requirements-based tests, security testing, penetration testing, fuzzing, code analysis, vulnerability scanning, update testing, and regression testing as appropriate. (see example)
11. Document residual risk and user responsibilities
    • If residual risk is acceptable: communicate required security assumptions, operating environment, configuration, update responsibilities, and residual risks. Otherwise, reassess risk and controls.
12. Maintain post-market cybersecurity
    • Monitor vulnerabilities, update SBOM/VEX, patch, disclose, respond to incidents, and feed learning back into the threat model.

Running example: connected infusion pump ecosystem

Consider a connected infusion pump ecosystem used in a hospital setting. The pump does not operate as an isolated device. It depends on embedded software, clinical users, hospital connectivity, cloud services, update infrastructure, maintenance tools, third-party software components, and lifecycle security records.

From a MedTech perspective, this matters because a cybersecurity weakness may affect more than data protection. It may affect therapy delivery, drug-library integrity, clinician decision-making, device availability, auditability, and the manufacturer’s ability to maintain the product safely after release.

Attack modeling

Attack modeling asks how an attacker could move from an entry point to an asset. Threat modeling converts those paths into structured threat scenarios, risk controls, verification evidence, and residual-risk decisions.

A practical attack-modeling workflow for a connected medical device has six steps.

Step 1. Define attacker objectives+

Start by asking what an attacker may want to accomplish in the specific product ecosystem. Objectives should be stated in terms of the asset or function the attacker wants to affect, not only in generic cybersecurity language.

The output of this step is a short list of attacker objectives that are relevant to the device’s intended use, clinical environment, and connectivity model.

For a connected medical device, attacker objectives may include:

• modify therapy parameters,
• access patient data,
• disrupt monitoring,
• install unauthorized firmware,
• abuse service access,
• exploit a vulnerable component,
• obtain credentials or cryptographic material,
• hide evidence by modifying logs.

Step 2. Identify entry points+

List every way data, commands, software, credentials, configuration, logs, or component information can enter or influence the system. Entry points may include wireless interfaces, Ethernet, USB, serial service ports, cloud APIs, web dashboards, mobile apps, update mechanisms, debug interfaces, user accounts, service tools, and third-party components.

Do not limit this step to obvious network interfaces. A service procedure, field-maintenance tool, default configuration, open-source dependency, or update workflow can also become an entry point.

The output of this step is an entry-point inventory linked to the system model and trust boundaries.

Step 3. Map attack paths+

Connect each attacker objective and entry point to the asset or function it could affect. A useful format is:

Entry point → Trust Boundary →
Affected Asset → Possible Impact

The goal is to describe how an attacker could move through the ecosystem. The attack path should identify the boundary crossed, the asset reached, and the possible MedTech consequence.

The output of this step is a set of candidate attack paths that can be reviewed for plausibility and clinical relevance.

Examples:

• Update server path: Update server → manufacturer-to-device update boundary → firmware image and update package → unauthorized software, persistent vulnerability, unsafe device behavior, or blocked post-market remediation.
• Clinician interface path: Clinician interface → user-to-device therapy boundary → therapy parameters and clinician credentials → unauthorized therapy configuration, unsafe setting change, weak accountability, or disputed clinical action.

Step 4. Enrich attack paths with frameworks and vulnerability knowledge+

Attack frameworks and catalogs enrich attack modeling. Framework are used to challenge the product-specific analysis and architectural model.

Tool or framework	What it helps answer	How to use it in MedTech
CAPEC	What attack patterns could apply to this architecture?	Use it to identify patterns such as interception, spoofing, replay, reverse engineering, command injection, abuse of authentication, and denial of service[16].
MITRE ATT&CK	What tactics and techniques might an adversary use after gaining access?	Use it for cloud services, identity systems, endpoints, enterprise networks, monitoring infrastructure, and incident-response planning[17].
CVE	Which known vulnerabilities affect components in the product?	Use it with the SBOM to determine whether a disclosed vulnerability applies to the device, cloud service, library, operating system, container, or dependency [18].
CWE	What weakness classes could exist in the design or implementation?	Use it to guide secure design reviews, code review, static analysis, and security testing [19].
STRIDE	How should the resulting threat be classified?	Use it after attack modeling to classify threats as spoofing, tampering, repudiation, information disclosure, denial of service, or elevation of privilege.

Use STRIDE to classify the threat, then use CAPEC to make the threat realistic. CAPEC is especially useful because it separates attack patterns from specific vulnerabilities. A CVE identifies a disclosed flaw in a known component. CAPEC helps the team reason about broader classes of attack that may exist through design, configuration, workflow, exposed interfaces, weak assumptions, or unsafe integration

For regulatory evidence, framework-informed analysis can strengthen:

If a reviewer asks why certain controls were selected, the manufacturer can explain that the control addresses a known class of attack relevant to the architecture and clinical use environment.

• Completeness of threat identification: The team can show that threat discovery used recognized attack-pattern and vulnerability sources to challenge assumptions.
• Traceability from attack pattern to control: A framework-informed threat can be traced to risk assessment, mitigation, security requirements, verification tests, and residual-risk decisions.
• Defensibility during review: If a reviewer asks why certain controls were selected, the manufacturer can explain that the control addresses a known class of attack relevant to the architecture and clinical use environment.

The output of this step is an enriched attack path with supporting attack patterns, relevant weakness classes, known vulnerabilities where applicable, and assumptions about exploitability.

Step 5. Translate attack paths into threat scenarios+

Convert each credible attack path into a threat-model entry. A useful threat-scenario record should include:

• attacker objective,
• entry point,
• trust boundary,
• affected asset,
• STRIDE category,
• possible clinical, privacy, operational, or lifecycle impact,
• existing controls,
• needed controls,
• verification evidence,
• residual-risk question.

The output of this step is a threat-model entry that can be traced to risk controls and evidence.

Step 6. Feed the result into risk assessment: +

Prioritize each threat scenario using exploitability, likelihood, vulnerability severity, clinical impact, essential performance, detectability, and environment of use.

Risk assessment should decide which controls are required, which controls are already sufficient, which assumptions must be documented, and which residual risks must be communicated.

The output of this step is a prioritized set of cybersecurity risks, selected controls, verification activities, residual-risk decisions, and post-market monitoring obligations.

Example Infusion Pump – Attack Modeling+

For a connected infusion pump, attack modeling may produce scenarios such as:

Procedure output	Update server example	Clinician interface example	How the output is used next
1. Attacker objective	Install unauthorized firmware, force rollback to a vulnerable version, or block a corrective update.	Use a compromised credential or active session to change therapy settings without authorization.	Defines what the attack model must test against safety, privacy, performance, and lifecycle-maintenance concerns.
2. Entry point inventory	Update server, update package, signing workflow, device update client, remote maintenance path.	Clinician interface, user account, browser or local UI session, authentication service, role-permission model.	Links the attack model to the system model, interfaces, and trust boundaries that need review.
3. Candidate attack path	Update server → manufacturer-to-device update boundary → firmware image and update package → unauthorized software or unsafe device behavior.	Clinician interface → user-to-device therapy boundary → therapy parameters and clinician credentials → unauthorized therapy configuration or unsafe setting change.	Shows how an attacker could move from an entry point to an asset with clinical or operational relevance.
4. Enriched attack knowledge	CAPEC-style patterns may include spoofing the update source, tampering with the package, downgrade attack, replay, or abuse of signing-key controls. CVE/CWE review focuses on update client, cryptographic library, package parser, and signing workflow weaknesses.	CAPEC-style patterns may include authentication bypass, authentication abuse, session hijacking, session replay, CSRF in web workflows, command injection, and privilege escalation. ATT&CK may add valid-account and account-manipulation behaviors where cloud identity or hospital IT is involved.	Makes the scenario more realistic and documents which attack patterns, weakness classes, known vulnerabilities, and exploitability assumptions were considered.
5. Threat scenario record	Potential STRIDE categories: spoofing and tampering. Candidate controls: signed updates, secure boot, rollback protection, authenticated update channel, protected signing keys, update verification tests.	Potential STRIDE categories: spoofing, elevation of privilege, tampering, and repudiation. Candidate controls: strong authentication, role-based authorization, session timeout, re-authentication for high-risk changes, protected audit logs, and usability safeguards.	Converts the attack path into a threat-model entry that can be traced to security requirements, controls, and verification evidence.
6. Risk-assessment input	Assess whether unauthorized firmware could affect essential performance, whether the attack is feasible in the deployment environment, and whether residual risk remains after secure-update controls.	Assess whether unauthorized configuration could cause patient harm, whether workflow or usability factors increase likelihood, whether audit logs support investigation, and whether user responsibilities are needed in labeling.	Feeds prioritization, control selection, verification planning, residual-risk decisions, and post-market monitoring obligations.

DFDs and STRIDE: making the model systematic

The infusion pump example showed the output of threat modeling. This section summarizes the general method for building that output from architecture.

Attack modeling identifies plausible attacker objectives, entry points, and attack paths. DFD + STRIDE then converts those paths into structured threat scenarios.

A data flow diagram (DFD) shows how the product is supposed to work. STRIDE helps the team ask how that same architecture could fail, be misused, or be attacked ^[1][2][13].

The traceable output is:

A useful DFD should show the product as a connected clinical system, not only as software modules. For a connected medical device, the DFD should include:

The DFD should be reviewed by engineering, cybersecurity, systems, clinical, QA/RA, and service stakeholders. Each group will see different assumptions. A software engineer may see an API, while a clinical reviewer may see a therapy workflow risk.

Each credible STRIDE question should become a threat scenario:

The final output should support traceability from architecture and trust boundaries to threat scenarios, controls, verification evidence, residual risk, and post-market monitoring.

Risk Assessment: from possible threats to prioritized controls

Threat modeling identifies what could go wrong. Risk assessment decides what must be controlled, verified, accepted, communicated, or monitored.

A useful cybersecurity risk assessment should connect five views:

A CVE in a library may be severe in general but not exploitable in the device implementation. That is why risk assessment uses CVSS as one input. CVSS describes vulnerability severity, while the full medical-device risk assessment also considers clinical context, exploitability, reachability, essential performance, detectability, environment of use, and patient-safety impact. Conversely, a moderate vulnerability may be clinically significant if it affects essential performance or blocks a required update path.

That is why SBOM and VEX documentation matter ^[1][4][8]. VEX helps document whether a known vulnerability is exploitable in the product’s actual configuration and use context. In MedTech, that decision should be traceable to architecture, threat model, risk assessment, and test evidence.

The risk assessment should produce more than a priority ranking. It should produce action decisions:

• Control decision: What control is required, and where in the ecosystem should it be implemented?
• Verification decision: What test, analysis, inspection, or monitoring evidence proves the control works?
• Residual-risk decision: What risk remains after controls, and is it acceptable in the clinical and operational context?
• Responsibility decision: Who maintains the control: device engineering, cloud operations, supplier quality, cybersecurity, service, or the healthcare delivery organization?
• Lifecycle decision: What must be monitored after release: CVEs, supplier notices, cloud configuration, identity controls, update success, field incidents, or service-tool access?

For the infusion pump ecosystem, the traceability can look like this:

Cybersecurity risk management documentation should summarize the method, risk conclusions, mitigation activities, residual-risk rationale, and traceability between the threat model, cybersecurity risk assessment, SBOM, VEX decisions, and testing documentation ^[4].

The practical MedTech rule is:

Key Takeaways

• CRA still matters to MedTech. MDR/IVDR medical devices may be excluded from the CRA’s direct scope, but connected ecosystem components can still create cybersecurity exposure.
• Cybersecurity risk does not stop at the device boundary. Companion apps, cloud services, update infrastructure, service tools, suppliers, and third-party components may affect safety, privacy, performance, availability, or lifecycle maintenance.
• Threat modeling is the practical bridge. It turns regulatory expectations into architecture, assets, attack paths, threats, controls, tests, residual-risk decisions, and post-market monitoring.
• MedTech threat modeling must connect security to clinical risk. STRIDE is useful, but each threat must be evaluated in relation to intended use, essential performance, patient safety, and clinical workflow.
• SBOM and VEX belong in the evidence chain. They help explain whether known vulnerabilities are present, reachable, exploitable, mitigated, or acceptable.
• Controls should be risk-driven. Secure boot, encryption, signed updates, key protection, segmentation, and monitoring are defensible when they trace back to credible threats and assessed risk.
• The cybersecurity file must tell a lifecycle story. It should show what was built, what can go wrong, what controls were chosen, how they were verified, what residual risk remains, and how the product will be maintained.

For MedTech leaders, the goal is not simply to show that cybersecurity controls exist. The goal is to show that the right controls were selected, verified, maintained, and connected to patient-safety risk.

References

[1] C2A Security. (n.d.). The Cyber Resilience Act explained: What MDMs and healthcare security leaders need to know. https://c2a-sec.com/the-cyber-resilience-act-explained-what-mdms-and-healthcare-security-leaders-need-to-know/

[2] Cooley. (2023, January 5). Medical devices and IVDs fall outside the scope of the proposed CRA – but for how long? Productwise. https://products.cooley.com/2023/01/05/medical-devices-and-ivds-fall-outside-the-scope-of-the-proposed-cra-but-for-how-long/

[3] European Commission. (n.d.). Cyber Resilience Act. Shaping Europe’s Digital Future. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

[4] Food and Drug Administration. (2026). Cybersecurity in medical devices: Quality management system considerations and content of premarket submissions. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket

[5] Göldi, A., Weisstanner, C., & Menges, F. (2025). Cybersecurity requirements for medical devices in the EU and US: A comparison and gap analysis of the MDCG 2019–16 and FDA premarket cybersecurity guidance. PMC. https://pmc.ncbi.nlm.nih.gov/articles/PMC12301760/

[6] L4B Software. (n.d.). CRA medical device compliance: What’s really exempt? https://www.l4b-software.com/cra-medical-device-ecosystem/

[7] Intertek. (n.d.). IEC 81001-5-1 compliance for medical devices. https://www.intertek.com/medical/connected-technologies/iec-81001-5-1-compliance/

[8] Johner Institute. (2022, May 23). Threat modeling – An introduction. https://blog.johner-institute.com/systems-engineering/threat-modeling/

[9] Medical Device Coordination Group. (2019/2020). MDCG 2019-16: Guidance on cybersecurity for medical devices. European Commission. https://ec.europa.eu/docsroom/documents/41863

[10] Medical Device Coordination Group. (2022). MDCG 2019-16 Rev.1: Guidance on cybersecurity for medical devices. European Commission. https://health.ec.europa.eu/system/files/2022-01/md_cybersecurity_en.pdf

[11] NXP Semiconductors. (n.d.). How NXP is raising the bar for cybersecurity in connected medical devices. https://www.nxp.com/company/about-nxp/smarter-world-blog/BL-NXP-CYBERSECURITY-CONNECTED-HEALTHCARE

[12] Open Source Security Foundation. (n.d.). EU Cyber Resilience Act (CRA). https://openssf.org/public-policy/eu-cyber-resilience-act/

[13] Rephine. (n.d.). Threat modelling & STRIDE: Your first step to MDR/IVDR cybersecurity compliance. https://www.rephine.com/resources/blog/threat-modelling-in-medical-devices/

[14] Seleon GmbH. (n.d.). The Cyber Resilience Act in medical technology. https://www.seleon.com/en/the-cyber-resilience-act-in-medical-technology/

[15] Toradex, Doulos, & NXP Semiconductors. (2026). Making cybersecurity compliance easier: Risk analysis and threat modeling

[16] MITRE. (n.d.). Common Attack Pattern Enumeration and Classification (CAPEC™). https://capec.mitre.org/

[17] MITRE. (n.d.). MITRE ATT&CK®. https://attack.mitre.org/

[18] CVE Program. (n.d.). CVE: Common Vulnerabilities and Exposures. https://www.cve.org/

[19] MITRE. (n.d.). Common Weakness Enumeration (CWE™). https://cwe.mitre.org/

Definitions and acronyms

• CAPEC: Common Attack Pattern Enumeration and Classification, a MITRE knowledge base of common attack patterns.
• CRA: EU Cyber Resilience Act, Regulation (EU) 2024/2847, setting horizontal cybersecurity requirements for products with digital elements.
• CVE: Common Vulnerabilities and Exposures, a public catalog of disclosed cybersecurity vulnerabilities.
• CVSS: Common Vulnerability Scoring System, used to score vulnerability severity.
• DFD: Data flow diagram, used in threat modeling to show processes, external entities, data stores, data flows, and trust boundaries.
• ECR: Essential Cybersecurity Requirement.
• IEC 62304: Medical device software life-cycle process standard.
• IEC 81001-5-1: Health software and health IT systems security standard focused on secure lifecycle processes.
• MDCG 2019-16: EU Medical Device Coordination Group guidance on cybersecurity for medical devices.
• MDR / IVDR: EU Medical Device Regulation / In Vitro Diagnostic Medical Device Regulation.
• SBOM: Software Bill of Materials.
• SaMD: Software as a Medical Device.
• SOUP: Software of Unknown Provenance.
• STRIDE: Threat-classification model: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
• VEX: Vulnerability Exploitability eXchange.

Appendix A – VEX

VEX (Vulnerability Exploitability eXchange) captures a product-specific assessment of a known vulnerability.

• Key elements:
  • Identified vulnerability: CVE ID + source (e.g., NVD URL)
  • Project decision: analysis of impact and disposition (e.g., not_affected, justification like code_not_reachable, response like will_not_fix / update)
  • Link to affected component: reference that ties the vulnerability entry back to the SBOM component (e.g., a CycloneDX component reference / package version)
• Practical note: Decoupled VEX data should be linked to a CycloneDX SBOM.

{
  "vulnerabilities": [
    {
      "id": "CVE-…",
      "source": { "name": "NVD", "url": "<https://nvd.nist.gov/vuln/detail/…>" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "response": ["will_not_fix", "update"],
        "detail": "Optional explanation of why the application is not affected."
      },
      "affects": [{ "ref": "urn:cdx:…/component@version" }]
    }
  ]
}

Appendix B – Vulnerability Response Workflow

Appendix C – Attack modeling

Example clinician interface path:

Exploitability assumptions to document: The team should state whether an attacker needs physical access to the pump, network access in the hospital environment, a stolen clinician credential, access to an unlocked session, access to a service account, or the ability to reach a cloud or web interface. The team should also document assumptions about MFA, password policy, session timeout, role separation, network segmentation, audit-log protection, and whether therapy changes require confirmation or independent review.

• Attack-pattern lens: CAPEC analysis challenges the team to consider authentication bypass, authentication abuse, session hijacking, session fixation, session replay, credential prediction or falsification, cross-site request forgery in web-based workflows, command injection where user input reaches command or configuration logic, and privilege escalation through role or permission weaknesses^[16].
• ATT&CK lens: If the clinician interface depends on cloud identity, enterprise identity, browser sessions, endpoints, or hospital IT infrastructure. Relevant adversary behaviors include use of valid accounts, account manipulation, persistence through modified permissions, abuse of remote or externally exposed services, and defense evasion through legitimate credentials ^[17].
• CWE / weakness lens: The team should check whether the interface design or implementation could include weakness classes such as broken authentication, improper authorization, insufficient session expiration, predictable session tokens, missing audit integrity, improper input validation, insecure credential storage, or insufficient protection of therapy-setting workflows ^[19].
• CVE / component lens: If the clinician interface uses a web framework, identity provider SDK, mobile framework, embedded web server, browser component, API gateway, operating system service, or third-party authentication library, the SBOM should be checked for known CVEs. The analysis should determine whether the vulnerable component is present, reachable through the clinician workflow, exploitable in the deployed configuration, and relevant to therapy-setting changes or credential compromise ^[18].

Enriched attack path output: An attacker obtains or reuses a clinician session, crosses the user-to-device therapy boundary, accesses therapy parameters, and attempts an unauthorized setting change. The credible threat scenarios are:

• spoofing of a clinician identity,
• elevation of privilege into a role that can modify therapy settings,
• tampering with therapy configuration, and
• repudiation if audit evidence is incomplete or alterable.

Candidate controls include:

• strong authentication,
• role-based authorization,
• session timeout,
• re-authentication for high-risk therapy changes,
• input validation,
• protected audit logs,
• separation of clinical and service roles,
• usability safeguards, and
• verification tests that prove unauthorized users cannot change therapy settings.

Appendix D – Why CAPEC is especially relevant in MedTech threat modeling

In a connected infusion pump ecosystem, CAPEC can sharpen the attack model in several places:

CAPEC is also useful because it separates attack patterns from specific vulnerabilities. A CVE identifies a disclosed flaw in a known component. CAPEC helps the team reason about broader classes of attack that may exist even when no public CVE has been published. That distinction is important in medical devices because a product can be vulnerable through design, configuration, workflow, exposed interfaces, weak assumptions, or unsafe integration, in the same way that it can be through a known software defect.

CAPEC also complements STRIDE. STRIDE is a compact classification framework: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. CAPEC provides richer attacker playbooks that can help populate each STRIDE category with realistic scenarios. For example:

• Spoofing: CAPEC-style thinking may reveal impersonation of a device, clinician, update server, gateway, or service tool.
• Tampering: CAPEC-style thinking may reveal modification of firmware, drug libraries, configuration files, logs, or network messages.
• Information disclosure: CAPEC-style thinking may reveal interception of wireless traffic, API enumeration, exposed secrets, or reverse-engineered protocols.
• Denial of service: CAPEC-style thinking may reveal flooding, lockout, resource exhaustion, or disruption of essential communication paths.
• Elevation of privilege: CAPEC-style thinking may reveal abuse of maintenance interfaces, misconfigured roles, weak authorization, or privilege escalation through vulnerable components.

The practical rule is:

For regulatory evidence, CAPEC can strengthen the cybersecurity file in three ways:

1. Completeness of threat identification
   • The team can show that threat discovery used a recognized attack-pattern catalog to challenge assumptions and strengthen brainstorming.
2. Traceability from attack pattern to control
   • A CAPEC-informed threat can be traced to a risk assessment, mitigation, security requirement, verification test, and residual-risk decision.
3. Defensibility during review
   • If a reviewer asks why certain controls were selected, the manufacturer can explain that the control addresses a known class of attack pattern relevant to the architecture and clinical use environment.

CAPEC works best as a targeted analysis aid. Relevant CAPEC patterns are selected according to the device architecture, interfaces, trust boundaries, clinical use environment, and plausible attack paths. The right use is targeted: start from the device architecture, identify interfaces and trust boundaries, select plausible CAPEC patterns, map them to STRIDE categories, connect them to medical-device risk, and then decide which controls and tests are justified.

CAPEC gives the MedTech team an attacker’s lens and turns the threat model into a systematic analysis of how the device ecosystem could be attacked.