Lawful Interception Explained: ETSI, 3GPP LI, CALEA and Wiretap Risk

Lawful interception (LI) is the capability a telecom or internet provider builds into its network so that, when served with a warrant or other legal authorisation, it can copy one target's communications and the data describing them and hand both to a law enforcement agency. ETSI and 3GPP standardise the plumbing, laws such as the US Communications Assistance for Law Enforcement Act (CALEA) make it mandatory, and the same capability is a high value target for anyone who wants to spy without a warrant.

An intercept system is a switch that, once flipped, quietly duplicates someone's traffic to another destination, and the standards require it to be invisible to the target and to most of the provider's own staff. If the wrong person reaches that switch, the secrecy that protects an investigation also hides the abuse. This post covers the architecture at a conceptual level, the legal duties as written in the primary texts, two officially documented cases, and a governance and hardening checklist for the teams that run these systems. It is not legal advice, and it does not describe how to reach or operate intercept interfaces.

Key takeaways

• LI is targeted and warrant driven. It differs from data retention (records kept about everyone) and from a provider's own monitoring for billing, fraud or operations.
• ETSI defines three handover interfaces. HI1 carries the warrant, HI2 carries intercept related information (IRI) and HI3 carries content of communication (CC). ETSI TS 103 120 covers much of HI1; TS 102 232-1 covers IP delivery for HI2 and HI3.
• Inside the network, X1 tasks the equipment. ETSI TS 103 221 defines X1 (administration), X2 (IRI) and X3 (content); 3GPP uses LI_X1, LI_X2 and LI_X3.
• 3GPP splits LI into three specs: TS 33.126 (requirements), TS 33.127 (architecture) and TS 33.128 (protocols), currently at Release 19 versions 19.3.0, 19.8.0 and 19.8.0.
• CALEA (1994) makes US carriers intercept capable, and since 2005 the FCC has applied it to facilities based broadband and interconnected VoIP. Section 105 requires lawful authorisation plus the affirmative intervention of a carrier employee.
• Built in intercept capability is a standing risk. In the 2004 to 2005 Athens affair rogue software used an operator's own intercept function to tap about 100 phones, and in November 2024 the FBI and CISA said PRC affiliated actors copied information subject to US court ordered requests.
• End to end encryption limits LI to metadata when the user, not the provider, holds the keys.
• Governance is the main control: segmentation, separation of duties, tamper evident logs, reconciliation of active intercepts against the warrant register, and a patched, inventoried mediation stack.

What is lawful interception, and how is it different from data retention and provider monitoring?

ETSI describes its LI work as standards supporting "common international requirements for law enforcement agencies, including the interception of content and disclosure of electronic communications related data." In practice LI has four defining properties:

1. Targeted. An intercept is tied to an identifier such as a phone number, subscriber identity or IP address named in a specific legal authorisation.
2. Time bound. 3GPP TS 33.126 requirement R6.5-10 says the provider "shall ensure that Lawful Interception is performed only for the time period as specified in the Warrant." In the US, 18 U.S.C. 2518(5) caps a Title III order at what is necessary and in any event thirty days, with extensions only on a new application and new judicial findings.
3. Real time. CALEA (47 U.S.C. 1002(a)) speaks of intercepting communications "concurrently with their transmission," or later only if the government accepts that.
4. Covert. TS 33.126 clause 6.6 requires that the target, other users, other agencies, other providers and non authorised staff or processes cannot detect the interception.

Retained data is different. Retention means a provider keeps certain records about every subscriber for a set period so an authority can request them later: historical, covering everyone, usually metadata. The EU tried to harmonise this with the Data Retention Directive (2006/24/EC). On 8 April 2014 the Court of Justice of the European Union declared it invalid in Digital Rights Ireland (joined cases C-293/12 and C-594/12), finding "a wide-ranging and particularly serious interference" with private life and data protection that was not limited to what is strictly necessary. National retention rules still exist in various forms, and ETSI TS 103 120 notes its warrant interface could also serve "retained data requests, seized data requests, data preservation orders and other similar legal requests."

A provider's own monitoring is different again. Flow records for capacity planning, call detail records for billing, signalling analytics for fraud and packet captures for troubleshooting are not lawful interception. They are not triggered by a warrant and not delivered to an agency. The security overlap is physical: the taps, packet brokers and analytics platforms that serve operations can sit close to interception points, and mixing them is one way intercept data leaks into systems with weaker access control.

What architecture do the ETSI standards define?

ETSI's Technical Committee on Lawful Interception produces the reference model most equipment follows. It separates the parts of the provider's network that do the interception from the parts that talk to the agency, with mediation in between.

The administration function and HI1

On the agency side, a law enforcement monitoring facility (LEMF) receives results. On the provider side, an administration function (the ADMF in ETSI and 3GPP documents) receives the warrant, validates it, and turns it into tasks.

The interface that carries the warrant is HI1. It was historically often manual: a signed order or a call to a 24 hour desk. ETSI TS 103 120, "Interface for warrant information," defines an electronic version "between two systems for the exchange of information relating to the establishment and management of lawful required action, typically Lawful Interception." It is "designed to provide a large part of the functionality for HI-1" and "is not designed to be used for HI-2 (delivery of intercept related information) or HI-3 (delivery of communications content)." The current version is V1.24.1 (August 2026). Moving the warrant from paper to software improves auditability, but the integrity of the warrant channel then depends on authentication and on the security of the systems at both ends.

Mediation, HI2 and HI3

Once a task is active, interception points produce two kinds of output:

• Intercept related information (IRI): who contacted whom, when, from which cell or access network, using which service. The US statutory equivalent, "call-identifying information" in 47 U.S.C. 1001, means "dialing or signaling information that identifies the origin, direction, destination, or termination of each communication."
• Content of communication (CC): the voice, messages or packets themselves.

A mediation function correlates that output with the warrant, formats it and delivers it: HI2 for IRI and HI3 for CC. ETSI TS 102 232-1 "specifies the general aspects of HI2, HI3, and HI4 interfaces for handover via IP based networks," including headers and transfer protocols; HI4 carries notifications about the LI service itself. Parts 2 to 7 of TS 102 232 define service specific IRI formats. The current part 1 version is V3.38.1 (August 2026). Its scope defers to 3GPP for mobile: it "does not override or supersede" TS 33.108 for GSM and UMTS, and where it conflicts with TS 33.128, TS 33.128 applies.

The internal interfaces: X0, X1, X2 and X3

ETSI TS 103 221-1 describes a second set of interfaces that never leave the provider, between administration and mediation and the "network internal functions, which facilitates the interception of communication":

TS 103 221-1 specifies X1 (current version V1.23.1, March 2026); part 2 covers X2 and X3. For a security architect, X1 is the most sensitive interface in the design. HI1 describes what an agency asked for. X1 is what makes the equipment do it.

Putting it together

How is lawful interception built into mobile networks?

3GPP, which writes the GSM, UMTS, LTE and 5G specifications, splits LI into three documents.

TS 33.126: requirements

TS 33.126 "specifies Stage 1 Lawful Interception requirements for 3GPP networks and services," adding that "the presence of a requirement in the present document does not in itself imply or mandate" any obligation. National law decides what is mandatory; 3GPP describes what equipment must be able to do. The security relevant requirements are unusually explicit:

• Lawful compliance (6.5): interception only for the warrant period (R6.5-10), notification of activation, change and deactivation (R6.5-30 to 50), correlation of all target communications with the warrant (R6.5-60), and a record retention policy "able to document the handling of the intercepts" (R6.5-70).
• Undetectability (6.6): by the target, other users, "non-authorized personnel or processes (including automated or Artificial Intelligence based systems)," other agencies, providers and countries (R6.6-10 to 70), with knowledge of interception capabilities limited to authorised parties (R6.6-80).
• Records and delivery integrity (6.6): LI management records "(e.g. log files)" visible only to authorised personnel (R6.6-100); a mechanism "(e.g. cryptographic hashing)" so they "cannot be unnoticeably altered" (R6.6-110); authenticity, confidentiality and integrity of delivery and mutual authentication with the agency (R6.6-120 to 150); and, for virtualised networks, ETSI GS NFV-SEC 012 for sensitive components (R6.6-160).

That list is a good template for any high risk administrative system: least knowledge, tamper evident logs, authenticated delivery and failure isolation. The current version is 19.3.0, uploaded to 3GPP on 20 June 2025 and republished by ETSI as TS 133 126 V19.3.0 in January 2026.

TS 33.127: architecture and functions

TS 33.127 "specifies both the architectural and functional system requirements for Lawful Interception (LI) in 3GPP networks," supporting "both network layer based and service layer based Interception." Its names map closely to ETSI's:

Annex A lists POIs in a non roaming 5G network in the AMF, UDM, SMF, UPF, SMSF, NEF and NWDAF. Interception capability is therefore distributed across the core: registration and mobility at the AMF, subscriber data at the UDM, sessions at the SMF and user traffic at the UPF. For what those functions do, see our explainer on the 5G core and its network functions; for the signalling transport underneath, see SCTP and telecom signalling security.

Two parts of TS 33.127 matter for a cloud native core.

Logging is in the specification. Clause 8.7 says LI functions "shall support securely creating, buffering and transporting log records" of lifecycle events, including addition, deletion, modification and retrieval of tasks and delivery destinations, status queries, configuration changes via LI_X0, errors, transport connections and "any unsuccessful communication attempt over any of the interfaces." It asks for "particular attention" to ensuring "that logs cannot be accessed or modified by unauthorised actors," says "by default logging shall be enabled," and allows logs to be stored "separately from any other logging system in the network."

Virtualisation puts LI in the software supply chain. The NFV clauses note that "some default LI configuration information will need to be provided as part of the VNF image packages and package descriptor files," and that it "needs to be adequately protected within NFV MANO and software catalogues." Storage of LI data in shared data stores "shall be auditable," and that storage interface must be protected so "an attacker cannot identify targeted users based on observation of this interface." An image catalogue holding LI enabled network function images is part of the intercept system's attack surface.

The current version is 19.8.0, uploaded on 24 September 2026 and published by ETSI as TS 133 127 V19.8.0 in October 2026.

TS 33.128: protocols and procedures

TS 33.128 is the Stage 3 document, now titled "Security; Protocol and procedures for Lawful Interception (LI); Stage 3" (the 3GPP portal notes it was previously "Handover interface for Lawful Interception (LI)"). It defines the message formats and procedures on the LI interfaces and builds on the ETSI TS 103 221 and TS 102 232 families. The current version is 19.8.0, uploaded on 24 September 2026. The relevant point here is that these are public protocol specifications, so their implementations in mediation and core software can be reviewed, tested and patched like any other protocol stack.

A dated timeline

What does CALEA require of US carriers, broadband and VoIP providers?

CALEA was enacted on 25 October 1994. It does not itself authorise interception; that authority comes from laws such as the Wiretap Act (18 U.S.C. 2510 and following) and the pen register statute. CALEA makes sure that when an agency has that authority, the network can deliver.

Section 103: capability requirements

47 U.S.C. 1002(a) says a carrier "shall ensure that its equipment, facilities, or services" that let a customer "originate, terminate, or direct communications" can, in summary: expeditiously isolate and enable the government, under a court order or other lawful authorisation, to intercept a subscriber's communications "to the exclusion of any other communications"; expeditiously provide reasonably available call identifying information associated with each communication (with location excluded when acquired solely under pen register and trap and trace authority, beyond what the phone number reveals); deliver both in a format the government can transport off premises; and do this unobtrusively while protecting communications not authorised to be intercepted.

Subsection (b) sets the limits. Law enforcement cannot require "any specific design of equipment, facilities, services, features, or system configurations" or prohibit any feature. The requirements do not apply to "information services," private networks or carrier interconnection facilities. And a carrier "shall not be responsible for decrypting, or ensuring the government's ability to decrypt, any communication encrypted by a subscriber or customer, unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication."

Section 105: systems security and integrity

47 U.S.C. 1004 reads in full: "A telecommunications carrier shall ensure that any interception of communications or access to call-identifying information effected within its switching premises can be activated only in accordance with a court order or other lawful authorization and with the affirmative intervention of an individual officer or employee of the carrier acting in accordance with regulations prescribed by the Commission."

That sentence contains two controls: legal authorisation, and a named person inside the carrier who must act. The FCC rules in 47 CFR Part 1, Subpart Z make them concrete:

• 1.20003 requires a senior officer or employee responsible for that control, and written policies stating that personnel need both "appropriate legal authorization and appropriate carrier authorization," how long records are kept, and 24 by 7 contacts. Carriers must report to affected agencies "any act of compromise of a lawful interception" to unauthorised persons and "any act of unlawful electronic surveillance that occurred on its premises."
• 1.20004 requires "a secure and accurate record of each interception of communications or access to call-identifying information, made with or without appropriate authorization," including the numbers or circuits involved and the start date and time.
• 1.20005 requires filing these policies with the FCC before starting service and within 90 days of a merger, divestiture or amendment; since 29 June 2023 these system security and integrity (SSI) plans go through the CALEA Electronic Filing System.

Note "made with or without appropriate authorization." The rule expects carriers to record unauthorised interceptions too, which only works if records sit where an intruder or rogue insider cannot quietly edit them.

Broadband and VoIP since 2005

The FCC's CALEA page states: "In 2005, the Commission extended coverage of CALEA to include facilities-based broadband Internet access providers and providers of interconnected Voice over Internet Protocol (VoIP) service." It adds that industry generally sets CALEA standards, that the FCC does not review manufacturer developed solutions, and that a carrier may build its own solution, buy one from its equipment makers, or use a trusted third party. That third party option matters for supply chain risk: an outsourced mediation service becomes part of the carrier's intercept system. For public statistics on how often content interception is authorised, the Administrative Office of the US Courts publishes an annual Wiretap Report.

The January 2025 declaratory ruling

On 16 January 2025 the FCC released FCC 25-9 (PS Docket No. 22-329, adopted 15 January 2025, with two commissioners dissenting). It concluded "that section 105 of CALEA affirmatively requires telecommunications carriers, as defined in CALEA, to secure their networks from unlawful access to or interception of communications," and that this extends "not only to the equipment they choose to use in their networks, but also to how they manage their networks." Its background cited press reports of intrusions into infrastructure "used to cooperate with lawful federal requests for wiretaps and communications data." Commission positions on this docket can change, so check PS Docket No. 22-329 for current status before relying on it.

Comparable regimes elsewhere

Most countries impose intercept capability duties through national law, and ETSI's standards exist because European governments wanted common technical requirements across many national regimes. Who authorises an intercept, for how long, whether a judge is involved and who audits it all vary. 3GPP acknowledges this by leaving the applicable subset to national regulation. For a multi country operator, the architecture is shared but the authorisation workflow, retention periods and oversight reporting are per jurisdiction. Take country specific legal advice; this post does not summarise other national statutes.

Why are built in intercept capabilities a security risk?

Every LI design assumes the only people who can turn on an intercept are authorised staff acting on a valid warrant. The capability exists whether or not that holds, and three failure modes recur.

1. Insider abuse. Someone with access to the administration function creates a task without a warrant, extends one past its end, or adds a delivery destination. Undetectability means the target will not notice and, because knowledge is restricted, most colleagues will not either. Separation of duties and independent reconciliation are what catch this.
2. Compromise of the intercept or mediation system. An outside attacker who controls an administration function, POI or mediation server inherits a ready made, covert collection system.
3. Leakage of targeting data. Even without new taps, access to mediation systems or logs reveals who is under investigation, which is valuable to a foreign service or a criminal group.

The Athens affair (2004 to 2005)

The best documented case is the Athens affair, reconstructed by Vassilis Prevelakis and Diomidis Spinellis in IEEE Spectrum ("The Athens Affair," 29 June 2007) from Greek parliamentary depositions, a report by the Hellenic Authority for the Information and Communication Security and Privacy (ADAE), and documentation. According to that account:

• The bugging began in the run up to the August 2004 Olympics and went unnoticed until 24 January 2005, when a switch generated errors about undelivered text messages.
• The victims were customers of Vodafone Greece, including the prime minister, several ministers, senior military and law enforcement officials, activists, journalists and a US embassy employee. Rogue software used "the lawful wiretapping mechanisms" of the operator's switches to tap about 100 phones.
• The exchange's intercept subsystem held a list of active taps, and an optional management system held the list of lawful requests; comparing the two would expose a tap with no request. The article reports the operator had not purchased that management system, so there was nothing to reconcile against.
• Per the ADAE report as described in the article, the rogue code altered the exchange's command handling so it could disable the transaction log and its alarm while running intercept commands, hid from routine integrity checks, and added a new user account. The authors call it the first rootkit they knew of on a special purpose telephone switch.
• On 4 March 2005 the switch manufacturer alerted the operator to unauthorised software in two central offices; it was isolated on 7 March and removed on 8 March, which the authors say tipped off the perpetrators. The operator was fined 76 million euros in December 2006.

The intercept function worked as designed; the assurance around it failed. There was no independent record of authorised requests, logging could be switched off from the system it watched, and software could change on a live switch without verification against a known good build. TS 33.126 R6.6-110 and TS 33.127 clause 8.7 read like direct answers to this case.

Telecom intrusions reported in 2024 and 2025

On 13 November 2024 the FBI and CISA said their investigation into PRC targeting of commercial telecoms had "revealed a broad and significant cyber espionage campaign," in which PRC affiliated actors compromised multiple telecom companies to enable theft of customer call records, compromise of private communications of a limited number of people mainly in government or politics, and "the copying of certain information that was subject to U.S. law enforcement requests pursuant to court orders." The statement does not describe how intercept or mediation systems were reached, and we will not speculate beyond it.

On 4 December 2024, CISA, NSA, FBI and partners in Australia, Canada and New Zealand published "Enhanced Visibility and Hardening Guidance for Communications Infrastructure." Joint advisory AA25-239A (last revised 3 September 2025) describes state sponsored actors targeting "large backbone routers of major telecommunications providers, as well as provider edge (PE) and customer edge (CE) routers," then going after authentication infrastructure such as TACACS+. For LI teams the message is that management plane weaknesses which expose routers also expose any administrative system reachable from them.

Why "only lawful users can operate it" is not a security property

A capability that can be activated remotely, is designed to be invisible to the people watched, and exists in every core function is attractive to anyone who can reach its control plane. Whether LI should exist is a question for legislatures. The engineering position is to build and audit it as the highest privilege system in the network.

How does end to end encryption change what lawful interception can capture?

LI copies what passes through the provider's equipment. If the provider applies the encryption, it can remove it; if the user's app applies it end to end, it usually cannot.

• 3GPP TS 33.126 R6.4-160: "The CSP shall remove any encryption it provides or manages before Delivery of the Interception Product to the LEA, or shall provide the LEA the information necessary to decrypt." R6.4-170 adds that if the provider supplies keys to the target without running the encryption service, it must provide the keys.
• 47 U.S.C. 1002(b)(3): no duty to decrypt subscriber encryption unless the carrier provided it and holds what is needed to decrypt.

Radio encryption between handset and mobile network is the operator's own, and interception points sit inside the core where traffic is in clear, so a call on the operator's voice service is available as content. A message in an end to end encrypted app reaches the user plane as ciphertext; HI3 delivers ciphertext, and CALEA does not require the operator to break it. What usually remains visible:

That is why agencies increasingly direct requests to app and cloud providers, usually for stored data under different legal processes rather than real time network interception. For where else traffic can be observed, see how attackers intercept network traffic across copper, fibre and Wi-Fi and transparent proxies and the risks of interception.

Content, IRI, retained data and app requests compared

This is orientation, not legal advice; the exact process depends on the data, the jurisdiction and the investigation.

How should a carrier or ISP security team harden lawful interception systems?

Treat the LI stack (administration function, mediation, interception points, log stores, and the HI and X interfaces) as its own security domain with its own owners, segment and evidence trail. The steps below draw on TS 33.126, TS 33.127, the FCC rules and the December 2024 CISA guidance, and assume you are the operator securing your own systems.

Step 1: Map the system and name an owner

List every component that can create, modify, carry or store an intercept: administration function, mediation servers, every network function or switch with a POI, triggering functions, log collectors, the HI1 gateway and any third party mediation service. Record software version, administrators, networks and exposed interfaces. 47 CFR 1.20003 already requires a senior officer; make that person the accountable owner of this map.

Step 2: Isolate the management plane

CISA's guidance says to "use an out-of-band management network that is physically separate from the operational data flow network," to manage devices only from it, and to block lateral management connections. For LI: X1 reachable only from the administration function, the administration function only from a few hardened operator workstations, nothing from the corporate network, default deny with logged denials. An illustrative nftables policy for an administration host (adapt names and addresses, and mirror it on network firewalls):

# /etc/nftables.d/li-admin.nft (illustrative)
table inet li_admin {
  set operator_ws {
    type ipv4_addr
    elements = { 10.40.0.11, 10.40.0.12 }   # dedicated LI operator workstations
  }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iifname "lo" accept
    iifname "oob0" ip saddr @operator_ws tcp dport { 22, 443 } accept
    log prefix "li-admin-deny " flags all counter drop
  }
  chain output {
    type filter hook output priority 0; policy drop;
    ct state established,related accept
    oifname "lo" accept
    oifname "x1net0" ip daddr 10.50.0.0/24 tcp dport 443 accept   # tasking to POIs only
    oifname "logs0" ip daddr 10.60.0.5 tcp dport 6514 accept      # remote log vault
    log prefix "li-admin-egress-deny " flags all counter drop
  }
}

Check syntax before loading, then confirm what is active:

sudo nft -c -f /etc/nftables.d/li-admin.nft && sudo nft -f /etc/nftables.d/li-admin.nft
sudo nft list table inet li_admin

Step 3: Separate duties and remove shared accounts

Three roles, three people: the legal reviewer who validates an authorisation, the operator who provisions the task, and the auditor who reconciles tasks against warrants. Nobody both approves and provisions. Every account is personal with multi factor authentication, which is also what makes the "individual officer or employee" in section 105 meaningful. CISA says to "validate all accounts and disable inactive accounts." On Linux based mediation hosts:

getent group li-operators li-admins                      # who holds LI privileges
sudo lastlog | awk 'NR==1 || $2 != "**Never"'             # spot dormant accounts
for u in $(getent group li-operators | cut -d: -f4 | tr ',' ' '); do sudo -l -U "$u"; done

Give vendor support time limited, ticket bound access through a monitored jump host, never a standing password.

Step 4: Log every task change off box, tamper evidently

TS 33.127 clause 8.7 lists what to log and turns logging on by default; TS 33.126 R6.6-110 asks for hashing or similar so records cannot be silently altered; CISA says to encrypt log transport and "store copies of logs off-site to ensure they cannot be modified or deleted." An illustrative rsyslog rule forwarding over mutually authenticated TLS:

# /etc/rsyslog.d/60-li-forward.conf (illustrative)
global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/pki/li-logs/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/pki/li-logs/host.pem"
  DefaultNetstreamDriverKeyFile="/etc/pki/li-logs/host.key"
)
action(
  type="omfwd" target="logvault.li.internal" port="6514" protocol="tcp"
  StreamDriver="gtls" StreamDriverMode="1"
  StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="logvault.li.internal"
  queue.type="LinkedList" queue.filename="li_fwd" queue.saveOnShutdown="on"
  action.resumeRetryCount="-1"
)

On the vault, a daily hash chain lets auditors detect edits, because each link includes the previous one:

#!/usr/bin/env bash
# append today's LI log digest to a hash chain (run on the log vault)
set -euo pipefail
LOG="/var/log/li/$(date -u +%F).log"
CHAIN="/var/lib/li-audit/chain.txt"
PREV=$(tail -n 1 "$CHAIN" 2>/dev/null | cut -d' ' -f1 || echo GENESIS)
FILE_HASH=$(sha256sum "$LOG" | cut -d' ' -f1)
LINK=$(printf '%s%s' "$PREV" "$FILE_HASH" | sha256sum | cut -d' ' -f1)
printf '%s %s %s\n' "$LINK" "$FILE_HASH" "$LOG" >> "$CHAIN"

Keep the chain on retention locked storage, with credentials held by the auditor, not the operator.

Step 5: Reconcile active tasks against the warrant register

Athens turned on the absence of a request list to compare with active taps. Export active tasks from the administration function and authorisations from your legal case system, and compare them on a schedule the auditor owns:

#!/usr/bin/env python3
# reconcile.py: flag LI tasks with no matching, in-date authorisation (illustrative)
import csv, datetime, sys

today = datetime.date.today()
register = {}
with open(sys.argv[1]) as f:            # warrant_register.csv: auth_id,target_id,start,end
    for r in csv.DictReader(f):
        register[r["auth_id"]] = r

problems = []
with open(sys.argv[2]) as f:            # active_tasks.csv: task_id,auth_id,target_id,destination
    for t in csv.DictReader(f):
        w = register.get(t["auth_id"])
        if w is None:
            problems.append((t["task_id"], "no authorisation on file"))
            continue
        if w["target_id"] != t["target_id"]:
            problems.append((t["task_id"], "target does not match authorisation"))
        if today > datetime.date.fromisoformat(w["end"]):
            problems.append((t["task_id"], "authorisation expired " + w["end"]))

for task, why in problems:
    print(f"ALERT task={task}: {why}")
sys.exit(1 if problems else 0)

Also compare each task's delivery destination with an approved list; a new destination matters as much as a new target. Where equipment supports it, compare the administration function's view with what the POIs report, since a compromised administration function can misreport its own state.

Step 6: Secure HI and X interfaces in transit

TS 33.126 R6.6-120 to 150 require authenticated, confidential, integrity protected delivery and mutual authentication with the agency. Hold internal X1, X2 and X3 traffic to the same standard: mutually authenticated TLS with certificates from a dedicated LI certificate authority, short lifetimes, no keys shared across sites, and the CA kept offline or in a hardware security module with every issuance logged.

Step 7: Treat mediation software as software that gets patched

Mediation platforms, administration functions and LI enabled network function images run on operating systems and ship TLS libraries, web frameworks, parsers and database drivers, many open source. "Do not touch the LI box" is a common rule because change can break a legal obligation, and the result is often an unpatched, rarely inventoried system at the centre of the most sensitive workflow in the company. Ask suppliers for a software bill of materials (SBOM) per release, test each release against a test LEMF, and patch on a schedule agreed with legal. Because LI configuration ships inside VNF image packages, your image catalogue, signing keys and MANO access control belong in this step too.

Step 8: Rehearse the incident

Decide in advance who is told when reconciliation finds a mismatch, how evidence is preserved, how the task is suspended, and which agencies must be notified under 47 CFR 1.20003(c). The Athens account shows the cost of removing rogue code before preserving logs. Exercise the playbook with legal and law enforcement liaison staff present.

Summary checklist

Common mistakes

• LI management interfaces on shared networks. X1 or the administration console reachable from operations or corporate networks turns any compromise there into a path to tasking.
• Shared or default accounts on mediation devices. A shared login defeats the idea of an individual employee intervening and makes every log entry useless as evidence.
• No independent audit trail. Logs kept only on the device they describe, or editable by the people who provision tasks. Logging that can be switched off from the system it watches is not a control.
• One way reconciliation. Checking that each warrant has a task, but not that each task has a warrant and an approved destination.
• Unpatched mediation software treated as untouchable. Agree a tested patch process with legal instead of freezing the stack for years.
• Unprotected network function images. LI defaults ship inside VNF images, so a writable catalogue can change intercept behaviour at scale.
• Mixing operational monitoring and LI tooling, which carries intercept data into systems with weaker controls.
• Deleting rogue code before preserving evidence.
• Assuming a third party mediation provider takes the risk away. The carrier keeps its section 105 obligations.

FAQ

What is lawful interception in simple terms?

A provider's built in ability to copy a specific person's communications and related data, when legally ordered, and deliver them to a law enforcement agency. It is targeted, time limited and designed so the target cannot tell.

What are HI1, HI2 and HI3?

The three ETSI handover interfaces. HI1 carries the warrant and administration, HI2 carries intercept related information such as call events and location, and HI3 carries content. ETSI TS 103 120 covers much of HI1; TS 102 232-1 covers IP delivery for HI2 and HI3.

What is the difference between X1, X2, X3 and the HI interfaces?

X interfaces stay inside the provider: X1 tasks interception points, X2 carries IRI and X3 carries content (ETSI TS 103 221; LI_X1 to LI_X3 in 3GPP). HI interfaces connect the provider to the agency.

Which 3GPP specifications cover lawful interception in 5G?

TS 33.126 (requirements), TS 33.127 (architecture and functions) and TS 33.128 (protocols and procedures), at Release 19 versions 19.3.0, 19.8.0 and 19.8.0 as of October 2026.

Does CALEA apply to internet providers and VoIP?

Yes, per the FCC, since 2005 for facilities based broadband internet access and interconnected VoIP, in addition to traditional carriers. The statute exempts "information services" from the capability requirements.

Can lawful interception read end to end encrypted messages?

Not by itself. Providers must remove encryption they provide or manage, but under 47 U.S.C. 1002(b)(3) a carrier need not decrypt subscriber encryption it did not provide. Metadata such as session times, volumes and destination addresses usually stays visible.

What was the Athens affair?

From 2004 to early 2005, rogue software on a Greek mobile operator's switches used the built in intercept function to tap about 100 phones, including the prime minister's, according to IEEE Spectrum's reconstruction from parliamentary and regulator records. It was found in January 2005 and removed in March 2005.

Who must approve a lawful intercept inside a US carrier?

47 U.S.C. 1004 requires a court order or other lawful authorisation plus the affirmative intervention of an individual carrier officer or employee. 47 CFR 1.20003 requires a responsible senior officer and policies demanding both legal and carrier authorisation.

Where Safeguard fits

Safeguard does not operate, monitor or audit lawful interception systems, and it does not inspect switches, routers or mediation appliances. Its fit is indirect: mediation platforms, administration functions and cloud native network functions are built from open source components and container images, and Step 7 depends on knowing what is inside them. Safeguard scans SBOM files, container images and repositories, matches components against vulnerability databases, shows which projects and products contain a given component version, and evaluates policies and gates before a build ships. A team can run safeguard scan --sbom mediation-release.cdx.json on a supplier's SBOM, or safeguard scan --image with an internally built network function image, and read the JSON results under ./output. Warrant validation, reconciliation and logging remain the operator's job.

Lawful intercept stacks carry the same open source dependencies as any other server software, and a mediation release that is never rebuilt keeps its old libraries for years. The section below covers how Safeguard helps close the gap between a published fix and the software you actually run; the fork and patch path it describes is generally available.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The Safeguard CLI demo shows a real session: the assistant reads a finding and its advisory, asks before any command that changes something, edits a dependency, runs the install and tests with approval, and pushes nothing. For an LI team the same flow fits an internal tool or containerised mediation component your engineers build, where unreviewed changes are not acceptable.

Click through it at your own pace, or open it full screen.

The local runner demo shows setting up the runner on your own machine, approving it with its device code and scanning from the terminal. Intercept environments are usually isolated, so scanning on hardware you control inside that segment matters.

Click through it at your own pace, or open it full screen.

The Claude with Safeguard demo shows connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. During a patch review that keeps a question such as "which of our network function images contain this library" and the tool permissions explicit.

Click through it at your own pace, or open it full screen.

Install the CLI from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

Quick check

Sources

• ETSI: lawful interception work (cybersecurity, privacy and users)
• ETSI TS 103 120 V1.24.1, interface for warrant information
• ETSI TS 102 232-1 V3.38.1, IP handover, part 1
• ETSI TS 103 221-1 V1.23.1, X1
• 3GPP TS 33.126 specification page
• ETSI TS 133 126 V19.3.0
• 3GPP TS 33.127 specification page
• ETSI TS 133 127 V19.8.0
• 3GPP TS 33.128 specification page
• FCC: CALEA
• 47 U.S.C. 1001
• 47 U.S.C. 1002
• 47 U.S.C. 1004
• 47 CFR Part 1, Subpart Z
• 18 U.S.C. 2518
• FCC 25-9 Declaratory Ruling
• IEEE Spectrum: The Athens Affair
• FBI and CISA joint statement, 13 Nov 2024
• CISA: hardening guidance for communications infrastructure
• CISA AA25-239A
• CJEU press release 54/14
• US Courts: Wiretap Reports

Last reviewed: 25 October 2026. ETSI and 3GPP publish new versions of these specifications several times a year, and FCC positions on CALEA can change; check the documents above for the versions and rules that apply to you. This post is general information, not legal advice.