SS7 and Diameter Explained: MAP, SIGTRAN and Signalling Firewalls

SS7 and Diameter are the signalling protocols that mobile and fixed operators use to set up calls, deliver SMS and let phones roam between networks. SS7 (ITU-T Q.700 series) runs 2G and 3G core signalling, often over IP through SIGTRAN, while Diameter (RFC 6733) does the same job in 4G. Both trust messages from partner networks too readily, so operators add signalling firewalls and enterprises should stop relying on SMS codes.

This guide covers the layers, the addressing, the interconnect, the abuse classes regulators describe and the defences that work, at the level public regulator and industry reports use, with no attack steps. If your product sends one time codes by text message, the last third is a plan you can start this week.

Key takeaways

• SS7 is a layered stack: MTP levels 1 to 3, then SCCP for routing across networks, TCAP for transactions, and application parts such as ISUP (calls), MAP (mobility and SMS) and CAP (intelligent network services).
• SIGTRAN moves SS7 onto IP with M3UA (RFC 4666), SUA (RFC 3868) and M2PA (RFC 4165) over SCTP. It changes the transport, not the trust model.
• Diameter replaced MAP for 4G. The S6a interface (3GPP TS 29.272) links the MME and the HSS. RFC 6733 requires TLS, DTLS or IPsec, but only hop by hop.
• The core weakness is trust. ENISA notes that attacks use "legitimate SS7/Diameter traffic", which makes them hard to spot.
• Defences are layered: GSMA filtering guidance, SMS home routing, signalling firewalls, monitoring, and in 5G the SEPP.
• For enterprises, the lesson is SMS codes. NIST SP 800-63B-4 treats phone network delivery as a restricted authenticator, and CISA says not to use SMS as a second factor.

A short timeline of SS7, SIGTRAN and Diameter

What is Signalling System No. 7 and what does it carry?

SS7 is the common channel signalling system defined by the ITU-T in the Q.700 series: control messages for many calls travel on a separate signalling network rather than in the voice circuit. The ITU lists the March 1993 edition of Q.700 as in force. Mobile operators later added their own application layer through 3GPP, and the suite still connects most of the world's telephone networks.

It carries three kinds of traffic. Call control: ISUP sets up and releases circuit switched calls and carries calling and called numbers. Messaging: 2G and 3G SMS move between the SMS centre and the serving switch as MAP operations, after the SMS centre asks the home register where to deliver. Mobility and roaming: when a phone appears in a new area or country, the visited network registers it with the home location register (HLR), fetches authentication data and downloads the subscriber profile. The FCC's 2024 notice describes the same role: routing calls and texts between networks and carrying caller ID and billing data.

The SS7 layers

Two details matter for security. First, ISUP sits directly on MTP 3, while MAP and CAP sit on TCAP and SCCP, so call control and mobility traffic use different routing and addressing. A filter that only understands one path misses the other. Second, every layer was designed for a closed club of national operators who trusted each other. Nothing in MTP or SCCP authenticates the sender. The address in the message is the address the receiver believes, and the response goes wherever that address points.

MAP, the part that matters for mobile security

3GPP TS 29.002 is a living document (Release 19 version 19.1.0, January 2026). Its operations cover location management (for example updateLocation, which tells the HLR which visitor register now serves a subscriber), authentication (SendAuthenticationInfo, which fetches vectors to challenge the SIM), pushing subscriber profiles, routing queries for calls and SMS, and supplementary services and USSD. Both names appear in Wireshark's MAP dissector reference. USSD deserves a mention because in some markets it carries mobile money, so a signalling problem there becomes a payments problem.

Each function is needed for roaming. A traveller's phone only gets service abroad because the home HLR answers a visited network it may never have dealt with directly, in a country where it has no contract of its own, often through one or two transit carriers. That openness is the design, and also the problem: the protocol has no way to tell a legitimate visited network from someone who has bought or borrowed access to the interconnect and presents a plausible address.

Point codes, global titles and STPs

Inside one network, each signalling node has a point code, a numeric address that MTP 3 routes on. Point codes do not cross borders, so SCCP adds the global title, usually an E.164 number that identifies a node such as an HLR. Signal transfer points (STPs) relay messages and translate global titles into the next hop.

ENISA calls global titles the signalling equivalent of IP addresses. The comparison is incomplete: a global title is just a field, and unless the receiver checks it against what it expects on that link, it believes it. ENISA also notes that some operators lease global titles to third parties, so traffic can leave under their signalling identity, and recommends they watch egress traffic. Over half of ENISA's respondents inspected traffic at STP or HLR level, which the agency endorsed: the STP sees the whole interconnect and the HLR sees attacks on home subscribers.

The interconnect: GRX and IPX

Operators began with bilateral links, then bought transit from carriers that reach hundreds of networks. For packet roaming the GSMA defined the GPRS Roaming Exchange (GRX) and later the IP Packet Exchange (IPX), a private IP network run by IPX providers. Diameter and 5G roaming signalling travel over IPX.

A message arriving over the interconnect has passed through intermediaries, any of which could have been the real sender. ENISA notes that opening networks to many partners is how operators make money, so it will not stop, and that only 38 percent of surveyed operators imposed security requirements on their carriers. The FCC adds that more networks and participants mean more opportunity for a bad actor.

How SIGTRAN carries SS7 over IP

RFC 2719 (October 1999) set out the SIGTRAN architecture: a common transport plus adaptation layers that present a familiar SS7 interface upward. The transport is SCTP, now RFC 9260 (June 2022), which adds message boundaries, multiple streams and multi homing. We cover it in SCTP explained.

M3UA is the most common: a signalling gateway relays SCCP and ISUP traffic to IP based HLRs, SMS centres and switches. RFC 4666 says M3UA data should carry SCTP payload protocol identifier 3, and IANA's SIGTRAN registry lists the shared message classes.

SIGTRAN changes the pipe, not the conversation: a MAP message over M3UA has the same unauthenticated global titles as before. RFC 2719 says security inside an operator intranet is "at the discretion of the network owner", while signalling over the public internet must be protected for authentication, integrity, confidentiality and availability. RFC 4666 defers to RFC 3788 (IPsec and TLS). So SIGTRAN keeps the old risk and adds a new one. The old risk is that the SS7 payload trusts its own address fields. The new one is that signalling now runs on IP equipment, which can be misconfigured, exposed to the wrong network segment or reached in ways a dedicated timeslot never could. A signalling gateway with an SCTP listener on a management VLAN, or an association accepted from any source address, turns an IP mistake into an interconnect problem. ENISA made the same point about Diameter, which is purely IP based: attackers who know internet protocols have more ways in.

What Diameter does in 4G

The base protocol

RFC 6733 (October 2012) defines Diameter, an authentication, authorisation and accounting protocol that replaced RFC 3588. ENISA notes it derives from RADIUS and took over many SS7 concepts, weaknesses included. Peers open transport connections, exchange capabilities, then send requests and answers made of attribute value pairs (AVPs).

Per RFC 6733 section 2.1, Diameter runs over TCP or SCTP on port 3868, with TLS over TCP and DTLS over SCTP. IANA registers port 5868 ("diameters") for the secured forms, citing RFC 6733, although the RFC's text prints 5658. Fallback to cleartext exists only for old RFC 3588 peers, and the RFC warns that it leaves the first capability exchange unprotected.

Section 13 is firm: Diameter "MUST NOT be used without one of TLS, DTLS, or IPsec." But security sensitive AVPs may cross intermediaries only with end to end security or a trusted same domain path, and the RFC specifies no end to end mechanism. TLS protects each hop; every agent in the path sees and can modify every message.

Agents and the S6a interface

RFC 6733 section 2.8 defines relay, proxy, redirect and translation agents. In mobile networks the Diameter Edge Agent (DEA) is the proxy at the operator border that all roaming Diameter traffic passes through, and Diameter Routing Agents route inside. ENISA describes the DEA as the 4G counterpart of the 5G SEPP.

3GPP TS 29.272 defines S6a (MME to HSS) and S6d (SGSN to HSS). RFC 5516 registered its commands under vendor specific application ID 16777251:

4G moved to IP and swapped global titles for Diameter host and domain identities, but kept the trust relationships: a partner's MME must be able to ask the home HSS for a location update. The FCC notes that because Diameter provides the same services as SS7 it has similar weaknesses, and its originating addresses can be spoofed by someone posing as a roaming partner.

Is Diameter safer than SS7?

Somewhat, where operators use what the standard offers. Mandatory hop by hop TLS, DTLS or IPsec is more than SS7 ever had, but after an IPX and a few agents the HSS still takes the Origin-Host and Origin-Realm on trust. In ENISA's 2018 survey, 60 percent of operators inspected Diameter interconnect traffic fully or partially, and the agency warned that where nobody monitored, spoofing the application ID would likely work. No respondent then reported seeing real Diameter attacks, which ENISA suggested might reflect narrower adoption at the time, or attackers still getting what they wanted from SS7. Its expectation was that attention would shift to Diameter as SS7 defences improved, which is why GSMA's Diameter guidance and edge filtering matter even in networks that have retired most of their SS7.

Which attack categories do industry bodies describe?

This section stays at the level regulators and GSMA linked reports use: why each class exists and what it costs a victim, not how it is done. ENISA's survey found SMS spam the most commonly reported, followed by spoofing, location tracking and subscriber fraud, with interception, denial of service and routing attacks reported less often.

Location tracking. To deliver calls and messages, the home network must know which switch or MME serves a subscriber, and that is the information abused. CSRIC VI, quoted by the FCC, said signalling based location "does not provide granular location data": usually a cell or serving switch, enough to identify a city or district, and harmful for officials and other high risk people when repeated over time. ENISA adds that misconfigured partners cause false positives, so reported tracking is probably overcounted. The FCC's 2024 notice focuses on exactly this class. It asked providers whether any successful unauthorised location tracking through SS7 or Diameter had happened since the CSRIC VI best practices of 2018, how effective the countermeasures had been, and what barriers remained. The notice also records that the FCC had already asked about SS7 best practice adoption in 2018 and Diameter adoption in 2020, so the 2024 request narrowed the focus to location.

SMS and call interception. ENISA describes altering a subscriber's registered location or profile so calls, SMS or data go elsewhere. It is harder to run and needs a lasting presence in the network. Because SMS is widely used as a second factor, interception can defeat two factor authentication; ENISA cites a publicly reported German case where intercepted banking codes were used to drain customer accounts. CISA makes the same point: SMS is not encrypted, so someone with access to a provider's network can read it.

Subscriber fraud. ENISA describes tampering with a subscriber's profile or triggering charging events to get service without paying: stealing prepaid voice, SMS or data credit, turning a prepaid subscriber into a postpaid one, billing someone else, or abusing mobile money services that run over USSD.

Spoofing and SMS spam. ENISA notes that addresses, names and subsystem numbers carry no authentication. Spoofing underpins most other classes; the commonest commercial abuse is routing bulk SMS around the charges the receiving network expects.

Denial of service. Mobility includes legitimate procedures for removing a subscriber from an area and for resetting equipment. ENISA notes these can be abused to deny service to one person, a group, or every subscriber attached to one network element, and that a repeated reset can cause persistent trouble. Small scale denial of service is hard to tell from ordinary faults.

GTP, which carries data sessions between roaming partners, shares the same interconnect; only 53 percent of ENISA's respondents monitored its control traffic. And as ENISA stresses, subscribers can do very little themselves. The work sits with operators, which is why enterprise advice below is about not depending on the phone network.

What are the defences?

The model is layers: block what should never arrive, check what should only arrive from certain senders, route sensitive traffic through the home network, monitor the edge, and in 5G authenticate the partner network cryptographically.

GSMA guidance and category filtering

The GSMA Fraud and Security Group's documents go to members, and its public pages blocked our fetches, so this relies on ENISA's summary. ENISA lists FS.11 (SS7 monitoring), FS.07 (SS7 filtering), FS.19 (Diameter interconnect security), IR.82 (SS7 security implementation), IR.88 (LTE roaming) and IR.77 (GRX and IPX backbone security).

FS.11 sorts SS7 messages into categories; ENISA found 76 percent of respondents monitored category 1 against roughly 43 percent for categories 2 and 3. In general terms:

• Category 1: operations meant only for use inside one operator. Arriving from outside without a bilateral agreement, they can be blocked with static rules.
• Category 2: operations legitimate only from an inbound roamer's home network. Filtering checks that the sender belongs to the same operator as the subscriber identity in the message.
• Category 3: operations partners must be allowed to send, such as location updates and authentication requests. Filtering needs state and plausibility: can this subscriber really have moved there that fast?

FS.19 applies the same thinking to Diameter, checking that the Origin-Realm fits the subscriber identity and the link the message arrived on.

SMS home routing

3GPP TR 23.840 studied routing mobile terminated SMS via the home network. With home routing, the home network answers delivery queries with its own SMS router instead of exposing the subscriber's identity and serving switch. ENISA found 87 percent of operators had deployed it.

Signalling firewalls and monitoring

A signalling firewall sits at the STP or DEA and applies category rules, state and velocity checks to all interconnect traffic. Only about 28 percent of ENISA's respondents had one in 2018. ENISA lists the limits: roaming subscribers are harder to protect because location updates are not authenticated; false positives from misconfigured partners have legal and commercial costs; load sharing means a firewall must see every path; and three quarters of operators named cost and complexity as blockers. It concluded that protection needs confidentiality and integrity, not only filtering. Some operators had set up bidirectional, secured links with a small number of trusted partners, which gives source authentication and integrity for that traffic, though ENISA noted it could never scale to every roaming partner.

The CSRIC V recommendations, as the FCC summarises them, are firewalls, monitoring and filtering, signalling aggregators with a wider view, security assessments and threat sharing; CSRIC VI added Diameter peer reviews and security gateways at domain boundaries. ENISA found 69 percent of operators monitored signalling regularly, using statistical analysis of message logs, real time signature detection and periodic log review. Response options included dropping or redirecting suspicious messages, answering them negatively and blocking global titles that emitted malicious traffic. It also found that signalling experts are few and often sit outside the security operations centre and the fraud team, which slows every one of those responses.

The 5G answer: the SEPP

5G replaces MAP and Diameter between operators with HTTP/2 service APIs and a Security Edge Protection Proxy on each side. TS 33.501 clause 5.9.3.2 (ETSI V19.7.0) requires the SEPP to act as a non-transparent proxy, mutually authenticate the peer SEPP, negotiate cipher suites, hide topology, verify that the sender may use the network identity in the message, rate limit, apply cross layer anti-spoofing checks, and make any change by up to two roaming intermediaries identifiable. The catch is interworking: while a network roams with 2G, 3G and 4G partners, SS7 and Diameter stay on the interconnect. We cover N32 and PRINS in The 5G core explained.

SS7, Diameter and 5G signalling compared

Why SMS one time codes inherit signalling risk

An SMS code is only as private as every network that carries it: aggregator, carriers, interconnect, home and serving networks. Signalling abuse is one route to stealing it; SIM swap, phishing and handset malware are others, covered in phishing, vishing, smishing and SIM swap explained. The fix for all of them is to stop treating the phone number as a security decision.

NIST SP 800-63B-4. Section 3.2.9 says there is one restricted authenticator: "the use of the PSTN for out-of-band authentication". Organisations must assess and accept that risk, make alternative authenticator types available to all subscribers, treat changing the registered number as binding a new authenticator, and should weigh signals such as a SIM change or number port before sending a code. At AAL2 a phishing resistant option must be available; at AAL3 it is required. See Is SMS two factor allowed?

CISA. Its Mobile Communications Best Practice Guidance, written for highly targeted individuals, says: "Do not use SMS as a second factor for authentication." Its reasoning is the one this post describes: SMS is not encrypted, and a threat actor with access to a provider's network can read intercepted messages. It recommends FIDO security keys as most effective, with passkeys as an acceptable alternative, and warns that enrolling an authenticator app does not automatically remove SMS from an account, leaving a weak fallback until someone turns it off. It also recommends a PIN on the mobile carrier account to make SIM swaps and port outs harder. CISA acknowledges one constraint: some services still fall back to SMS during account recovery, so eliminating it everywhere may not be possible. Your own product does not have to be one of them.

Step by step: an SS7 and Diameter risk plan for an enterprise

You cannot fix your carrier's interconnect. You can stop your security depending on it.

Step 1: inventory phone number dependencies

Look in login, password reset, payment step up, account recovery, admin consoles and support desk verification.

# Find SMS and voice verification paths in a code base (adjust the terms to your stack)
grep -rniE "sms|otp|one[_-]?time|verify(_|-)?phone|send_?code|voice_?call|callback" \
  --include=*.{js,ts,py,go,java,kt,rb,php,cs} src/ | grep -viE "test|mock" | sort | head -100

# List SMS or telephony SDKs declared as dependencies
npm ls --all 2>/dev/null | grep -iE "sms|telephony|voice|otp" || true
pip list 2>/dev/null | grep -iE "sms|telephony|voice" || true
grep -iE "sms|telephony|voice" go.mod pom.xml build.gradle Gemfile.lock composer.lock 2>/dev/null

Then export enabled authentication methods from your identity provider and SaaS admin consoles, and record for each SMS or voice method where it is used, who it covers and whether a stronger method exists alongside it.

Step 2: move staff to phishing resistant MFA

Start with administrators and engineers, then everyone; see our phishing resistant MFA rollout order.

# Example authentication policy (illustrative; map the keys to your identity provider)
policies:
  - name: admins-and-engineers
    applies_to: [group:admins, group:engineering]
    allowed_methods: [webauthn_security_key, webauthn_platform_passkey]
    disallowed_methods: [sms, voice, email_otp]
    recovery: [recovery_codes, helpdesk_identity_proofing]
  - name: all-staff
    applies_to: [group:everyone]
    allowed_methods: [webauthn_security_key, webauthn_platform_passkey, totp_app]
    disallowed_methods: [sms, voice]

Step 3: remove the SMS fallback

Adding a passkey does not remove the phone number already on the account. Find accounts with both and remove SMS and voice once the stronger factor is verified; see turning off SMS fallback.

Step 4: treat SMS as restricted for customers

Offer passkeys or an authenticator app to every user. Check SIM change and port signals before sending a code. Never let one SMS code reset both the password and the second factor. Bind codes to the requesting session, expire them fast and rate limit sends. See plan a migration off SMS codes.

Step 5: ask your carriers

If you buy mobile service for staff or SMS delivery for your product, you can ask about controls. Keep the questions about defences, not attacks:

• Do you run SS7 and Diameter signalling firewalls at the interconnect, with category 1 to 3 filtering in line with GSMA FS.11 and FS.19?
• Is SMS home routing deployed for your subscribers, and do you monitor GTP control traffic on roaming links?
• Do you set security requirements for interconnect carriers and IPX providers, and do you lease your global titles to third parties?
• Does 5G roaming go through a SEPP, and with which partners?
• Can we set a port out PIN or freeze on every corporate line, and how is a SIM swap authorised?
• How would you tell us about suspected signalling based tracking or interception affecting our lines?

Record the answers and compare suppliers. The asking itself gives the account team a reason to prioritise the work.

Step 6 (operators and labs): check your own exposure

Scan only ranges you own or are authorised to test.

# Run only against address ranges you own or are authorised to test.
sudo nmap -sY -p 2905,3565,14001,3868,5868 --reason 192.0.2.0/24
sudo nmap -sS -p 3868,5868 --reason 192.0.2.0/24

On a Diameter node you control, require TLS. In the open source freeDiameter daemon:

# freeDiameter.conf (excerpt) for a lab HSS
Identity = "hss.lab.example";
Realm    = "lab.example";
Port     = 3868;
SecPort  = 5868;
TLS_Cred = "/etc/freeDiameter/hss.cert.pem", "/etc/freeDiameter/hss.key.pem";
TLS_CA   = "/etc/freeDiameter/peers-ca.pem";
TLS_CRL  = "/etc/freeDiameter/peers-ca.crl";
ConnectPeer = "mme.lab.example" { ConnectTo = "198.51.100.10"; No_TCP; };

freeDiameter's sample config documents a No_TLS peer option that assumes "transparent security instead of TLS". Treat it as a finding unless IPsec is provably underneath.

To baseline your own lab captures, these tshark filters use fields from Wireshark's display filter reference:

tshark -r lab-diameter.pcapng -Y "diameter.flags.request == 1" \
  -T fields -e diameter.Origin-Host -e diameter.Origin-Realm \
  -e diameter.applicationId -e diameter.cmd.code | sort | uniq -c | sort -rn
tshark -r lab-sigtran.pcapng -Y "m3ua" \
  -T fields -e m3ua.protocol_data_opc -e m3ua.protocol_data_dpc | sort | uniq -c
tshark -r lab-sigtran.pcapng -Y "sccp" \
  -T fields -e sccp.calling.digits -e sccp.calling.ssn -e sccp.called.digits | sort | uniq -c

Knowing which domains, global titles and operations normally cross each link is how monitoring starts.

Common mistakes

• Calling SMS good enough. NIST restricts it and CISA says not to use it as a second factor.
• Adding passkeys but keeping the SMS fallback. The weakest enrolled method sets the account's real strength.
• Letting one SMS code reset everything. That turns an interception into a takeover.
• Assuming 5G ends the problem. Older roaming partners keep SS7 and Diameter on the interconnect.
• Treating Diameter TLS as end to end. It is hop by hop.
• Filtering only category 1. Damaging traffic looks like normal roaming and needs stateful checks.
• Exposing SIGTRAN or Diameter ports. IP transport needs ordinary firewall discipline and an allow list of peers.
• Leasing global titles without egress controls. ENISA singles this out: traffic leaving under your signalling identity is your responsibility.
• Keeping signalling experts away from security. ENISA found the expertise often sits outside the SOC and fraud teams; put them together.

FAQ

What is SS7 in simple terms?

SS7, Signalling System No. 7, is the set of protocols telephone networks use to talk to each other about calls, text messages and roaming. It runs on a signalling network separate from the voice itself and is defined in the ITU-T Q.700 series, with the mobile parts in 3GPP TS 29.002.

What is the difference between SS7 and Diameter?

SS7 serves 2G, 3G and fixed telephony. Diameter (RFC 6733) replaced MAP for 4G, runs over IP and requires TLS, DTLS or IPsec between peers, but keeps the same roaming trust model.

Can someone track my phone through SS7?

Regulators confirm that signalling abuse can reveal a phone's approximate location. CSRIC VI told the FCC it usually shows the serving cell or switch, which may identify a city or district, not GPS coordinates. Defending against it is mainly an operator job through filtering, firewalls and home routing.

Is SMS two factor authentication safe?

It is weaker than any phishing resistant method. NIST SP 800-63B-4 lists phone network delivery as a restricted authenticator, and CISA advises against SMS as a second factor because messages can be intercepted. Use passkeys or security keys, and remove the SMS fallback once they are enrolled.

What is SIGTRAN?

The IETF suite that carries SS7 over IP using SCTP and adaptation layers such as M3UA, SUA and M2PA.

What is a signalling firewall?

A system at the STP or Diameter Edge Agent that blocks messages that should never come from outside, checks sender consistency, and applies stateful plausibility checks to roaming traffic.

What are GSMA FS.11 and FS.19?

GSMA Fraud and Security Group documents for members: FS.11 for SS7 monitoring and its message categories, FS.19 for Diameter interconnect security.

Does 5G fix SS7 and Diameter problems?

For 5G to 5G roaming, largely yes in design: the SEPP adds mutual authentication, identity checks and protection against silent changes by intermediaries. But networks still interwork with older partners, so SS7 and Diameter stay on the interconnect, and SEPPs only help when configured correctly.

Where Safeguard fits

Safeguard does not inspect signalling traffic, operate a signalling firewall or protect phone numbers, and it has no view into carrier networks. The honest connection is the software around them. Signalling gateways, Diameter agents, lab cores and your own authentication service are built from open source libraries and container images: SCTP stacks, ASN.1 and TLS libraries, HTTP/2 servers, and the SDKs that send codes and handle passkeys. Safeguard scans those repositories, images and SBOMs, matches components against vulnerability data, ranks findings with reachability analysis, and shows which projects carry a component version when an advisory lands.

Moving off SMS codes means new authentication code and new dependencies, and signalling equipment runs on open source libraries that receive fixes on someone else's schedule. The gap between a published fix and a deployed one is where most of that exposure lives.

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

These demos show dependency and remediation workflows, not telecom signalling. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo is a real CLI session. You ask it to fix the lodash CVE in a repository, and it reads the finding and the advisory, asks before any command that changes something, moves lodash to 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow applies when you bump a vulnerable WebAuthn, TLS or SMS SDK dependency in the authentication service you are moving off SMS codes.

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

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask which of your projects still ship a given SMS or telephony SDK version, or which services pull a particular SCTP or Diameter library, and get the answer from your own scan data.

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

This demo is a real Android session: you send work to a computer running the Safeguard CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It is a practical way to keep an engineer in the loop on a dependency fix while away from the desk, without the approval itself depending on an SMS code.

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

Quick check

Sources

• ITU-T Recommendation Q.700: Introduction to CCITT Signalling System No. 7
• ITU-T Recommendation Q.702: Signalling data link
• ITU-T Recommendation Q.703: Signalling link
• ITU-T Recommendation Q.704: Signalling network functions and messages
• ITU-T Recommendation Q.711: Functional description of the SCCP
• ITU-T Recommendation Q.761: ISDN User Part functional description
• ITU-T Recommendation Q.771: Functional description of transaction capabilities
• ITU-T Recommendation Q.713: Signalling connection control part formats and codes
• ITU-T Recommendation Q.773: Transaction capabilities formats and encoding
• 3GPP TS 29.002: Mobile Application Part (MAP) specification
• 3GPP TS 29.078: CAMEL Application Part (CAP) specification
• 3GPP TS 29.272: MME and SGSN related interfaces based on Diameter protocol
• 3GPP TR 23.840: Study into routeing of MT-SMs via the HPLMN
• 3GPP TS 33.501: Security architecture and procedures for 5G System
• ETSI TS 133 501 V19.7.0 (2026-08), PDF
• 3GPP TS 29.573: 5G System PLMN Interconnection; Stage 3
• RFC 2719: Framework Architecture for Signaling Transport
• RFC 3331: SS7 MTP2-User Adaptation Layer (M2UA)
• RFC 3868: SCCP User Adaptation Layer (SUA)
• RFC 4165: SS7 MTP2-User Peer-to-Peer Adaptation Layer (M2PA)
• RFC 4666: SS7 MTP3-User Adaptation Layer (M3UA)
• RFC 5516: Diameter Command Code Registration for the 3GPP Evolved Packet System
• RFC 6733: Diameter Base Protocol
• RFC 9260: Stream Control Transmission Protocol
• IANA: Signaling User Adaptation Layer Assignments
• IANA: Service Name and Transport Protocol Port Number Registry
• ENISA: Signalling Security in Telecom SS7/Diameter/5G (March 2018)
• FCC DA 24-308: Request for comment on measures to prevent location tracking via Diameter and SS7 (27 March 2024)
• CISA: Mobile Communications Best Practice Guidance
• NIST SP 800-63B-4: Authentication and Authenticator Management
• freeDiameter: sample configuration file
• Wireshark display filter reference: Diameter
• Wireshark display filter reference: M3UA
• Wireshark display filter reference: GSM MAP
• Wireshark display filter reference: SCCP

Last reviewed: 25 October 2026. 3GPP and the IETF revise these specifications regularly, and GSMA guidance is updated for members; check the linked documents for the versions your carriers and equipment actually use.