Decision guideGLOBAL

ETSI Standards Hub Choose the right ETSI standard

A practical decision tree in text: pick the ETSI standard that matches your product or trust service, then plan controls, tests, and evidence.

This guide pins the current ETSI editions and uses object-of-assurance logic so teams do not choose the wrong standard or the wrong version.

Back to main artifact Review sources

Author

Sorena AI

Published

Mar 4, 2026

Updated

Mar 4, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Mar 4, 2026

Updated Mar 4, 2026

Overview

If you start with the wrong ETSI standard or the wrong ETSI edition, you usually end up with the wrong evidence. Use this page to choose the right ETSI cybersecurity standard by what you are building and what you need to prove, then pin the exact edition before implementation starts.

Section 1

Fast path: match your use case to the right current ETSI document

Start by selecting the correct object of conformity: a consumer IoT product, a trust service provider, or a certificate issuance service. Then choose the ETSI document that directly targets that object.

If your goal is independent assessment, choose both the baseline and the assessment method where ETSI separates them.

Consumer IoT product security baseline: ETSI EN 303 645 V3.1.3
Consumer IoT assessment and test scenarios: ETSI TS 103 701 V2.1.1
Trust Service Provider general policy and operational requirements: ETSI EN 319 401 V3.1.1
Certificate policy requirements in general issuance contexts: ETSI EN 319 411-1 V1.5.1
Qualified certificate policy and qualified certificate issuance: ETSI EN 319 411-2 V2.6.1

Section 2

Step 1: define the object you need to assure

ETSI documents are intentionally specific. You get faster clarity when you write the scope in one sentence and keep it consistent across engineering, security, legal, and assurance teams.

For consumer IoT, scope usually means device, companion app, and backend services required for security functions such as updates, vulnerability reporting, authentication, and telemetry. For trust services, scope usually means the TSP organization, its policies and practices, and the service processes and security controls that make the trust service reliable and auditable.

Name the thing you must secure: device family, platform, service, or certificate issuance function
List the security-relevant interfaces and dependencies
Define responsibility boundaries between your team and third parties
Write the assurance boundary: what will be assessed, by whom, and against which ETSI edition

Section 3

Step 2: define what you need to prove

Different ETSI documents lead to different evidence styles. Some are outcome-focused baselines you implement and document. Others are assessment specifications designed for repeatable evaluation.

For example, TS 103 701 is explicitly the conformance-assessment method for EN 303 645 and sets out the structure, roles, and documentation inputs that make IoT product assessments repeatable.

Self-assurance goal: implement the EN requirements and keep evidence and rationale traceable
Independent assessment goal: plan for test scenarios, verdict logic, and lab-ready inputs
Audit or supervisory goal: ensure policy, logging, incident response, and governance evidence are repeatable and attributable

Section 4

Step 3: pin the edition before you build controls

Version drift breaks audits. The ETSI stack in this hub spans current publications from 2024 and 2025, and some of the IoT and trust-service documents were revised recently enough that older internal mappings are likely stale.

Pin the title, version, and publication date in scope documents, control matrices, and evidence packs before implementation begins.

EN 303 645 V3.1.3 replaces older hub assumptions based on V2.1.1
TS 103 701 V2.1.1 aligns the assessment method to the newer EN 303 645 edition
EN 319 401 V3.1.1, EN 319 411-1 V1.5.1, and EN 319 411-2 V2.6.1 should be pinned explicitly in trust-service programs

Section 5

Common selection mistakes

ETSI work goes off the rails when teams choose a document by name recognition instead of by object and assurance outcome. Avoid these predictable mistakes.

Treating EN 303 645 as a test plan instead of a baseline standard and forgetting TS 103 701 when assessment structure is needed
Using TSP policy requirements for product security or product standards for trust-service governance
Mixing qualified and non-qualified certificate-policy expectations without a clear boundary between EN 319 411-1 and EN 319 411-2
Ignoring version pinning and discovering too late that the evidence pack maps to an older edition

Recommended next step

Use ETSI Standards Hub Choose the right ETSI standard as a cited research workflow

Research Copilot can take ETSI Standards Hub Choose the right ETSI standard from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on ETSI Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Research workflow

Open Research Copilot for ETSI Standards Hub Choose the right ETSI standard

Start from ETSI Standards Hub Choose the right ETSI standard and answer scope, timing, and interpretation questions with cited outputs.

Explore next step

Talk to Sorena

Talk through ETSI Standards Hub

Review your current process, evidence gaps, and next steps for ETSI Standards Hub Choose the right ETSI standard.

Explore next step

Primary sources