HSA Publishes GL-10 Best Practices for Medical Device Cybersecurity

Singapore’s Health Sciences Authority (HSA) has published GL-10-R1, Best Practices Guide for Medical Device Cybersecurity. The revision history records it as a first release effective 17 August 2026. HSA’s medical-device guidance list labels the file “GL-10-R1 … (2026 Aug) PUB.” A 14 August 2026 consultation-response notice says HSA incorporated public comments and published the finalised guide on that list.

GL-10’s legal status is the first fact that matters. Section 2 states: “This document does not constitute regulatory guidance and does not establish regulatory requirements or expectations for pre-market submission or registration.” It is practical advice for managing cybersecurity across the total product life cycle (TPLC) of connected devices. It is not a new cybersecurity statute, not a registration checklist, and not a replacement for HSA’s separate software regulatory guidelines.

Who and what is in scope

The guide applies to all connected general medical devices and IVDs placed on the Singapore market, whether professional use only (PUO) or non-PUO. It covers devices newly supplied in Singapore and devices already installed and in use.

The intended readers are manufacturers, product registrants, importers, local authorised representatives, and healthcare providers. Manufacturer-related recommendations begin at the Development stage. Healthcare-provider responsibilities described in the guide begin at the Support stage and continue through Limited Support and End of Support.

GL-10 does not create a new connected-device class or change SMDR registration categories. This article covers only what GL-10 itself says.

The TPLC model in GL-10

GL-10 organises cybersecurity work into four stages: Development, Support, Limited Support, and End of Support. Limited Support sits between End of Life (EOL) and End of Support (EOS). In HSA’s definitions, EOL means the manufacturer no longer sells the product beyond its defined useful life and support may be reduced; EOS means the manufacturer has terminated service support activities.

The operational transfer at EOS is carefully qualified. For devices that were previously placed on the Singapore market with an adequate manufacturer-supported cybersecurity life cycle, operational responsibility for managing the risks of continued use after EOS shifts to the healthcare provider. That transfer:

• does not remove continuing manufacturer, product-registrant, importer, or local-authorised-representative duties, including communication of known safety risks, support for appropriate safety actions, and applicable regulatory reporting; and
• should not be read as a basis for shifting manufacturer life-cycle responsibilities to healthcare providers before EOS.

GL-10 recommends beginning the Support-to-Limited-Support transition about two to three years before EOS, with the caveat that timing may vary with device complexity and criticality. That timeline is a recommendation in the guide, not a statutory notice period.

What GL-10 recommends during development

During Development, HSA’s recommendations cluster around security design, risk management, testing, user information, a post-market plan, and a Software Bill of Materials (SBOM).

Secure by Design and Secure by Default. Secure by Design means building security into the architecture from the outset. Secure by Default means the device is configured to be as secure as possible without requiring the user to change settings.

Risk management. The guide treats cybersecurity as in-scope for life-cycle risk management, from concept through EOL. Where the probability of an intentional cyberattack is hard to estimate, it recommends assessing exploitability of known vulnerabilities, including Common Vulnerability Scoring System (CVSS) approaches. Risk-control preference follows ISO 14971: inherent safety by design, then protective measures, then information for safety.

User information. The development-stage user-information recommendations include cybersecurity End of Support information and an SBOM.

Post-market plan. The recommended plan covers post-market vigilance, vulnerability disclosure, patching and updates, recovery, and information sharing.

SBOM. GL-10 describes an SBOM as a detailed list of software components, including open-source tools, third-party software, and libraries. The key elements it lists are author name, timestamp, software-component vendor, name, version, unique identifier, and dependency relationship. Two illustrative use cases show a manufacturer using an SBOM for supply-chain and patch management, and a healthcare provider using vendor SBOMs during incident response. They are examples, not mandatory dossier templates.

AI-enabled devices. Section 6.7 is an additional consideration, not a new AI registration route. It says Generative AI introduces threats such as prompt injection, hallucinations, misinformation, and accidental data leakage, which should be addressed alongside traditional cybersecurity threats. The recommended focus areas are model design, AI supply-chain protection, safe deployment, and security during operation and updates.

Because GL-10 is not regulatory guidance, none of the above becomes an HSA pre-market submission expectation merely by appearing in this document. Manufacturers still have to meet whatever cybersecurity, software, and post-market duties apply under other HSA instruments. GL-10 is a map of practices HSA considers useful across that life cycle.

What changes at Support, Limited Support, and EOS

During Support, manufacturers should provide full cybersecurity support, including patches and updates. Product registrants, importers, and local authorised representatives should help get that support and information to Singapore users. Healthcare providers are not expected to carry the full cybersecurity burden while manufacturer support remains available.

At Limited Support, manufacturer support decreases. The guide recommends that manufacturers tell users about the reduction, the remaining timeline to EOS, unsupported parts, available software updates, and compensating controls. Healthcare providers are asked to reassess continued use against security risk, remaining usability, support resources, and patient impact.

At EOS, the healthcare provider assumes primary operational responsibility for cybersecurity risks of continued use without active manufacturer support, again only for devices that had an adequate manufacturer-supported cybersecurity life cycle. Manufacturers should still hand over product-security information, communicate the EOS transition, and continue known cybersecurity-related patient-safety communication and applicable reporting.

GL-10 also says healthcare providers should comply with the Ministry of Health Cyber & Data Security Guidelines for Healthcare Providers under the Health Information Act 2026. That is a healthcare-provider duty GL-10 points to, not a new medical-device registration requirement issued in GL-10 itself.

How this sits next to HSA’s software guidance

GL-10 is a new first-release document. It does not revise GL-04-R4, HSA’s regulatory guidelines for software medical devices, including machine learning-enabled devices. Keep the two documents in different folders: GL-04 speaks to software registration and change control; GL-10 speaks to connected-device cybersecurity practice and does not set submission expectations.

What manufacturers should do with a non-binding guide

Pure Global’s recommended use of GL-10 is to test whether the company’s connected Singapore portfolio can actually be operated on HSA’s TPLC map—not to treat the PDF as a new registration file:

1. List every connected general medical device and IVD on the Singapore market, including installed base, and assign current TPLC stage (Development, Support, Limited Support, or EOS).
2. Write or confirm EOL and EOS dates and the two-to-three-year communication plan GL-10 recommends before EOS. Product registrants, importers, and local authorised representatives should be able to deliver that information in Singapore.
3. Check the development pack against GL-10’s headings: Secure by Design/Default, life-cycle risk management, testing, user information (including EOS information and SBOM), and the five-part post-market plan.
4. Confirm the SBOM can support incident response, using at least the seven key elements HSA lists. GL-10 does not prescribe a file format.
5. Keep AI threat analysis inside cybersecurity risk management where Generative AI is in the device, without treating section 6.7 as a standalone HSA AI submission rule.
6. Do not transfer manufacturer duties early. The EOS operational shift is qualified and does not cancel known-risk communication or applicable reporting.

Read the complete GL-10-R1 guide and HSA’s consultation-response notice. For Singapore market context, see the HSA glossary entry, Singapore market overview, and HSA medical device regulations. Pure Global’s medical device cybersecurity service covers TPLC security work that sits beside, and does not replace, HSA registration.