Introduction: Why Connected Device Submissions Stall at HSA’s Cybersecurity Item
Your CSDT is in, screening went smoothly, and then HSA comes back asking for two things the file doesn’t have: security test reports for the device and a traceability matrix showing how each cybersecurity risk is controlled and tested. The architecture section describes encryption and authentication well enough. But nothing shows that anyone checked whether they work.
That’s usually the real question behind a search for how to clear an HSA medical device cybersecurity self declaration. HSA doesn’t ask for a signed cybersecurity statement at registration, and Annex 4 of GN-15 isn’t about cybersecurity at all. What HSA asks for, in GN-15’s submission tables, GN-17 section 4.3 and item 8.7 of its premarket submission checklist, is evidence: a risk analysis, control measures, security test reports, a traceability matrix, operating system details and a plan for handling threats after launch. A manufacturer’s declaration of conformity does come in, but under a separate and voluntary scheme run by the Cyber Security Agency of Singapore, CLS(MD).
This guide sorts out the Annex 4 confusion, goes through checklist item 8.7 line by line, covers what to test in a self-declaration before filing and how CLS(MD) fits, and shows where findings belong in the CSDT and what continues after registration.
What HSA Means by a Cybersecurity Declaration
Under the Health Products Act and the Health Products (Medical Devices) Regulations, HSA regulates medical devices, and Singapore was the first country to achieve the highest regulatory classification by WHO in March 2026 for medical devices. Product registration comes after GN-15, while GN-17 provides the ASEAN Common Submission Dossier (CSDT) template for preparing the technical file.
Declarations are a part of a registration, but not for cybersecurity. The GN-15 Revision 15, effective from 1 October 2026, contains templates for a letter of authorisation, marketing history, safety, and labelling, adverse events and field safety corrective actions. Additionally, the CSDT has a declaration of conformity. None of these asks for a cybersecurity statement.
The cybersecurity declaration that people tend to think of is from the Cybersecurity Labelling Scheme for Medical Devices (CLS(MD)): each application is based on a manufacturer’s declaration of conformity, supported by evidence (section 7).
For registration itself, HSA judges cybersecurity on evidence, and a signature can’t stand in for a test report.
HSA GN 15 Annex 4 Requirements: Clearing Up the Confusion
So what are the HSA GN 15 Annex 4 requirements in the current revision? GN-15 R15 has eight annexes.
Annex
Title
1
Letter of Authorisation Template
2
Marketing History Declaration Template
3
Safety Declaration Template
4
Device Labelling, Adverse Events and Field Safety Corrective Actions Declaration Template
5
Summary of Evaluation Routes for Class B Medical Device Registration
6
Summary of Submission Requirements (Class B)
7
Summary of Evaluation Routes for Class C and D Medical Device Registration
8
Summary of Submission Requirements (Class C and D)
Annex 4 is a declaration by the product owner. Its first part, for abridged, expedited and immediate routes, confirms that labelling, packaging and instructions for use match those approved by the reference agency. Its second part, for every application, covers adverse events and field safety corrective actions. You’ll still need to sign it, but it won’t answer a single cybersecurity question.
Cybersecurity is in item 12 of Annex 6 (Class B) and Annex 8 (Class C and D), under design verification and validation, as “evidence to support the cybersecurity of connected medical devices.” Annex numbers have also moved between revisions, and in earlier versions of GN-15, Annex 4 summarised the Class B evaluation routes. That’s partly why searches for Annex 4 cybersecurity compliance Singapore send teams to the wrong document. Instead, work from the current GN-15 and its submission tables.
The Cybersecurity Evidence HSA Expects in a Product Registration
GN-17 Revision 5, also in force since 1 October 2026, explains what sits behind item 12.
Section 4.2 asks the device description to state connectivity capabilities, such as wireless, Bluetooth, internet or network connection.
Section 4.3 lists four evidence items for connected devices: a cybersecurity vulnerabilities and risk analysis, the control measures, security test reports and/or evidence verifying the device’s cybersecurity and the effectiveness of its controls, and ongoing plans for surveillance, timely detection and management of threats over the device’s useful life.
Section 4.5 expects the risk management report to include cybersecurity risks where they apply.
Two details are problematic. The reviewers mark security test reports not applicable to IBR and ICR applications, the immediate registration routes, although the rest of the cybersecurity evidence still applies. And GN-17 points to HSA’s software guidelines, GL-04, for the details. According to Pure Global’s summary, the December 2025 revision of GL-04 reorganised its cybersecurity section with more attention to operating system end-of-support and rules out devices running an unsupported operating system where the risks can’t be mitigated. HSA’s essential principles guidance (GN-16) also covers IT security and protection against unauthorised access, so this evidence answers a safety requirement, not only a paperwork one.
The HSA GN 15 Cybersecurity Checklist: Premarket Submission Checklist Section 8.7, Item by Item
HSA’s premarket submission checklist (MD-01 R1, October 2026) turns all of this information into six items under section 8.7. It’s the closest thing to an official HSA GN 15 cybersecurity checklist, and it applies to Class B devices on the Full and Abridged routes and to Class C and D devices on the Full, Abridged, and Expedited routes.
Item
What HSA asks for
What convinces an evaluator
1
Cybersecurity vulnerabilities and risk analysis
A threat model covering every interface, linked to the ISO 14971 file
2
Cybersecurity control measures
Controls mapped to specific threats, not a generic feature list
3
Security test reports and/or evidence verifying cybersecurity and control effectiveness
Dated reports stating the version tested, scope, method, tester independence, findings and retests
4
A traceability matrix linking risks, controls and the tests that verify them
One row per risk, each ending in a test result (section 8)
5
Operating system information
Compatible OS versions for software on phones or computers, or the dedicated or embedded OS for other systems
6
An ongoing plan for surveillance, detection and management of threats
Monitoring, patching, OS end-of-support handling and breach detection across the device’s useful life
The checklist says its examples are “not limited to” those listed, so read the six items as a floor rather than a ceiling. Item 3 is where most files are thinnest, and item 4 is what holds the others together. A risk with no control, or a control with no test, jumps out of a well-built matrix. In a page of narrative, it can hide for months.
Where files usually fall short:
The test report covers an older software version than the one in the submission.
The team attached raw scanner output but included no analysis of what the findings mean for the device.
The team described the controls but provided no evidence that they were tested.
The team listed operating system versions without end-of-support dates or a plan to address them.
The post-market plan promises monitoring without saying who does it, how often, or what triggers a patch.
HSA Medical Device Penetration Testing Singapore: What to Test Before You File
People searching for HSA medical device penetration testing Singapore often assume it’s compulsory for registration. It isn’t. GN-17 asks for security test reports “and/or evidence”, and HSA’s software guidelines give structured penetration testing, vulnerability scanning and malware testing as examples of that evidence. HSA’s GL-10 best practices guide, published in August 2026, describes penetration testing as simulating real-world attacks, but it also says plainly that it doesn’t set requirements for premarket submission. In practice, though, a penetration test is the most direct way to fill item 3 and the test column of item 4.
Scope it around the device, as hospitals will actually run it. Test the build you plan to file, set up on a segmented clinical network, with the companion app on current phone operating systems and the cloud tenant configured as it would be for a customer. Include the update server and any remote service access too, as both are easy to leave out of scope and both are routes an attacker would try.
Key Areas to Test Before HSA Medical Device Registration
Area
What testers check
Hardware and firmware
Debug ports left enabled, firmware that can be read out with keys inside, missing secure boot
Wireless and network
Bluetooth pairing that allows interception, data readable without pairing, commands that work when replayed, and exposed network services
Apps, portals and cloud
Mobile app storage and certificate checks, clinician portal authorisation, API access control and separation between hospitals
Hospital and public healthcare integrations
HL7 and FHIR interfaces, links into systems run for public healthcare clusters, and assumptions that the hospital network is safe
Credentials and updates
Universal default passwords, no limit on login attempts, unsigned or downgradable software updates
The final row is more significant than its length implies. Shared default passwords are among the easiest issues to fix before filing. Evaluators and hospital buyers increasingly expect to test basic controls such as per-device credentials, lockout and/or rising delays after failed attempts, and signed software updates that reject older versions, and these controls are essential.
The report must be written in such a way that an evaluator can use it without having to call you. State the versions of software and firmware tested, the date, the scope, any software or firmware excluded and why, the method, who is responsible and how independent, and each finding and severity, fix, and retest result. Recognised method names are useful for this purpose. Security testing is now part of the health software life cycle as outlined in IEC 81001-5-1, while GL-10 highlights Singapore’s TR 67:2018 and UL 2900.
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.
CLS(MD): The Singapore Medical Device Cybersecurity Declaration and Label
CSA launched CLS(MD) on 16 October 2024 with MOH, HSA and Synapxe. It’s voluntary and covers medical devices that handle personal or clinical data, or that connect to other devices, systems or services.
Level
What it requires
1
Baseline cybersecurity requirements
2
Enhanced cybersecurity requirements
3
Enhanced requirements plus independent third-party software binary analysis and penetration testing
4
Enhanced requirements plus independent third-party binary analysis and a security evaluation
At all levels, the application is based on a declaration of conformity with supporting evidence; applicants must engage an Approved Testing Laboratory to review it. If anything deserves to be called a Singapore medical device cybersecurity declaration, it is that document. At Level 1 and 2, it provides the evidence, and the laboratory reviews the manufacturer’s evidence that the device meets the requirements for its level. Independent binary analysis and penetration testing are at Level 3, and it’s at that level that penetration testing becomes a must.
Registration for CLS(MD) and HSA are independent of each other. The label is not a substitute for any part of the CSDT, and registration does not require a label. They rely on the same evidence, however. The risk analysis, controls and test reports you create for item 8.7 are the basis for a CLS(MD) declaration, and hospital purchasers may request either. Before budgeting, please consult the scheme publications of CSA for the validity of the label, fees and current requirement lists.
Mapping Penetration Test Findings to the ASEAN CSDT
Security evidence belongs in the CSDT’s design verification and validation section, beside the rest of your preclinical evidence, with cybersecurity risks carried into the risk management report.
The traceability matrix is the part most teams underbuild. A simple version looks like this (the rows are illustrative):
Risk
Control
Test case
Result
Retest
Attacker guesses the clinician login on the device
Per-device credentials and lockout after failed attempts
Repeated login attempts against the device
Failed: no lockout
Passed after fix, report v1.1
Tampered software update installed
Signed updates with downgrade protection
Install modified and older packages
Passed: both rejected
Not needed
One hospital reads another’s patient data through the cloud API
Tenant check on every request
Request another tenant’s record with a valid token
Passed: refused
Not needed
The ISO 14971 finding should also include the clinical consequence in plain words, in addition to the finding itself. An evaluator recalls the following: “Someone in the ward corridor could silence an alarm.”
If there is any remaining open at submission, for each one, provide a residual risk statement, stating what the problem is and why it is unlikely or very limited to be exploited, which controls mitigate it, what users need to do, and if a fix is likely, when. Firmware 2.3 (to be available next quarter) introduces passkey pairing. For example, the device accepts Bluetooth pairing without a passkey for 60 seconds after powering on; an attacker would have to be within range during pairing. Once paired, the device encrypts the link. Firmware 2.3 will also come with an IFU that instructs staff to pair devices in a controlled area. Four sentences, and the evaluator is sure of what is open and why it is ok at this time.
PDPA, the Health Information Act and Hospital Buyers
Singapore customers will also seek this proof for various reasons, beyond just registration. The PDPA sets out the requirements for organisations to safeguard the personal data they collect and hold or control and to notify the PDPC within three calendar days after determining that a breach is notifiable. If you have patient information in your cloud-based platform, it applies to you.
The Health Information Act, passed in January 2026 and phasing in through early 2027 according to Baker McKenzie, applies to healthcare providers rather than manufacturers. MOH’s cybersecurity and data security guidelines for healthcare providers push the same providers to check the security of what they buy. Be prepared to provide the test report, matrix and support plan you provided HSA to the procurement team.
It also makes it easier to have a buyer pack ready: A summary of the latest test and when and what it was for, the SBOM if requested, your patch dates, and a named security contact. Most hospitals will not require the entire report, and you may wish to submit it only under a confidentiality agreement.
Cybersecurity Obligations After HSA Registration
There are clear change rules with HSA regarding patches for security. With GN-21 Revision 7, software changes to only address a cybersecurity vulnerability are still notifiable, but they are considered a notification (change type 2Aii). Prior approval applies if the change is related to a reportable adverse event or an ongoing field safety corrective action.
You need to implement the support plan for the item: You monitor components using a software bill of materials, a coordinated vulnerability disclosure process, timely patching, and recovery. GL-10 describes three levels of support. Full support is followed by limited support for critical issues, and finally end of support, where the healthcare provider assumes responsibility for ongoing use. If you know which phase a device is in, you can avoid awkward conversations later. As the guidance winds down, it is worth reading IMDRF’s guidance on legacy medical devices, which shows how the responsibility of manufacturing and hospitals is shared.
Retest after you add an interface, change the authentication or the update mechanism, move hosting, replace a core component, or learn of a vital vulnerability in something you ship, and maintain a regular cycle that suits the risk of the device.
HSA Cybersecurity Readiness Checklist for Connected Medical Devices
Before testing
Risk class, evaluation route and connectivity confirmed
Threat model and data flows current, and linked to the risk file
Generate the SBOM from the build that will be tested, matching the version you’ll file.
During testing
Tester independent from the developers, with that recorded
Hardware, wireless, apps, cloud and hospital integrations in scope
Default credentials, login limits and the update path tested
Before submission
All six item 8.7 elements present
Traceability matrix complete, with every risk ending in a test result
Critical and high findings fixed and retested, or justified in the risk file
Operating system information and end-of-support plan stated
After registration
Notifications filed for cybersecurity-only software changes
Vulnerability monitoring and disclosure process running
Retest triggers defined
How Qualysec Supports HSA-Aligned Medical Device Testing
Qualysec is a specialized penetration testing company, and medical device work is where our reports feed straight into regulatory files. We scope the device, the companion app, and the cloud back end together, so we don’t miss weaknesses between them. Findings are written for two readers. Engineers receive reproduction steps and a fix, while the regulatory teams receive an impact description and a test result that they can use in the traceability matrix and the CSDT. Each fix is tested again afterwards and will reflect closed findings rather than open findings.
According to Oivi’s Clutch review, they hired us in March and April 2026 as a health tech company that creates a portable retinal camera. The scope included the desktop app that controls the camera and takes pictures, the web app where users log in and view patient information, and the back-end services supporting both; each discovery included details on how to duplicate it, a severity level, and a recommended remediation. This is not an HSA project, but it is a project that yielded the type of evidence that 8.7 requires.
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.
HSA medical device cybersecurity self declaration clears connected devices based on evidence. Treat its cybersecurity item as an evidence pack, not a form to sign: six elements, one matrix that ties them together, and test results showing the controls hold. The time teams lose hunting for an Annex 4 form is time they could have spent testing.
Timing does the rest. Test early enough to fix and retest before you file, so the CSDT answers the evaluator’s questions before they’re asked, and keep the same evidence current for CLS(MD), hospital buyers and every patch after registration.
Primary call. HSA clears connected devices on evidence, and a missing security test report is one of the easiest queries to avoid. Talk to our team about testing your device, app and cloud back end before you file, so your CSDT answers checklist item 8.7 in full.
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 a reviewer reads them.
Frequently Asked Questions
1. Does HSA require a cybersecurity self-declaration for medical device registration?
There are a number of cybersecurity documents. HSA is requesting a risk analysis, controls, security test reports, a traceability matrix, operating system information and a post-market plan. The voluntary labelling scheme is done under a manufacturer’s declaration of conformity, but not under registration.
2. What does Annex 4 of GN-15 cover, and where are the cybersecurity requirements?
The declaration on device labelling, adverse events and field safety corrective actions is in Annex 4 of GN-15 Revision 15. The details for cybersecurity are in the checklists in the GN-17 section 4.3 and checklist item 8.7, while the security requirement is in item 12 of Annex 6 and Annex 8.
3. Is penetration testing mandatory for HSA medical device registration in Singapore?
No, HSA requires security test reports or other evidence, and one of the examples in the HSA’s software guidelines is penetration testing. CLS(MD) is only mandatory at Level 3 (and CLS(MD) is voluntary).
4. What cybersecurity documents should a connected medical device include in its HSA submission?
The six item 8.7 elements are risk analysis, control measures, security test reports or other evidence, a traceability matrix, operating system information and an ongoing plan for managing threats. Security test reports aren’t required for IBR and ICR applications.
5. Is the CLS(MD) label required to sell a connected medical device in Singapore?
No. It’s optional and distinct from HSA registration and will be asked for by hospital buyers when they are making their purchase.
6. Does a cybersecurity patch need a change notification to HSA after registration?
Yes. The change of software for a single cybersecurity vulnerability is a notification for all risk classes in accordance with the GN-21 Revision 7. If the change is due to a reportable adverse event or an ongoing field safety corrective action, then prior approval is required instead.
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.
