A consumer IoT product is more than a device. Firmware, mobile applications, cloud services, APIs, update infrastructure, suppliers, and support operations all create security responsibilities. This article explains how ETSI EN 303 645 requirements can be turned into accountable product work: defined decisions, named owners, and reviewable evidence across the connected system.
ETSI EN 303 645 provides a cybersecurity baseline. Certification, legal compliance, and conformity conclusions depend on the applicable jurisdiction, product context, and assessment arrangement. [1]
This is a conceptual, product-team-oriented explainer rather than a complete implementation or certification guide.
What ETSI EN 303 645 Covers—and What It Does Not
ETSI EN 303 645 defines outcome-oriented cybersecurity provisions for consumer IoT products. It does not prescribe one software stack, cloud architecture, or programming language. A smart camera, doorbell, thermostat, or smart lock may apply the provisions differently according to its hardware, data flows, suppliers, and support model. [1]
Treat these documents as complementary inputs, not interchangeable evidence: ETSI EN 303 645 sets the baseline, ETSI TS 103 701 supports conformity assessment, ETSI TR 103 621 provides implementation guidance, ENISA’s IoT tool supports threat planning, and the UK Code of Practice offers additional consumer IoT guidance. [1][2][3][4][5]
ETSI EN 303 645 requirements: Turning Provisions into Product Work
Make ETSI EN 303 645 requirements actionable by translating each provision into a workstream with a decision, an owner, and a record. The groupings below support planning; the normative source remains the standard itself. [1]
Identity, Access, and Vulnerability Handling
The first workstream concerns who can access the product, how credentials are managed, and what happens when a vulnerability is discovered.
The baseline addresses the use of universal default passwords. Make an explicit decision about initial authentication, credential uniqueness, password changes, recovery, privileged access, and device provisioning. A product requirement might state that each device receives a unique credential during manufacturing or onboarding, with administrative access separated from ordinary user access.
Vulnerability handling also needs an owner and a process. A vulnerability disclosure process should define how reports are received, triaged, prioritized, remediated, and communicated. Publishing an email address is only a starting point. The process should identify who evaluates severity, approves a fix, identifies affected customers, and records disclosure decisions.
A connected doorbell supplier may need coordination between firmware engineers, a cloud operations team, customer support, and a communications owner. Without that ownership model, a technically correct patch can still be delayed by unclear responsibilities.
Updates, Integrity, and Communications
The release owner should define secure software updates as part of the product lifecycle, not as a post-launch task. Record how update packages are authenticated, how delivery is protected, how failures are handled, and how long support is expected to continue. The implementation may vary, but the decision and its assumptions belong in the product record. [1][3]
Software integrity is closely related. A design review can examine whether firmware, applications, configuration files, and update mechanisms can be modified without authorization. It might cover signing keys, build pipelines, release approvals, and the handling of compromised or rejected packages.
Secure communications apply across the entire system. The map should cover device-to-cloud traffic, mobile-to-cloud communication, local interfaces, administrative channels, and integrations with external services. Map where sensitive information travels and identify the protections expected at each boundary.
Reducing exposed attack surfaces is another planning task. For a connected appliance, the release review might disable unused network services, limit administrative interfaces, remove unnecessary debug endpoints, and check open ports before release.
Data, Resilience, and Lifecycle Operations
Personal-data protection belongs in the cybersecurity workstream, not in a separate paperwork exercise. The product owner should record what data is collected, why it is needed, where it is stored, who can access it, and when it is deleted. A voice-enabled device, for instance, may create different privacy responsibilities from a temperature sensor even when both use the same cloud platform.
The provisions also address resilience, telemetry, user-data deletion, installation and maintenance, and input validation. [1] Assign a security or product owner to review these areas using the following checks:
Can the product remain safe when the network or cloud service is unavailable? Which diagnostic data is collected, and is it necessary? Can users delete data without contacting support? Are installation and maintenance instructions understandable? Are inputs validated before they reach device, application, or backend logic?
Consider a smart thermostat that loses internet connectivity. A resilience review should establish what happens locally, which functions continue, and whether a cloud outage creates unsafe or confusing behavior. A telemetry review should distinguish operational data needed for support from data collected merely because it is available.
Input validation deserves attention across APIs, mobile applications, device interfaces, and administrative tools. A product team does not need to publish its entire defensive coding strategy in a standards summary, but it should be able to explain where validation occurs and how invalid or unexpected data is handled.
How ETSI TS 103 701 Supports Assessment Preparation
ETSI TS 103 701 complements the baseline with a conformance-assessment framework covering assessment roles, evidence, procedures, verdicts, and test scenarios. [2]
Two terms are particularly useful for product teams:
- Implementation Conformance Statement (ICS): A structured statement about which provisions apply and how the product addresses them.
- Implementation eXtra Information for Testing (IXIT): Additional information that helps an assessor understand the implementation and carry out relevant tests.
The evidence register supports both documents: it records the decisions and artifacts that inform the ICS, while the IXIT gathers the implementation detail an assessor may need to interpret those artifacts and plan relevant tests.
The specification also includes conceptual and functional assessment scenarios, including testing related to the default-password provision. [2] This workflow organizes readiness evidence but does not define or reproduce a formal conformity assessment.
The ICS and IXIT should reflect the product scope, available evidence, and assessment method selected for the engagement; they are assessment inputs, not substitutes for the baseline provisions.
Use Guidance and Checklists Without Confusing Their Roles
ETSI TR 103 621 provides interpretive guidance that can help engineers discuss provisions in terms of architecture, development, operations, and support. Keep that guidance distinct from the normative baseline. [3]
ENISA’s online IoT security tool offers a planning aid. A security lead can use it to explore threats, security domains, standards, and security measures, then transfer relevant findings into the product’s threat-and-control map. [4]
The UK Code of Practice for Consumer IoT Security provides complementary guidance through 13 consumer IoT security guidelines. Its plain-language treatment of passwords, vulnerability disclosure, updates, and related practices can inform product reviews, while ETSI EN 303 645 remains the baseline used in this guide. [5]
A Focused Readiness Workflow
Use this five-step readiness method for each release:
- Define the product boundary: list the device, firmware, applications, cloud services, APIs, suppliers, and support paths that can affect security.
- Map the applicable provisions: record which ETSI EN 303 645 provisions apply, the reason for each decision, and any scope exclusions.
- Assign owners and evidence: name an owner for every provision and link the decision to design records, tests, threat analysis, update records, or operational evidence.
- Review gaps and actions: rank missing evidence or control weaknesses, assign a due date, and record the release action if a gap remains open.
- Revisit after change: repeat the mapping when firmware, cloud services, suppliers, interfaces, or threat assumptions change.
Prioritize provisions affecting exposed interfaces, credentials, update paths, personal data, safety-relevant behavior, or unsupported lifecycle states. Keep gaps explicit and link each decision to an artifact, review date, and responsible team. Use the resulting register to organize release decisions and assessment inputs.
If a thermostat adds a remote firmware-update feature, the evidence register can assign the update owner, link the approval and rollback records, and state whether the feature is ready for release or requires further review. Tools can organize vulnerability intake, releases, approvals, and audit records; the product team remains responsible for deciding whether the evidence is sufficient for the release.
How Donusoft Can Support Connected-System Security Work
Possible Donusoft delivery activities include mapping device, firmware, cloud, web, and mobile boundaries; integrating vulnerability intake with release workflows; and organizing reviewable records for update approvals, triage decisions, and evidence registers. These activities document product decisions and coordinate owners; they do not establish conformity or certification.
Conclusion: Make the Baseline Part of Product Delivery
ETSI EN 303 645 requirements are most useful when treated as accountable product work rather than as a document to read once before launch. Each provision should connect to an owner, a design decision, an operational process, and evidence that can be maintained over time.
ETSI TS 103 701 adds an assessment perspective, and ETSI TR 103 621 provides implementation guidance. ENISA’s tool and the UK Code of Practice offer complementary planning prompts. Together, they can inform a provision map, threat-and-control records, and assessment-oriented evidence without replacing the baseline or one another.
Possible Donusoft support includes connecting ETSI-oriented requirements with device and cloud architecture work, vulnerability triage, release coordination, and records that track security decisions across the product lifecycle.
Frequently Asked Questions
What is ETSI EN 303 645?
In this article, ETSI EN 303 645 is the baseline used to organize consumer-IoT security decisions and evidence. [1]
What are the main ETSI EN 303 645 requirements?
The 13 provisions in sections 5.1–5.13 address topics including no universal default passwords, vulnerability disclosure, secure updates, protection of security-sensitive information, secure communications, reduced attack surfaces, software integrity, personal-data protection, resilience, telemetry, user-data deletion, understandable maintenance, and input validation. Verify this provision mapping against the cited edition of ETSI EN 303 645 before publication. [1]
Is ETSI EN 303 645 mandatory?
There is no universal answer. Whether it is required or relevant depends on the jurisdiction, product type, market, applicable regulation, contractual obligations, and customer expectations. The responsible team should obtain appropriate legal and regulatory advice for its specific situation.
What is the difference between ETSI EN 303 645 and ETSI TS 103 701?
ETSI EN 303 645 supplies the baseline provisions. ETSI TS 103 701 supplies an assessment framework, including roles, procedures, evidence, ICS, IXIT, verdicts, and test scenarios. Use the two documents together when preparing evidence, but do not treat the assessment framework as a substitute for the baseline. [1][2]
Does following ETSI EN 303 645 guarantee certification or compliance?
No. Those conclusions depend on the applicable assessment, regulatory, contractual, and jurisdictional context.
How should a product team prepare IoT security evidence?
Start by defining product scope, mapping applicable provisions, assigning owners, documenting design decisions, collecting testing and lifecycle records, and maintaining the evidence as the product changes. An evidence register is more effective when created during development rather than assembled at the end.
Sources
- [1] ETSI EN 303 645 V3.1.3: Cyber Security for Consumer Internet of Things — Baseline Requirements
- [2] ETSI TS 103 701 V2.1.1: Conformance Assessment of Baseline Requirements
- [3] ETSI TR 103 621 V2.1.1: Guide to Cyber Security for Consumer Internet of Things
- [4] Your Must Have IoT Security Checklist: ENISA’s Online Tool
- [5] Code of Practice for Consumer IoT Security
;)
