Australian government guidance recommends secure-by-design practices for IoT manufacturers, drawing on AS ETSI EN 303 645. Topics include passwords, vulnerabi
Official source publication date: . AndroidSBC review date: 2026-10-26.
What does Australian government secure-by-design guidance cover?
Guidance from the Australian Signals Directorate and Australian Cyber Security Centre helps IoT manufacturers apply secure-by-design principles drawn from AS ETSI EN 303 645.
Key points from the official publication
- The guidance addresses weak or duplicated default passwords and recommends secure setup behavior.
- It calls for a vulnerability disclosure policy and a process for receiving and acting on security reports.
- It covers secure software updates, protection of credentials and personal data, and reduced exposed attack surfaces.
- Additional principles cover communication security, software integrity, resilience to outages, telemetry, deletion of personal data, maintainability and input validation.
- The official guidance focuses on devices; related back-end services require their own security controls and assessment.
Practical actions for an Android product project
- Create a threat model for the finished product, its cloud service and its maintenance interfaces.
- Use unique provisioning, protected keys and authenticated update packages with recovery behavior.
- Minimize network services and document data collection, retention and deletion.
- Verify the final enclosure, communications modules and production firmware rather than relying on a development-board configuration.
What does this mean for Android board and embedded-device projects?
Translate these principles into product requirements: unique provisioning, signed and recoverable updates, protected secrets, minimal exposed services, encrypted communications, logging, resilience and documented support. Verify the final product against its intended Australian use and applicable requirements.
What should buyers and engineering teams verify?
- The exact board, PCB revision, SoC, BSP branch, kernel and Android build.
- The finished product’s intended use, wireless modules, enclosure and destination market.
- Security-update ownership, vulnerability contact, support period and incident process.
- Which controlled report, declaration or certificate applies to the exact configuration.
This article is an engineering summary, not legal or conformity-assessment advice. Requirements can change; confirm the current official text and obtain qualified local advice for the finished product.
Buyer FAQ
Common procurement and engineering questions related to this update are answered below. Project decisions must use the current official requirements and the exact product configuration.
What secure-by-design items should be included in an Android board RFQ?
Include unique provisioning, protected credentials, signed updates and rollback, service minimization, encrypted communications, logging, data handling, vulnerability reporting, support period and recovery requirements.
Is compliance with secure-by-design guidance the same as product certification?
No. Guidance supports engineering risk reduction but does not by itself prove certification, regulatory conformity or suitability for a specific finished product.
Should the cloud service be reviewed separately from the Android device?
Yes. Device security, mobile or web applications, update infrastructure, APIs and cloud services have different attack surfaces and should receive coordinated but distinct assessments.
Official primary source
Primary source
Australian Signals Directorate / Australian Cyber Security Centre
Read the original official publication
Source URL: https://www.cyber.gov.au/publication/iot-secure-by-design-guidance-for-manufacturers
Editorial note: This is an original AndroidSBC engineering summary of the cited official publication. It is not legal advice and does not claim that every Android board or finished device is certified for the named market.
