Every mobile network ever built was designed to function before it was designed to resist attackers.
From 2G to 5G, mobile networks evolved with a priority on connectivity, interoperability, and speed. Security came later—usually when it was already too late. And that’s exactly why threat modeling in telecom isn't just useful—it's essential.
While threat modeling is well understood in traditional IT and software engineering, applying it to telecom requires a very different mindset. Telecom systems are sprawling, protocol-heavy, often proprietary, and deeply dependent on trust between entities—making them an unusually attractive playground for attackers.
In this post, we’ll break down how threat modeling works in telecom, which assets and entry points matter most, and how to design defenses based not on best practices—but on what real attackers actually do.
Why Telecom Needs a Custom Threat Modeling Approach
Most conventional threat modeling frameworks—like STRIDE, PASTA, or OCTAVE—were built for software systems with bounded scope, APIs, and developer-controlled environments.
Telecom is different.
Mobile networks:
- Span physical, virtual, and radio environments
- Rely on complex, layered protocol stacks (SS7, GTP, Diameter, SIP, HTTP/2, etc.)
- Include legacy systems still in active use (hello, 2G roaming)
- Involve third parties with partial trust (roaming partners, MVNOs, IPX carriers)
- Have protocol stacks where “insecure by design” is often the default
In other words, a SIM card can get a device online, but it can also trigger silent SMS commands or hijack calls. And while HTTP/2 is used in 5G’s Service-Based Architecture, it’s still vulnerable to old-school MITM techniques if TLS isn’t enforced properly.
A threat modeling exercise for telecom needs to focus less on speculative risks and more on actual attacker playbooks.
What Are We Modeling? Assets That Actually Get Attacked
Before modeling threats, you need to define what’s worth protecting. In telecom, these are the assets that consistently appear in real-world pentests and threat reports:
1. Subscriber Identities and Location
- IMSI, SUPI, MSISDN
- SUCI encryption keys
- Roaming identity leaks
- Paging requests linked to device location
2. Authentication & Session State
- AKA flows (EPS-AKA, 5G-AKA, EAP-AKA’)
- Attach, detach, and handover procedures
- KASME, K_SEAF, and other session keys
3. Core Network Functions
- MME, SGW, PGW, AMF, SMF, UPF
- Diameter, GTP-C, SBI interfaces
- Configuration and management APIs (Netconf, REST, SSH)
4. Signaling Infrastructure
- SS7 and MAP for 2G/3G
- Diameter in 4G
- HTTP/2 APIs in 5G SBA
- IPX/GRX transit networks
5. Radio Access Network (RAN)
- eNodeBs and gNodeBs
- Open RAN control interfaces
- S1AP, X2, NGAP
6. SIM and Device APIs
- OTA SMS
- SIM applets (S@T, WIB, USIM Toolkit)
- VoLTE/IMS SIP stacks
These aren’t theoretical. These are the actual entry points that adversaries—ranging from hacktivists to state actors—actively test and exploit.
Common Telecom Threat Scenarios
Threat modeling becomes valuable when we start predicting what an attacker can actually do with access to certain assets or interfaces.
Here are a few canonical telecom threat scenarios:
IMSI Catching and Location Tracking
Even in 5G, SUCI encryption isn’t always enforced. If a device reverts to cleartext SUPI or IMSI under certain network conditions (e.g., attach failures, emergency mode), it becomes traceable via rogue base stations or passive surveillance setups.
Rogue Diameter Peering in Roaming
Many operators still accept inbound Diameter traffic over IPX without mutual TLS or AVP validation. Attackers posing as a roaming partner can send Update Location Requests, purge subscribers, or trigger re-authentication floods.
GTP Session Hijacking
Poor GTP-C validation allows attackers to spoof Create Session Requests or hijack TEIDs. This leads to subscriber impersonation, DoS, and uncontrolled tunneling through the network perimeter.
SIP Spoofing in VoLTE/IMS
VoLTE stacks are notoriously fragile. SIP fuzzing or spoofed INVITE/REGISTER messages can crash call session servers, spoof CLI, or trick devices into accepting fake calls.
ePDG Attacks via Wi-Fi Offload
Wi-Fi offload using EAP-AKA often has weak certificate validation. Attackers with a fake ePDG and rogue Wi-Fi can trick devices into leaking session keys or silently accept MITM connections.
Building a Telecom Threat Model: The Four-Layer Approach
Telecom security isn't flat. It’s layered. Threat modeling should be too.
1. Protocol Stack Level
Map which protocols are in use: NAS, GTP, Diameter, SIP, HTTP/2, SCTP. Identify which are vulnerable to injection, spoofing, fuzzing, or downgrade manipulation. Document endpoints and whether mutual authentication is enforced.
2. Network Topology Level
Draw a full map of all network functions (MME, PGW, UPF, HSS, etc.), plus interconnects, IPX gateways, and public/external-facing elements. Note segmentation or the lack thereof. Find flat trust zones.
3. Operational Trust Level
Define which entities are trusted (home network, MVNOs, roaming partners, vendors). Check how that trust is enforced—or not. Can external entities impersonate Diameter peers? Can signaling firewalls be bypassed?
4. Device/User Level
List all possible inputs from the subscriber device: SIM, IMSI, attach messages, APN configurations, over-the-air updates, VoLTE SIP traffic. Identify which fields are validated, which can be spoofed, and which trigger logic on the core network.
Realistic Attacker Personas in Telecom
To model telecom threats correctly, you need to think like attackers—not just random hackers, but real personas with real capabilities:
- Script Kiddies – Running IMSI catcher apps on rogue eNodeBs, scanning for public IPs on GTP ports, fuzzing SIP interfaces.
- Malicious Roaming Partners – Sending malformed or unauthorized signaling messages via IPX.
- Insider Threats – Abuse of lawful interception systems, backdoors in NMS interfaces, or unlogged access to HSS.
- State-Level Adversaries – Long-term tracking of subscribers using passive probing, SIM-level exploits, and injection at IPX or cable landing points.
Each persona brings different tools and goals. Your threat model should reflect the reality of all of them.
What Threat Modeling Reveals That Audits Miss
Penetration testing gives you a snapshot. Vulnerability scans find configuration issues. But threat modeling shows you design flaws—the deep-seated assumptions that attackers exploit over and over:
- Assuming signaling messages are “internal” and don’t require authentication
- Trusting devices to always validate certificates
- Believing physical proximity is required for attacks
- Thinking SIM cards can’t run arbitrary code
- Treating IPX as a secure transport layer instead of what it really is: an attacker playground
Threat modeling forces teams to challenge these assumptions before attackers do.
Closing Thoughts: Don't Just Fix—Model
Telecom security isn’t about applying patches and praying. It’s about understanding your own systems better than your adversaries. That means threat modeling every core network interface, every subscriber behavior, and every third-party trust relationship.
If you’re not threat modeling your Diameter interfaces, someone else is. If you’re not tracing the attach path from SIM to SBI, someone else already has. And if you’re assuming your network is secure because no one’s exploited it yet—that’s the oldest telecom vulnerability of all.
At P1 Security, threat modeling isn’t just a checkbox—it’s the foundation of how we approach telecom security assessments. With over a decade of experience auditing mobile network infrastructure worldwide, we’ve dissected real-world attack paths across 2G, 3G, 4G, and 5G networks. From GTP fuzzing in production environments to identifying Diameter routing leaks and SBI authentication bypasses, our methodology is grounded in how attackers actually operate—not how protocols were supposed to work on paper. Our internal frameworks combine protocol analysis, interface enumeration, and attacker emulation to build threat models that reflect modern risks across both legacy and cloud-native telecom deployments. If it connects subscribers and speaks a protocol, we’ve likely broken it—or helped someone else secure it before someone else did.
