Summarize this blog post with
The HSA query is concise. The evaluator wants a traceability matrix from your security risks to controls and tests. They want to know which operating systems your app supports. Your team provided a well-written architecture document and a scan summary. It did not include proof that the controls work, or a clear statement of which phone and desktop operating systems the software runs on.
That’s a common place for SaMD registrations to stall, and the reason is simple. Software has no box, no tamper seal and no fixed network. It runs on phones, browsers and shared clinical workstations the manufacturer has no control over, and it talks to cloud services and hospital systems that are changing all the time. The software guidelines established by HSA, GL-04, mandate that SaMD developers illustrate, instead of just explaining, their implementation and validation of security features.
What HSA leaves open is how you test. GL-04 is about penetration testing, code analysis, vulnerability scanning and malware testing, but it does not define a tool, a frequency or a tester. These are your options, and they will determine whether your evidence satisfies the evaluator on the first attempt.
This SaMD Cybersecurity Testing Singapore guide covers how HSA regulates software, the 5 cybersecurity items GL-04 R4 asks for at registration, what section 8 adds, how to build and scope a test plan, what testers target, SBOMs, AI-enabled software and what continues after registration. Two example tests are a patient API vulnerability and a release pipeline blocking known vulnerable components.
How HSA Regulates Software as a Medical Device
GL-04 Revision 4 dated December 31, 2025, covers software embedded in medical devices and software that runs on general-purpose computing platforms, such as standalone medical mobile apps, which IMDRF refers to as SaMD.
Classification follows GL-07 Revision 2, effective 21 July 2025. It weighs the importance of the information that the software provides (treat or diagnose, drive management or inform management) against the severity of the patient’s condition. It has a table for non-IVD SaMD from Class A to Class C. IVD SaMD is classed under GN-14. Revision 2 also clarified that clinical decision support software, which merely implements existing clinical guidelines and does not provide any new recommendations beyond those guidelines, is not considered a medical device.
Section 4 of GL-04 sets out the dealer’s licences, which some software teams find surprising.
The cybersecurity rules sit in four places. GL-04 R4 sets the software-specific detail. GN-17 and item 8.7 of HSA’s premarket submission checklist set the general dossier items, which our companion article on HSA cybersecurity declarations covers. GL-10 adds best practices that aren’t binding. Read together, these are the HSA SaMD cybersecurity guidelines that shape a submission, with GL-04 as the main reference for software.
HSA SaMD Cybersecurity Guidelines: The Five Items GL-04 R4 Asks for Registration
Section 3.7 applies to “software running on a general-purpose computing platform, including SaMD and connected medical devices. ” Manufacturers must put in place the minimum necessary hardware, network and IT security measures, including protection against unauthorised access, and submit five items.
Item iv is where the opening query came from, and item v is the one most often answered vaguely. “Android and iOS” isn’t an answer. Android 12 and later, iOS 16 and later, and Windows 11 23H2 are the required operating systems for the reading station.
GL-04 also encourages manufacturers to reference IEC 81001-5-1, the security life cycle standard for health software. It’s a sensible backbone for the whole programme.
HSA GL 04 Software Medical Device Security: Inside Section 8
Section 8 explains the thinking behind the five items, and it’s the closest thing to a test brief for HSA GL 04 software medical device security.
- 8.2.1 Secure device design. Build security in from the start, so the software prevents unauthorised use, detects and responds to attacks, and recovers where it can.
- 8.2.2 Cyber risk management. Apply ISO 14971 to cybersecurity, in parallel with safety risk management. GL-04 suggests threat modelling tools and states that manufacturers can use CVSS to score vulnerabilities. It also requires monitoring all software, including third-party software, for new vulnerabilities.
- 8.2.3 Verification and validation. Testing should show the code is free from significant known vulnerabilities, and “security testing can include” penetration testing, code analysis, vulnerability scanning and malware tests. That wording matters. Penetration testing is one route to the evidence, not a mandatory step.
- 8.2.4 Post-market management plan. Vigilance is a formal process for receiving reports from vulnerability finders, a patching plan for regular and reactive updates, recovery after incidents, and information sharing through ISAOs and ISACs. No patch timelines are set.
- 8.2.5 Operating system end of support. This is the strictest line in the document. “Software medical devices operating on unsupported OS with inherent cybersecurity risks that cannot be adequately mitigated” are unacceptable and will not be permitted for supply in Singapore. Manufacturers should tell users about end-of-support dates early and shouldn’t recommend an unsupported OS in labelling unless mitigations are adequate. For software already deployed, interim measures may include network isolation or update mechanisms to migrate users to a supported OS, with compatibility assessment and V&V testing on the new OS.
- 8.3 Patient confidentiality. Comply with local data protection law, including the PDPA. If a breach is notifiable, the PDPC must be told within three calendar days of that assessment.
Building a SaMD Security Test Plan for HSA
Start with scope, because SaMD rarely lives in one place. A typical system has a client app or web front end, APIs, cloud hosting, an identity provider and integrations with hospital systems or devices. Each should map to at least one Section 3.7 item.
| Test activity |
Section 3.7 item it supports |
| Threat modelling workshop and data flow review |
ii
|
| Penetration test of app, APIs, identity and cloud |
i, iv
|
| Vulnerability scanning and dependency checks |
ii, iii, iv
|
| Code analysis and malware scan of release builds |
iv
|
| OS compatibility and minimum version checks |
v
|
| Patch and disclosure process walkthrough |
iii
|
General-purpose platforms require focus. Test the oldest OS version you support, not just the newest phone in the office. Evaluate the software prevalent in web browsers to determine if it is web-based. If clinicians share a workstation, check what the next user can see: cached records, saved sessions, and files left in a downloads folder.
Version control matters too. Under section 3.3, the registered version should appear in the software’s user interface, and section 3.4 says that if your validation reports cover a different version from the one you’re registering, you must compare the two and explain why the reports still apply. Simplest route: test the release candidate you plan to file. If the version moves, keep a short delta analysis and retest anything security-relevant.
Software as a Medical Device Penetration Testing: What Testers Target
Penetration testing for software as a medical device is concerned with where the software alone determines who sees what.
Authentication and roles. Clinicians, patients, carers and administrators have different needs for rights. Testers call the API directly to check login strength, multi-factor choices, session expiry on shared devices, or if a patient account can access clinician functions.
Patient data APIs. Broken object-level authorisation is the flaw we’d put first on any SaMD test plan, and it’s listed first in the OWASP API Security Top 10. The API checks that you’re logged in, then returns whatever record ID you ask for.
The fixed version checks the care relationship on every request and refuses with the same 404 a missing record gets, so IDs can’t be probed.
We ran both on 27 October 2026 and sent real HTTP requests with synthetic patients and tokens.
In the vulnerable build, a patient could read another patient’s EEG report by changing one number, and a clinician could read every record in the system. Authentication worked perfectly in both builds, which is precisely why scanners miss these vulnerabilities. In the risk file, it belongs under item ii as a confidentiality risk with clear patient harm, and the passing retest is item iv evidence.
Mobile, Cloud, and Third-Party Security Testing
Mobile apps. Test against OWASP MASVS: What is stored on the device, and is it encrypted? Does the app validate certificates, or accept an intercepting proxy? How straightforward is the app to reverse engineer in order to expose keys or hidden endpoints?
Cloud and infrastructure. Storage permissions, exposed admin interfaces, secrets in environment variables, logging of patient data, and separation between hospital tenants.
Third-party libraries and services. Section 8.2.2 wants you to monitor it all. You need to know what you ship (section 8 of this guide).
Code analysis and malware testing. GL-04 names both. Static analysis catches injection flaws and hard-coded secrets before release, and a malware scan of the signed installer shows nothing unwanted made it into the build.
Secure Your Business with a Expert-Led Security Assessment
Partner with certified security specialists to identify, prioritize, and remediate real-world risks across your systems.
Book a Security Assessment →
Singapore SaMD Vulnerability Assessment: Scanning, Scoring and Triage
In a Singapore SaMD vulnerability assessment, the assessment often begins with an automated scan of dependencies, containers, cloud configuration and exposed services. Scanning is quick and repeatable, but it only finds known vulnerabilities. Manual testing can uncover logic flaws, such as the one above, that no signature describes. You need both, and section 8.2.3 lists them.
GL-04 uses CVSS for scoring. However, a CVSS score is a description of vulnerability and not a patient outcome. A 9.8 in a library that your software never calls may be less important than a 6.5 that lets a patient see another patient’s results. Score with CVSS and then translate each finding into the harm that could result, using the same severity scale as your ISO 14971 file.
Link the harm rating to the fix timelines and add them to the risk file. GL-04 has no deadlines, so create your own, build them into the post-market plan (item iii) and keep proof you met them.
Software Bill of Materials SaMD Singapore: What GL-04 and GL-10 Each Say
Search for Software Bill of Materials SaMD Singapore guidance, and you’ll find a gap where it should be. GL-04 R4 does not mention SBOMs. What it does require, in section 8.2.2, is the monitoring of all software, including third-party software, for new vulnerabilities, which is very hard to do without one.
The SBOM recommendation is now in HSA’s non-binding best practices guide, GL-10 section 6.6. It contains author name, timestamp, supplier, component name, version, unique identifier and dependency relationship. GL-10 also expects the SBOM in customer security documentation, leading to more Singapore hospitals requesting one at procurement.
The SBOM is only useful if it matches the release. Generate it from the build, every time. This GitHub Actions workflow produces a CycloneDX SBOM on each release tag, keeps it as evidence, and blocks the release if any component has a known vulnerability rated high or critical.
We ran the same commands locally on 27 October 2026 for two releases of a sample patient portal API, using live npm advisory data.
Release 3.2.0 was blocked by five high-severity findings. Release 3.2.1, with updated packages, passed. Two limits to know. npm’s SBOM had a package URL for each component, but none had a supplier field, so you’ll need to add supplier data to meet GL-10’s list. And the gate only knows published advisories. So it supports item iii, monitoring, rather than replacing a penetration test.
AI and Machine Learning SaMD: Extra Security Testing
GL-04 section 9 on machine learning-enabled medical devices covers requirements, continuous learning, post-market monitoring, and modifications. It relies on the general software sections for cybersecurity, so the five section 3.7 items apply as written.
In GL-10 section 6.7 the AI-specific risks such as prompt injection, false outputs, misinformation and accidental data leakage are added. For testers, that means trying to subvert instructions with whatever input the model sees, checking to see if one patient’s data might show up in another’s output and retesting after model updates. Treat the model file and its runtime libraries as first-class citizens: include them in the SBOM, check who can replace the model in production, and ensure a model update will follow the same signed release path as code.
The HSA’s AI in Healthcare Guidelines (AIHGle 2.0) launched in March 2026 are not a separate or additional premarket requirement. HSA said developers should continue to refer to GL-04 for the details.
After Registration: Change Notification, Change Management Programmes and Retesting
GL-04 Figure 2 lists “software changes solely to address a cybersecurity vulnerability” as a Notification change (type 2Aii) for all risk classes. You still submit it, but it’s the lightest route. An operating system change compared with the registered version falls under type 2Aiii instead: Notification for Class B, Technical for Classes C and D.
GN-37 offers SaMD makers a change management programme, where anticipated changes are approved in advance and implemented without a separate notification each time. It mentions cybersecurity as a life cycle duty but says nothing about security patches, so it’s unclear whether they can be pre-specified in a CMP. Ask HSA before planning around it.
Plan OS migrations well before the vendor’s end-of-support date. Windows 10, for example, reached end of support on 14 October 2025 outside paid extended updates, and any SaMD whose reading station still depended on it needed a mitigation or a migration plan under section 8.2.5. Migration testing should include the full V&V set GL-04 asks for, not just a launch check.
Retest when you add an API or integration, change authentication or session handling, move cloud provider or region, migrate OS versions, take a major library upgrade, or learn of a serious vulnerability in something you ship.
SaMD Cybersecurity Testing Checklist for HSA Submissions
Before testing
- Class confirmed under GL-07, licences checked under GL-04 section 4
- Threat model and data flows current
- Release candidate frozen, version visible in the UI
During testing
- App, APIs, identity provider, cloud and integrations in scope
- Object-level authorisation tested for every role
- Oldest supported OS and shared workstations included
- Code analysis and malware scan run on the release build
Before submission
- All five section 3.7 items present, with the traceability matrix complete
- Supported OS versions and end-of-support dates stated
- High-risk findings fixed and retested, or justified in the risk file
After registration
- Cybersecurity-only patches filed as notifications
- SBOM generated and checked on every release
- Retest triggers recorded in the post-market plan
How Qualysec Supports SaMD Cybersecurity Testing for Singapore
Qualysec is a specialized penetration testing company, and SaMD testing is mostly about the gaps between parts. We test the app, the APIs and the cloud back end as one system, because that’s where authorisation flaws like the one in section 6 hide. Each finding is mapped to the GL-04 section 3.7 item it answers and is written so it can go straight into your traceability matrix. We retest after each fix and each significant release, so the submission shows closed findings and the post-market file remains current. Our SaMD testing service page sets out the general scope.
HippoClinic, which builds a multimodal platform for brain disorders, engaged us from February to May 2025, according to its CTO’s Clutch review. The goal was FDA compliance, and the outcomes listed in the review are a penetration test, vulnerability resolution, and FDA documentation. That wasn’t an HSA submission, but the evidence HSA’s section 3.7 asks for is built from the same work.
Prepare for Your Next Cybersecurity Audit with Qualysec
Choose a partner that helps you identify and fix real security risks before attackers do. We are here to help.
Talk to an Expert→
Conclusion and Next Steps
HSA doesn’t ask SaMD cybersecurity testing Singapore makers to promise that their software is secure. It asks them to show it. GL-04 R4 section 3.7 spells out what that looks like: the controls you built, the vulnerabilities you know about and the patient harm they could cause, a plan for handling threats after launch, test evidence tied together by a traceability matrix, and the exact operating systems the software runs on. Read that way, section 3.7 stops being a list of documents and becomes the brief for your test plan.
The rest of the guidance shapes how you meet that brief. Penetration testing isn’t mandatory, but it’s the most direct way to prove that access controls hold. The patient API example shows why: login worked perfectly in both builds, yet only one of them stopped a patient from reading someone else’s record. An SBOM isn’t a registration requirement either, but GL-04 expects you to monitor every third-party component, and GL-10 recommends one as part of the security documentation hospitals receive. Generating it from every build, with a gate that stops known vulnerable releases, covers both. The only firm line is the operating system. Software on an unsupported OS whose risks can’t be adequately mitigated won’t be permitted for supply, so support dates belong in the plan from the first release.
Primary call. HSA asks SaMD makers for evidence that their security controls work, with a traceability matrix to prove it. Talk to our team about testing your app, APIs, and cloud back end against GL-04 before you file, so that the submission addresses every cybersecurity item the first time.
Secondary call. Want to see how findings are written up first? Review a sample penetration testing report, with severity, reproduction steps and fixes laid out the way engineers and reviewers read them.
Frequently Asked Questions
1. What cybersecurity information does HSA require for SaMD registration in Singapore?
GL-04 R4 section 3.7 asks for five items: the controls in place, known and foreseeable vulnerabilities with a patient-harm risk analysis, ongoing plans to manage threats, including OS end of support, evidence that the controls work with a traceability matrix, and operating system details.
2. Is penetration testing mandatory for Software as a Medical Device under HSA rules?
No. GL-04 says security testing “can include” penetration testing, code analysis, vulnerability scanning and malware tests. What’s required is evidence that the controls were verified.
3. Does HSA require a Software Bill of Materials for SaMD?
Not for registration. GL-04 R4 doesn’t mention SBOMs, though it requires monitoring all third-party software. GL-10, which isn’t binding, recommends one.
4. Can SaMD run on an operating system that has reached end of support in Singapore?
Only if the risks can be adequately mitigated. GL-04 section 8.2.5 says software on an unsupported OS whose risks can’t be adequately mitigated won’t be permitted for supply in Singapore.
5. Does a security patch to registered SaMD need a change notification to HSA?
Yes. Changes made solely to fix a cybersecurity vulnerability are a Notification for all risk classes under GL-04 Figure 2.
6. How does HSA cybersecurity guidance apply to AI and machine learning SaMD?
The same five section 3.7 items apply. GL-10 section 6.7 adds AI risks such as prompt injection and data leakage, and AIHGle 2.0 isn’t a separate premarket requirement.
About Piyush Bhuyan
Pabitra Kumar Sahoo is the Co-Founder and Chief Operating Officer (COO) at Qualysec. With a deep commitment to elevating global cybersecurity standards, he directs corporate operations and service strategy, helping enterprises mitigate compliance debt and defend their digital infrastructure through elite, human-led penetration testing.
Leave a Comment.
Your email address will not be published. Required fields are marked *
