Summarize this blog post with
The device is already FDA cleared. The cybersecurity file passed review in the US, so the Singapore team opted for HSA’s shorter route, expecting a swift assessment. And then the questions began: what operating systems is the software compatible with, where is the traceability matrix linking security risks with controls and tests, and what happens when the operating system reaches the end of support?
That does not mean the FDA file was thin. This means HSA has its own guidelines on cybersecurity, and approval by a reference agency does not negate the cybersecurity item of HSA.
The good news is that the regulators agree on much more than they disagree. The HSA, FDA and EU all expect security risk management to be embedded in safety risk management, security to be built in from the design, testing that proves the controls work, and a plan for vulnerabilities after launch. Most of that goes back to the same IMDRF principles. They disagree on the details: what documents are required, whether an SBOM is legally required, how to deal with patches after approval, and what to do with software on an out-of-support operating system.
This guide compares HSA vs FDA medical device cybersecurity requirements and then places the EU MDR and IMDRF guidance next to them. It covers what each regulator wants from penetration testing, a worked example of one findings list feeding three submissions, the postmarket differences that catch teams out and a checklist for entering Singapore with an existing US or EU file.
Why the Comparison Matters for Singapore Submissions
HSA’s abridged route leans on prior approval. Under GN-15 Revision 15, the reference agencies are Health Canada, Japan’s MHLW, the US FDA, and the TGA or EU notified bodies, with an approved labelled use that is identical to the one intended for Singapore. For Class C and D, TGA and EU approvals count only where those agencies reviewed the device themselves, not under a mutual recognition agreement.
The abridged route doesn’t drop cybersecurity. HSA’s premarket submission checklist applies its cybersecurity item, 8.7, to the Full and Abridged routes for Class B and to the Full, Abridged and Expedited routes for Class C and D. Only the immediate routes (IBR and ICR) are spared security test reports under GN-17. Even then, the rest of the cybersecurity evidence still applies.
Singapore also adds things no other regulator here has: a hard line on unsupported operating systems, a best practices guide (GL-10) written for hospitals as well as manufacturers, and a voluntary cybersecurity label, CLS(MD). Those three are where a US or EU file most often comes up short.
Singapore Medical Device Cybersecurity Standards: The HSA Framework
Singapore medical device cybersecurity standards come from four documents, plus the standards they point to.
| Document |
Status |
What it contributes |
| GL-04 R4 (Dec 2025) |
Registration guideline |
Five cybersecurity items at registration (section 3.7) and the detail behind them (section 8), including the unsupported OS rule |
| GN-17 R5 and checklist item 8.7 (Oct 2026) |
Registration requirements |
Risk analysis, controls, test reports or other evidence, traceability matrix, OS information, postmarket plan |
| GL-10 R1 (Aug 2026) |
Best practice, not binding |
Total product life cycle duties for manufacturers and hospitals, five assessment methods, SBOM elements |
| CLS(MD) |
Voluntary label run by CSA |
Four levels; independent penetration testing at Level 3 |
GL-04 recommends manufacturers look to IEC 81001-5-1. GL-10 references Singapore’s TR 67:2018, UL 2900, and ISO/IEC 27001. Our HSA penetration testing guide goes into detail on the registration evidence, so here is the short version: HSA wants proof controls work; it wants them tied together in a traceability matrix. HSA wants exact operating system details; HSA wants a plan for the day support ends.
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 →
The FDA Approach: Section 524B and the February 2026 Premarket Guidance
Section 524B of the FD&C Act, which went into effect on 29 March 2023, applies to “cyber devices”: devices that incorporate software, can connect to the internet, and have characteristics that could be vulnerable to cybersecurity threats. Their sponsors are required to:
- Submit a plan to monitor, identify and address postmarket vulnerabilities, including coordinated vulnerability disclosure;
- maintain processes giving reasonable assurance that the device is cybersecure, with updates and patches “on a reasonably justified regular cycle” for known unacceptable vulnerabilities and “as soon as possible out of cycle” for critical ones;
- provide an SBOM covering commercial, open-source and off-the-shelf components.
The FDA’s premarket guidance, issued in February 2026, replaced the June 2025 version. It’s broader than 524B: it includes any device with software or programmable logic, whether connected or not. The testing section includes security requirements testing, threat mitigation testing, vulnerability testing (fuzzing, attack surface analysis, software composition analysis of binaries) and penetration testing. It specifies what a penetration test report should contain: the independence and technical expertise of the testers, scope, duration, methods and results.
The update was mainly to bring the guidance into line with the QMSR, which came into effect on 2 February 2026 and includes ISO 13485:2016. In DLA Piper’s summary, the old Part 820 sections were replaced with subclauses from ISO 13485, with no substantive change flagged to testing or SBOM expectations.
One FDA habit is worth borrowing for Singapore: architecture views. The guidance asks for a global system view, a multi-patient harm view, an updateability and patchability view, and security use case views. HSA doesn’t name them, but a multi-patient harm view is a clean way to show the patient-harm focus GL-04 asks for in its risk analysis item.
HSA vs EU MDR Cybersecurity Requirements
The EU writes cybersecurity into the MDR’s general safety and performance requirements. MDCG 2019-16 Rev.1 (July 2020), still the current MDCG cybersecurity guidance, maps the relevant Annex I items:
- 17.2: software developed to the state of the art, including information security, verification and validation.
- 17.4: minimum requirements for hardware, IT network characteristics and IT security measures.
- 18.8: protection against unauthorised access.
- 23.4(ab): minimum IT requirements in the instructions for use.
Comparing HSA vs EU MDR cybersecurity requirements, the most significant difference is who assesses them. In the EU, a notified body reviews technical documentation against the GSPRs. In Singapore, HSA evaluates the dossier itself against a named list of evidence. The MDR states outcomes, while HSA’s checklist names documents, down to the traceability matrix and OS details.
The content still lines up well. The minimum IT requirements the MDR wants in the instructions for use (23.4(ab)) are close to what HSA asks for in its OS item, and MDCG 2019-16’s postmarket section covers the same ground as HSA’s ongoing monitoring plan. A well-kept GSPR checklist with evidence references is a good starting point for the CSDT.
Two newer EU laws matter at the edges. The Cyber Resilience Act doesn’t apply to products covered by the MDR or IVDR (Article 2(2)), but companion apps and other products outside those regulations may fall under it, with reporting duties from September 2026. NIS2 can apply to medium and large manufacturers in the health sector, depending on national transposition.
IMDRF Medical Device Cybersecurity Compliance: The Common Baseline
There’s no IMDRF certificate. IMDRF medical device cybersecurity compliance means aligning with three non-binding documents that most regulators draw on.
- N60 (2020): principles across the total product life cycle, shared responsibility, and the main design, testing and postmarket practices.
- N70 (2023): legacy devices, with end of life and end of support and the transfer of responsibility to healthcare providers.
- N73 (2023): SBOMs and how they’re shared and used.
HSA’s GL-10 cites all three, and its life cycle stages and definitions come largely from N60 and N70. The FDA’s SBOM expectations and the EU’s life cycle approach follow the same lines. So a file built on IMDRF principles travels well. It just needs each regulator’s labels and document names added.
In practice, N73 is the most useful of the three for a Singapore launch. GL-10 expects the SBOM to reach hospitals as part of the customer security documentation, and N73 sets out how one should be shared and kept current. N70 is the one to read before you set end-of-support dates, because it explains what healthcare providers need from you and how early, when support winds down.
Side-by-Side: HSA, FDA, EU MDR and IMDRF Compared
International Medical Device Penetration Testing Requirements
Searches for international medical device penetration testing requirements often assume a law somewhere demands a pentest. In the main regulations, none does. What exists is a mix of recommendations and one scheme requirement:
- FDA: penetration testing is part of the recommended test suite, and the report should state the tester’s independence and expertise, scope, duration, methods, and results.
- EU: MDCG 2019-16 lists penetration testing with security feature testing, fuzzing and vulnerability scanning.
- Singapore: GL-04 says security testing “can include” penetration testing. It becomes mandatory only for CLS(MD) Level 3, with a fuller security evaluation at Level 4.
- Health Canada: its 2019 guidance lists structured penetration testing among methods to consider, asks for a cybersecurity bill of materials for Class III and IV, and wants test reports for Class IV.
- Australia: the TGA guidance (version 1.2, 2022) suggests penetration testing “commensurate with risk level”.
- Japan: IEC 81001-5-1 has been required under the essential principles since 1 April 2024, according to Intertek.
So the practical answer is to design one test that satisfies the most demanding reader. In practice, this means meeting the FDA’s report expectations and the HSA’s traceability matrix. A report that works for all of them usually carries:
- the software version, build and hash tested, matching the version you’ll register;
- tester names or roles, and a statement of independence from the development team;
- scope across the device, apps, cloud and hospital interfaces, with anything excluded and why;
- dates, duration and methods, including the manual testing done;
- each finding with severity, steps to reproduce, the fix, and a dated retest result.
Singapore MedTech Cybersecurity Compliance: One Evidence Pack for Several Markets
Singapore MedTech cybersecurity compliance is easiest when the same evidence feeds every file. An FDA cybersecurity package maps well into the ASEAN CSDT, but three gaps usually need closing for HSA: explicit OS details for the software and the whole device system, a traceability matrix in the form checklist item 8.7 asks for, and a plan for OS end of support that answers GL-04 section 8.2.5. Going the other way, an HSA dossier needs an SBOM in the FDA’s format and a 524B postmarket plan before it’s ready for a US cyber device submission.
If you’re planning both markets, start from the FDA structure. It’s the most prescriptive on test reports and SBOM content, so it leaves the fewest gaps to fill. Then add the HSA items on top, rather than squeezing an HSA dossier into the FDA’s shape afterwards.
Keep software versions aligned. GL-04 asks you to compare versions if your validation reports cover a different one from the version you register, and a test report for build 2.3 won’t settle questions about build 2.5.
Case study example: one findings list, three submissions
Take three findings from a single penetration test of a connected infusion monitor and its companion app (an illustrative example):
One finding, one fix, one retest, and three different places it lands. Writing the finding once, with a column for each regulator’s reference, saves rewriting it three times later.
From the tester’s side, the third row is the one to raise earliest. A hard-coded key takes an afternoon to fix. An operating system migration on a hospital reading station takes months of compatibility testing, and in Singapore it decides whether the product can be supplied at all.
Postmarket Differences That Catch Teams Out
Patches. All risk classes HSA treats a software change that is made only to address a cybersecurity vulnerability as a notification (change type 2Aii). They are light but you still have to file them. The FDA’s 2016 postmarket guidance says routine cybersecurity updates and patches are typically not subject to premarket review, and 524B sets the patch cadence. EU’s MDCG 2019-16 requires manufacturers to plan for updates beyond field safety corrective actions and to keep cybersecurity in post-market surveillance.
Vulnerability disclosure. The FDA writes coordinated vulnerability disclosure into the 524B plan. HSA’s GL-04 asks for a formal process to receive reports from vulnerability finders and disclose mitigations, and GL-10 adds information sharing.
End of support. This is where Singapore is the strictest. Software running on an unsupported OS “with inherent cybersecurity risks that cannot be adequately mitigated” “will not be allowed for supply in Singapore,” GL-04 says. The FDA handles end-of-life support through SBOM support levels and dates, and the EU through MDCG guidance to prevent end-of-life components. IMDRF N70 provides the shared vocabulary.
Incidents. In the EU, a cybersecurity problem that does cause or has the potential to cause a serious incident becomes a vigilance matter, with IMDRF codes to classify it (MDCG 2019-16, section 5.2). It also changes the patch route in Singapore: under GN-21 an amendment associated with a reportable adverse event or a field safety corrective action in progress requires prior approval rather than a notification.
Multi-Market Cybersecurity Checklist for Singapore Market Entry
Before testing
- Map each target market’s evidence list: HSA checklist 8.7, FDA premarket elements, MDR Annex I
- Freeze the version you’ll file, and record its build and hash
- Confirm OS versions and support end dates for the software and the whole system
During testing
- Cover the device, apps, cloud and hospital interfaces
- Record tester independence, scope, duration and methods
- Tag each finding with its HSA, FDA and EU references
Before each submission
- HSA: traceability matrix, OS details, unsupported OS plan
- FDA: SBOM with support levels, 524B plan
- EU: GSPR checklist entries and IFU minimum IT requirements
After approval
- File HSA Notifications for cybersecurity-only patches
- Keep SBOMs current, and retest after significant changes
How Qualysec Supports Multi-Market Medtech Cybersecurity Testing
Qualysec is a specialized penetration testing company, and multi-market medtech work comes down to testing once and documenting carefully. We scope a single test across the device, the companion app and the cloud back end, record version, independence, duration and methods the way the FDA asks, and tag each finding with the HSA vs FDA medical device cybersecurity references it supports. Every fix is retested, so each submission shows closed findings. Our FDA and EU MDR comparison covers those two markets in more depth.
vTitan, an Indian medtech company, engaged us from December 2024 to February 2025 to test its Accuflow Uro medical device and companion mobile app against FDA guidelines, according to its Clutch review. The reviewer reported reduced vulnerabilities, mitigated risks and compliance achieved. That was an FDA-focused engagement, not an HSA submission, but it’s the same evidence a Singapore dossier is built from.
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
Regulators have more in common than their documents let on. The practical way is to build the evidence to the strictest reader in each area: FDA for test reports and SBOMs, HSA for traceability and operating system support and the EU for documenting against the GSPRs. Then label it for each market.
Test once but document for each regulator you file with. The HSA query will be answered before it’s sent with a finding written with all three references, fixed and retested on the version you’re registering.
Primary call. An FDA or CE file rarely covers everything HSA asks for, and the gaps show up as queries. Talk to our team about one penetration test scoped for Singapore, the FDA and the EU, with findings mapped to each submission before you file.
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 is the main difference between HSA and FDA medical device cybersecurity requirements?
Cyber devices (including a mandatory SBOM). The FDA’s core duties are statutory (section 524B). The HSA is implemented through registration requirements that require a traceability matrix and the OS details to be provided, and does not allow unsupported operating systems where the risk cannot be mitigated.
2. Can FDA cybersecurity documentation be reused for an HSA submission in Singapore?
Yes, mostly. Anticipate incorporating detailed operating system information, a traceability matrix as requested in checklist item 8.7, and a plan for the operating system’s end-of-support. HSA’s shortened pathway does not take the cybersecurity item out of FDA clearance.
3. Does HSA require a Software Bill of Materials like the FDA does?
No. GL-04 R4 does not mention SBOMs, but requires monitoring of all third-party software. GL-10 recommends one as best practice and hospitals often ask for it.
4. How do HSA cybersecurity requirements compare with the EU MDR?
The MDR sets binding, outcome-oriented requirements in Annex I, assessed by notified bodies. HSA checks submissions against named evidence items itself. The technical content overlaps significantly.
5. Is penetration testing required by HSA, the FDA and the EU MDR?
Not a legal requirement in any of the three. It is one of the methods listed in EU; it is recommended by the FDA, and the content of the reports is specified; it is provided as an example by the HSA. Singapore’s voluntary CLS(MD) label requires it from Level 3 onwards.
6. What role does the IMDRF play in medical device cybersecurity, and does HSA follow it?
The IMDRF issues non-binding principles: N60, N70 and N73. All three are referenced in HSA’s GL-10 and its life cycle stages and definitions are based on them.
About Pabitra Kumar Sahoo
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 *
