---
title: "ETSI EN 303 645 default passwords: what must consumer IoT teams do?"
canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/faq/default-passwords"
source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/faq/default-passwords"
author: "Sorena AI"
description: "ETSI EN 303 645 default password guidance for consumer IoT: unique or user-defined passwords, pre-installed password generation, change mechanisms, brute-force controls, and TS 103 701 evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "ETSI EN 303 645 default passwords"
  - "universal default passwords"
  - "consumer IoT password evidence"
  - "TS 103 701 IXIT"
  - "ETSI EN 303 645"
  - "default passwords"
  - "consumer IoT security"
  - "TS 103 701"
  - "compliance evidence"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# ETSI EN 303 645 default passwords: what must consumer IoT teams do?

ETSI EN 303 645 default password guidance for consumer IoT: unique or user-defined passwords, pre-installed password generation, change mechanisms, brute-force controls, and TS 103 701 evidence.

*Artifact Guide* *GLOBAL* *ETSI EN 303 645*

## ETSI EN 303 645 Default passwords for consumer IoT products

A focused answer on what ETSI EN 303 645 provision 5.1 expects when consumer IoT products use passwords or other authentication values.

Grounded in ETSI EN 303 645 and ETSI TS 103 701. Use it as implementation guidance, not for legal interpretation.

Short answer: ETSI EN 303 645 does not allow universal default passwords to remain in use after factory default. Where passwords are used, provision 5.1 requires passwords outside factory default to be unique per device or defined by the user; if pre-installed unique passwords are used, their generation must reduce automated attacks against a device class or type.

## What does ETSI EN 303 645 require for default passwords?

Provision 5.1-1 applies where passwords are used. In any state other than factory default, each consumer IoT device password must be unique per device or defined by the user. That means a shipped value such as a universal admin password cannot be the operational password after setup.

The standard gives several acceptable patterns: unique pre-installed passwords, requiring the user to choose a password during initialization, or avoiding passwords by using another authentication method. The answer should be scoped to each authentication mechanism, not just to the product as a whole.

- List every password-based authentication mechanism for users and machine-to-machine authentication.
- For each mechanism, state whether the password is user-defined, unique per device, factory-default only, or not used.
- Do not present a product as aligned with provision 5.1 if a universal password remains usable after initialization or reset into an operational state.

Sources for this answer:

- [ETSI EN 303 645 V2.1.1, clause 5.1](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for provision 5.1-1 on unique or user-defined passwords outside factory default.
- [ETSI TS 103 701 V2.1.1, TSO 5.1](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for documenting and testing password-based authentication mechanisms in IXIT 1-AuthMech.

## How should pre-installed unique passwords be handled?

Provision 5.1-2 applies when pre-installed unique per-device passwords are used. The generation mechanism must reduce the risk of automated attacks against a class or type of device, so the evidence has to cover the generation method, not only a sample label or onboarding screenshot.

ETSI gives examples of weak patterns to avoid: incremental counters, common strings, and passwords obviously related to public information such as MAC addresses or Wi-Fi SSIDs. TS 103 701 turns that into conceptual checks on regularities, common patterns, relationship to public information, and appropriate complexity.

- Document the password generation mechanism in IXIT 1-AuthMech, including the authentication mechanism that uses it.
- Show that generated passwords are not based on predictable counters, public identifiers, common strings, or obvious device information.
- Keep functional evidence that sampled device passwords match the documented generation mechanism.

Sources for this answer:

- [ETSI EN 303 645 V2.1.1, provision 5.1-2](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for requirements on pre-installed unique per-device password generation.
- [ETSI TS 103 701 V2.1.1, test group 5.1-2](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for checking obvious regularities, common patterns, public-information links, complexity, and implementation consistency.

## What else belongs in a provision 5.1 password evidence pack?

Default-password work is only one part of clause 5.1. If users can authenticate against the device, the device must provide a simple mechanism for the user or administrator to change the authentication value. If the device is not constrained, it must also have a mechanism that makes brute-force attacks on authentication mechanisms via network interfaces impracticable.

For an assessment, TS 103 701 expects the supplier organization to complete ICS and IXIT information so the test laboratory can derive a test plan. Incomplete IXIT information can lead to an inconclusive test result because the test case cannot be properly executed.

- Include user-facing instructions for changing passwords or other authentication values, and verify the old value stops working after change.
- Document brute-force prevention for network-addressable authentication, such as delays, limited attempts, suspension, lockout, suitable entropy, or two-factor authentication.
- Tie each claim to the assessed device version, user manual, interfaces, onboarding flow, reset behavior, and IXIT entries used by the test plan.

Sources for this answer:

- [ETSI EN 303 645 V2.1.1, provisions 5.1-4 and 5.1-5](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for changing authentication values and making network brute-force attacks impracticable.
- [ETSI TS 103 701 V2.1.1, assessment methodology](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for ICS, IXIT, test-plan derivation, and inconclusive verdicts when required evidence is insufficient.

## Primary sources

- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for no universal default passwords, unique or user-defined passwords, changeable authentication values, and brute-force protection.
  - Quote: "Where passwords are used and in any state other than the factory default"
- [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for TSO 5.1, IXIT 1-AuthMech, conceptual tests, functional tests, ICS, IXIT, external evidence, and verdict handling.
  - Quote: "The IXIT pro forma describes necessary information on the implementation"
- [ETSI Search and Browse Standards](https://www.etsi.org/standards-search?ref=sorena.io) - Use ETSI's public standards search to check current deliverable status before making procurement, audit, or public compliance claims.
  - Quote: "Search and Browse Standards"

## Topic Guides

- [ETSI EN 303 645 Applicability and Scope](/artifacts/global/etsi-en-303-645/applicability-and-scope.md): Decide whether a connected product is in scope of ETSI EN 303 645, define the consumer IoT evidence boundary, and document N/A justifications for assessment.
- [ETSI EN 303 645 compliance: ICS, IXIT, evidence](/artifacts/global/etsi-en-303-645/compliance.md): Plan ETSI EN 303 645 compliance evidence for consumer IoT products with scope, ICS, IXIT, TS 103 701 assessment steps, verdict risks, and source-linked controls.
- [ETSI EN 303 645 consumer IoT products: what is in scope?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md): ETSI EN 303 645 FAQ on consumer IoT product scope: devices, associated services, constrained devices, out-of-scope industrial uses, ICS, IXIT, and TS 103 701 evidence.
- [ETSI EN 303 645 Current Version Tracker](/artifacts/global/etsi-en-303-645/current-version-tracker.md): Track ETSI EN 303 645 version evidence, ETSI deliverable status checks, TS 103 701 assessment alignment, and change triggers for consumer IoT security work.
- [ETSI EN 303 645 CVD Workflow for IoT Vulnerability Reports](/artifacts/global/etsi-en-303-645/vulnerability-disclosure-cvd-workflow.md): Source-linked workflow for ETSI EN 303 645 vulnerability disclosure: public policy contents, reporting contact, acknowledgement and status timelines, timely action, and TS 103 701 evidence.
- [ETSI EN 303 645 Data Protection Provisions](/artifacts/global/etsi-en-303-645/data-protection-provisions.md): source-linked guide to ETSI EN 303 645 data protection provisions for consumer IoT: personal data security, telemetry transparency, consent, and deletion evidence.
- [ETSI EN 303 645 FAQ: Consumer IoT Security Questions](/artifacts/global/etsi-en-303-645/faq.md): source-linked answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, default passwords, updates, vulnerability disclosure, telemetry, deletion, and TS 103 701 evidence.
- [ETSI EN 303 645 ICS and IXIT Evidence Template](/artifacts/global/etsi-en-303-645/ics-and-ixit-evidence-template.md): Build a source-linked ICS and IXIT evidence template for ETSI EN 303 645 consumer IoT assessments, with clear separation between EN provisions and TS 103 701 test information.
- [ETSI EN 303 645 implementation checklist](/artifacts/global/etsi-en-303-645/implementation-checklist.md): Use this ETSI EN 303 645 implementation checklist to scope a consumer IoT product, record Annex B support statuses, map IXIT evidence, and avoid weak conformance claims.
- [ETSI EN 303 645 Implementation Evidence Guide](/artifacts/global/etsi-en-303-645/implementation-evidence.md): Build ETSI EN 303 645 implementation evidence from Annex B support/detail records, TS 103 701 ICS and IXIT inputs, test verdicts, and scoped external evidence.
- [ETSI EN 303 645 IoT Applicability Workflow](/artifacts/global/etsi-en-303-645/iot-applicability-workflow.md): Decide whether ETSI EN 303 645 applies to a consumer IoT product, what associated services belong in scope, and how to record justified non-applicability.
- [ETSI EN 303 645 personal data deletion FAQ for consumer IoT](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md): What ETSI EN 303 645 says about deleting user data and personal data from consumer IoT devices, associated services, apps, and evidence records.
- [ETSI EN 303 645 requirements: consumer IoT provision map](/artifacts/global/etsi-en-303-645/requirements.md): Map ETSI EN 303 645 consumer IoT requirements to product scope, Annex B ICS entries, TS 103 701 evidence, and implementation owners.
- [ETSI EN 303 645 Secure Update Evidence Workflow](/artifacts/global/etsi-en-303-645/secure-update-evidence-workflow.md): Build secure-update evidence for ETSI EN 303 645 using provision 5.3, Annex B support/detail records, and TS 103 701 ICS, IXIT, and test-plan inputs.
- [ETSI EN 303 645 Secure Update Workflow](/artifacts/global/etsi-en-303-645/secure-update-workflow.md): Map ETSI EN 303 645 secure-update provisions into a practical workflow for consumer IoT update mechanisms, support-period disclosures, and TS 103 701 evidence.
- [ETSI EN 303 645 Secure Updates and Vulnerability Disclosure](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): source-linked guide to ETSI EN 303 645 clauses 5.2 and 5.3 for consumer IoT vulnerability disclosure, security updates, support periods, and TS 103 701 evidence.
- [ETSI EN 303 645 support period: what must consumer IoT teams publish?](/artifacts/global/etsi-en-303-645/faq/support-period.md): ETSI EN 303 645 support-period guidance for consumer IoT: defined security-update support periods, user-accessible publication, constrained-device replacement support, model designation, and TS 103 701 evidence.
- [ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?](/artifacts/global/etsi-en-303-645/faq/telemetry.md): ETSI EN 303 645 telemetry guidance for consumer IoT teams: security anomaly examination, IXIT 24-TelData evidence, personal-data minimization, and consumer telemetry disclosures.
- [ETSI EN 303 645 test evidence: what should consumer IoT teams keep?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md): ETSI EN 303 645 test evidence guidance for consumer IoT teams: ICS support claims, IXIT detail, TS 103 701 test plans, verdicts, and external evidence checks.
- [ETSI EN 303 645 vs EU CRA for Consumer IoT](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-eu-cra.md): Use ETSI EN 303 645 and ETSI TS 103 701 evidence when preparing consumer IoT cybersecurity work that may also need a separate EU CRA legal mapping.
- [ETSI EN 303 645 vs RED Cybersecurity Delegated Act](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-red-cybersecurity-delegated-act.md): Compare ETSI EN 303 645 consumer IoT security evidence with RED cybersecurity planning without treating the ETSI baseline as a substitute for RED legal scope.
- [ETSI EN 303 645 vs UK PSTI: Evidence Crosswalk](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Compare ETSI EN 303 645 evidence with UK PSTI review needs without assuming the same scope, legal trigger, or assurance route.
- [ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md): What ETSI EN 303 645 requires for consumer IoT vulnerability disclosure policies, report handling, status updates, timely action, and TS 103 701 evidence.
- [ETSI TS 103 701 Test Evidence Workflow for EN 303 645](/artifacts/global/etsi-en-303-645/ts-103-701-test-evidence-workflow.md): Build an ETSI TS 103 701 test evidence workflow for EN 303 645 consumer IoT assessments: DUT identification, ICS, IXIT, test plans, verdicts, and external evidence.
- [How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products?](/artifacts/global/etsi-en-303-645/faq/constrained-devices.md): ETSI EN 303 645 constrained-device guidance: what counts as constrained, when non-applicability can be justified, and what evidence should support update and authentication decisions.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize ETSI EN 303 645 provision 5.1

Use this guidance to map authentication mechanisms, IXIT entries, password generation evidence, change flows, and brute-force controls before an assessment or customer review.

- [Build the evidence pack](/solutions/assessment.md): Turn provision 5.1 into product-scoped controls, IXIT fields, test notes, and owner actions.
- [Check a password claim](/solutions/research-copilot.md): Review whether a proposed default-password statement is narrow enough for the ETSI sources.
- [Talk through implementation](/contact.md): Review authentication scope, password generation, reset behavior, and assessment evidence with Sorena.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/faq/default-passwords