ETSI EN 303 645: cybersecurity for consumer IoT

Hugues Orgitello updated 7 Oct 2026 18 min read

ETSI EN 303 645 is the baseline cybersecurity standard for consumer connected devices. Published as a European Standard in June 2020 (V2.1.1) and revised in September 2024 (V3.1.3), it now holds 78 provisions, 36 of them mandatory. It is not a harmonised standard under RED article 3.3, where presumption of conformity comes from the EN 18031 series, but it is the text that the UK PSTI regulations, the Singapore labelling scheme and the former Finnish label are built on. This guide sets out what the standard actually requires, provision by provision, how ETSI TS 103 701 assesses it, and where it sits next to RED and the Cyber Resilience Act.

Versions and dates

The ETSI deliver server lists every published version. The change history in Annex C of V3.1.3 and the national transposition dates in its foreword give the timeline below. No version later than V3.1.3 is published as of 7 October 2026.

Date	Document	What happened
February 2019	TS 103 645 V1.1.1	First publication, as an ETSI Technical Specification
June 2020	EN 303 645 V2.1.1	Publication as a European Standard, "expansion to 68 provisions" (Annex C)
June 2020	TS 103 645 V2.1.2	Same technical content as EN 303 645 V2.1.1
August 2021	TS 103 701 V1.1.1	First conformance assessment specification
January 2024	TS 103 645 V3.1.1	"Revision to improve applicability and testability"
June 11 to 9 September 2024	EN 303 645 V3.1.2	EN approval procedure
11 September 2024	EN 303 645 V3.1.3	Adoption, then publication in September 2024
31 December 2024	EN 303 645 V3.1.3	Date of announcement (doa)
30 June 2025	EN 303 645 V3.1.3	Latest date for national publication (dop/e) and withdrawal of conflicting national standards (dow)
May 2025	TS 103 701 V2.1.1	Assessment method aligned on TS 103 645 V3.1.1 and EN 303 645 V3.1.3

Two consequences follow. A test report against "EN 303 645" is only meaningful with its version number, because the provision list changed between V2.1.1 and V3.1.3. And the UK regulations name V2.1.1 dated 19 June 2020, so the version that gives deemed compliance in the UK is not the current one.

Origin

The introduction of the standard lists the documents it was built from, among them the UK DCMS report "Secure by Design: Improving the cyber security of consumer Internet of Things" (March 2018), the ENISA Baseline Security Recommendations for IoT, the IoT Security Foundation framework, the GSMA IoT Security Guidelines, DIN SPEC 27072 and the OWASP IoT Top 10. Its stated focus is "elementary attacks on fundamental design weaknesses (such as the use of easily guessable passwords)", not prolonged or sophisticated attacks or attacks that need sustained physical access. The Mirai botnet of 2016, built from home routers and IP cameras, is the usual illustration of that class of weakness.

The provisions are "primarily outcome-focused, rather than prescriptive": they say what must be achieved, not which technology to use. The introduction also announces the direction of travel: "future revisions of the present document will mandate provisions that are currently recommendations".

Scope

Clause 1 covers "consumer IoT devices that are connected to network infrastructure (such as the Internet or home network) and their interactions with associated services". Its non-exhaustive list of examples:

• connected children's toys and baby monitors;
• connected smoke detectors, door locks and window sensors;
• IoT gateways, base stations and hubs to which multiple devices connect;
• smart cameras, smart speakers and smart televisions with their remote controls;
• wearable health trackers;
• connected home automation and alarm systems;
• connected appliances such as washing machines and fridges;
• smart home assistants.

The only exclusion in the text is for devices "primarily intended to be used in manufacturing, healthcare or other industrial applications"; industrial control equipment is the territory of other series such as IEC 62443. The definition of consumer IoT device adds two notes that matter in practice: a consumer device used in a business context stays a consumer IoT device, and so does a device installed by a professional. "Associated services" (mobile apps, cloud, third-party APIs chosen by the manufacturer) are part of the IoT product, and "manufacturer" covers every relevant economic operator in the supply chain, not only the device maker.

Structure and status notation

Clause	Content
1 to 3	Scope, references (no normative reference), terms and abbreviations
4	Implementation of the standard: provisions are informed by the manufacturer's risk assessment and threat modelling; the standard "does not define a testing or certification method"
5	Cyber security provisions: 5.0 (reporting implementation) and 5.1 to 5.13
6	Data protection provisions
Annex A	Architectures, device states, interfaces (informative)
Annex B	Implementation conformance statement (ICS) pro forma, Table B.1 (informative)
Annex C	Change history

Table B.1 marks each provision with one or more notations:

• M: mandatory requirement ("shall").
• R: recommendation ("should"). Provision 5.0-1, itself mandatory, requires a recorded justification for every recommendation that is not applicable or not fulfilled.
• C: conditional; if the condition (numbered footnote) is not met, the provision is marked N/A.
• F: applies only if a feature, capability or mechanism exists (lettered footnote), for example "debug interfaces exist on the device". The F notation is new in V3; V2.1.1 only used M, R and C.

The provisions, clause by clause

The counts below come from Table B.1 of each version. "Void" entries in V3.1.3 (5.3-4, 5.3-6, 5.3-15, 5.6-4, 5.13-1, 6-3) are not counted: each was split into "A" and "B" provisions.

Clause	Title in the standard	V2.1.1 (M / R)	V3.1.3 (M / R)	Mandatory provisions in V3.1.3
5.0 (4 in V2)	Reporting implementation	1 / 0	1 / 0	5.0-1
5.1	No universal default passwords	5 / 0	5 / 1	5.1-1 to 5.1-5
5.2	Implement a means to manage reports of vulnerabilities	1 / 2	1 / 2	5.2-1
5.3	Keep software updated	7 / 9	7 / 12	5.3-2, -3, -7, -8, -10, -13, -16
5.4	Securely store sensitive security parameters	4 / 0	4 / 0	5.4-1 to 5.4-4
5.5	Communicate securely	4 / 4	4 / 4	5.5-1, -5, -7, -8
5.6	Minimize exposed attack surfaces	3 / 6	3 / 7	5.6-1, -2, -4A
5.7	Ensure software integrity	0 / 2	0 / 2	none
5.8	Ensure that personal data is secure	2 / 1	2 / 1	5.8-2, -3
5.9	Make systems resilient to outages	0 / 3	0 / 3	none
5.10	Examine system telemetry data	0 / 1	0 / 1	none
5.11	Make it easy for users to delete user data	1 / 3	1 / 3	5.11-1
5.12	Make installation and maintenance of devices easy	0 / 3	0 / 3	none
5.13	Validate input data	1 / 0	2 / 0	5.13-1A, -1B
6	Data protection provisions	4 / 1	6 / 3	6-1, 6-2, 6-3A, 6-3B, 6-5, 6-6
Total		33 / 35 (68)	36 / 42 (78)

Four of the thirteen clauses (5.7, 5.9, 5.10, 5.12) contain only recommendations. A product can conform to EN 303 645 without secure boot, provided the justification required by 5.0-1 is recorded.

5.1 No universal default passwords

Where passwords are used, in any state other than the factory default, they "shall be unique per device or defined by the user" (5.1-1). Pre-installed unique passwords must be generated so as to reduce the risk of automated attacks (5.1-2). V3 adds a recommendation not to use passwords for machine-to-machine authentication (5.1-2A). Authentication must use best practice cryptography (5.1-3), the user must be able to change the authentication value (5.1-4), and brute-force attacks over network interfaces must be made impracticable (5.1-5).

5.2 Vulnerability reports

The manufacturer "shall make a vulnerability disclosure policy publicly available" (5.2-1), with at least contact information and timelines for acknowledgement of receipt and for status updates until resolution. Acting on vulnerabilities in a timely manner (5.2-2) and continuous monitoring (5.2-3) are recommendations. The standard points to ISO/IEC 29147 among its informative references.

5.3 Keep software updated

Mandatory items include a secure update mechanism unless a resource constraint determined by the use case prevents it (5.3-2), updates simple to apply (5.3-3), best practice cryptography for updates (5.3-7), timely security updates (5.3-8), verification of authenticity and integrity for updates delivered over a network interface (5.3-10), publication of the "defined support period" (5.3-13) and a clearly recognisable model designation (5.3-16). The defined support period is the minimum time, as a period or end date, during which security updates will be provided; the standard sets no minimum length.

5.4 Sensitive security parameters

Sensitive security parameters in persistent storage must be stored securely (5.4-1); a hard-coded unique device identity must resist tampering (5.4-2); hard-coded critical security parameters in source code are forbidden (5.4-3); and keys used for update integrity and for communication with associated services must be unique per device (5.4-4). Trusted execution environments and secure elements appear as examples, not requirements.

5.5 Communicate securely

The device "shall use best practice cryptography to communicate securely" (5.5-1). The standard names no protocol version: "best practice cryptography" is defined as cryptography suitable for the use case with no indication of a feasible attack with readily available techniques. Security-relevant configuration changes over a network interface require authentication (5.5-5), critical security parameters communicated via remotely accessible network interfaces must stay confidential (5.5-7) and be managed with secure processes (5.5-8).

5.6 Attack surface

Unused network and logical interfaces must be disabled (5.6-1), unauthenticated disclosure of security-relevant information minimised (5.6-2), and debug interfaces (test points, UART, SWD, JTAG) "disabled or protected via a best practice authentication or access control mechanism" (5.6-4A). Physical protection of debug ports, least privilege, code minimisation, hardware memory access control and secure development processes are recommendations.

5.7 to 5.13

• 5.7 Software integrity: verification through secure boot (5.7-1) and alerting on unauthorised change (5.7-2) are both recommendations.
• 5.8 Personal data: sensitive personal data sent to associated services must be protected with best practice cryptography (5.8-2), and all external sensing capabilities (camera, microphone, etc.) must be documented for the user (5.8-3).
• 5.9 Resilience: all three provisions, including staying locally functional after loss of network access, are recommendations.
• 5.10 Telemetry: examining telemetry for security anomalies is a recommendation.
• 5.11 Deleting user data: users "shall be provided with functionality such that all their user data can be erased from the consumer IoT device in a simple manner" (5.11-1); the rest is recommended.
• 5.12 Installation and maintenance: recommendations only.
• 5.13 Input validation: data input via user interfaces (5.13-1A) and via network interfaces (5.13-1B) must be validated.

Clause 6: data protection

Clause 6 is a single list of provisions numbered 6-1 to 6-8 (Table B.1 writes 6.1, 6.2...). The standard states that it "can help" with GDPR compliance; it does not restate GDPR articles.

Provision	Requirement (V3.1.3)	Status
6-1	Clear and transparent information on what personal data is processed, for what purposes, by whom and for how long, including third parties such as advertisers	M
6-2	Means to obtain consent in a valid way, where processing is based on consent	M (F)
6-3A	Means to withdraw consent at any time	M (F)
6-3B	Means to store information about the consent	M (F)
6-4	Processing of personal data in telemetry limited to what is necessary	R (F)
6-5	Information on what telemetry is collected, how, by whom and why	M (F)
6-6	Data limited to what is necessary for the purposes in 6-1, and deleted when no longer necessary	M (F)
6-7	For aggregate results, minimum data, early aggregation, minimal retention	R (F)
6-8	Use of data anonymisation technologies	R (F)

Provisions 6-3B, 6-6, 6-7 and 6-8 do not exist in V2.1.1, which had five clause 6 provisions.

Conformity assessment: ETSI TS 103 701

Clause 4 of EN 303 645 says the standard does not define a test method and that "a way to assess conformance" is given in TS 103 701, titled "Conformance Assessment of Baseline Requirements". The current V2.1.1 (May 2025) references TS 103 645 V3.1.1 and EN 303 645 V3.1.3. Its main features:

• Who assesses: the test laboratory can be part of the supplier (first party, self-assessment), a user organisation (second party) or an independent body (third party). Competence requirements such as ISO/IEC 17025 are "out of the scope" of the document, and so is defining a certification scheme.
• Inputs from the supplier: the ICS (Table B.1 of EN 303 645, with Y, N or N/A and a justification for each N/A or N) and the IXIT, "Implementation eXtra Information for Testing", the basis of a grey-box methodology.
• Depth: test scenarios target "basic effort"; invasive analysis of hardware and software modules is out of scope.

Phase (clause 4.3)	Actor	Content
1	Supplier	Identification of the device under test
2	Supplier	Completed ICS
3	Supplier	IXIT for every provision claimed "Yes"
4	Laboratory	ICS validation: no mandatory provision claimed "N", N/A claims plausible
5	Laboratory	Test plan and test groups for each provision claimed "Yes"
6	Laboratory	Overall verdict

Verdicts are PASS, FAIL or INCONCLUSIVE at test case, test group and overall level. An overall PASS requires a valid ICS and a PASS for every claimed provision. If a recommended provision fails, the results can be reused for a PASS against an ICS that no longer claims it, with a justification. The content of the assessment report is left to the scheme that uses it.

National regimes that use EN 303 645

United Kingdom: PSTI

Part 1 of the Product Security and Telecommunications Infrastructure Act 2022 is made operational by SI 2023/1007, in force since 29 April 2024. Schedule 1 sets three security requirements for manufacturers of relevant connectable products; Schedule 2 says when a manufacturer is "treated as complying".

PSTI requirement (Schedule 1)	Deemed compliance (Schedule 2, Condition A)
Passwords unique per product or defined by the user, not based on incremental counters or public information	EN 303 645 V2.1.1 provision 5.1-1 and, where relevant, 5.1-2
Published point of contact for security issues, with timelines for acknowledgement and status updates	Provision 5.2-1, or ISO/IEC 29147:2018 paragraphs 6.2.2, 6.2.5 and 6.5
Published defined support period, expressed with an end date, never shortened	Provision 5.3-13, with the UK definition of defined support period

Changes since the regime started:

• SI 2025/211 (in force 25 February 2025): when a manufacturer extends the support period, the new period must be published as soon as practicable; motor vehicles, two- or three-wheel vehicles and quadricycles, and agricultural and forestry vehicles covered by the corresponding EU type-approval regulations are excepted in Great Britain.
• SI 2025/1267 (made 3 December 2025, in force 4 December 2025): a product currently holding an unexpired label at any level of the Singapore Cybersecurity Labelling Scheme (specification version 1.4, April 2025) or a Japan JC-STAR label (level STAR-1) is deemed compliant with all three requirements (Conditions B and C), and is also deemed to meet the statement of compliance requirement (new Schedule 2A).

Other points from the texts: the statement of compliance must contain the items in Schedule 4, including the defined support period and, for deemed compliance via a standard, its number, version and date; manufacturers and importers keep it for 10 years or the defined support period, whichever is longer. Excepted products include desktop and laptop computers and non-cellular tablets (unless designed for children under 14), medical devices under the Medical Devices Regulations 2002, smart charge points, and certain smart meters. The maximum penalty under section 38 of the Act is the greater of £10 million and 4% of qualifying worldwide revenue.

Singapore: Cybersecurity Labelling Scheme

The Cyber Security Agency of Singapore runs four levels, each requiring the assessment tiers below it:

Tier	Content according to CSA
1	Baseline security requirements "based on ETSI EN 303 645": no default password, security updates, vulnerability reporting
2	Adherence to "all mandatory requirements within the ETSI EN 303 645"
3	Lifecycle requirements based on the IMDA IoT Cyber Security Guide, plus software binary analysis by a test laboratory
4	Penetration testing by a test laboratory

The scheme started with Wi-Fi routers and smart home hubs and now covers all categories of consumer IoT devices. CSA lists mutual recognition with Finland (Level 3), Germany (BSI IT Security Label, Level 2), Korea (CIC Basic, Level 3) and the United Kingdom (PSTI compliance recognised as Level 1).

Australia: mandatory rules since 4 March 2026

The Cyber Security (Security Standards for Smart Devices) Rules 2025, made under the Cyber Security Act 2024 and registered on 4 March 2025, apply their security standard from 4 March 2026. Schedule 1 covers the same three topics as PSTI: passwords, reports of security issues, and defined support periods and security updates. The instrument does not cite ETSI EN 303 645.

Finland: label closed to new applications

Traficom launched its Cybersecurity Label in 2019. On 21 October 2024, it announced that it would stop granting new labels, citing the RED cybersecurity requirements applicable from 1 August 2025 and the Cyber Resilience Act; existing labels stay valid at least until the end of 2024.

EN 303 645 in the EU: RED 3.3, EN 18031 and the CRA

Delegated Regulation (EU) 2022/30 activates Article 3(3)(d), (e) and (f) of the RED for internet-connected radio equipment (and some childcare, toy and wearable equipment) from 1 August 2025. Implementing Decision (EU) 2025/138 of 28 January 2025 (OJ of 30 January 2025) cites three harmonised standards drafted by CEN and CENELEC:

• EN 18031-1: Article 3(3)(d), network protection;
• EN 18031-2: Article 3(3)(e), personal data and privacy;
• EN 18031-3: Article 3(3)(f), protection from fraud for equipment processing virtual currency or monetary value.

The citation carries restrictions. One concerns the same topic as provision 5.1-1: clauses 6.2.5.1 and 6.2.5.2 of the three standards allow a user not to set or use any password, and if that option is implemented the presumption of conformity does not apply. EN 303 645 has no such option: a password, where used, must be unique per device or defined by the user.

EN 303 645 is not cited under the RED, so applying it gives no presumption. It still has uses in the EU: as the provision catalogue behind a risk assessment, as evidence in the technical file alongside EN 18031, and for products without a radio (wired-only devices with no Wi-Fi, BLE or cellular interface), which the RED does not cover.

The timeline is moving. Delegated Regulation (EU) 2026/339 repeals Regulation 2022/30 with effect from 11 December 2027, the date the Cyber Resilience Act (Regulation (EU) 2024/2847) applies in full. CRA reporting obligations for actively exploited vulnerabilities and severe incidents already apply since 11 September 2026, to radio and non-radio products alike.

Dimension	EN 303 645 V3.1.3	EN 18031-1/-2/-3:2024
Producer	ETSI, TC CYBER	CEN and CENELEC
EU legal effect	None on its own, not cited in the OJ	Presumption of conformity with RED 3(3)(d)(e)(f), with restrictions, until 11 December 2027
Products	Consumer IoT devices and associated services	Radio equipment within Delegated Regulation 2022/30
Structure	78 provisions, M or R, in clauses 5.0 to 5.13 and 6	One part per RED essential requirement
Default passwords	Unique per device or user-defined, no opt-out	Option to skip a password removes presumption (Decision 2025/138)
Assessment method	ETSI TS 103 701	Within the EN 18031 parts
Used by	UK PSTI deemed compliance (V2.1.1), Singapore CLS tiers	CE marking under the RED

Which text applies where

Market and product	Legal requirement	Role of EN 303 645
EU, internet-connected radio product	RED 3(3)(d)(e)(f) until 10 December 2027, then CRA; CRA reporting since 11 September 2026	Not a presumption route; useful as a provision catalogue
EU, product without radio	CRA reporting since 11 September 2026, full application 11 December 2027	Not a presumption route
United Kingdom, consumer connectable product	PSTI, SI 2023/1007	V2.1.1 provisions 5.1-1, 5.1-2, 5.2-1, 5.3-13 give deemed compliance
Singapore, CLS label	Scheme of CSA	Basis of Tiers 1 and 2
Australia, consumer smart device	Smart Devices Rules 2025, from 4 March 2026	Not cited by the instrument

Claims the texts contradict

Common claim (including earlier versions of this page)	What the primary text says
"Thirteen provisions"	Thirteen clauses (5.1 to 5.13), plus 5.0 and clause 6: 78 provisions in V3.1.3, 68 in V2.1.1 (Table B.1, Annex C)
Clause 6 has five families: consent, transparency, default settings, identifiable telemetry, GDPR Article 9 sensitive data	Clause 6 has provisions 6-1 to 6-8 on information, consent, withdrawal and record of consent, telemetry, data minimisation, aggregation and anonymisation; no provision on Article 9 data
Secure boot, resilience to outages and telemetry examination are mandatory	5.7, 5.9 and 5.10 contain only recommendations
The standard cites TLS 1.2, IPsec, LoRaWAN OTAA, Zigbee Pro or Thread as accepted mechanisms	It requires "best practice cryptography" and names no protocol version
TS 103 701 uses a PIXIT	It uses the IXIT, "Implementation eXtra Information for Testing"; PIXIT is a protocol testing term
TS 103 701 assessments are performed under ISO/IEC 17025 accreditation	Laboratory competence requirements are out of scope; first-party self-assessment is allowed
The UK PSTI Act applies EN 303 645 V3.1.3	SI 2023/1007 defines "ETSI EN 303 645" as V2.1.1 (19 June 2020)
PSTI penalties reach £10 million or 4% of turnover	The maximum is the greater of £10 million and 4% of qualifying worldwide revenue (section 38)
Singapore CLS Levels 3 and 4 add a TS 103 701 assessment	CSA describes Tier 3 as lifecycle requirements plus binary analysis and Tier 4 as penetration testing; TS 103 701 is not mentioned
EN 18031 is "mandatory for radio products since 1 August 2025"	The essential requirements are mandatory; the harmonised standards are one way to show conformity, and their citation has restrictions
EN 18031 is published by CENELEC alone	Decision 2025/138 states that CEN and CENELEC drafted the three standards
Out of scope: motor vehicles, critical infrastructure (NIS2)	The standard excludes only devices primarily for manufacturing, healthcare or other industrial use; vehicle exceptions come from UK PSTI, not from EN 303 645
A V4 is expected in 2027	ETSI has published no version after V3.1.3; no date for a future revision is given in the documents cited here

For a manufacturer: a practical approach

1. Fix the version and the markets. Record which version each market expects: V2.1.1 provisions for UK deemed compliance, V3.1.3 for a current TS 103 701 assessment, EN 18031 for RED presumption in the EU. See our RED checklist for the European side.

2. Fill Table B.1 early. The ICS forces a decision on all 78 provisions. Every "N" or "N/A" needs a justification (provision 5.0-1), and the mandatory set (passwords, vulnerability disclosure policy, secure update, published support period, secure storage, debug interfaces, input validation, data protection information) drives architecture choices.

3. Assess and keep the evidence. Run a TS 103 701 assessment, as self-assessment or with a third party, in parallel with the RED tests if the product has a radio. Keep the ICS, IXIT and verdicts with the technical file; in the UK, keep the statement of compliance for 10 years or the defined support period, whichever is longer.

See also

• Product cybersecurity: obligation, evaluation, label
• PSA Certified: Arm-led IoT security baseline
• NISTIR 8425 and the US Cyber Trust Mark: consumer-IoT label
• NIST SP 800-213 and 8259A: US baseline for IoT cybersecurity
• Common Criteria (ISO/IEC 15408): IT security eval
• FIPS 140-3: cryptographic module validation
• Cyber Resilience Act (CRA)

Working on EN 303 645 or EN 18031 assessment of a consumer IoT product for a real product? AESTECHNO can audit your design and certification plan. Get in touch

Limits of the standard

EN 303 645 is a baseline. It does not address prolonged or sophisticated attacks, and its outcome-based wording ("best practice cryptography", "timely") leaves room for interpretation, which TS 103 701 narrows through the IXIT and test groups without prescribing tools. It also carries no legal effect by itself: its weight comes from the regimes that point to it, and those point to different versions. Mastering the provisions, together with RED 3.3 and CE marking, remains a useful technical layer for placing a consumer IoT product on several markets.

A 30-minute audit with AESTECHNO engineers.

AESTECHNO is the electronics design house that edits spilma. We help product teams scope their certification effort and avoid the common mistakes.

Book a free audit

Going further

• RED checklist: RED compliance project approach phase by phase
• RED 3.3 activation: Delegated Regulation 2022/30 applicable since 1 August 2025
• Publication of EN 18031 standards: presumption of RED 3.3 conformity
• RED 3.3 repeal scheduled for 11 December 2027: Delegated Regulation 2026/339
• CRA reporting starts: obligations from 11 September 2026
• RED tests: overview of 3.1(a), 3.1(b), 3.2 and 3.3 testing
• CE marking: European transversal framework
• Glossary: definitions of ETSI, ENISA, CENELEC terms

Sources & references

1. ETSI EN 303 645 V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements, ETSI www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf
2. ETSI EN 303 645 V2.1.1 (2020-06), the version referenced by the UK PSTI regulations, ETSI www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf
3. ETSI deliver, list of all EN 303 645 versions, ETSI www.etsi.org/deliver/etsi_en/303600_303699/303645/
4. ETSI TS 103 701 V2.1.1 (2025-05), Conformance Assessment of Baseline Requirements, ETSI www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf
5. UK Product Security and Telecommunications Infrastructure Act 2022, UK Legislation www.legislation.gov.uk/ukpga/2022/46/contents
6. PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023, SI 2023/1007, UK Legislation www.legislation.gov.uk/uksi/2023/1007/contents
7. PSTI Security Requirements (Amendment) Regulations 2025, SI 2025/211, UK Legislation www.legislation.gov.uk/uksi/2025/211/made
8. PSTI Security Requirements (Amendment) (No. 2) Regulations 2025, SI 2025/1267, UK Legislation www.legislation.gov.uk/uksi/2025/1267/made
9. Delegated Regulation (EU) 2022/30, RED Article 3(3)(d)(e)(f), EUR-Lex eur-lex.europa.eu/eli/reg_del/2022/30/oj
10. Implementing Decision (EU) 2025/138, citation of EN 18031-1/-2/-3:2024, EUR-Lex eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202500138
11. Delegated Regulation (EU) 2026/339, repeal of Regulation 2022/30 from 11 December 2027, EUR-Lex eur-lex.europa.eu/eli/reg_del/2026/339/oj
12. Regulation (EU) 2024/2847, Cyber Resilience Act, EUR-Lex eur-lex.europa.eu/eli/reg/2024/2847/oj
13. CLS(IoT) for manufacturers, cybersecurity levels and assessment tiers, Cyber Security Agency of Singapore www.csa.gov.sg/our-programmes/certification-and-labelling-schemes/cybersecurity-labelling-scheme/for-manufacturers/
14. Cyber Security (Security Standards for Smart Devices) Rules 2025, Federal Register of Legislation (Australia) www.legislation.gov.au/F2025L00276/latest/text
15. Traficom stops granting new Cybersecurity Labels (21 October 2024, in Finnish), Traficom www.traficom.fi/fi/uutiset/liikenne-ja-viestintavirasto-traficom-lopettaa-uusien-tietoturvamerkkien-myontamisen