TGA Publishes Updated Guidance on the Regulation of Software-Based Medical Devices – Key Considerations for Manufacturers

On 24 February 2026, the Australian Therapeutic Goods Administration (TGA) published updated guidance titled “Understanding how we regulate software-based medical devices.”

The guidance explains how software, including artificial intelligence (AI), is regulated under the Therapeutic Goods Act 1989 and the Therapeutic Goods (Medical Devices) Regulations 2002.

Although the document does not introduce new legislation, it provides detailed clarification on regulatory obligations that directly affect manufacturers of software-based medical devices supplied in Australia.

Manufacturers Are Responsible for Determining Device Status

The TGA clearly states that it is the manufacturer’s responsibility to determine whether their product meets the definition of a medical device.

Importantly, software developers may meet the legal definition of a manufacturer even if development activities are outsourced or based on pre-existing software platforms. Where a developer alters the intended purpose of a general platform, they may assume manufacturer responsibilities under the Act.

For manufacturers, this reinforces the need for:

  • Clear determination of regulatory status

  • Defined intended purpose

  • Documented regulatory assessment

Intended Purpose Determines Regulatory Classification

The guidance reiterates that regulation is based on the manufacturer’s intended purpose, as documented in:

  • Instructions for use

  • Labelling

  • Advertising materials

  • Technical documentation

  • Website information

Even where two software products appear technically similar, differences in intended purpose may result in different regulatory outcomes.

The intended purpose determines:

  • Whether the product is a medical device

  • Device classification

  • Applicable conformity assessment procedures

  • Requirement for ARTG inclusion

Software Updates May Trigger Regulatory Consequences

The TGA highlights that software updates can affect regulatory status.

If new functionality is introduced — such as diagnostic support, treatment recommendations, or clinical monitoring — the software may:

  • Newly meet the definition of a medical device; or

  • Change classification due to altered risk profile; or

  • Trigger additional regulatory obligations, including ARTG inclusion.

Manufacturers must assess the regulatory impact of updates and ensure continued compliance with the Therapeutic Goods Act 1989 and associated regulations.

Broad Definition of “Supply” in Australia

Under the Act, “supply” includes making software available in Australia via:

  • App stores

  • Cloud platforms

  • Websites

This applies whether software is downloaded or accessed remotely, and whether it is free or paid.

Even if hosted overseas, software that is accessible or intended for use in Australia is subject to regulation if it meets the definition of a medical device.

For manufacturers operating internationally, this is a critical consideration.

Classification of Software-Based Medical Devices

All software-based medical devices are considered active medical devices for classification purposes.

Australia applies a four-tier classification system:

  • Class I

  • Class IIa

  • Class IIb

  • Class III

Higher classification results in increased regulatory scrutiny and more rigorous conformity assessment requirements.

The classification rules for programmed, programmable and software-based medical devices are set out in Schedule 2 of the Regulations.

Conformity Assessment and Regulatory Evidence

Manufacturers must demonstrate compliance with applicable regulatory requirements through:

  • TGA Conformity Assessment Certification; or

  • Appropriate market authorisation evidence from a comparable overseas regulator.

The level of conformity assessment depends on device classification.

For Class I devices, manufacturer certification and declaration of conformity are required, but direct third-party assessment is generally not required.

Essential Principles – Specific Obligations for Software

Manufacturers must demonstrate compliance with all relevant Essential Principles (Schedule 1 of the Regulations).

The guidance highlights specific software-related requirements:

Essential Principle 12.1

  • Safe operation and system requirements

  • Cybersecurity

  • Data management

  • Design and development controls

  • Version control

  • Risk management

  • Verification and validation

  • Change and configuration management

  • Maintenance and problem resolution

Essential Principle 13.2(3)

  • Electronic provision of information where applicable

Essential Principle 13B

  • Identification of current software version and build number

  • Version information must be accessible and identifiable

  • Information must be in English

Manufacturers must maintain documentation demonstrating compliance throughout the device lifecycle.

Ongoing Post-Market Responsibilities

Following inclusion in the Australian Register of Therapeutic Goods (ARTG), manufacturers and sponsors must continue to meet regulatory obligations, including:

  • Incident reporting via IRIS

  • Cooperation in safety corrective actions

  • Maintenance of technical documentation

  • Compliance with advertising requirements

  • Ensuring ARTG information remains accurate

Regulatory compliance continues throughout the product lifecycle.

Key Takeaways for Manufacturers

The updated TGA guidance reinforces that manufacturers of software-based medical devices must:

  • Clearly define and document intended purpose

  • Assess regulatory implications of software updates

  • Determine classification correctly

  • Maintain conformity assessment evidence

  • Ensure compliance with software-specific Essential Principles

  • Implement robust lifecycle and change management processes

Manufacturers supplying software in Australia should review their regulatory strategy to ensure alignment with the clarified expectations set out by the TGA.

Read the full document below.

Próximo
Próximo

IMDRF Publishes Final Guidance on the Selection of Adverse Event Terminology