SS7 Vulnerabilities: How the Backbone of Global Telecom Became a Security Nightmare

Pick up your phone and make a call. It connects in under two seconds. You hear a voice on the other end. The whole thing feels unremarkable, which is exactly how it's supposed to feel.

What you can't see is the signaling infrastructure that made that call possible - a decades-old protocol stack that predates the commercial internet, was designed by engineers who assumed everyone using it could be trusted and has never fully recovered from that assumption.

That protocol is SS7. Signaling System No. 7.

The name sounds obscure because it is. Most people have never heard of it. But security researchers, intelligence agencies, law enforcement, and a fairly unsettling number of criminals know it well, because SS7 isn't just a set of technical protocols. It's also an active attack surface that lets adversaries track your location, intercept your text messages, and bypass the two-factor authentication protecting your bank account. Without touching your phone. Without you knowing.

This isn't a theoretical vulnerability waiting to be discovered. It's been known for years. The exploits have been demonstrated publicly at conferences. Banks have had customers drained. Journalists have been tracked. Governments have used it against dissidents.

And yet SS7 is still running. Still woven into the fabric of how mobile networks communicate with each other. Still trusted, implicitly, by carriers around the world.

This article explains why this is still the case, starting from first principles, working through the actual attack mechanics, and ending at what mitigation looks like in practice (and where it still falls short).

What SS7 Actually Is

SS7 is a collection of protocols used by telecom operators to exchange signaling information. Not the actual calls or text messages themselves but the control data that tells the network how to handle those calls and messages.

Think of it as the nervous system of the telecom network. When you make a call, there's a process that runs before the voice connection opens: your carrier needs to figure out where you are, verify you're a valid subscriber, locate the person you're calling, reserve capacity, and set up the routing. None of that is visible to you. SS7 is what handles it.

Specifically, SS7 is responsible for:

Call setup and teardown - The mechanics of opening and closing a voice connection between two endpoints.

SMS routing - Figuring out where a text message needs to go and how to get it there, even across different carriers.

Subscriber authentication - Verifying that the device on the network is associated with a valid account.

Roaming coordination - What happens when you travel and your phone connects to a foreign carrier's towers while still being billed to your home carrier.

Location updates - Tracking which cell towers a phone is connected to so the network can route incoming calls and messages to the right place.

The protocol was standardized in 1980 by the ITU, and it was designed at a time when the threat model was essentially nothing. The people building SS7 assumed that the only entities with access to the signaling network were legitimate telecom operators, who had business agreements with each other and mutual incentives to behave. Security wasn't designed in because it didn't seem necessary.

That was a reasonable assumption in 1980. It is not a reasonable assumption now.

The Architecture You Need to Understand

Before getting into the attacks, it helps to have a mental model of what SS7 is actually connecting.

The core components of a traditional SS7 network are:

MSC (Mobile Switching Center): This handles call switching. It's what routes your voice traffic from one point to another. Think of it as the telephone exchange, but for mobile.

HLR (Home Location Register): This is a database that stores permanent subscriber data such as your phone number, your subscription status, which services you're allowed to use, and a record of your current location in the network. Every carrier has an HLR for its own subscribers.

VLR (Visitor Location Register): A temporary store that's local to each MSC. When you're roaming in a new area, the VLR in that area gets a copy of your relevant subscriber data from your HLR. It doesn't persist but instead it's just there for efficiency.

STP (Signal Transfer Point): These are the routing nodes that forward SS7 messages between different network elements. They're analogous to routers in IP networks.

SS7 Network Architecture

The key point here is that these components communicate with each other by exchanging SS7 signaling messages, and those messages can originate from anywhere inside the SS7 network. There's no strong authentication mechanism that verifies whether a message actually came from a legitimate node versus an attacker who found a way onto the network.

Why SS7 Is Fundamentally Broken

The core design flaw is this: SS7 trusts any node that can reach the network.

There's no cryptographic verification. No mechanism that says "prove you are who you claim to be before I respond to this query." A node sends a message asking for subscriber information, and the receiving node responds. That's more or less how the trust model works.

This was acceptable in the 1980s when SS7 access was genuinely limited to a small number of large, heavily regulated carriers. The barriers to accessing the network were physical and legal. You had to be a licensed operator with physical signaling links into the infrastructure.

That's no longer true.

Today, SS7 access is much more fragmented. There are hundreds of carriers globally, including small operators in countries with inconsistent regulatory oversight. Third-party wholesale providers lease SS7 connectivity for various legitimate purposes to IoT companies, virtual network operators, various middlemen in the international roaming ecosystem. And at the edges of this ecosystem, there are providers that will sell SS7 access to parties that have no particularly legitimate reason to want it.

You don't need to compromise a major carrier. You need to find a weak link - a small operator in a jurisdiction where nobody is checking closely, a gateway provider with loose controls, a wholesale reseller who doesn't ask too many questions. Once you have SS7 access, you're inside the trust boundary, and you can send the same signaling messages that any legitimate carrier would send.

That's the attack surface.

Trust Issues in SS7

The Protocol Stack That Enables the Attacks

Understanding the vulnerabilities requires a quick look at how SS7 is structured.

MTP - Message Transfer Part

MTP handles the low-level plumbing of getting messages from one place to another. It operates in three layers:

MTP Level 1 covers the physical connection - the actual wires or fiber.

MTP Level 2 handles error correction and retransmission.

MTP Level 3 handles routing decisions - figuring out how to get a message from its source to its destination.

MTP on its own is fairly basic. It's what sits above it that creates the vulnerabilities.

SCCP - Signaling Connection Control Part

SCCP adds logical addressing on top of MTP. It introduces something called Global Title Translation (GTT), which lets SS7 messages be routed based on phone numbers or other identifiers rather than just network addresses.

This matters for attacks because it means you can address a signaling message to a particular phone number, and the network will figure out how to route it including querying the HLR to find out where that subscriber is currently located. That lookup process is part of how the tracking attacks work.

TCAP - Transaction Capabilities Application Part

TCAP enables stateful transactions across SS7 - requests and responses that are matched together, allowing for the kind of back-and-forth that's needed for authentication or subscriber queries.

MAP - Mobile Application Part

This is the layer where the dangerous operations live.

MAP runs on top of TCAP and handles the actual mobile-specific operations: authenticating subscribers, routing SMS, updating location information, querying subscriber data. When a phone roams onto a foreign network, it's MAP messages that coordinate with the home carrier's HLR to retrieve the subscriber's profile. When an SMS is delivered, MAP is involved in figuring out where to send it.

MAP is also where most of the SS7 attack operations are implemented. The messages that attackers send to intercept SMS, track locations, and redirect calls are MAP messages.

SS7 Protocol Stack

How Attackers Actually Get Access

The obvious question is: if SS7 access is restricted to telecom operators, how do attackers get in?

The short answer is that "restricted to telecom operators" is doing a lot more work in that sentence than it can actually support.

There are several realistic paths to SS7 access:

Purchasing access from shady providers: There's a market for SS7 connectivity. Some providers in it are legitimate like IoT companies, virtual carriers, international roaming intermediaries. Others are essentially selling access to anyone willing to pay, with minimal vetting. Researchers and journalists have documented this.

Compromising a small carrier: Attacking the weakest link in the global SS7 mesh. A small operator in a country with limited regulatory capacity might have adequate enough external security but inadequate internal controls. Compromising their systems gives access to their SS7 connectivity.

Using signaling gateways: Various legitimate businesses have signaling gateway access for specific purposes. If those businesses have poor security hygiene, they become attack vectors.

Underground markets: SS7 access has appeared on criminal forums. Not cheap, not easy to use without technical knowledge, but available.

Once access is obtained, sending arbitrary MAP messages is not technically difficult for someone with telecom background. The hard part is getting in. The attacks themselves are relatively straightforward.

The Actual Attacks

Location Tracking

This is probably the simplest SS7 attack to understand, and it's genuinely alarming once you internalize what it means.

The MAP protocol includes a message type called ProvideSubscriberInfo. Its legitimate purpose is to allow network elements to query a subscriber's current location for example, so an MSC can figure out where to route an incoming call.

An attacker with SS7 access can send this same message, targeting any subscriber by phone number. The HLR receives the request, looks up where the subscriber is currently registered, and sends back a response that includes the current MSC and, depending on network configuration, cell tower information.

That cell tower data can be precise enough to locate someone to within a few hundred meters in an urban area.

The attacker doesn't need to install anything on the target's phone. The target doesn't receive any notification. No user interaction is required. It just works, as long as the target's phone is on and connected to the network, which is nearly always.

SS7 ProvideSubscriberInfo Attack Flow

This is why SS7-based tracking is particularly favored by anyone who wants surveillance without the operational complexity of device compromise - certain intelligence agencies, private investigators in legal grey areas, stalkerware-adjacent services, and straightforward criminals.

The technical fix would require carriers to validate whether incoming ProvideSubscriberInfo requests are coming from entities that should legitimately be asking about that subscriber. Most carriers have not implemented this consistently.

SMS Interception and OTP Bypass

This is the attack that has caused the most visible real-world damage, specifically because it undermines SMS-based two-factor authentication.

The attack works by abusing the location update mechanism that's fundamental to how mobile networks operate. When you travel from one area to another, your phone registers with local towers, and the network updates its records to reflect your new location. MAP contains a message type called UpdateLocation that handles this process.

An attacker can send a spoofed UpdateLocation message to your home carrier's HLR, claiming that your subscriber record should now be associated with an attacker-controlled MSC rather than your actual location.

Once the HLR has accepted this update, incoming messages and SMS get routed to the attacker's infrastructure instead of your actual phone. Your phone might continue to show service normally, because voice calls and data may not be affected immediately. But any SMS sent to your number will go to the attacker.

SMS Rerouting via Fake MSC Update

The consequences for SMS-based 2FA are obvious. An attacker who knows your banking credentials (obtained through phishing, a data breach, or a keylogger) now just needs to trigger a one-time password to be sent to your number. They intercept it via SS7. They complete the authentication. Your account is compromised before you've noticed anything is wrong.

In documented cases, this attack chain has been used against bank customers with genuine financial impact. It's not theoretical. Banks have paid out fraud claims that trace back to SS7-intercepted OTPs.

This is one of the reasons that security professionals have spent years recommending against SMS for 2FA when better alternatives exist. Authenticator apps and hardware tokens aren't vulnerable to this class of attack. But SMS 2FA is still widespread because it's easier to deploy and has near-universal adoption. Almost everyone has a phone that receives texts.

Call Interception

Voice calls can also be redirected through SS7 manipulation, though it's somewhat more complex than SMS interception.

The mechanism typically involves manipulating call forwarding settings through SS7 messages. MAP includes operations for inserting and modifying subscriber data, including call forwarding instructions. An attacker who can send these messages to your carrier can configure your number to forward calls without touching your phone's settings.

In more sophisticated attacks, the attacker sets up a conference bridge arrangement: incoming calls to your number get connected to a bridge that forwards to both you and the attacker. The call goes through normally from your perspective, while the attacker is listening in.

Voice Call Redirection via Fake Routing

This is the kind of capability that's relevant to surveillance, corporate espionage, and intelligence operations. It requires slightly more infrastructure than SMS interception but is well within reach for a motivated, technically capable attacker with SS7 access.

Subscriber Data Extraction

MAP allows querying subscriber data beyond just location. An attacker can retrieve:

IMSI (International Mobile Subscriber Identity) - The unique identifier associated with your SIM card, distinct from your phone number. IMSIs are useful for other attacks, including IMSI catcher-based tracking.

MSISDN mapping - The relationship between phone numbers and IMSIs, which can be used to build profiles or enable further targeting.

Roaming status - Whether and where a subscriber is roaming, which reveals travel information.

Extracting IMSI and Subscriber Data from HLR

None of this requires anything sophisticated. It's just querying network databases that respond to anyone with SS7 access.

Denial of Service

SS7 can also be abused to disrupt service entirely. Attackers can:

Send cancel location updates that deregister a subscriber from the network, essentially disconnecting their phone.

Flood the signaling infrastructure with messages, consuming capacity and causing delays or failures.

Force repeated deregistrations to create a persistent outage for a targeted subscriber.

These attacks are less common in the wild because they're noisy and easier to notice, but they're available in the toolkit.

Real-World Impact

It's worth being specific about what "active exploitation" means in practice.

Bank account theft via SS7 has been documented in multiple countries. The attack chain is well-understood at this point: obtain credentials through conventional means, use SS7 to intercept OTP, complete transaction. German bank customers lost money this way. Brazilian telecom subscribers have been targeted. Similar incidents have occurred across multiple continents.

Government surveillance using SS7 capabilities has been reported involving state actors tracking political opponents, journalists, and human rights workers. Privacy International and other organizations have documented cases where SS7-based tracking was used against people who had taken precautions against other forms of surveillance but hadn't accounted for signaling-layer attacks.

Criminal fraud operations use SS7 as part of broader attack chains such as SIM-based fraud, crypto account takeovers, corporate espionage - wherever SMS-based authentication or phone number verification is the critical control being bypassed.

The people most at risk are not necessarily those you'd expect. High-profile targets like politicians and executives are obvious targets for state-sponsored surveillance. But ordinary bank customers, cryptocurrency holders, and anyone relying on SMS for account security is also exposed, because the criminal use cases don't require sophisticated adversaries, just ones with access and motive.

Why SS7 Hasn't Been Replaced

A natural question: if this is so bad, why hasn't it been fixed or replaced?

The honest answer is that it's a genuinely hard problem, and it involves more than just engineering.

Legacy infrastructure is part of it. The global telephone network has been built on SS7 over decades. Replacing the signaling infrastructure is not like deploying a software update. Instead, it requires coordinated hardware and software changes across hundreds of operators in dozens of countries with different regulatory regimes, different equipment vendors, and different financial situations.

Global interoperability complicates things further. International roaming requires carriers in different countries to exchange signaling information. Upgrading to a more secure protocol means either forcing all carriers to upgrade simultaneously (essentially impossible) or running both old and new systems in parallel (which doesn't solve the security problem because interworking exposes you to the old system's vulnerabilities anyway).

Cost is a factor. For many carriers, especially smaller ones in emerging markets, SS7 infrastructure was paid for years ago and is still working. The business case for expensive upgrades is harder to make when the downside is "our subscribers might be spied on" rather than "our service goes down."

Regulatory fragility - Enforcement varies enormously. Some regulators have pushed carriers to implement SS7 firewalls and anomaly detection. Others have not.

SS7 Network Interconnected with LTE and 5G Core

Diameter: The "Improvement" That Wasn't

When 4G LTE networks were designed, the telecom industry moved from SS7 to a protocol called Diameter for the evolved packet core. Diameter was supposed to be more modern and more secure.

The assessment from security researchers has been roughly: it's marginally better in some ways and has its own serious vulnerabilities. The core trust-model problem was never fully addressed. Diameter inherits many of the same assumptions as SS7, and the implementation of security features varies across deployments.

More problematically, the real world is not a clean sheet. Every modern carrier still interconnects with SS7 networks for international roaming, for SMS interoperability, for compatibility with older networks. This interconnection happens through gateways that translate between SS7 and Diameter.

Those gateways are vulnerability laundering machines. If an attacker can use SS7 to send a message that a gateway will faithfully translate and forward into a Diameter network, the Diameter network's security improvements don't help. The attack crosses the boundary.

This problem applies to 5G as well. 5G standalone core networks use a different signaling architecture, but most 5G deployments are non-standalone i.e. they rely on 4G infrastructure for parts of their operation, which brings Diameter back in, which brings SS7 reachability back in. The stack is interconnected in ways that make clean isolation difficult.

The practical conclusion is that improving the security of one protocol layer doesn't provide the protection you'd hope for as long as interworking with legacy systems remains a requirement.

diagram showing SS7 to Diameter interworking gateway exposing vulnerabilities

What Does an End-to-End Attack Look Like?

It helps to trace a realistic attack chain to understand how these pieces fit together.

Suppose the target is an individual with a bank account protected by SMS-based 2FA. The attacker's goal is to drain the account.

Step 1: SS7 access: The attacker obtains access to an SS7 network. Maybe through a shady wholesale provider. Maybe by compromising a small operator. This isn't trivial, but it's not as hard as it should be.

Step 2: IMSI lookup: The attacker knows the target's phone number. Using SS7 queries to the HLR, they retrieve the IMSI associated with that number. This is the unique identifier they'll need for subsequent operations.

Step 3: Location query: The attacker queries the target's current location. This confirms the phone is active and gives the attacker confidence they have the right subscriber. It may also serve a tactical purpose and confirming the target isn't, for example, currently at their bank branch where unusual account activity might be questioned in person.

Step 4: Location update spoofing: The attacker sends a fake UpdateLocation message to the target's home carrier, registering the attacker's infrastructure as the target's current MSC. The HLR accepts this. The target's phone number is now associated, in the network's records, with the attacker's equipment.

Step 5: SMS interception: The attacker initiates a password reset or transaction authorization on the target's bank account. The bank sends an OTP via SMS to the target's phone number. The SMS gets routed to the attacker. The target's actual phone may see a brief service disruption or nothing at all.

Step 6: Account access: The attacker uses the intercepted OTP to complete the authentication. They're in. Whatever comes next like fund transfer, credential change, account takeover for sale - is a function of the attacker's goals.

The whole chain can happen in minutes. The target probably doesn't know anything has happened until they notice money is missing or a subsequent login attempt fails.

Why Detection Is Hard

One of the things that makes SS7 attacks so persistent is that they're genuinely difficult to detect.

The attack messages look like legitimate network traffic. A location update from an attacker looks identical to a location update from a real MSC handling a subscriber's travel. A subscriber query from an attacker looks identical to a query from a legitimate network element doing its job. There's no inherent marker that distinguishes malicious signaling from normal signaling.

Detection requires behavioral analysis such as looking for patterns that are statistically inconsistent with how real network events work. A subscriber whose "location" jumps instantaneously from one country to another is suspicious. Multiple HLR queries for the same subscriber from unusual sources is suspicious. But distinguishing "suspicious" from "person traveling internationally with an unusual roaming partner" is not always straightforward.

The network operators who are victims of this problem often aren't even directly involved in the attack. If an attacker is using an SS7 node in one country to query an HLR in another country about a subscriber of a third country's carrier, who exactly is responsible for detecting and stopping it? The answer is everyone and therefore effectively no one.

What Mitigation Actually Looks Like

There are real defenses against SS7 attacks. The problem is that deployment is incomplete and uneven.

SS7 firewalls are the primary defense. These sit at the edge of a carrier's signaling network and filter incoming messages based on rules about what's legitimate. For example, a location update claiming that a domestic subscriber is now registered with an MSC in a completely unexpected location might be blocked. Query messages from sources that aren't recognized as legitimate interconnect partners might be dropped.

This helps, but it requires investment and active maintenance. The rules need to stay current as both the legitimate network topology and the attack patterns evolve. A carrier that deployed a firewall in 2017 and hasn't updated the rules may have meaningful gaps.

Anomaly detection is complementary to firewalls. Rather than blocking based on static rules, anomaly detection looks for patterns like unusual query volumes, geographically implausible location sequences, signaling from unexpected sources. This can catch novel attack patterns that rule-based systems miss.

Home routing for SMS addresses the SMS interception attack specifically. Home routing ensures that SMS destined for a subscriber passes through the home carrier's infrastructure before being delivered, rather than being handed off directly to wherever the network thinks the subscriber is. This gives the home carrier visibility and interception capability before the message leaves their domain. Implemented correctly, it makes the UpdateLocation spoofing attack significantly harder.

Network segmentation reduces the blast radius of a compromised node by limiting which parts of the infrastructure can reach which other parts. A node that's been compromised can only do as much damage as its connectivity allows.

None of these defenses is universal. The GSMA and ITU have published guidelines and recommendations. Some carriers take them seriously. Others don't. Enforcement mechanisms are limited, and the incentives to invest in signaling security don't always align cleanly with the carriers' financial interests.

What It Means for You

If you use SMS-based two-factor authentication to protect sensitive accounts, you're exposed to this attack class. Not necessarily at high probability. Getting targeted with an SS7 attack requires someone motivated to use resources they've obtained exposed in a way that stronger authentication methods wouldn't leave you.

The practical advice that follows from this is not new, but it's grounded in a real threat model:

If you have the option to use an authenticator app rather than SMS for 2FA, use it. Google Authenticator, Authy, and equivalent tools generate codes on your device rather than receiving them via SMS, which means SS7 cannot intercept them.

Hardware security keys (FIDO2/WebAuthn compatible) are stronger still. They provide cryptographic authentication that cannot be replicated by an attacker who has intercepted your phone number.

For most everyday accounts, these alternatives are available. The inconvenience is marginal. The security improvement is not.

For the accounts where SMS is the only 2FA option, the practical mitigation is awareness knowing that SMS 2FA is weaker than it looks and calibrating your behavior accordingly (stronger primary passwords, more careful phishing hygiene, alertness to unexplained service disruptions).

The Bigger Picture

SS7 is a good case study in how infrastructure security decisions accumulate over time. The engineers who designed it weren't careless, they were building for the threat model that existed in their context, with the constraints they had. The assumption that only trusted operators would have access wasn't naive; it was accurate.

What changed is the world. The number of entities with SS7 access grew. Regulatory enforcement didn't keep pace. Vulnerabilities were discovered and published. Attack tooling became more accessible.

And the infrastructure itself couldn't be replaced quickly because it was now load-bearing. Pull SS7 out and you break international roaming. You break SMS interoperability. You potentially break emergency services integration in places where it's built on old signaling infrastructure. The dependencies are real.

This is a pattern that shows up in a lot of critical infrastructure security: the cost of replacing something that works is high and diffuse, borne by everyone; the cost of not replacing it falls unevenly on people who happen to be targeted. The incentives don't always produce the right outcome.

SS7 will eventually be retired, or isolated enough that it no longer presents a meaningful attack surface. But "eventually" could mean another decade or more. In the meantime, the attacks continue, the defenses are deployed inconsistently, and the users sitting at the end of the chain - the people whose location is being queried, whose texts are being read mostly have no idea this attack surface exists.

That's exactly where the problem lives.