Vulnerability management and coordinated disclosure

IEC 81001-5-1:2021 · §5.7 — Security activities after release

Why post-release security is mandatory

Health software does not exist in a static security environment. New vulnerabilities are discovered in third-party libraries, operating systems, and network protocols every day. A software product that was secure at release can become vulnerable within weeks if the manufacturer does not actively monitor and respond to newly disclosed vulnerabilities. IEC 81001-5-1 §5.7 recognises this reality and requires that security be treated as a continuous lifecycle activity, not a one-time release gate.

SOUP and OTS component monitoring

SOUP (Software of Unknown Provenance) is a core concept in IEC 62304 §8, referring to pre-existing software components used without access to source code — including open-source libraries, commercial middleware, operating systems, and hardware firmware. IEC 81001-5-1 §5.7 requires manufacturers to:

1. Maintain a complete SOUP/OTS inventory (which forms the core of the SBOM)
2. Subscribe to vulnerability notification channels for each SOUP item — including NVD (National Vulnerability Database), vendor security advisories, and CVE feeds
3. Assess each newly disclosed vulnerability against the deployed software configuration to determine whether it is exploitable
4. Determine a risk-based response: patch, workaround, compensating control, or accepted risk with documentation
5. Track the status of each vulnerability through to resolution or accepted residual risk

Software Bill of Materials (SBOM)

The SBOM is the machine-readable inventory of all software components in a released product. It is required by IEC 81001-5-1 §5.6 as a release deliverable and is the foundation for post-release vulnerability monitoring. The SBOM must include: component name and version; supplier/source; known licence; known vulnerabilities at time of release; and the SBOM format (SPDX or CycloneDX are the most widely adopted).

The FDA's 2023 cybersecurity guidance requires SBOM submission for all premarket submissions containing software. The SBOM must be updated with each software release and provided to customers on request. Health software manufacturers should consider automating SBOM generation using tools integrated into the CI/CD pipeline (e.g., Syft, Trivy, OWASP Dependency-Track).

Coordinated Vulnerability Disclosure (CVD)

CVD is the process by which external parties — security researchers, customers, regulators, or CERTs — can report vulnerabilities in the manufacturer's product and receive a structured, timely response. IEC 81001-5-1 §5.7 requires manufacturers to establish and operate a CVD process. The standard references ISO/IEC 29147 (vulnerability disclosure guidelines for vendors) and ISO/IEC 30111 (vulnerability handling processes for vendors) as the applicable standards for CVD implementation.

A minimum CVD process must include:

• A publicly accessible and clearly visible disclosure channel (email address or web form) — often hosted at security.{company}.com or disclosed in a security.txt file
• An acknowledgement to the reporter within 5 business days
• Regular status updates to the reporter throughout the investigation
• A target resolution timeline (typically 90 days, following responsible disclosure conventions)
• A policy for coordinated public disclosure once a fix is available
• Criteria for emergency disclosure when active exploitation is occurring

Product Security Incident Response Team (PSIRT)

Large manufacturers typically operate a PSIRT — a dedicated function responsible for receiving, investigating, and coordinating the response to product security vulnerabilities. For smaller organisations, the PSIRT function may be fulfilled by the RA/QA team, but the process must still be formally defined and documented. The PSIRT must have defined escalation paths for vulnerabilities with potential patient safety impact, including triggers for regulatory notification.

Security advisories and customer notification

When a vulnerability is confirmed and a fix or workaround is available, the manufacturer must issue a Security Advisory to customers. The advisory must include: a description of the vulnerability; affected product versions; severity assessment (CVSS score recommended); recommended actions (patch, workaround, or compensating controls); and the timeline for a permanent fix if a workaround is the interim recommendation.

Link to EU MDR Post-Market Surveillance

EU MDR Article 83 requires manufacturers to implement a Post-Market Surveillance (PMS) system that actively collects and analyses data from the field. Cybersecurity events — including discovered vulnerabilities, exploitation attempts, and security incidents — are field data within the meaning of MDR Article 83. The PMS plan must include provisions for monitoring the cybersecurity status of deployed software, and the Periodic Safety Update Report (PSUR) or Post-Market Surveillance Report (PMSR) must address cybersecurity findings.

Serious security incidents that could lead to patient harm may trigger EU MDR Article 87 serious incident reporting obligations. Manufacturers must assess each security incident against the MDR serious incident criteria and initiate a field safety corrective action (FSCA) if the criteria are met.

Record retention