In early December 2025, the IEC released an interpretation sheet to clarify important aspects of IEC 81001-5-1, the international standard for securing health software and health IT systems. The goal of the new interpretation is to help manufacturers and operators better understand how security responsibilities are defined throughout the software lifecycle and how risk transfer should occur once a product is deployed.
These clarifications matter because modern healthcare relies heavily on connected medical devices and health software. Security risks can emerge not only in the device or software itself but also in the broader environment in which it operates.
Health Software Operates in a Larger Ecosystem
The interpretation sheet reinforces that health software exists within a connected and complex healthcare ecosystem. It functions inside a wider health IT system and infrastructure and interacts with surrounding technology. ISO 81001-1 is identified as the reference that defines this sociotechnical ecosystem and explains how health software relates to the broader healthcare system.
This means that security evaluations cannot be limited to isolated software components. They must account for how the software interacts with medical devices, external systems, networks, and operators.
Clarifications on Documentation and Security Issue Disclosure
The interpretation sheet highlights the importance of accompanying documentation that manufacturers must provide to operators. This documentation supports the transfer of risk-related information from the manufacturer to the organization that deploys and uses the software.
The interpretation also addresses the disclosure of security related issues. It notes that identifying the severity and characteristics of vulnerabilities, including scoring approaches such as CVSS, helps operators understand the nature of security issues and how they should be addressed.
In addition, it clarifies that security guidelines referenced in the standard correspond to specific documentation requirements described in other clauses.
Clarified Software Item Classifications
One of the most detailed sections of the interpretation involves software item classifications. These classifications determine how different clauses of the standard apply to different types of software components.
The interpretation defines three categories:
Maintained software
Software for which the manufacturer provides updates.
Supported software
Software intended for use with the health software product where updates may be managed by the operator or an external supplier.
Required software
Software that must be used for the health software to operate but for which the manufacturer may not be able to obtain updates.
The interpretation explains that these categories are nested. Supported software includes maintained software. Required software includes supported software. This allows clauses that refer to one category to also apply to categories contained within it unless otherwise stated.
The interpretation also clarifies how specific clauses apply to these categories.
Clause 5.2.3, which addresses the identification and management of security risks, applies to maintained, supported, and required software.
Clause 6.3.1, which concerns communicating update information, applies to maintained and supported software. Operators should be notified about updates to these types of software items.
Clauses 6.3.2 and 6.3.3, which address making updates available and verifying update integrity, apply only to maintained software.
These clarifications help manufacturers understand how to classify software items and how to meet the corresponding requirements.
How Classifications Support Risk Transfer
The interpretation sheet explains why these distinctions exist. It notes that risk associated with the use of health software transitions to the operator once the product is installed and used. For example, operators may need to manage the timing of security updates to ensure compatibility with shared systems. This helps explain the role of supported software.
In other situations, manufacturers may not be able to obtain security notifications or updates for certain software items. This explains the role of required software. Even when updates are unavailable for these items, manufacturers remain responsible for maintaining the overall security of the health software product through other means.
The interpretation also explains that software items may change categories during the product lifecycle. Items may be downgraded from maintained to supported or required. When this happens, manufacturers must reassess the relevant requirements to ensure appropriate handling of risk.
Transitional Products and Postmarket Clarifications
The interpretation clarifies that the concept of transitional health software applies to entire products that were developed before IEC 81001-5-1 existed. It is separate from the maintained, supported, and required categories and is not a fourth classification. Transitional products are evaluated differently because they were not originally developed under the full set of activities described in clauses 4 through 9 of the standard.
The interpretation also clarifies expectations for reviewing public incident reports. It explains that the activity focuses on reviewing the relevant information rather than the entire source.
How C2A Is Relevant to These Clarifications
The interpretation sheet strengthens expectations around identifying software risks, communicating update responsibilities, and managing security across the software lifecycle. These expectations align closely with the challenges that organizations face when working with complex medical devices and interconnected health software.
C2A provides capabilities that help address these challenges by focusing on context driven risk decisions rather than raw vulnerability lists. Instead of treating all CVEs equally, C2A connects SBOM information to device architecture, data flows, threat models, potential attack paths, and real world exposure. This helps teams identify which vulnerabilities are likely to matter in practice.
This approach supports clearer decision making when applying the intent of clause 5.2.3, which requires identifying and managing risks for all software items. By showing which components are reachable or relevant in an actual deployment, C2A helps manufacturers understand what requires action and what does not.
C2A also strengthens communication between manufacturers and operators. The interpretation sheet emphasizes that operators need clear information about updates, configuration expectations, and software item responsibilities. C2A provides a unified view of vulnerabilities, prioritization, and recommended actions. This helps operators act on security information more quickly and understand their responsibilities as software categories change over time.
Finally, the interpretation sheet reinforces that security is a continuous activity. C2A helps teams maintain this ongoing oversight by reducing the time required to analyze vulnerabilities and by providing structured, repeatable processes for assessing exposure. This supports organizations as they manage both premarket and postmarket security activities and helps them maintain a secure posture across the life of the device or software product.
Schedule a demo to learn more about C2A context-driven platform that connects SBOM information to device architecture, data flows, threat models, potential attack paths, and real world exposure.
