Test whether a product is a covered consumer-grade relevant connectable product, verify the three smart-device security-standard controls, prepare the statement of compliance, and retain evidence for the required record period.
Product, security, legal, compliance, and supply-chain teams should validate each decision against jurisdiction-specific legal, contractual, and policy requirements before implementation.
Start by deciding whether the item is a . The Cyber Security (Security Standards for Smart Devices) Rules 2025 then apply the Cyber Security Act 2024 smart-device regime to -grade products that will be acquired in Australia by a consumer, unless an exclusion applies. Part 1 of the Rules commenced on 4 March 2025; Part 2 and Schedule 1 commenced on 4 March 2026. After scope, test passwords, security-issue reporting, security-update support-period publication, statement contents, retention, and enforcement evidence.
1
Section 1
1. Confirm the product is in smart-device scope
Start every checklist record with the product facts that decide whether the Security Standards for Smart Devices Rules 2025 apply. The Rules cover relevant connectable products that are intended by the for personal, domestic or household use or consumption, or are of a kind likely to be used that way, when the products will be acquired in Australia by a .
The Australian Law test can include a business acquisition. The current monetary limb covers goods priced at no more than $100,000, and goods ordinarily acquired for personal, domestic, or household use can qualify regardless of price. Specified acquisitions for resupply or for use up or transformation in production, manufacture, repair, or treatment are excluded.
Record any exclusion before testing controls. The Rules exclude desktop computers and laptops, tablet computers, smartphones, therapeutic goods, road vehicles, and road vehicle components from the -grade standard.
Record the product type, model, batch or stock-keeping-unit identifier, , , Australian acquisition channel, and intended personal, domestic or household use.
Apply the Act's connectivity test: confirm that the product is internet-connectable or meets the more specific network-connectable product conditions, rather than treating any indirect connection as enough.
For second-hand supply, record the manufacture date before closing the scope review. The Act excludes second-hand goods only from the paragraph 13(1)(b) supply trigger; a product manufactured on or after 29 November 2025 can still meet paragraph 13(1)(a).
Document the -acquisition basis under the Rules rather than assuming that every connected business or industrial device is covered.
If relying on section 15's constitutional exception for a requirement outside internet or like-service connection, use, or protection, record why the entity is neither a constitutional corporation nor acting in interstate, Territory, or international trade or commerce.
If relying on an exclusion, keep the exclusion category, supporting product evidence, reviewer, and approval date with the checklist record.
2. Check the three mandatory smart-device security controls
For in-scope products, test the product against the three Schedule 1 control areas. The checklist should produce evidence that passwords, security-issue reporting, and security-update support-period publication have been reviewed for the product hardware and relevant software.
The check should cover passwords used with the product hardware, pre-installed software, and software that must be installed for the 's intended purposes. Passwords must be unique per product or defined by the user, and unique-per-product passwords must not be based on incremental counters, public information, serial numbers unless protected by accepted encryption or keyed hashing, or otherwise guessable in a way unacceptable as .
evidence: description, account and setup flows, password-generation method, uniqueness evidence, and reviewer confirmation that no prohibited derivation method is used. Record separately any cryptographic key, pairing personal identification number used outside the internet protocol suite, or application programming interface key because the Rules exclude those from the definition of password.
Security-issue reporting evidence: public point of contact, acknowledgement timing, status-update timing, and proof the information is accessible, clear, transparent, in English, free of charge, available without prior request, and available without requesting personal information.
Security-update evidence: the expressed as a period with an end date, the affected update-capable hardware and software, and the place where the support period is published.
Support-period publication evidence: proof the information is accessible, clear, transparent, in English, free of charge, available without prior request or a request for personal information, and understandable without prior technical knowledge.
Website evidence: when the offers the product on a website it controls, retain screenshots or page exports showing the support-period information with acquisition information and with equal prominence where main product characteristics appear.
The must be prepared by, or on behalf of, the . It is a statutory regulatory record. The official explanatory statement says it need not be physically provided at the point of sale, although an entity may provide or publish it.
The Act still requires the to supply the product with the statement. Neither the Act nor the Rules prescribe a delivery medium, so record the channel-specific method used to connect the statement to the supplied product instead of treating public publication alone as conclusive.
The statement should be checked against each required field before supply: product type and batch identifier, name and address, the name and address of an , each other authorised representative in Australia if any, manufacturer declaration, compliance declaration, at issue date, signatory signature, signatory name and function, place of issue, and date of issue.
Retain the for five years, because the Rules set a five-year retention period for statements under the -grade standard.
Keep the statement with the product-scope assessment, Schedule 1 control evidence, source URLs, reviewer approval, handoff record, and any exception note.
When a product or batch changes, re-check whether the existing statement still matches the product type, batch identifier, support period, software state, and declaration.
If using a statement prepared for another comparable market, verify every field required by the Australian Rules is still present.
4. Add enforcement and recall evidence before release
A release-ready checklist should make it easy to respond if the or Minister uses the Act's compliance, stop, recall, publication, or examination powers. Keep evidence in a form that can show both product compliance and statement-of-compliance accuracy.
For recall readiness, the Rules allow publication of recall-notice details and actions if an entity fails to comply with a recall notice. Product, support, and communications teams should therefore keep a current consumer-action draft for each covered product family.
Assign one product owner for technical remediation, one compliance owner for statement records, one security owner for vulnerability-reporting intake, and one communications owner for -facing recall language.
Keep an audit packet containing product samples or access instructions, statement copies, support-period publication evidence, vulnerability-reporting page evidence, and -control test results.
Escalate before launch if the product scope is uncertain, the lacks an end date, security-issue reporting is not publicly accessible, or the statement does not match the current product batch.
Review the checklist after firmware changes, companion-app changes, support-period extensions, changes, Australian channel changes, vulnerability-process changes, or regulator notices.
Current official explanation of the Australian Consumer Law acquisition test, including business purchases, the $100,000 threshold, and acquisition exclusions.