How to Comply with TGA MDCSG Requirements

If you make a connected medical device and you sell it in Australia, cybersecurity is not an optional extra bolted on before submission. It is part of what makes the device safe, and the Therapeutic Goods Administration treats it that way. The mistake I see most often is teams treating the TGA's Medical Device Cyber Security Guidance as a document to satisfy at the ARTG inclusion stage, then forgetting it the day the device ships. The guidance is built around the opposite idea: security across the total product lifecycle, from design through the entire time the device is in the field.

I am Alexander Sverdlov, founder of Atlant Security and a former Microsoft security consultant. Since 2013 I have run more than 200 security assessments across 14 countries, including for connected-product and healthcare technology manufacturers. This is a practical guide to meeting the TGA's expectations for medical device cyber security without either under-doing it and failing conformity, or over-engineering a low-risk device into an unshippable state.

What the TGA Actually Expects

The TGA's medical device cyber security guidance for industry sits underneath the Essential Principles in the Therapeutic Goods (Medical Devices) Regulations 2002. It is guidance, not a standalone law, but it explains how the TGA expects you to demonstrate that your device meets the Essential Principles when that device has software, connectivity, or programmable elements. The ones that matter most for cybersecurity are the principles covering devices with programmed systems, construction and interaction with their environment, and the information supplied with the device.

The guidance is explicitly a total product lifecycle model. It splits into two halves you must address together:

• Pre-market. Security by design, threat modelling and risk management, secure development, verification and testing, and the evidence you present at conformity assessment for ARTG inclusion.

• Post-market. Monitoring for new vulnerabilities, coordinated vulnerability disclosure, patching and updates, and reporting where a cybersecurity issue rises to a reportable event.

It also leans on recognised standards rather than reinventing them. Expect to work with ISO 14971 for risk management, IEC 62304 for medical device software lifecycle, IEC 81001-5-1 for health software security activities, and the IMDRF principles for medical device cybersecurity. Aligning to these is the cleanest way to produce evidence the TGA will accept.

Step 1: Do Cybersecurity Risk Management, Not Just Safety Risk

Manufacturers already run safety risk management under ISO 14971. Cybersecurity risk is related but distinct: a safety hazard analysis asks what happens if a component fails, while a security analysis asks what happens if an adversary makes it fail. You need both, and you need to connect them, because a security vulnerability only matters clinically when it can lead to patient harm.

• Threat model the device across software, firmware, hardware interfaces, wireless links, and the networks and back-end services it depends on.

• Trace each credible threat through to its potential clinical impact, so you prioritise the risks that could affect patient safety rather than every theoretical finding.

• Document mitigations and residual risk in a form that maps to your ISO 14971 risk file and to the Essential Principles.

This is the work that makes or breaks a submission. An independent vulnerability assessment early in development finds the design-level problems while they are still cheap to fix, rather than after tooling and firmware are locked.

Step 2: Build Security In, Not On

Security by design is the single most cost-effective decision in the whole lifecycle. Retrofitting encryption or authentication after the architecture is set is where budgets and timelines get destroyed. The controls the TGA expects to see reflected in the design include:

• Authentication and access control appropriate to the device, so that clinical functions and configuration are not exposed to unauthenticated access.

• Encryption for sensitive data at rest and in transit, particularly patient data and any remote communication channel.

• Secure boot and firmware integrity so the device only runs authentic, unmodified code.

• A secure update mechanism designed in from the start, because a device you cannot patch in the field is a liability the moment a new vulnerability appears.

• A software bill of materials (SBOM). You cannot manage vulnerabilities in third-party and open-source components you have not inventoried, and the TGA increasingly expects an SBOM.

Step 3: Verify With Real Testing

Design intent is not evidence. The TGA expects verification that the security controls you designed actually work, and this is where a documented, independent test program carries weight at conformity assessment.

• Commission penetration testing against the device, its wireless interfaces, its mobile or web companion apps, and its back-end services. A pacemaker programmer, an infusion pump, and a connected diagnostic each have a very different attack surface.

• Test the update mechanism itself, because a flawed update path is a direct route to compromising every device in the field.

• Keep the test reports and remediation records as part of your technical documentation. Evidence that you found and fixed issues is more convincing than a clean report with no methodology behind it.

Step 4: Stand Up Post-Market Cyber Surveillance

This is the half most manufacturers underestimate. A device that was secure at launch does not stay secure, because new vulnerabilities are discovered in the components it is built on. The TGA expects an active post-market cybersecurity capability for the life of the product:

• Monitor vulnerability feeds and your SBOM so you learn when a component in your device is newly affected.

• Run a coordinated vulnerability disclosure process so security researchers can report issues to you responsibly, with a published point of contact.

• Patch and update deployed devices within timelines proportionate to the risk, using the secure update mechanism you designed in.

• Report where a cybersecurity issue meets the threshold for adverse event or recall reporting under your ongoing obligations to the TGA.

Step 5: Manage Your Software Supply Chain

Modern medical devices are assembled from third-party libraries, real-time operating systems, and cloud services. Each is a path into your device and your patients' data. Vet the security practices of the suppliers whose components sit inside your product, require them to disclose vulnerabilities to you, and keep your SBOM current so a newly disclosed flaw in a shared component does not go unnoticed. If any part of your device relies on cloud infrastructure, that infrastructure is in scope too - our cloud security consulting work often sits alongside device assessments for exactly this reason.

Pre-Market and Post-Market at a Glance

Lifecycle stage	Key activity	Evidence the TGA looks for
Design	Threat modelling, security by design, SBOM	Cyber risk file linked to ISO 14971, architecture documentation
Development	Secure coding, IEC 62304 lifecycle	Development records, component inventory
Verification	Penetration testing, update-path testing	Test reports with methodology and remediation
Labelling	Security information for users	Instructions covering secure configuration and use
Post-market	Monitoring, disclosure, patching, reporting	Surveillance plan, disclosure contact, update history

The Mistakes That Cost Manufacturers

• Treating cybersecurity as a submission checkbox. The post-market obligations run for the life of the device. A one-time effort at inclusion is not compliance.

• No update mechanism. If you cannot patch a fielded device, your only options when a vulnerability appears are a recall or accepting the risk. Design the update path in from day one.

• No SBOM. You cannot respond to a vulnerability in a component you did not know you shipped.

• Confusing safety risk with security risk. They are related but not the same. You need a cybersecurity risk analysis connected to, but distinct from, your ISO 14971 hazard analysis.

If your device handles health information for patients in other markets, the underlying discipline overlaps heavily with frameworks like HIPAA in the US, and our HIPAA work is often relevant to the same product teams.

Frequently Asked Questions

Is the TGA medical device cyber security guidance mandatory?

The guidance itself is not law, but the Essential Principles in the Therapeutic Goods (Medical Devices) Regulations are mandatory, and the guidance explains how the TGA expects you to demonstrate you meet them for connected and software-based devices. In practice, following it is how you produce acceptable conformity assessment evidence.

Does the TGA certify the cybersecurity of my device?

The TGA does not issue a separate cybersecurity certificate. Cybersecurity is assessed as part of conformity assessment against the Essential Principles for inclusion in the ARTG. You demonstrate compliance through your technical documentation, risk files, and test evidence.

What standards should we align our device to?

ISO 14971 for risk management, IEC 62304 for software lifecycle, IEC 81001-5-1 for health software security activities, and the IMDRF medical device cybersecurity principles. Aligning to recognised standards is the most efficient way to produce evidence the TGA will accept.

Do the requirements apply to Software as a Medical Device (SaMD)?

Yes. Software that meets the definition of a medical device is subject to the Essential Principles, and the cybersecurity guidance applies to it just as it does to physical connected devices. The attack surface is different, but the lifecycle obligations are the same.

How much of the effort is post-market?

A significant and continuing share. Monitoring, coordinated vulnerability disclosure, patching, and reporting run for the entire time the device is supported and in the field. Manufacturers who budget only for pre-market work are the ones who struggle when the first serious vulnerability lands.

Bring Security Into Your Device Program Early

The manufacturers who pass TGA conformity smoothly are the ones who treated cybersecurity as a safety property from the first design review, not a compliance scramble before submission. If you are building or maintaining a connected medical device and want an independent read on your threat model, your test evidence, or your post-market surveillance, we assess medical device and connected-product security against the standards the TGA relies on. Talk to Atlant Security about scoping an assessment for your device.