TGA Medical Device Cybersecurity

The TGA aligns with IMDRF principles and recognizes much of the content that satisfies the FDA's February 3, 2026 final premarket cybersecurity guidance. The mechanism is different: instead of a single submission section, cybersecurity evidence is mapped to the Essential Principles 12 and 12A and to the conformity assessment route appropriate for the device class. This post explains what the TGA expects in 2026, where Australian sponsors and overseas manufacturers most commonly fall short, and how to convert an existing FDA package into ARTG-ready content.

Why this matters

The Australian Register of Therapeutic Goods (ARTG) is the gateway for medical device commercialization in Australia. Cybersecurity expectations are written into the Essential Principles in the Therapeutic Goods (Medical Devices) Regulations 2002 and elaborated in the TGA's industry guidance. The guidance aligns with IMDRF N60 ("Principles and Practices for Medical Device Cybersecurity") and references IEC 81001-5-1, AAMI TIR57 / ANSI/AAMI SW96:2023, and ISO 14971. Sponsors that operate from an FDA Section 524B baseline can reuse most technical content, but the conformity assessment evidence, labeling, and postmarket plan need to map to Australian rules. Skipping that mapping is the most common reason TGA reviewers raise cybersecurity questions on otherwise complete applications.

How the TGA Classifies Medical Devices

EU-Aligned Classification

The TGA uses classes broadly aligned with the EU MDR: Class I, Class IIa, Class IIb, Class III, and Active Implantable Medical Devices (AIMD). The classification rules under Schedule 2 of the Regulations determine the conformity assessment route. Connected diagnostic and therapeutic software devices commonly fall in Class IIa or IIb; implantables and life-sustaining devices fall in Class III or AIMD.

The Software Classification Rule

The TGA's software-as-a-medical-device classification rules, in force since February 2021 with transition arrangements that closed in November 2024, elevated many SaMD products to Class IIa or higher. This rule is significant for cybersecurity because the rule shifts the bar for evidence and conformity assessment. Sponsors must check current classification rules for software products at the time of application.

How the TGA Classifies IVD Medical Devices

In vitro diagnostic devices sit in a separate classification scheme in Australia. IVDs are classified Class 1, 2, 3, or 4 IVD under Schedule 2A of the Therapeutic Goods (Medical Devices) Regulations 2002, based on the public health risk and the risk to the individual if the result is wrong. That is a different ladder from the Class I to III and AIMD scheme used for other devices, and it changes both the conformity assessment route and the depth of cybersecurity evidence the TGA expects.

Decision Criteria

Work through these questions in order to place an IVD:

1. Is the product an IVD at all? If it is a reagent, calibrator, control material, instrument, or software intended to examine a specimen taken from the body to provide information about a physiological state, disease, or compatibility, it is an IVD. Software that only stores or transmits results without interpreting them may fall outside the IVD scheme and be regulated as SaMD instead.
2. Is it for self-testing or point of care? Self-test IVDs carry a higher classification than the same assay used in a laboratory, because there is no professional interpreting the result.
3. What happens if the result is wrong for the individual? A wrong result that leads to a life-threatening treatment decision, a missed cancer diagnosis, or a transfusion error pushes the device up the ladder.
4. What happens if the result is wrong at population scale? Transmissible-agent screening, blood and tissue donor screening, and detection of agents with a high risk of propagation sit at the top of the scheme.
5. Is it an in-house IVD? Laboratories manufacturing IVDs for their own use fall under a separate TGA framework with its own notification and compliance obligations rather than standard ARTG inclusion.

The practical result:

How IVD Class Changes Cybersecurity Obligations

The six pre-market expectations in the TGA cyber security guidance apply to every connected IVD, but the evidence bar scales with class:

• Class 1 and 2 IVD. A documented security risk assessment tied to ISO 14971, an SBOM for any bundled software, secure configuration labeling, and a postmarket monitoring plan. Penetration testing is expected where the analyzer or middleware is network connected.
• Class 3 IVD. Everything above plus a formal threat model that treats result integrity, quality-control bypass, and LIS or middleware interoperability as first-class harm scenarios, security architecture views, and verification evidence proportionate to the mandatory application audit.
• Class 4 IVD. The Class 3 content plus population-scale harm analysis in the risk file (for example, a manipulated donor-screening result propagating into the blood supply), documented controls over result transmission integrity, and a postmarket plan with defined timelines for vulnerability triage across long installed lifetimes.

Two class-driven consequences catch sponsors out. First, Class 3 and Class 4 IVDs attract a mandatory application audit, so cybersecurity evidence that would never be read for a Class 1 device is read line by line. Second, the harm analysis has to be about diagnostic error, not device malfunction. A threat model that only reasons about availability and device uptime will draw questions, because the patient harm from an IVD flows through the wrong result reaching a clinician.

Connectivity does not change the class, but it does change the evidence. A Class 2 IVD analyzer with an HL7 or ASTM interface into a networked LIS needs the same interface-level analysis as a higher-class device, because that interface is the path an attacker uses to alter results.

Essential Principles 12 and 12A

What the Essential Principles Require

Essential Principle 12 covers medical devices that incorporate software or are themselves software, requiring that they be developed with regard to the state of the art and to the principles of development lifecycle, risk management, validation, and verification. Essential Principle 12A explicitly covers programmable medical devices and requires repeatability, reliability, and performance consistent with the intended use. Cybersecurity sits inside both principles.

How the TGA Reads the Evidence

The TGA accepts evidence from EU notified body conformity assessments, MDSAP audits, and FDA submissions in many cases, but the sponsor's Australian Declaration of Conformity must explicitly map evidence to the relevant Essential Principles. A US-cleared device with an FDA Section 524B package still needs the EP mapping for the ARTG inclusion.

The TGA Cybersecurity Guidance Content Areas

The TGA's "Medical device cyber security guidance for industry" (v1.2, November 2022, still the current version as of 2026) lists six pre-market expectations:

The structure mirrors the FDA Feb 3, 2026 guidance and the Health Canada 2019 guidance, which is why the technical content is largely portable.

ARTG Conformity Assessment Evidence Routes by Class

Classification tells you the risk tier. The conformity assessment route tells you who has to certify the evidence, which certificate the TGA will accept, and how much of your cybersecurity documentation a reviewer will actually read before inclusion. Sponsors who get the classification right and the route wrong still end up in a request for information.

Who Can Certify the Evidence

Australia recognizes three broad sources of conformity assessment evidence:

• TGA Conformity Assessment Certificate. Issued by the TGA itself after a direct assessment of the manufacturer's quality management system and technical documentation. Mandatory for Class 4 IVDs and for Australian-manufactured Class III and AIMD devices, and available by choice to any manufacturer.
• Comparable overseas regulator evidence. The TGA accepts EU MDR and IVDR notified body certificates, and in defined circumstances certificates and approvals from other comparable regulators, as the basis for an abridged assessment. This is the route most overseas manufacturers use.
• Manufacturer's own declaration. For the lowest risk tiers, the manufacturer holds the technical file and the sponsor makes an Australian Declaration of Conformity without third-party certification. The evidence still has to exist and be produceable on request.

Whichever route applies, the sponsor lodges an Australian Declaration of Conformity that maps the evidence to the Essential Principles. Cybersecurity evidence is mapped to Essential Principles 12 and 12A, and that mapping is the sponsor's obligation regardless of who issued the underlying certificate.

Routes and Cybersecurity Evidence Depth

What This Means in Practice

Three route-driven behaviors are worth planning for.

See also: Health Canada Cybersecurity Requirements, IMDRF Cybersecurity Guidance Explained, and MDSAP for Medical Device Compliance.

Mandatory audit classes get a real technical review. For Class III, AIMD, and Class 3 and 4 IVDs, the TGA reads the technical documentation rather than accepting the certificate at face value. Cybersecurity gaps that survived a notified body review can surface here, most often as a threat model that is not traceable to the risk management file.

Abridged routes still need the Essential Principles mapping. An EU MDR certificate demonstrates conformity with the EU General Safety and Performance Requirements, not with the Australian Essential Principles. The crosswalk from GSPR 17 and Annex I security content to EPs 12 and 12A has to be written out, and it is the single most common piece of missing paperwork in cybersecurity-related requests for information.

Changes to security controls can be certificate-affecting. Adding an update mechanism, changing authentication architecture, or altering the network interface can constitute a substantial change requiring notification to the certifying body and to the TGA before the change reaches the Australian market. Build that trigger into the change control procedure rather than discovering it during a postmarket update.

Relying on Comparable Overseas Regulator Reports

The TGA runs a comparable overseas regulator (COR) framework that lets sponsors use assessment reports and approvals from other trusted regulators instead of repeating the full assessment in Australia. For cybersecurity, this is the mechanism that makes a Section 524B package or an EU notified body file worth reusing. It is a reliance pathway, not a mutual recognition pathway: the TGA still makes its own decision, and it still expects the evidence to be mapped to the Australian Essential Principles.

Which Regulators the TGA Treats as Comparable

The TGA's comparable overseas regulator arrangements cover, among others, the US FDA, the EU notified body system under MDR and IVDR, Health Canada, Japan's PMDA, and Singapore's HSA, with the accepted scope varying by device type and by the specific program the approval came from. Two points matter more than the list itself. First, the scope is device-specific: a regulator can be comparable for one class or device type and not for another. Second, the report has to cover the same device, same intended purpose, and same manufacturing sites as the Australian application. Confirm current scope on the TGA's comparable overseas regulator pages before you build an application around a given report, because the arrangements are updated over time.

What a COR Report Can and Cannot Do for Cybersecurity

A COR report can shorten the TGA's assessment of technical documentation you have already had reviewed elsewhere. It cannot replace the sponsor's Australian obligations.

• Can support: the security risk assessment, threat model, secure design rationale, SBOM, verification and penetration testing evidence, and the software lifecycle process evidence under IEC 81001-5-1.
• Cannot replace: the Australian Declaration of Conformity, the EP 12 and 12A mapping, Australian-specific labeling and instructions for use, and the postmarket plan aligned to URPTG and TGA adverse event reporting.
• Does not transfer automatically: conditions, restrictions, or postmarket commitments imposed by the overseas regulator. Disclose them; the TGA will decide whether equivalent conditions apply in Australia.

Practical Guidance for Citing Overseas Reports

Treat the citation as a traceable evidence package rather than a reference in a cover letter.

1. Cite the report precisely. Name the regulator, the decision or certificate number (510(k) number, De Novo number, PMA number, notified body certificate number), the decision date, the device name as approved, and the intended purpose as approved. A reference to "FDA cleared" with no number will draw a request for information.
2. Include the report itself, not a summary. Provide the assessment report or certificate plus the relevant technical documentation. Where the FDA decision summary is thin on cybersecurity, which is common, include the submitted cybersecurity documentation directly rather than relying on the public summary to carry it.
3. Prove device identity. Add a short statement of equivalence covering device name and model, intended purpose, software version, hardware configuration, and manufacturing sites, with an explicit note on any difference between the overseas-approved device and the Australian device. Software version drift is the difference sponsors most often forget to declare.
4. Provide the crosswalk table. One row per Essential Principle clause relevant to software and cybersecurity, with the specific overseas document, section, and page number that satisfies it. Reviewers follow this table; if it is missing, they ask for it.
5. Reconcile the standards. State which standards the overseas evidence was built against (ANSI/AAMI SW96:2023, AAMI TIR57, IEC 81001-5-1, ISO 14971, IMDRF N60) and confirm they are the versions the TGA guidance points to. Where an older version was used, explain the gap and how it was closed.
6. Declare deficiencies and their resolution. If the overseas regulator raised cybersecurity deficiencies, include the deficiency letter and your response. Omitting them and having the TGA find them later is materially worse than disclosing them.
7. Bridge the postmarket plan. The overseas plan usually maps to the overseas reporting regime. Add an Australian annex covering URPTG obligations, TGA adverse event reporting timelines, and the Australian sponsor contact who owns vulnerability disclosure intake.
8. Keep the file current. If the overseas approval is amended, supplemented, or subject to a safety action after you lodge, update the Australian application. Reliance on a superseded decision is a live compliance risk, not just an administrative one.

A Worked Example

A Class IIb connected infusion pump cleared by the FDA under a 510(k) in 2026 would cite the 510(k) number and decision date, attach the cybersecurity documentation submitted with that 510(k) (threat model, SBOM with VEX, architecture views, penetration testing report, postmarket cybersecurity management plan), add a statement confirming the Australian device is the same model at the same software version from the same manufacturing site, and provide a crosswalk table mapping each artifact to EP 12 and EP 12A. The postmarket cybersecurity management plan would carry an Australian annex for URPTG and TGA reporting. That package is normally enough for the TGA to rely on the FDA assessment rather than re-reviewing the technical file from scratch.

Mapping an FDA Section 524B Package to ARTG Content

What Maps Directly

The threat model, SBOM with VEX, security architecture views, verification and penetration testing evidence, and postmarket cybersecurity management plan from a Section 524B package map directly into the TGA's six expectations. Sponsors should bundle the evidence with an explicit EP 12 and EP 12A mapping document so reviewers can trace each expectation to a piece of evidence.

What Needs Adaptation

The Australian labeling content must satisfy local language and regulatory requirements. The postmarket plan must reference Uniform Recall Procedure for Therapeutic Goods (URPTG) obligations and the TGA's adverse event reporting expectations, not the FDA's 21 CFR Part 803 pathway alone. The Declaration of Conformity must be Australian-specific.

Postmarket Obligations and Recall Reporting

URPTG and Hazard Alerts

The Uniform Recall Procedure for Therapeutic Goods governs how sponsors handle product recalls, hazard alerts, and safety advisories in Australia. Cybersecurity incidents that meet the threshold for a hazard alert or recall trigger URPTG obligations, including notifications to the TGA and to healthcare providers.

Adverse Event Reporting

Sponsors must report serious adverse events and near-incidents to the TGA. Cybersecurity incidents that result in or could result in serious injury, illness, or death are reportable. The IR plan and CVD policy referenced in the application package should make the Australian reporting pathway explicit.

Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.

How Blue Goat Approaches TGA Submissions

We treat TGA submissions as an Essential Principles mapping exercise for sponsors who already have an FDA Section 524B package. The technical content set carries over largely intact; the work is in the Declaration of Conformity, the EP 12/12A mapping, the Australian-specific labeling, and the postmarket plan adaptation for URPTG and TGA adverse event reporting. Our team holds CISSP, OSCP, and prior military red-team credentials, and our submission work is grounded in IEC 81001-5-1, AAMI TIR57 / ANSI/AAMI SW96:2023, ISO 14971, IMDRF N60, and the FDA February 3, 2026 final premarket cybersecurity guidance. If the regulator raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our international medical device cybersecurity services or compare regimes on the EU MDR vs FDA cybersecurity guide.

FAQ

Does the TGA require an SBOM?

Yes. The TGA's medical device cybersecurity guidance lists an SBOM as one of the six pre-market expectations. CycloneDX and SPDX are the common formats, consistent with FDA and Health Canada practice. The SBOM must be current at the time of application.

Can the TGA accept an FDA Section 524B submission as-is?

The technical content is largely accepted, but the sponsor still must produce an Australian Declaration of Conformity, an Essential Principles 12 and 12A mapping, and labeling and postmarket content that fit Australian requirements. The TGA does not waive the EP mapping based on FDA clearance alone.

What is Essential Principle 12A?

EP 12A is the Australian Essential Principle that explicitly covers programmable medical devices. It requires that programmable medical devices perform with repeatability, reliability, and consistency appropriate for the intended use. Cybersecurity evidence supports EP 12A by demonstrating that security controls do not undermine that performance.

How does TGA classification differ from FDA classification?

The TGA uses an EU-aligned classification system (I, IIa, IIb, III, AIMD), while the FDA uses three classes (I, II, III) under 21 CFR Part 860. The classification rules are different, and a device that is FDA Class II may be TGA Class IIa, IIb, or III depending on the rules that apply.

What postmarket reporting applies to cybersecurity incidents?

Sponsors must report serious adverse events and near-incidents to the TGA, and incidents that meet the threshold for a hazard alert or recall trigger URPTG obligations. The postmarket cybersecurity plan should describe the decision criteria, the timeline, and the owner for each pathway.

Ready to bring your device to the Australian market?

If you have an FDA-cleared device and need a TGA ARTG inclusion with cybersecurity content that maps cleanly to Essential Principles 12 and 12A, we can help. If the regulator raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.

---

Christian Espinosa, Founder, Blue Goat Cyber, CISSP, OSCP. Christian has led international medical device cybersecurity programs across FDA, EU MDR, and APAC pathways and previously commanded military red-team operations. Read more at christian-espinosa.