TL;DR: Medical device security now depends on governing open source components, SBOM accuracy, vulnerability response, and lifecycle monitoring, because FDA 524B, FDA premarket guidance, and EU CRA all push cybersecurity into the compliance core, according to Kusari. The compliance burden is no longer separable from software supply chain control, and device teams need traceable ownership, patch discipline, and evidence-ready monitoring.
At a glance
What this is: Kusari’s guide argues that medical device cybersecurity depends on SBOM transparency, vulnerability management, and lifecycle monitoring for open source software embedded in regulated products.
Why it matters: For IAM, NHI, and security teams supporting connected devices, the issue is governance over inherited software risk, traceability, and evidence that controls still work after release.
Context
Medical device cybersecurity is no longer limited to network hardening or a one-time compliance review. Once open source software is embedded in a device, the organisation inherits ongoing responsibility for its integrity, vulnerability handling, and update discipline across the product lifecycle.
That changes the governance problem for teams responsible for connected devices and their supply chains. SBOM quality, ownership of component risk, and lifecycle monitoring now sit alongside security design and regulatory evidence, which makes this relevant to broader identity and software governance programmes even when no human identity issue is the primary subject.
Key questions
Q: What breaks when a medical device SBOM is incomplete?
A: An incomplete SBOM breaks vulnerability triage, release tracing, and regulator-facing evidence. Teams cannot reliably determine which device versions contain a vulnerable component or prove that a fix reached the right products. In practice, incomplete component inventories turn remediation into guesswork and slow both safety decisions and compliance response.
Q: When should device teams prioritise postmarket monitoring over premarket documentation?
A: They should prioritise postmarket monitoring as soon as the device ships, because vulnerability exposure continues after approval. Premarket documentation is necessary, but it cannot show whether newly disclosed flaws affect deployed products or whether patches were applied successfully. Continuous monitoring is what keeps the initial evidence usable.
Q: What do teams get wrong about open source in medical devices?
A: They often treat open source as a procurement issue instead of an ongoing governance obligation. The mistake is assuming component adoption ends the control problem, when the real challenge is ownership, patch coordination, and traceability across the device lifecycle. That is where security, safety, and compliance intersect.
Q: How should regulated product teams manage software supply chain risk in connected devices?
A: They should manage it as a lifecycle control, not a one-time assessment. That means authoritative SBOMs, vulnerability intake, named ownership for dependencies, and evidence that updates can be traced from code change to shipped artifact. The goal is to make every device supportable after release.
Technical breakdown
SBOM accuracy is the control plane for device software risk
A software bill of materials is only useful if it is complete, current, and mapped to the shipped build. In medical devices, that accuracy becomes the basis for vulnerability triage, legal exposure tracking, and regulator-facing evidence. If teams cannot identify which open source components are present, they cannot reliably assess whether a disclosed flaw affects a released device or a pending submission. The operational issue is not inventory for its own sake, but traceability from component to product version to remediation status.
Practical implication: establish build-to-release traceability so every shipped device version can be tied to an authoritative SBOM.
Lifecycle monitoring is required after pre-market submission
Medical device security does not end when the product is approved or shipped. New vulnerabilities can appear in embedded libraries long after release, and regulatory expectations now extend into postmarket monitoring and remediation. That means teams need a process for continuously identifying affected products, evaluating exploitability, and coordinating patches or compensating controls. The governance challenge is that static documentation quickly becomes stale when software dependencies change or threats evolve.
Practical implication: pair release governance with continuous vulnerability monitoring and a defined postmarket response workflow.
Open source dependency governance is now a compliance issue
Open source components are not inherently risky, but unmanaged dependency sprawl creates hidden obligations around security fixes, license terms, and supply chain evidence. In regulated device environments, a missing owner or unclear update path can turn a technical defect into a compliance failure. This is where software supply chain governance overlaps with broader security discipline: teams need clear accountability, approved component intake, and controlled update mechanisms so they can demonstrate that the device remains supportable over time.
Practical implication: assign named ownership for dependency intake, patching, and license review across the product lifecycle.
Threat narrative
Attacker objective: The practical objective is to exploit unmanaged third-party software in a regulated device environment to create security exposure that is harder to detect, patch, and evidence.
- Entry occurs when third-party or open source code is incorporated into a medical device without full visibility into its components and update status.
- Escalation follows when a vulnerable dependency remains in production because teams cannot rapidly map the issue to specific device versions or deployed populations.
- Impact is regulatory and operational, with safety, remediation, and compliance exposure increasing when the organisation cannot prove control over the software supply chain.
Breaches seen in the wild
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Software supply chain governance has become part of medical device security, not a side control. The article reflects a broader shift in regulated technology: once third-party code ships inside the device, the burden is no longer limited to vendor assurances or point-in-time testing. Teams need traceability from component inventory to deployed build, otherwise cybersecurity evidence collapses into guesswork. For device programmes, this means governance must reach into the software bill of materials, release process, and ongoing vulnerability handling.
SBOM quality is only valuable when it supports operational decisions. A complete inventory is not the end state. It has to answer which devices are affected, which versions are exposed, and which fixes can be applied without breaking clinical or operational function. That is why the critical concept here is evidence-ready component governance: the ability to turn component data into defensible action during remediation, audit, and regulatory review. Practitioners should treat SBOM accuracy as a live control, not documentation.
Regulatory pressure is pushing device cybersecurity toward continuous accountability. FDA 524B, premarket guidance, postmarket monitoring, and the EU Cyber Resilience Act all point in the same direction. The market signal is that security for connected devices must be measurable across the lifecycle, not asserted at launch. For practitioners, the question is whether ownership, patching, and monitoring are embedded in the operating model or left to ad hoc response after a flaw is disclosed.
The identity angle here is supply chain trust, not user authentication. In medical devices, the governance challenge often starts with software provenance, component custody, and update authority. That places machine and software identity concerns inside the supply chain conversation, because update trust and component integrity depend on knowing what was built, signed, and deployed. The practitioner takeaway is to align device governance with software provenance controls and to treat uncontrolled dependency intake as an identity-adjacent trust problem.
Lifecycle monitoring closes the gap between design-time security and field reality. Devices ship into environments that change, dependencies age, and disclosure timelines accelerate. Security teams that rely on pre-market evidence alone will miss post-release exposure. The discipline now required is sustained monitoring with ownership attached to each product line. Practitioners should assume that every shipped device needs a standing process for inventory refresh, vulnerability intake, and remediation prioritisation.
From our research library:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Evidence-ready component governance: medical device teams now need component inventories that can survive audit, patching, and postmarket vulnerability response. A static SBOM is not enough if it cannot show which release is affected and who owns the fix. For programmes that ship connected products, governance has to move from document creation to operational traceability.
The next practical test is whether a device organisation can still answer basic exposure questions after a vulnerability disclosure lands. If the team cannot identify affected builds, map customer deployments, and demonstrate a remediation path, the control model is too weak for regulated software. According to the State of Secrets in AppSec, only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
For practitioners
- Build release-linked SBOM governance Tie every device release to a versioned SBOM that maps components, hashes, and ownership to the shipped artifact. Treat incomplete component records as a release blocker, not a documentation gap.
- Operationalise postmarket vulnerability intake Create a workflow that matches disclosed vulnerabilities to affected device models, firmware versions, and customer deployments, then routes remediation decisions through a named owner.
- Assign dependency accountability Name owners for open source intake, patch validation, and license review so each dependency has a clear control path from adoption to retirement.
- Monitor secure update evidence Track whether update mechanisms can be traced from source code changes to signed release artifacts and deployed devices, including rollback and exception handling.
- Align device controls to regulatory evidence Map SBOM, vulnerability handling, and lifecycle monitoring evidence to FDA 524B, premarket guidance, and EU CRA obligations before the next submission.
Key takeaways
- Medical device cybersecurity now depends on governance over embedded software, not just device hardening at deployment.
- SBOM accuracy, vulnerability response, and lifecycle monitoring are the controls that determine whether teams can prove and maintain safety over time.
- Regulatory pressure from FDA 524B, premarket guidance, and the EU Cyber Resilience Act makes software supply chain evidence part of the operating model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and NIS2 and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Open source device software needs secure build and lifecycle control. |
| Recommendation — Apply CIS-16 to govern software component intake, build integrity, and release validation. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity of Software, Firmware and Information | The article centres on maintaining trustworthy device software across the lifecycle. |
| Recommendation — Use PR.DS-08 to preserve software and firmware integrity from build to postmarket updates. | ||
| MITRE ATT&CK | TA0003;TA0011 — Persistence; Command and Control | Compromised dependencies can sustain attacker presence and update paths. |
| Recommendation — Map vulnerable dependency exposure to TA0003 and TA0011 to improve threat detection. | ||
| NIS2 | Art. 21 — Cybersecurity risk management measures | Lifecycle security and supply chain controls align with regulated product obligations. |
| Recommendation — Map device supply chain controls to Art. 21 and retain evidence for lifecycle risk management. | ||
| EU Cyber Resilience Act | Art. 10 — Essential cybersecurity requirements | The article directly discusses CRA-driven SBOMs, secure updates, and vulnerability handling. |
| Recommendation — Use Art. 10 to anchor SBOM, secure update, and vulnerability handling requirements in product governance. | ||
Key terms
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Postmarket Cybersecurity Surveillance: The process of monitoring devices after release for emerging vulnerabilities, adversary activity, and remediation needs. It is a governance mechanism that connects external threat intelligence, patch management, and operational ownership so that device security does not stop at product launch.
- Software Supply Chain Governance: Software supply chain governance is the set of policies, controls, and oversight used to manage how software is built, signed, delivered, and updated. It covers source code, dependencies, build systems, artifacts, and release processes, with the goal of reducing tampering, malicious code insertion, and unauthorized change across the software lifecycle.
- Evidence-Ready Traceability: Evidence-ready traceability is the ability to connect a shipped product version to its component inventory, build artifact, and remediation status without manual reconstruction. It turns documentation into operational proof and is critical when regulators or customers need to see what was affected and what was done.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the identity control foundations that support broader security and compliance programmes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org