ETSI TS 104 007 V1.2.1 (2025-05)

Lawful Interception (LI); Lawful Interception Architecture

RTS/LI-00284

General Information

• Status: Not Published
• Technical Committee: LI - Lawful Interception
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 14-May-2025
• Completion Date: 07-May-2025

Standards Content (Sample)

TECHNICAL SPECIFICATION
Lawful Interception (LI);
Lawful Interception Architecture

2 ETSI TS 104 007 V1.2.1 (2025-05)

Reference
RTS/LI-00284
Keywords
functional architecture, interception,
lawful interception
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2025.
All rights reserved.
ETSI
3 ETSI TS 104 007 V1.2.1 (2025-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Approach . 9
4.1 General approach . 9
4.2 LI entities and procedures . 10
4.2.1 Overview . 10
4.2.2 Entities . 10
4.2.3 Process . 11
4.2.4 LI lifecycle . 11
5 Functional view . 12
5.1 General . 12
6 Security first approach. 14
6.1 Introduction . 14
6.1.1 Approach . 14
6.1.2 Trust domains . 14
6.1.2.1 Trust domain definition . 14
6.1.2.2 Domain separation . 14
6.1.2.3 Controlled interconnection . 14
6.1.2.4 Cross-trust-domain gateway deployment . 14
6.2 LI assets . 15
6.2.1 Identifiers are fundamental LI assets . 15
6.2.2 Further LI assets . 17
6.3 Trust domains . 17
6.3.1 Introduction to trust domains . 17
6.3.2 Trust domain collapse . 17
6.4 LI architecture . 17
6.4.1 Security-first approach to LI architecture . 17
6.4.2 LI architecture including IDs . 18
6.4.3 LI architecture . 21
6.4.4 Simplified LI architecture . 23
6.5 Attestation . 24
6.6 Certificate management . 25
7 Provisioning . 26
7.1 Provisioning Phases . 26
7.1.1 Overview . 26
7.1.2 Phase 0 (X0) . 26
7.1.3 Phase 1 (X0) . 27
7.1.4 Phase 2 (X0) . 27
7.1.5 Phase 3 (X0) . 28
7.1.6 Phase 4 (X0) . 28
ETSI
4 ETSI TS 104 007 V1.2.1 (2025-05)
7.1.7 Phase 5 (X0) . 28
7.1.8 Phase 6 (X0) . 28
7.1.9 Phase 7 (X1) . 28
8 Further security aspects . 29
8.1 General . 29
8.2 Compromise of interface endpoints . 29
8.2.1 Overview . 29
8.2.2 Analysis . 29
Annex A (informative): Attestation . 31
A.1 Definition of remote attestation . 31
A.2 The simplest attestation flow . 31
A.3 A brief overview . 31
A.3.1 Attestation framework . 31
A.3.2 Ground truth . 32
A.3.3 Attested session creation . 34
A.3.4 Attester environment . 34
A.3.5 Hardware layers . 35
A.4 Attestation full picture . 38
Annex B (normative): Checklist . 39
B.1 Purpose . 39
B.2 Functions and interfaces . 39
B.3 Provisioning flow . 39
B.4 Attestation . 39
B.5 Certificate management . 40
B.6 Functional concerns . 40
Annex C (informative): Change history . 41
History . 42

ETSI
5 ETSI TS 104 007 V1.2.1 (2025-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Lawful Interception (LI).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document describes a comprehensive blueprint for a Lawful Interception (LI) system, designed to align
with the mandates of Law Enforcement Agencies (LEAs) for the surveillance of telecommunications with utility across
varying legal and regulatory environments. The LI architecture detailed herein sets out to meet stringent requirements,
outlining the necessary high-level entities, procedures, and the functional roles essential for the operation of
interception. It specifies how lawful authorizations, such as warrants, are processed and executed by Communication
Service Providers (CSPs) to deliver Intercept Related Information (IRI) and Content of Communication (CC) to LEAs
through secure channels.
The present document emphasizes a security-centric approach, incorporating Zero Trust principles across the
architecture to ensure secure operations. This security view is intertwined with the functional aspects, ensuring that both
data integrity and privacy are preserved throughout the interception process. The architecture is designed to enable
distinct LEAs to carry out interception activities simultaneously and independently, safeguarding against the risk of
inter-agency or other non-authorized detection.
ETSI
6 ETSI TS 104 007 V1.2.1 (2025-05)
Through the definition of a methodical LI lifecycle, starting from authorization and ending with the delivery of
intercepted communications, the present document covers the operational protocols, the interplay between the various
entities, and the safeguarding mechanisms in place. The described LI system is adaptable to the dynamic and evolving
landscape of national laws and telecommunication technologies, ensuring future-proof applications across different
jurisdictions and technological paradigms.
Introduction
The present document explains thoroughly the intricate architecture of Lawful Interception (LI) systems as stipulated
across varying regulatory environments, a cornerstone for maintaining the delicate balance between national security,
law enforcement, and individual privacy. Mapped out herein are the protocols that govern the interception of
telecommunications as per the legal frameworks established by ETSI TS 101 331 [1]. Commencing with a broad
overview of the key players and their respective roles within the LI ecosystem, the present document progressively
narrows down to a more detailed analysis of the functional and security viewpoints.

ETSI
7 ETSI TS 104 007 V1.2.1 (2025-05)
1 Scope
The present document on Lawful Interception architecture provides an overview of the technical framework and
components involved in facilitating lawful interception of communications for law enforcement agencies. The present
document outlines the key principles, standards, and protocols governing lawful interception, including the roles and
responsibilities.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 101 331: "Lawful Interception (LI); Requirements of Law Enforcement Agencies".
[2] European Union Council Resolution 96/C 329/01 of 17 January 1995 on the lawful interception of
telecommunications.
[3] ETSI GS NFV-IFA 026: "Network Functions Virtualisation (NFV) Release 5; Management and
Orchestration; Architecture enhancement for Security Management Specification".
[4] ETSI TS 104 000: "Lawful Interception (LI); Internal Network Interface X0".
[5] ETSI TS 133 126: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; 5G; Lawful Interception requirements (3GPP
TS 33.126)".
[6] ETSI TS 133 127: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; 5G; Lawful Interception (LI) architecture and
functions (3GPP TS 33.127)".
[7] IETF RFC 9334: "Remote ATtestation procedureS (RATS) Architecture".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI ETR 330: "Security Techniques Advisory Group (STAG); A guide to legislative and
regulatory environment".
ETSI
8 ETSI TS 104 007 V1.2.1 (2025-05)
[i.2] ETSI GR NFV-IFA 029 (V3.3.1): "Network Functions Virtualisation (NFV) Release 3;
Architecture; Report on the Enhancements of the NFV architecture towards "Cloud-native" and
"PaaS"".
[i.3] ETSI GS NFV-IFA 040 (V4.1.1): "Network Functions Virtualisation (NFV) Release 5;
Management and Orchestration; Requirements for service interfaces and object model for OS
container management and orchestration specification".
[i.4] NIST Special Publication (NIST SP) 800-207: "Zero Trust Architecture".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
root of trust: hardware-based seed/key material or function that contains it, upon which a hierarchy of keys are built to
support higher functions
trust anchor: root certificate authority in the network
zero trust: security concept where no entity, whether inside or outside a network perimeter, is automatically trusted,
but granularly authorized
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ABAC Attribute Based Access Control
ADMF ADMinistrative Function
API Application Programming Interface
ARP Attestation Relying Party
AVS Attestation Verifier Service
CA Certificate Authority
CC Content of Communication
CISM Container Infrastructure Service Manager
CMF Certificate Management Function
CPU Central Processing Unit
CSP Communication Service Provider
CSR Certificate Signing Request
CTDGW Cross Trust Domain GateWay
DMZ De-Militarized Zone
ELI Element of LI
HMEE Hardware Mediated Execution Enclave
ID IDentifier
IRI Intercept Related Information
LEA Law Enforcement Agency
LEMF Law Enforcement Monitoring Function/Facility
LI Lawful Interception
Li-Admf Lawful Interception-Administrative function interface
Li-Ap Lawful Interception-Application interface
LICA Lawful Interception Certificate Authority
LICF Lawful Interception Control Function
LICM Lawful Interception Certificate Management function
ETSI
9 ETSI TS 104 007 V1.2.1 (2025-05)
LIGW Lawful Interception GateWay
LIID Lawful Interception IDentifier
Li-No Lawful Interception-Network Output interface
Li-Os Lawful Interception-Operations support interface
LIPF Lawful Interception Provisioning Function
LISE LI Security Engine
Li-Vn Lawful Interception-Virtual network interface
LRPG LI Routing Proxy Gateway
MANO MANagment and Orchestration
MDF Mediation and Delivery Function
MOGW ManO GateWay
Ne-Admf Network-Administrative function interface
NF Network Function
NFIID Network Function Instance IDentity
NFV Network Function Virtualisation
NFVO Network Function Virtualisation Orchestrator
NOGW Network Output GateWay
NRF NF Repository Function
NWF NetWork functionality Function
OS Operating System
Os-Mano Operations support-MANO interface
OSS/BSS Operations Support System/Business Support System
Oss-LI Operations support-Lawful Interception interface
POI Point Of Interception
RAM Random Access Memory
RATS Remote ATtestation procedureS
SDN Software Defined Network
SIRF System Information Retrieval Function
SOC System On Chip
TD Trust Domain
TF Triggering Function
TLS Transport Layer Security
TPM Trusted Program Module
UEFI Universal Extensible Firmware Interface
VM Virtual Machine
VNF Virtual Network Function
ZTA Zero Trust Architecture
4 Approach
4.1 General approach
The present document defines the Lawful Interception (LI) architecture to meet the requirements of LEAs regarding the
Handover Interface for the interception of telecommunications (see ETSI TS 101 331 [1]).
Clause 4.2 describes a high-level view of the entities and procedures that are generally required to be supported in
LI systems.
Clause 5 sets out the functional view of the architecture that supports the elements and procedures required by
clause 4.2.
Clause 6 sets out the security view of the architecture that supports secure operation following Zero Trust principles as
defined by NIST [i.4].
Clauses 5 and 6 are to be read together, as the security view in clause 6 motivates the functional view of clause 5.
Clause 7 gives an overview of the provisioning process.
ETSI
10 ETSI TS 104 007 V1.2.1 (2025-05)
4.2 LI entities and procedures
4.2.1 Overview
The functional role model described in this clause is a reference example to facilitate a general understanding of the
typical operation of interception and the typical responsibilities of the various elements.
National laws that describe the conditions and restrictions of interception and procedures will apply as described in
references [2] and [i.1].
The LEA obtains a lawful authorization, such as a warrant, from a court of law or other responsible body (the
"authority" in figure 4.2.1-1). The LEA presents the lawful authorization to the CSP via an administrative interface or
procedure (interface port HI1).
Intercept Related Information (IRI) and the Content of Communication (CC) are delivered to the Law Enforcement
Monitoring Function (LEMF) of the requesting LEA, via interfaces HI2 and HI3, respectively.
A lawful authorization may describe the interception target, the interception period, and the IRI and the CC that are
allowed to be delivered for this LEA. For different authorizations, different constraints may apply that further limit the
general restrictions set by the law. The interception target may also be described in different ways in a lawful
authorization (e.g. subscriber address, physical address, services, etc.).
A target may be the subject of interception of different authorizations. It is necessary to support strict separation of
these lawful interceptions. It is therefore possible that more than one lawful authorization may be issued relating to the
same interception target. These various lawful interceptions may contain different constraints on the IRI and the CC.
These various lawful interceptions may fall under different laws.

Figure 4.2.1-1: General provisioning flow
4.2.2 Entities
The entities in the functional flow in figure 4.2.1-1 are given in table 4.2.2-1.
ETSI
11 ETSI TS 104 007 V1.2.1 (2025-05)
Table 4.2.2-1: Provisioning entities
Entity Role
Authority The authorization authority is a judicial or administrative body designated by local laws
or regulations. It gives the LEA the lawful authorization to intercept a target.
LEA The LEA requests that the CSP intercept communications according to a lawful
authorization.
The LEA receives, through a Law Enforcement Monitoring Function, the interception
product (CC and IRI) relating to a target identity.
CSP An entity which provides communication services to subscribers.
Target identity The target identity corresponds to the identity of a given interception target, which is an
entity that makes use of a given service offered by a CSP.

4.2.3 Process
The process as described in this clause stands as an example. In a specific country, the national process will be based on
various national laws and circumstances.
The authorization authority requires, through the LEA, the interception of services utilized via the telecommunication
network by the interception target. The LEA receives the communications involving the target identity(ies) which the
CSP has associated with the interception target.
Referring to the functional role model, and assuming that the lawful authorization is to be given to a CSP, actions are
shown in table 4.2.3-1.
Table 4.2.3-1: Functional role model process actions
Reference Action
(see figure 4.2.1-1)
1 An LEA requests lawful authorization from an authorization authority, which may be a court of
law.
2 The authorization authority issues a lawful authorization to the LEA.
3 The LEA sends the request for lawful interception along with the lawful authorization to the
CSP. The CSP determines the relevant target identities from the information given in the lawful
authorization.
4 The CSP causes interception facilities to be applied to the relevant target identities.
5 The CSP informs the LEA that the lawful authorization has been received and acted upon.
Information may be passed relating to the target identities and the target identification.
6 IRI and CC related to the target identity are passed from the CSP facilities to the LEA LEMF.
7 Either on request from the LEA or when the period of authority of the lawful authorization has
expired the CSP will cease the interception arrangements.
8 The CSP signals its facilities to halt interception (see note).
9 The CSP announces the cessation to the LEA (see note).
NOTE: Steps 8 and 9 may be asynchronous.

To apply interception, a network administrator typically requires the following parameters for the special commands:
• Target identification.
• LEMF address for CC.
• LEMF address for IRI.
• Delivery address parameters for LEMF (e.g. for authentication and security).
• Alarm routing (if different from the delivery address).
The syntax of the necessary commands may be different in various systems.
4.2.4 LI lifecycle
Figure 4.2.4-1 depicts the general LI lifecycle state machine.
ETSI
12 ETSI TS 104 007 V1.2.1 (2025-05)

Figure 4.2.4-1: LI lifecycle state machine
After an LEA delivers a warrant to the CSP, the CSP provisions the interception. In the ACTIVE state, the Lawful
Interception system elements detect, capture and deliver interception product to the LEA (labelled "production" in
figure 4.2.4-1). These three production actions occur each time a targeted communication is identified, and therefore
may happen many times during the lifecycle.
Depending on requirements, once provisioned, the LI system can enter directly into the ACTIVE state (immediate
activation of LI), or enter the INACTIVE state (for delayed activation of LI), in which it still requires a RESUME
transition to enter the ACTIVE state. The "production" activities of detect, capture, and deliver from figure 4.2.4-1
happen only in the ACTIVE state. It is in this ACTIVE state only that interception product is delivered to the requesting
LEA.
A transition from ACTIVE to INACTIVE will stop production except for the Delivery of Target Communications
already captured before the transition. A transition from INACTIVE to ACTIVE will resume the process from the
detect action.
If provisioning causes LI to enter the INACTIVE state for a delayed start of interception, once the delay period is over
the RESUME transition will occur moving the LI into the ACTIVE state.
Some jurisdictions may not support the delayed start of the interception. In such cases, provisioning of interception
causes LI to immediately transition to the ACTIVE state, thus the production actions start directly upon provisioning,
and stop directly upon de-provisioning.
5 Functional view
5.1 General
A high-level functional view of the LI architecture is given in figure 5.1-1 below.
ETSI
13 ETSI TS 104 007 V1.2.1 (2025-05)

Figure 5.1-1: Functional architecture
Table 5.1-1 below gives a brief description of these functional elements; however, the reader should be aware that
security requirements and zero-trust principles mean that these functional elements are further subdivided into smaller
logical elements (see clause 6).
Table 5.1-1: High-level functions
Function Description
ADMF LI administrative function. Responsible for controlling the other LI functions within the CSP's
network, in response to warrant and tasking information received from the LEA administrative
function (see note).
MDF Mediation and delivery function. Packages LI product coming from ELIs for onwards delivery and
fan-out to the relevant LEAs.
ELI Element of LI. All-encompassing term for any function that performs LI functions.
LEA Admin LEA administrative function. Responsible for providing warrant and tasking information to the CSP.
LEMF Law Enforcement Monitoring Facility. Responsible for receiving LI product from the CSP.
NOTE: Multiple/distributed ADMF deployment models are possible, but out of scope of the present document.

Table 5.1-2 below gives a brief description of the interfaces shown; however, the reader should be aware that security
requirements and zero-trust principles imply that the security architecture subdivides these interfaces (see clause 6).
Table 5.1-2: High-level interfaces
Interface Description
HI1 The HI1 interface is used to send warrant and other interception request information
between the LEA and the CSP.
HI2 The HI2 interface is used to send IRI from the MDF to the LEMF.
HI3 The HI3 interface is used to send CC from the MDF to the LEMF.
X1 The X1 interface is used for provisioning and control of LI functions in the network.
X2 The X2 interface is used to deliver intercept related information.
X3 The X3 interface is used to deliver content.

ETSI
14 ETSI TS 104 007 V1.2.1 (2025-05)
6 Security first approach
6.1 Introduction
6.1.1 Approach
This architecture is rooted in the Zero Trust principles outlined by NIST SP 800-207 [i.4]. The first step is to identify
the resources or assets that the network comprises or uses, which need protection, and allocate each of them to
appropriate trust domains.
6.1.2 Trust domains
6.1.2.1 Trust domain definition
A trust domain is a collection of functions that share the same set of administrative and security policies (particularly
access control). Trust domains are further elaborated on in clause 6.3.
6.1.2.2 Domain separation
In this architecture, trust in the network is based on technical procedures and requirements placed on functions in an
attempt to replace assumed trust of functions on the basis of their location only. Because the network functions where
the Elements of LI (ELIs) reside are dynamically created, this architecture is designed to be able to integrate the
orchestration and management of network functions and the ELIs. Consequently, the ADMF shall contain functions that
handle the trust establishment of ELIs, as they are instantiated and as they evolve through their life cycle. The ADMF
further contains functions to manage the LI interfaces and the LI operations that provide intercepted information to the
LEA. Moreover, functions for orchestration of ELIs should be kept isolated from LI intercept run-time operations. In
such context, this architecture contains a logical separation of trust domains and requirements on how information
exchange between trust domains is to be handled to reduce risk of compromise propagation.
6.1.2.3 Controlled interconnection
Functions in different trust domains need to exchange information. APIs that are used inside a trust domain shall be
separated and protected from APIs that facilitate the interconnections for cross-trust-domain exchanges. This separation
and controlled interconnect of trust domains in this architecture is embodied in a newly defined Cross Trust Domain
GateWay (CTDGW). Figure 6.1.2.3-1 introduces the concept.

Figure 6.1.2.3-1: Cross-trust-domain gateway
6.1.2.4 Cross-trust-domain gateway deployment
Figure 6.1.2.3-1 is necessarily simplistic in introducing the idea of a CTDGW, as it shows the CTDGW spread across
trust domains. This is clearly not possible in practice, as CTDGWs will belong to one or the other domain and can be
deployed independently of the functions and trust domains they separate or within them. Figure 6.1.2.4-1 offers the
possible combinations.
ETSI
15 ETSI TS 104 007 V1.2.1 (2025-05)

Figure 6.1.2.4-1: CTDGW deployment options
This clarifies that the domain that implements the CTDGW is the one and same domain that establishes the policy that
governs the west/eastbound flows. Certainly, both domains can choose to deploy local CTDGWs, based on local
security policy or criteria.
6.2 LI assets
6.2.1 Identifiers are fundamental LI assets
In the LI domain, a central resource, or asset, is the target ID. Further important assets (or resources) are: the lifecycle
state of LI, the interception product, points of interception, topology/connectivity information, etc. However, these are
arguably downstream derivatives of the fundamental assets. Figure 6.2.1-1 contextualizes the main identifiers and
places them in top-level trust domains.

Figure 6.2.1-1: Primary LI assets
There are two main trust domains of interest: the network trust domain (A) and the LI trust domain (B). Table 6.2.1-1
defines these identifiers.
ETSI
16 ETSI TS 104 007 V1.2.1 (2025-05)
Table 6.2.1-1: Identifiers
Identifier Description
NFIID The identifier of the Network Function that contains the data of interest to LI. The NFIID is
the value assigned to the network function instance by the orchestration layer.
ELIID The ID of the Element of LI that is tasked to perform any LI function.
WarrantID The ID of the warrant (or legal administrative instrument) provided by the LEA to the CSP.
LEAID The ID of the Law Enforcement Agency that presented the warrant to the CSP.
LIID The ID assigned by the CSP that ties together all other IDs.
TargetID The original ID derived by the CSP from information presented by the LEA in the warrant.
TargetID' The network may derive other targetIDs from the initial targetID.
ProductID The ID assigned by the CSP to the interception product.

The landscape of the architecture quickly complicates when the lifecycle of the identifiers is considered. Each identifier
is spawned and managed in one trust domain but may continue to be managed while being used by functions within
other trust domains. Specifically, the lifecycle of the ELI is inherently tied to the lifecycle of the encompassing NF, but
an NF and its associated ELI are managed and controlled from different trust domains. The identifiers are used, and
therefore transferred, between trust domains, as in figure 6.2.1-2.

Figure 6.2.1-2: Identifiers cross trust domains
Through the lifecycle of LI, ID usage and projection is even more complicated, as seen in figure 6.2.1-3 which
introduces the concept of sub-trust-domains which will be expanded in clause 6.4.

Figure 6.2.1-3: Identifiers project across sub-trust-domains
ETSI
17 ETSI TS 104 007 V1.2.1 (2025-05)
6.2.2 Further LI assets
As previously indicated, reducing the security of the LI domain to the security of target IDs is simplistic. Further assets
to consider in a holistic approach to the security of LI are the lifecycle state of LI, the interception product, points of
interception, topology/connectivity information, the separation of sub-trust domains, the assignment of administrators in
and across trust domains, etc. This is beyond the scope of the present document but has to be considered in LI
deployments.
6.3 Trust domains
6.3.1 Introduction to trust domains
Protecting the identifiers gives rise to the idea of segregating them into Trust Domains (TDs). TDs are central to the
security of the LI architecture. In the spirit of complying with the NIST-defined Zero Trust Architecture (ZTA) [i.4]
where TDs are central, as a consequence TDs are also foundational in the LI architecture defined in the present
document.
To reiterate, a trust domain is a collection of functions that share the same set of administrative and security concerns
and policies (particularly access control). It is expected that compartmentalization of trust domains spans the vertical
stack of functionality in the CSP network, ideally from hardware to the application layer. Administrators in the CSP
network are assigned to one or more trust domains based on CSP criteria, using state of the art Attribute Based Access
Controls (ABAC). In virtual networks, multiple trust domains should be considered by CSPs during the deployment
phase, where a CSP wishes to achieve security role and management separation, security isolation, separation between
sensitive and non-sensitive components, etc. Whether or not a CSP uses these concepts in their networks, if a network is
LI obligated, a CSP shall use them in the LI space.
6.3.2 Trust domain collapse
The present document is not prescriptive in the trust do
...