Australia's Smart Device Security Standard: What Manufacturers Must Publish Since 4 March 2026

Since 4 March 2026, consumer smart devices made for the Australian market have had to meet a mandatory security standard. The rules are short. Passwords can't be shared defaults, manufacturers must publish how to report security problems, and they must publish, with an end date, how long the device will get security updates. The support-period rule is the one most product teams underestimate, because it reaches the product page, the companion app and the marketing copy.

This post is for manufacturers, importers and product security teams that ship connected consumer devices into Australia. It covers what the Cyber Security Act 2024 and its smart device rules require, what is out of scope, how the government reads the trickier points, how enforcement works, how it lines up with the UK and EU rules you may already follow, and a script that checks your own product pages for the two publishing duties.

The short answer

The Cyber Security (Security Standards for Smart Devices) Rules 2025 apply to consumer smart devices manufactured on or after 4 March 2026. There are three requirements: no universal default passwords, a published way to report security issues with stated acknowledgement and update times, and a published defined support period with an end date. Every device must also be supplied with a statement of compliance, which manufacturers and suppliers keep for five years. Laptops, desktops, tablets, smartphones, therapeutic goods and road vehicles are excluded. Enforcement runs through compliance, stop and recall notices from the Department of Home Affairs, with public naming if a recall notice is ignored.

What counts as a smart device

The Act calls these relevant connectable products (section 13). That covers products that connect to the internet over IP, and also network-connectable products: devices that link directly to an internet-connected product over IP, or over a non-IP protocol such as Bluetooth or Zigbee where the device can talk to two or more products at once. Cables don't count. Wireless keyboards and mice that connect to a computer through a wireless linking product are covered by a specific provision.

The Rules then narrow it to the consumer class (section 8): products intended, or likely, to be used "for personal, domestic or household use or consumption" and acquired by a consumer under the Australian Consumer Law. The exclusions are:

• desktop and laptop computers,
• tablets,
• smartphones,
• therapeutic goods,
• road vehicles and road vehicle components.

The explanatory statement says computers, tablets and phones were left out because of their complex component supply chains. It also notes that, apart from smartphones, they're excluded from similar UK rules too.

Two readings from the Home Affairs FAQ, updated on 4 March 2026, matter for scoping:

• Classes, not sales. The standard applies to whole classes of product. If a device could be bought by a consumer for household use, every unit must comply, including those sold to businesses. A product is out of scope only if there is no circumstance in which a consumer would acquire it.
• Aftermarket car gear is probably in. Aftermarket audio and navigation units aren't road vehicle components unless an Australian Design Rule applies to them, so the vehicle exclusion doesn't cover them.

The three requirements

1. Passwords (Schedule 1, clause 2)

Where a device uses passwords for its hardware, its pre-installed software, or software the user has to install to use it, those passwords must be unique per product or set by the user. Unique passwords must not be:

• based on incremental counters (the rules give "password1" and "password2" as the example),
• based on or derived from publicly available information,
• derived from identifiers such as serial numbers, unless that is done with encryption or a keyed hash accepted as good industry practice,
• or otherwise guessable.

The FAQ adds two clarifications. The standard doesn't force a device to have passwords at all. And a default password is allowed only while the device is in its factory default state.

2. Reporting security issues (clause 3)

The manufacturer must publish at least one point of contact for reporting security issues, and when a reporter will receive an acknowledgement and status updates until the issue is resolved. This covers the device's hardware and pre-installed software, any software that has to be installed, and software used in connection with the product, such as a companion app or cloud service. The information has to be in English, free, available without anyone asking for it, and must not require the reporter to hand over personal information. The FAQ says a manufacturer may ask for a contact address such as an email so it can send the acknowledgement, but can't make personal information a condition of reporting.

3. The defined support period (clause 4)

The manufacturer must publish how long security updates will be provided, as "a period of time with an end date". The FAQ is explicit that "in five years" isn't enough. Its compliant examples include "no earlier than 30 June 2027" and "ending on 30 June 2029". The period:

• must be published for the hardware, the pre-installed software and any required or manufacturer-developed software, so the device firmware and its first-party app each need one,
• can be extended, and an extension must be published as soon as practicable, but it can never be shortened,
• must be understandable "by a reader without prior technical knowledge".

If the manufacturer sells the device on its own website, the support period must appear prominently with the other purchase information and alongside the product's main characteristics, on every page where those characteristics appear. The FAQ's example covers a comparison page, a product page and a checkout page, and all three need it. It also warns that putting the date only in the statement of compliance or a regulatory section of the site isn't enough.

The statement of compliance

Suppliers must ship each device with a statement of compliance prepared by or for the manufacturer (Act section 16, Rules section 9). It must include:

• the product type and batch identifier,
• the names and addresses of the manufacturer, an authorised representative, and any authorised representatives in Australia,
• declarations that it was prepared by or for the manufacturer and that, in the manufacturer's opinion, the product complies,
• the defined support period at the date of issue,
• the signatory's signature, name and function,
• and the place and date of issue.

Both the manufacturer and the supplier must keep a copy for five years (Rules section 10). On batch identifiers, the FAQ gives manufacturers flexibility, including wildcards, as long as it's clear which group of products a statement covers. On the UK, it says a statement prepared under the UK's product security rules can be reused in Australia if it also meets every Australian requirement.

How enforcement works

Part 2 enforcement escalates in steps (Act sections 17 to 20):

1. Compliance notice, after the entity gets at least 10 days to respond, setting out what to fix and by when.
2. Stop notice, if the compliance notice isn't followed or the fix is inadequate.
3. Recall notice, if the stop notice isn't followed: stop the product reaching Australian buyers and arrange returns.
4. Public naming. If a recall notice is ignored, the Minister can publish the entity, the product, the non-compliance and its risks. The Rules allow the notice to include recommended consumer actions, up to destroying the product.

Each notice can be internally reviewed if the request is made within 30 days. The Secretary can also have products independently audited and request statements of compliance. Sections 15 and 16 can be the subject of enforceable undertakings (section 79). The Act doesn't list them among its civil penalty provisions. The FAQ describes the regulator's approach as "education-first".

Australia, the UK and the EU side by side

If you already comply with the UK rules, the Australian work is mostly a second check. Confirm that your support period is written as an end date in plain language and appears on every Australian-facing product page. Then add the Australian-specific fields to your statement of compliance.

Check your own product pages

The two publishing duties are the easiest to get wrong and the easiest to check. This script reads a product page, from a URL or a saved file, and looks for a support-period statement that has an actual end date. It flags relative wording like "five years of updates", and looks for a vulnerability reporting route, either on the page or in the site's security.txt, along with stated acknowledgement and update times. It's a pattern-matching aid for your own pages, not a compliance ruling.

#!/usr/bin/env python3
"""Self-check a product page against the two publishing duties in Australia's smart
device standard (Cyber Security (Security Standards for Smart Devices) Rules 2025,
Schedule 1 clauses 3 and 4): a defined support period with an END DATE, and a
published way to report security issues with acknowledgement and status updates.
A heuristic aid for your own pages, not a compliance determination.
Usage: python3 au_device_page_check.py <product-page URL or .html file> [...]"""
import html, re, sys, urllib.request
from urllib.parse import urlparse

MONTHS = "January|February|March|April|May|June|July|August|September|October|November|December"
DATE = rf"(\d{{1,2}} ({MONTHS}) \d{{4}}|({MONTHS}) \d{{1,2}},? \d{{4}}|\d{{4}}-\d{{2}}-\d{{2}})"
SUPPORT = re.compile(rf"security updates?[^.]{{0,80}}?(until|through|to|ending on|no earlier than)[^.]{{0,30}}?{DATE}", re.I)
RELATIVE = re.compile(r"security updates?[^.]{0,80}?(for|of) (\d+|one|two|three|five|ten) (years?|months?)"
                      r"|(\d+|one|two|three|five|ten)[- ](years?|months?) of (security )?updates|lifetime (security )?updates", re.I)
REPORT = re.compile(r"(report (a |any )?(security|vulnerabilit)|vulnerability disclosure|security\.txt|psirt)", re.I)
ACK = re.compile(r"acknowledg", re.I)
STATUS = re.compile(r"(status updates?|keep you (updated|informed)|progress updates?)", re.I)

def text_of(src):
    if src.startswith("http"):
        req = urllib.request.Request(src, headers={"User-Agent": "au-device-page-check"})
        raw = urllib.request.urlopen(req, timeout=20).read().decode("utf-8", "ignore")
    else:
        raw = open(src, encoding="utf-8").read()
    raw = re.sub(r"<(script|style)[\s\S]*?</\1>", " ", raw)
    return re.sub(r"\s+", " ", html.unescape(re.sub(r"<[^>]+>", " ", raw)))

def security_txt(src):
    if not src.startswith("http"):
        return None
    url = f"https://{urlparse(src).netloc}/.well-known/security.txt"
    try:
        body = urllib.request.urlopen(urllib.request.Request(url, headers={"User-Agent": "x"}), timeout=10).read().decode()
        return [l for l in body.splitlines() if l.lower().startswith("contact:")]
    except Exception:
        return []

for src in sys.argv[1:]:
    t, issues = text_of(src), []
    print(f"\n{src}")
    m = SUPPORT.search(t)
    if m:
        print(f"  support period with end date: \"{m.group(0)[:110]}\"")
    elif RELATIVE.search(t):
        issues.append(f"support period is relative, not an end date: \"{RELATIVE.search(t).group(0)}\" (clause 4(3))")
    else:
        issues.append("no defined support period found on this page (clause 4(1), and 4(7) for pages that sell the product)")
    contacts = security_txt(src)
    if REPORT.search(t) or contacts:
        print(f"  reporting route: {'security.txt ' + str(contacts) if contacts else 'mentioned on page'}")
        if not (ACK.search(t) and STATUS.search(t)):
            issues.append("no statement of when reporters get an acknowledgement and status updates (clause 3(2)(b))")
    else:
        issues.append("no way to report security issues found (clause 3(2)(a))")
    for i in issues:
        print(f"  [!] {i}")
    if not issues:
        print("  no gaps found by these checks")

We ran it against three test pages: one compliant, one that promises "5 years of security updates", and one with neither duty met.

$ python3 au_device_page_check.py fx/good.html fx/relative.html fx/missing.html
fx/good.html
  support period with end date: "security updates until at least 30 June 2029"
  reporting route: mentioned on page
  no gaps found by these checks

fx/relative.html
  reporting route: mentioned on page
  [!] support period is relative, not an end date: "5 years of security updates" (clause 4(3))
  [!] no statement of when reporters get an acknowledgement and status updates (clause 3(2)(b))

fx/missing.html
  [!] no defined support period found on this page (clause 4(1), and 4(7) for pages that sell the product)
  [!] no way to report security issues found (clause 3(2)(a))

Run it across every Australian product, comparison and checkout page. Clause 4(7) applies to each place the main characteristics appear, not just the main product page.

What to do now

1. List which devices are in scope, using the class test. If a consumer could buy it, treat it as in scope, even if you mostly sell to businesses.
2. Fix password handling at manufacture. Unique per device or user-set, and not derived from serial numbers unless through a keyed function.
3. Publish a reporting route with timelines. "We acknowledge reports within five business days and send status updates until resolution" meets the shape of clause 3. A security.txt file and a disclosure policy page are a natural home for it.
4. Choose support end dates you can keep. You can extend them but never shorten them, so set dates engineering will stand behind for firmware and the app.
5. Update product pages and statements of compliance, and set up five-year retention for both manufacturer and supplier copies.

The fair view

The standard is deliberately minimal. Three requirements won't make a device secure, and the support-period rule doesn't require any particular length of support. It only requires being honest about it. That's still worth something. A published end date lets buyers compare, gives retailers something to check, and turns "how long will you patch this?" from a support-forum argument into a fact on the product page. It also lines up closely with the UK's rules and points the same way as the EU's, so a team that builds this once can reuse most of it across all three markets. For how the UK rules have worked in their first year, see our PSTI review.