Understanding SBOM, SOUP, COTS, and OTS in Medical Device Cybersecurity
Jun 17, 2025
- Interlynk
In today’s connected healthcare world, understanding the software inside medical devices is critical — not just for secure development, but also for compliance and patient safety.
Regulators such as the FDA and IEC 62304 require medical device makers to track all included software components — whether custom, open-source, or third-party — and classify them based on origin and lifecycle documentation.
This post explores four key concepts: SBOM, SOUP, COTS, and OTS, and their role in meeting FDA cybersecurity and IEC 62304 requirements.
SBOM (Software Bill of Materials)
Definition: A formal record of all software components used in a device or application (including open-source libraries, proprietary code, firmware, APIs, and binaries).
Why It Matters:
Identifies vulnerable components (e.g., log4j).
Supports faster incident response.
Required under FDA Section 524B (March 2023).
Example: A Class II infusion pump includes third-party code. If a CVE emerges, an SBOM allows immediate impact assessment and patch prioritization.
Regulations Requiring SBOM:
FDA FD&C Act §524B
Executive Order 14028 (federal procurement)
EU Cyber Resilience Act
SOUP (Software of Unknown Provenance)
Definition: Software not developed under a documented medical software lifecycle process (e.g., open-source libraries, externally trained AI/ML models, legacy drivers).
Risks:
Unknown security history.
No clear development traceability.
Potential use of insecure APIs or cryptographic modules.
How to Handle (IEC 62304):
Perform risk analysis by device safety class.
Validate functionality and safety impacts.
Monitor vulnerabilities (e.g., NVD feeds).
Document mitigations.
Example: An ECG monitor uses a GitHub graphing library. If the library fails, it may display incorrect waveforms, affecting diagnosis.
OTS and COTS Software
Definitions:
OTS (Off-the-Shelf): Pre-built software not designed for the device.
COTS (Commercial Off-the-Shelf): Commercially licensed OTS software (e.g., Windows OS).
Risks & Mitigations:
No source code or patch control.
Vendor lifecycle decisions may affect safety.
FDA requires proof that OTS won’t degrade device performance.
Regulatory Guidance:
FDA’s Premarket Submission Guidance for COTS software.
IEC 62304 requires validation even if software is unmodified.
Regulation Round-Up
SBOM → Required for FDA, FD&C Act §524B, EU CRA.
SOUP Management → Required for IEC 62304, FDA guidance.
OTS/COTS Usage → Required for IEC 62304, FDA OTS guidance.
Why It Matters
Proactive Risk Mitigation: Faster detection and patching.
Regulatory Compliance: Avoid rejection or fines.
Patient Safety: Prevent device malfunctions or hacks.
Supply Chain Resilience: Transparency strengthens lifecycle security.
Manufacturer Best Practices
Automate SBOM generation via SCA tools.
Maintain CBOMs with patch timelines and responsibilities.
Create a SOUP registry with risk analyses.
Engage COTS vendors for long-term support.
Monitor CVE/NVD feeds for known and unknown software.
Integrate risks into ISO 14971 processes for patient safety.
In the regulated medical device industry, compliance isn’t just paperwork — it’s about protecting patients. A robust SBOM, SOUP, and COTS/OTS strategy ensures security, compliance, and trust in next-generation medical technologies.