Introduction: A Best Practices Guide With No Pass Mark
The hospital’s procurement team has one more request before it signs. It wants the product life cycle documentation described in section 7.1.1 of HSA’s new GL-10 guide, plus an SBOM for the device. Your sales lead forwards the email with a single line: “Do we have this document?”
Since August 2026, that request has a source document. GL-10 is HSA’s Best Practices Guide for Medical Device Cybersecurity, and it sets out what manufacturers and healthcare providers should do across a device’s life, from design to the day support ends. It doesn’t set a pass mark. There’s no required test, no fixed frequency and no approval step. That leaves a lot open, and the gaps tend to become clear at exactly this kind of moment.
Penetration testing sits inside that open space. GL-10 section 6.3 names five ways to assess a device, and penetration testing is one of them. The other four are vulnerability testing, security audits, code review and configuration review. A well-scoped test can produce evidence for most of the guide’s sections, as long as you know which section each result answers.
This article maps HSA GL 10 medical device cybersecurity practice to concrete test activities, clause by clause. It covers the four life cycle stages, the five assessment methods, scoping for Singapore hospital networks, two tested code examples, where GL-10 stops and mandatory rules begin, and a retesting checklist that runs through to end of support.
What Is HSA GL-10? Singapore’s Medical Device Cybersecurity Best Practices Explained
HSA released a draft for public consultation from 10 March to 12 May 2025, and the final guide, GL-10 Revision 1, followed in August 2026. Allen & Gledhill dates the publication to 14 August; the document’s own revision history says 17 August.
HSA published a draft for public consultation between 10 March and 12 May 2025 and the final guide (GL-10 Revision 1) in August 2026. Allen & Gledhill dates the document as published on 14 August, although the revision history within it is dated 17 August.
The guide covers connected general medical devices and IVDs, whether newly supplied or already in use in Singapore. It’s written for manufacturers, product registrants, importers, local authorised representatives and healthcare providers, so a hospital’s IT team is as much its audience as a manufacturer’s engineers.
Be clear on its status. Section 2 says the guide “does not constitute regulatory guidance” and sets no requirements for pre-market submission or registration. Those requirements live elsewhere, mainly in GN-17 and HSA’s premarket submission checklist (section 8). GL-10 lists HSA’s software guidelines, GL-04, among its references, but it doesn’t mention GN-15 or GN-17 at all.
Three principles run through the document:
- Shared responsibility. Manufacturers retain design and life cycle responsibilities, and providers have operational responsibilities starting with support.
- Transparency. Parties exchange information, report problems and coordinate vulnerability disclosure, and manufacturers provide advance notice of the end of support.
- Secure by design. Security is considered at every step of development, not added at the end.
HSA Total Product Lifecycle Cybersecurity: The Four GL-10 Stages
GL-10 frames HSA total product lifecycle cybersecurity as four stages. Two definitions matter. End of life (EOL) is when the manufacturer stops selling the product, and end of support (EOS) is when every form of service support stops.
| Stage | What GL-10 expects | Testing evidence that fits |
|---|---|---|
| Development (pre-market) | Secure by design and default, risk management, security testing, user documentation, SBOM, post-market plan | Full assessment of the release build, findings fixed and retested |
| Support | Full manufacturer support, including patches, plus life cycle documentation for users | Retests after significant updates, component monitoring against the SBOM |
| Limited support (between EOL and EOS) | Reduced support announced, timeline to EOS, unsupported parts flagged, compensating controls recommended | Tests showing the recommended compensating controls actually work |
| End of support | Provider takes primary operational responsibility for continued use | Provider-side checks of isolation, firewall rules and removed remote access |
The handover is meant to be gradual. GL-10 says the transition should begin about two to three years before EOS, and that handing over operational responsibility doesn’t remove the manufacturer’s or registrant’s duties, such as telling users about known safety risks and meeting reporting obligations.
The HSA GL 10 Penetration Testing Mapping: Clause by Clause
The table below is the essence of an HSA GL 10 penetration testing mapping. Read each row from left to right; it specifies the recommendation, the test activity, and the evidence recorded after the test.
| GL-10 section | What it recommends | Test activity | Evidence produced |
|---|---|---|---|
| 6.1 | Secure by design and secure by default. | Review a factory-fresh unit as shipped: default accounts, open services, debug features | Out-of-the-box hardening report |
| 6.2 | Risk management that assumes known, exploitable vulnerabilities could be targeted; example controls include authentication, encryption, code signing, secure boot, segmentation and patch management | Threat model, then test each claimed control. | Pass or fail result per control, linked to the risk file |
| 6.3 a to e | Vulnerability testing, penetration testing, security audits, code review, configuration review | Vulnerability assessment and penetration test, with code and configuration review where risk warrants | Reports with severity, reproduction steps and retest results |
| 6.4 | Customer security documentation, covering infrastructure needs, secure configuration, logging, recovery, update steps, EOS information and the SBOM | Check every documented port, rule and setting against the real device | Documentation accuracy findings |
| 6.5 | Post-market plan: vigilance, disclosure, patching, recovery, information sharing | Install and roll back a patch, restore from backup, send a test report through the disclosure channel | Post-market readiness evidence |
| 6.6 | SBOM with supplier, component, version, unique identifier and dependencies | Match components to public advisories, then confirm reachability by testing | Triaged component vulnerability list |
| 6.7 | AI-enabled devices: prompt injection, false outputs, misinformation, data leakage | Injection and leakage testing of AI features | AI findings and known limitations |
| 7.1 to 7.3 | Five vulnerability management principles; compensating controls at EOS | Retest after updates; validate segmentation and isolation | Dated retest reports, compensating control results |
A few rows need care.Section 6.1 describes the two ideas, but that section does not list any features; section 6.2 presents the example controls, and when you test them, you cite 6.2. Section 6.1 instructs testers to assume that attackers could target any known, exploitable vulnerability, which makes testing essential. When a scanner identifies a vulnerable component, testers must determine whether attackers can actually exploit that weakness on the device. This helps them assess the severity of the potential harm.
The row that most teams overlook is section 6.4. You can only list them in the documentation that administrators are supposed to use to configure your firewalls, so if they forget to mention one or omit one that you still use, it’s a real find. There is no detail in 6.5, but GL-10 has detail about patching, about recovery and disclosure, and they are each exercisable and not necessarily describable.
HSA Medical Device Security Testing Guidelines: GL-10 Section 6.3 in Depth
Section 6.3 is the nearest thing GL-10 offers to HSA medical device security testing guidelines, and it says plainly that its list is “not exhaustive” and that no single approach suits every situation.
| Method | What GL-10 describes | What it finds well | What it misses on its own |
|---|---|---|---|
| a) Vulnerability testing | Scanning, often automated, for known weaknesses | Outdated components, missing patches, exposed services | Whether a finding is reachable or exploitable on this device |
| b) Penetration testing | Simulating real-world attacks on systems, networks or applications to find and exploit weaknesses and gauge impact | Chained weaknesses, authorisation flaws, real clinical impact | Low-level code defects it never touches. |
| c) Security audits | Reviewing policies, procedures and technical controls against standards | Process gaps, missing controls | Whether the controls work in practice |
| d) Security code review | Manual or automated review of source code | Injection flaws, authentication weaknesses | Configuration and deployment mistakes |
| e) Security configuration review | Checking settings against best practices | Weak defaults, unnecessary services | Flaws in custom code |
For audits, GL-10 cites TR 67:2018, UL 2900-1 and UL 2900-2-1, IEC 81001-5-1 and ISO/IEC 27001 and 27002.
On depth, GL-10 says only that devices with higher risks “may need more thorough and frequent testing.” It doesn’t set a test frequency, call for independent testers or mention fuzz testing, so don’t claim it does. A sensible reading is to scale effort with both clinical risk (HSA’s Class C and D devices) and exposure. An infusion pump on the hospital network deserves more than a standalone thermometer.
Medical Device Vulnerability Assessment Singapore: Scoping a GL-10 Aligned Test
A medical device vulnerability assessment Singapore hospitals will trust covers the whole system, not just the box on the bedside table. Our general HSA penetration testing guide walks through the method; here’s what GL-10 adds to the scope.
- Hardware and firmware. Debug ports, readable firmware, secure boot and code signing (section 6.2 controls).
- Wireless and network. Pairing, configuring the Wi-Fi, exposed services and encryption during the transfer.
- Apps, portals and cloud. Mobile app storage, clinician portal authorisation and cloud API access control between hospitals.
- Hospital network assumptions. Test twice: once from the segmented clinical network your documentation recommends and once from a flat network. The second run shows what happens when the hospital can’t segment, which is the honest basis for the compensating controls you’ll later recommend.
From SBOM to Triage List
Section 6.6 requires an SBOM, and section 7.1.2 requires that users prioritise and triage. The script shown below makes the connection between the two. It reads a CycloneDX SBOM, checks each component for the elements in section 6.6 lists, matches components with an advisory file, indicates if an operating system is at the end of support, and sorts the output. This is a condensed version; the complete script is included with this article.
We ran it on 23 October 2026 against a sample SBOM for a fictional bedside gateway and an advisory file holding four real CVE entries.
There are two things that stand out from the above. The in-house DICOM library doesn’t have a supplier, identifier or dependency graph; thus, nothing can ever be matched against it. And there is still a need to test the top CVE rows. The script starts with the most important of the two CVEs, and CVE-2023-38545 is only reachable via a SOCKS5 proxy, while CVE-2022-37434 is only if inflateGetHeader is called by the code. This advisory file is used as a substitute. In reality, you would be feeding it from a live source like NVD or OSV.
Security Logging That Hospitals Can Use
Security logging is mentioned in both Sections 6.4 and 7.1.1. The first API below is silent in places where it doesn’t need to be and chatty in places where it does need to be.
The fixed version records structured events, exchanges tokens and patient IDs for keyed pseudonyms that are not reversible by the hospital, and triggers an alert after 5 failed attempts in 5 minutes.
The test sent six wrong passwords, one correct login and two record requests, one of them without a token.
The vulnerable API did not log any of the guessing and gave a working token and patient identifier to anyone who could read its logs. The fixed one presented the hospital with six events and an alert to act on. This is a single-process synthetic data test. Only failures per account are counted; if you’re going to spray a password across many accounts, then you need a per-source rule as well.
Mapping GL-10 Post-Market Stages to a Retesting Programme
Once a device ships, testing becomes a schedule rather than a project.
| Stage | Retest trigger | What to test |
|---|---|---|
| Support | Significant updates, new interfaces, new advisories against SBOM components | The five section 7.1.2 principles: updates applied, assets listed with EOL and EOS dates, critical updates prioritised, deferrals justified with a risk assessment, regular review for new threats |
| Limited support | Announcement of reduced support | Each compensating control you recommend, tested on a representative installation |
| End of support | Provider decision to keep the device in use | Isolation, firewall rules, removed remote access and limited physical access |
The retest is typically the responsibility of the hospital at the end of support, in view of the primary operational responsibility defined in section 7.3. A locked-down installation requires administrators to keep certain ports, accounts, and services open. Manufacturers can help administrators prepare for this process by providing these details well before the end of support (EOS).
The procurement team will request the section 7.1.1 life cycle documentation, including details of operating system, version, known issues, required ports/services, firewall rules for isolation, expected dates of service changes, anti-malware, logging, backup and restore, vulnerability notification methods, and administrative accounts and compensating controls. Testing each piece before delivery is cheaper than fixing it after a hospital has built its network around it.
Singapore Medical Device VAPT Compliance: Where GL-10 Meets Mandatory Requirements
Singapore medical device VAPT compliance depends on which rule you’re answering, because GL-10 itself binds no one.
- Registration. GN-17 Revision 5 section 4.3 and item 8.7 of the premarket submission checklist ask connected devices for a cybersecurity risk analysis, controls, security test reports and/or other evidence, a traceability matrix, operating system information and a post-market plan.
- Security patches. Under GN-21 Revision 7, software changes made solely to address a cybersecurity vulnerability are a Notification (Change Type 2Aii), unless linked to a reportable adverse event or an ongoing field safety corrective action.
- CLS(MD). The voluntary label requires independent penetration testing at Level 3 and a fuller security evaluation at Level 4, and an approved testing laboratory is mandatory at every level. CSA’s FAQ estimates about a month of lab time for Level 3 penetration testing and lists fees, excluding GST, of S$85, S$142, S$4,493 and S$10,421 for Levels 1 to 4. Labels last as long as the device gets security updates, up to three years.
- Data protection. Under the PDPA, organisations must notify the PDPC within three calendar days of assessing a breach as notifiable. GL-10 section 7.1.2 points providers to MOH’s cyber and data security guidelines under the Health Information Act 2026, which Baker McKenzie describes as rolling out through early 2027.
A GL-10 aligned test can feed all four. The same report answers checklist item 8.7, supports a CLS(MD) declaration and gives a hospital something concrete to file.
AI-Enabled Medical Devices Under GL-10 Section 6.7
In section 6.7, the authors list prompt injection, false outputs (hallucinations), misinformation and accidental data leakage as risks associated with generative AI and state that these risks may result in incorrect diagnoses or treatment errors. It categorises the response into four sections: model design, AI supply chain security, deployment security, and operational security and updatability.
For these tests, testers should attempt to influence the model’s instructions through any input it receives, whether from a document or an image. They should examine what information users can extract about other patients and repeat the tests whenever developers update the models. In addition, Section 6.7 asks developers to identify known limitations, so they should document any issues they cannot fix in the user documentation.
Turning Test Results Into GL-10 Evidence
Evidence is only considered a finding if it can be followed by another. For each one, the name of the GL-10 section it answers, the risk it relates to, the control tested, the result and the retest date. This chain of risk, control and result is the same as the one that HSA’s checklist requests as a traceability matrix, so one document can be used for both.
Consider the customer security documentation and the SBOM as test deliverables as well. The section 6.4 documentation check returns accuracy findings and the SBOM triage returns a component list with status. Both need to be correct, as they both go to hospitals.
Anything left open, you address in accordance with the ISO 14971 sequence: inherent safety by design, then protections, then information for safety. When you have considered and implemented all practicable risk reduction measures, GL14971 requests that you provide an analysis of the benefits and risks with documented justification. If you find a test that reveals what an attacker CAN and CAN’T do, then that justification is much stronger to defend.
GL-10 Penetration Testing Checklist for Manufacturers and Healthcare Providers
Development stage
- Factory-fresh unit reviewed for default accounts, open services and debug features
- We tested each 6.2 control section and linked the results to the risk file.
- SBOM complete against section 6.6 and triaged
- Customer documentation checked against the real device
Support stage
- Retest triggers defined and recorded
- Patch install, rollback and backup restore exercised
- Disclosure channel tested end-to-end
Limited support
- EOS timeline and unsupported parts communicated
- Every recommended compensating control tested
End of support
- Device isolated, remote access removed, firewall rules verified
- Third-party components tracked in the provider’s vulnerability database
- Alternatives reviewed on a set cycle
How Qualysec Supports GL-10 Aligned Medical Device Testing
Qualysec is a specialist pen test outfit, and GL-10 fits the model of how pen testers test: the device, companion app and cloud back end all together, because hospitals use them all together! We correlate each finding to the GL-10 section addressed and the HSA registration item addressed; thus, the engineering team gets one report, and the regulatory file and the procurement review process get one report. Continuous retesting is provided through support, limited support and end of support, including checks of the compensating controls you recommend.
From January through April 2025, we worked with Topia Life Sciences, a medical device R&D firm, as detailed in their Clutch review. We have tested its Android and iOS apps, its web dashboard hosted on DigitalOcean, and its embedded devices. The aim was to achieve FDA compliance, testing and remediation based on IEC 62304, with zero critical or high vulnerabilities found after remediation and retesting in the final report. This is not an engagement of a GL-10 device but rather an engagement of the same device, application, and cloud space as described in sections 6.2 through 6.6 of GL-10.
Conclusion and Next Steps
While HSA GL 10 medical device cybersecurity is supposed to be a guidance document, it is more appropriate as a test plan. Each section (6.1-7.3) is a description of something that is testable on a real device, and if you test it, you create the evidence that the hospital will accept.
Start in development, where fixes are cheap, and retest at each stage until the device is retired. The procurement email asking for section 7.1.1 documentation and an SBOM is coming either way; it’s far easier to answer with test results already in the file.
Primary call. GL-10 lists penetration testing as a best practice, and Singapore hospitals increasingly ask for the evidence at procurement. Talk to our team about a test mapped to GL-10 sections 6 and 7, so your device, app and cloud back end are covered from development to end of support.
Secondary call. Do you want to see how we write up findings first? Review a sample penetration testing report, with severity, reproduction steps and fixes laid out the way engineers and auditors read them.
Frequently Asked Questions
1. Is HSA GL-10 mandatory for medical device manufacturers in Singapore?
No. Section 2 says it doesn’t constitute regulatory guidance or set requirements for pre-market submission or registration. The binding cybersecurity requirements for registration sit in GN-17 section 4.3 and checklist item 8.7.
2. Does GL-10 require penetration testing of connected medical devices?
No. It lists penetration testing as one of five assessment methods in section 6.3, alongside vulnerability testing, security audits, code review and configuration review, and says the list isn’t exhaustive. It becomes a requirement only at CLS(MD) Level 3, with a broader security evaluation at Level 4, and CLS(MD) itself is voluntary.
3. Which GL-10 sections can a penetration test provide evidence for?
The majority of them are directly 6.2 (testing each control), 6.3 (the method itself), 6.4 (checking documentation against the device), 6.5 (patching and recovery paths), 6.6 (confirming SBOM findings), 6.7 (AI features) and 7.1 to 7.3 (retesting and compensating controls).
4. How does GL-10 relate to HSA registration requirements and the CLS(MD) label?
The best practice is GL-10, while the evidence of registration is required, and the CLS(MD) is not. They overlap in many ways, and one well-documented test can do all three.
5. What should Singapore healthcare providers test once a device reaches the end of support?
The compensating controls mentioned by the GL-10 part 7.3 are limited physical access, removed remote access, firewall rules and network segregation or isolation. Providers need to maintain a vulnerability database for third-party components and periodically review options.
6. How often should a connected medical device be retested under GL-10’s total product life cycle approach?
There is no interval for GL-10. When major changes are made, new interfaces are introduced, or important advisories come out against your components, retest; any additional cycle should be proportionate to the risk.
