Singapore’s Health Sciences Authority (HSA) has published GL-10-R1, Best Practices Guide for Medical Device Cybersecurity, providing a comprehensive set of practical recommendations for managing cybersecurity throughout the Total Product Life Cycle (TPLC) of connected medical devices.
The guide is Revision 1, August 2026, with the revision history recording its first release as effective from 17 August 2026.
The publication comes at a time when medical devices are becoming increasingly connected, software-dependent and integrated with hospital networks, cloud platforms and other digital healthcare systems. While greater connectivity brings significant clinical and operational benefits, it also increases exposure to cybersecurity threats.
For a medical device, a cybersecurity incident may go beyond loss of data or system access. A compromised device could potentially affect its availability or intended performance, delay treatment or contribute to an incorrect clinical decision. This is why HSA approaches cybersecurity as a patient-safety and product life-cycle issue rather than simply an IT security concern.
First, GL-10-R1 is not a new registration requirement
This is an important distinction for manufacturers.
HSA clearly states that GL-10-R1 does not constitute regulatory guidance and does not establish regulatory requirements or expectations for pre-market submission or registration. Instead, the document provides practical recommendations for managing cybersecurity throughout the TPLC of connected medical devices.
In other words, manufacturers should not automatically convert every recommendation in GL-10-R1 into a new HSA submission requirement. The guide is better used as a framework for reviewing whether cybersecurity has been adequately considered throughout development, deployment, maintenance, post-market support and eventual product retirement.
The scope is broad. It covers connected general medical devices as well as connected In-Vitro Diagnostic (IVD) devices placed on the Singapore market, whether intended for professional or non-professional use. Importantly, it is relevant not only to new products but also to devices already installed and in use in Singapore.
The intended stakeholders include manufacturers, product registrants, importers, local authorised representatives and healthcare providers. Manufacturer-related recommendations start at the Development stage, while the responsibilities described for healthcare providers begin during the Support stage.
Cybersecurity is a Total Product Life Cycle activity
One of the strongest messages in GL-10-R1 is that cybersecurity cannot be handled as a one-time development activity or a penetration test performed just before product release.
HSA divides the cybersecurity life cycle into Development, Support, Limited Support and End of Support. Cybersecurity activities and responsibilities evolve as the device moves through these stages.
This has practical implications for manufacturers. Cybersecurity planning needs to consider not only how a product is protected when it enters the market, but also how vulnerabilities will be monitored, how software components will be maintained, how patches will be delivered, how security information will reach customers and what will happen when the device or its components are no longer actively supported.
HSA also identifies three general principles underlying this approach: Shared Responsibilities, Transparency and Communication, and Secure by Design.
Shared responsibility does not mean that responsibility is simply transferred to the healthcare provider once the device is installed. Manufacturers remain responsible for incorporating appropriate cybersecurity measures into device design and life-cycle planning. Product registrants, importers and local authorised representatives support the communication and implementation of relevant cybersecurity measures in Singapore. Healthcare providers assume operational responsibilities during use, but HSA specifically notes that they should not be expected to carry the full cybersecurity responsibility while manufacturer support remains available.
Transparency is equally important. Manufacturers and other stakeholders should have appropriate channels for communicating vulnerabilities, updates, mitigations and changes in product support. This becomes particularly important as a device approaches End of Life or End of Support.
Building security into product development
During the Development stage, GL-10-R1 focuses on security design, risk management, cybersecurity assessment and testing, user information, post-market planning and the Software Bill of Materials.
Two concepts receive particular attention: Secure by Design and Secure by Default.
Secure by Design means cybersecurity should be considered from the beginning of the design process. Rather than adding security controls after the architecture has already been established, manufacturers should anticipate potential threats and vulnerabilities and design the product to resist them.
Secure by Default takes this further from the user’s perspective. A device should be configured to provide an appropriately secure state from the outset without depending on the customer to change multiple settings before the product becomes secure.
In practice, these principles can influence decisions around authentication, access privileges, encryption, secure boot, code signing, operating-system hardening, network connectivity, software-update mechanisms and security logging.
The underlying message is straightforward: addressing security during architecture and development is generally more effective than attempting to correct fundamental weaknesses after the device has already been deployed.
Cybersecurity and ISO 14971 risk management
GL-10-R1 closely connects cybersecurity with medical device risk management.
The Risk Management Plan should formally include cybersecurity within its scope and establish criteria for determining whether cybersecurity risks are acceptable. HSA also recommends that the risk management team include individuals with dedicated cybersecurity expertise.
During risk analysis, manufacturers should consider how cybersecurity threats could compromise the confidentiality, integrity or availability of the device, its data, software or functions. Malware, unauthorised access and denial-of-service attacks are examples of threats that could create hazardous situations and ultimately lead to patient harm, delayed treatment or incorrect clinical decisions.
One practical challenge is estimating the probability of an intentional cyberattack. Unlike some conventional failure modes, a cyberattack involves an intelligent adversary and changing threat environment. HSA therefore points to exploitability assessment, including approaches such as the Common Vulnerability Scoring System (CVSS), when dealing with known vulnerabilities. Where a vulnerability is known and exploitable, manufacturers should consider that it could be targeted and focus on the potential severity of the resulting harm.
For risk controls, HSA follows the familiar hierarchy under ISO 14971: inherent safety by design, protective measures, and information for safety. The guide gives examples such as secure boot, code signing, operating-system hardening, encryption, network segmentation, authentication, role-based access controls and patch management.
Once controls have been implemented, residual cybersecurity risks should be evaluated against predefined acceptability criteria. Where residual risk remains unacceptable after practicable controls have been applied, a documented benefit-risk analysis should be undertaken.
Importantly, the process does not finish when the device is released. Threat intelligence, newly discovered vulnerabilities, field experience and cybersecurity incidents should feed back into the risk management file and may trigger further risk analysis and control activities.
Cybersecurity assessment and testing
Security controls also need to be verified.
GL-10-R1 recommends maintaining traceability between cybersecurity requirements and verification results so that manufacturers can demonstrate that identified security controls have actually been implemented and tested.
HSA discusses several assessment approaches, including vulnerability testing, penetration testing, security audits, source-code review and security configuration review. The guide does not prescribe one standard testing package for every device. Instead, manufacturers should select the appropriate combination based on the device, its intended use and associated cybersecurity risk. A higher-risk connected device may reasonably require more extensive or frequent testing than a device with a relatively limited attack surface.
The guide also refers to recognised standards and practices including IEC 81001-5-1, UL 2900-1, UL 2900-2-1, ISO/IEC 27001 and ISO/IEC 27002.
For manufacturers, the practical question should therefore not simply be, “Have we completed a penetration test?” It should be whether the overall security verification strategy adequately addresses the product’s architecture, attack surface and risk profile.
SBOM as a practical cybersecurity tool
The Software Bill of Materials (SBOM) is another major element of the guide.
An SBOM provides visibility into the software components incorporated into a medical device, including open-source components, third-party software, libraries and dependencies. This visibility becomes particularly important when a new vulnerability is disclosed in a widely used software component.
If the SBOM is accurate and current, the manufacturer can more quickly determine which device models and software versions may be affected, assess the associated risk and decide whether a patch, mitigation or customer communication is necessary.
HSA identifies information such as the SBOM author, timestamp, software-component supplier, component name, version, unique identifier and dependency relationships as key elements.
The guide also gives practical examples of how an SBOM can support supply-chain security, vulnerability monitoring, incident response and remediation. For healthcare providers, access to SBOM information can help identify affected devices when a vulnerability emerges across their network.
The important point for manufacturers is therefore not simply to produce an SBOM once. It needs to remain useful enough to support vulnerability assessment and incident response throughout the supported life of the device.
User information is part of cybersecurity
GL-10-R1 also gives considerable attention to information supplied to users.
A connected device can have strong technical controls and still be exposed to unnecessary cybersecurity risks if it is incorrectly configured, connected to an unsuitable network or not updated properly.
The user manual or Instructions for Use should therefore provide appropriate information on secure setup and operation, available security features, known cybersecurity considerations, software and firmware updates, troubleshooting and how to contact the manufacturer when a security issue is identified.
Customer security documentation may go further by addressing infrastructure requirements, secure configurations, endpoint protection, firewall rules, whitelisting, logging, secure network deployment, incident response, configuration recovery, software-update procedures, End of Support information and SBOM.
HSA also makes an important practical point: detailed cybersecurity documentation may itself reveal information about potential weaknesses. Sensitive security information should therefore be distributed through secure and trusted communication channels.
Post-market cybersecurity cannot be an afterthought
The guide identifies post-market vigilance, vulnerability disclosure, patching and updates, recovery, and information sharing as the five main considerations for a post-market cybersecurity plan.
During the Support stage, manufacturers should provide active cybersecurity support, including patches and updates. Product registrants, importers and local authorised representatives should facilitate timely access to this information and support for users in Singapore.
Product security and life-cycle documentation may need to address operating-system versions, known software issues, software components, required ports and services, firewall rules, maintenance schedules, security logging, backup and restoration, vulnerability notification and privilege management.
Manufacturers should also monitor the support status of third-party components. A medical device may still be actively supported by its manufacturer while an operating system, library or other software component within the device approaches its own EOL or EOS. This is another reason why SBOM and life-cycle management need to work together.
AI-enabled medical devices receive specific attention
GL-10-R1 includes a separate section on additional considerations for medical devices incorporating Artificial Intelligence.
HSA recognises that AI can support diagnosis, disease-risk prediction and workflow improvements, but it can also introduce additional cybersecurity concerns. For Generative AI in particular, the guide identifies threats such as prompt injection, hallucinations, misinformation and accidental data leakage.
Security should therefore be considered across the AI development cycle, including model design, the AI supply chain, deployment, operation and updates. Protection of patient data, monitoring the accuracy of AI outputs and transparency around AI-generated content are also highlighted.
This section should not be interpreted as establishing a separate HSA AI registration route. Rather, it highlights additional threat scenarios that manufacturers may need to consider within their overall cybersecurity approach.
Limited Support and the transition towards EOS
The transition from active Support to Limited Support is one of the more useful practical aspects of GL-10-R1.
HSA describes this as a gradual shift in operational responsibility as the device approaches EOL and EOS. Importantly, the guide recommends that transition planning begin approximately two to three years before EOS, although the appropriate timing may vary depending on the complexity and criticality of the device.
This is not presented as a statutory notification period. It is a practical recommendation intended to give healthcare providers enough time to assess the device, plan budgets and consider retirement or replacement.
During Limited Support, manufacturers should maintain close communication with healthcare providers and make information available on remaining support, potential risks, available updates, unsupported components and possible compensating controls. Healthcare providers, in turn, need to consider whether continued use remains appropriate based on cybersecurity risk, usability, resources required to maintain the device and potential impact on patients.
This is particularly relevant for medical devices with long clinical service lives. A device may remain mechanically or clinically functional even after some of its software components are no longer supported.
What happens at End of Support?
At EOS, the guide states that the healthcare provider assumes primary operational responsibility for managing cybersecurity risks associated with continued use of the device without active manufacturer support. However, this applies to devices that were previously placed on the Singapore market with an adequate manufacturer-supported cybersecurity life cycle.
The distinction is important because EOS does not automatically remove every responsibility from the manufacturer or Singapore supply chain.
Manufacturers should provide the necessary product-security information, clearly communicate the transition to EOS and continue communicating known cybersecurity-related patient-safety risks and supporting applicable post-market safety and regulatory reporting activities where appropriate.
Where healthcare providers decide to continue using a device beyond EOS, HSA points to measures such as continued risk assessment, inventory and vulnerability management, restricting physical or remote access, firewalls, network segregation or isolation and periodic reassessment of whether continued use remains appropriate.
The guide therefore treats EOS as a managed transition rather than an abrupt point at which cybersecurity responsibility simply disappears.
What should manufacturers take away from GL-10-R1?
For manufacturers supplying connected medical devices in Singapore, GL-10-R1 can be used as a practical health check of the existing cybersecurity programme.
A useful review would consider whether cybersecurity is genuinely incorporated into product architecture and risk management; whether security requirements are traceable to verification; whether vulnerability and penetration testing are appropriate for the device; whether the SBOM is current enough to support incident response; whether customer security information is adequate; and whether post-market vulnerability, patching and communication processes work in practice.
Manufacturers should also know where each product sits in its life cycle. For products approaching EOL or EOS, cybersecurity transition planning should begin early enough for product registrants, importers, local authorised representatives and healthcare providers to understand the remaining support, risks and available options.
For AI-enabled devices, the review should also consider whether AI-specific threats have been incorporated into the wider cybersecurity risk-management process rather than managed as an isolated AI exercise.
Conclusion
HSA’s GL-10-R1 Best Practices Guide for Medical Device Cybersecurity does not introduce a new pre-market registration requirement. What it does provide is a useful and fairly detailed picture of good cybersecurity practice across the life of a connected medical device.
The guide reinforces several themes that manufacturers should increasingly expect to manage together: Secure by Design, cybersecurity risk management, security verification and testing, SBOM, vulnerability monitoring, patching, customer security information, post-market surveillance, AI-related cybersecurity risks, and EOL/EOS planning.
Most importantly, cybersecurity does not end when a device is released. HSA’s conclusion reinforces the need for continuous monitoring, timely updates, proactive risk management and collaboration between manufacturers, healthcare providers and other stakeholders throughout the device life cycle.
For manufacturers developing or supplying connected medical devices in Singapore, GL-10-R1 provides a useful opportunity to review whether existing cybersecurity processes are capable of supporting the device not only at market entry, but throughout its complete operating life.
MedOrdyn Solutions provides regulatory support to medical device manufacturers navigating evolving global regulatory and compliance requirements.
For regulatory support, contact info@medordyn.com.
Follow MedOrdyn Solutions for regular updates on medical device regulations, standards, cybersecurity and global market access.
