5G Security Explained: SUCI, 5G-AKA and What Your Hotspot Exposes

5G security rests on two ideas. SUCI encrypts your permanent subscriber identity with the home operator's public key before it ever crosses the air, and 5G-AKA lets your home network, not just the network you are roaming on, confirm that your phone really authenticated. Both apply only on standalone 5G. Your phone hotspot, meanwhile, is a small Wi-Fi router with its own LAN exposure.

This post goes one level deeper than our guide to mobile hotspots and tethering from LTE to 5G Advanced. That post covers how tethering works and how to choose a setup. Here we open 3GPP TS 33.501, the 5G security architecture specification, and follow your phone through identity concealment, authentication, encryption and integrity. Then we come back down to the LAN that your laptop joins when you tap "Personal Hotspot", and finish with what an enterprise policy should say about it.

Everything technical below was checked against the current version of TS 33.501 (V20.3.0, dated September 2026), the GSMA eSIM IoT specification, IETF RFC 9048, Android and Apple documentation, and guidance from CISA, NIST and ENISA. The sources are listed at the end.

Key takeaways

• On 2G, phones authenticate to the network but the network never proves itself to the phone. A false base station can therefore pose as the operator, ask for the IMSI and, on older ciphers, read traffic.
• 3G and 4G added mutual authentication, but a phone still answers an identity request before security is set up, so IMSI catchers kept working on those generations too.
• 5G replaces the plaintext IMSI with SUCI, an ECIES encryption of the subscriber number under the home operator's public key. The standard profiles use X25519 (Profile A) or secp256r1 (Profile B), with AES-128 in CTR mode and a 64-bit HMAC-SHA-256 tag.
• SUCI only helps if the operator provisions the public key in the SIM. Without it, the phone must use the "null scheme", which sends the subscriber number in clear.
• 5G-AKA keeps the familiar SIM challenge and response but adds a home network confirmation step. The visited network only gets the anchor key after the home network has checked the response.
• EAP-AKA' is the other primary method. It runs the same SIM algorithms inside EAP, binds keys to the access network name, and uses SHA-256 instead of SHA-1.
• Non-standalone 5G (5G radio, 4G core) inherits 4G identity and authentication. SUCI, 5G-AKA and the 5G core's protections apply only on standalone 5G.
• User plane integrity protection is optional in 5G and decided per session by network policy. LTE research such as aLTEr showed why integrity matters even when data is encrypted.
• eSIM moves the SIM profile into a soldered secure element and replaces physical swaps with certified remote provisioning. It does not stop an attacker who talks your carrier into moving your number.
• A phone hotspot is a NAT router with DHCP, DNS forwarding and, on dedicated 5G routers, a web admin page. What it exposes depends on its Wi-Fi security, client isolation and admin settings, not on 5G.
• Android lets users and enterprise admins switch off 2G. iPhone turns off 2G and 3G when Lockdown Mode is on.

A dated timeline of cellular security

Dates come from the sources at the end. Where a source gives only a year, so do we.

How the generations compare

"Optional" for ciphering is not a typo. TS 33.501 says confidentiality of user data and of radio signalling is optional to use and "should be used whenever regulations permit." Integrity of signalling is mandatory, apart from listed exceptions and unauthenticated emergency calls.

What could IMSI catchers do on 2G to 4G?

An IMSI catcher, also called a false base station, is a radio that pretends to be a cell tower. Phones pick the strongest suitable cell, so a nearby fake tower can attract them. What it can do next depends on the generation the phone speaks.

2G: no proof the tower is real

GSM authenticates the SIM to the network: the network sends a random challenge, the SIM answers with a value only the right key could produce. The network never answers a challenge from the phone. Google's Android security team describes the consequence plainly: GSM lacks mutual authentication, which enables person in the middle attacks, and over the air interception and decryption of 2G traffic has been demonstrated since 2010.

A fake 2G tower can therefore ask the phone for its IMSI (the International Mobile Subscriber Identity on the SIM), accept it without proving anything, and pick a weak or null cipher for the session. Calls and SMS sent over that link are exposed. That is why downgrade to 2G is, in Google's words, the most common use of false base stations.

3G and 4G: mutual authentication, but identity still leaks

UMTS introduced AKA (Authentication and Key Agreement). The SIM, now a USIM application, checks a token called AUTN that proves the challenge came from the home network and is fresh. A fake tower cannot complete AKA without the subscriber key, so it cannot set up an encrypted session that the phone will accept.

The identity problem stayed. Before AKA runs, the network may need to know who you are. If it does not recognise your temporary identity, it sends an identity request and the phone replies with the IMSI in clear. A false base station can send that request too. It learns that a specific SIM is present, then releases the phone. No keys are needed for that.

4G LTE kept the same pattern. It also kept two further gaps that researchers spent years documenting: unauthenticated broadcast and pre-security messages that can trigger downgrade or denial of service, and a user plane that is encrypted but not integrity protected. We come back to the second gap below.

5G: SUCI conceals the subscriber identity

5G gives every subscription a SUPI (Subscription Permanent Identifier). For SIM based subscriptions the SUPI contains the IMSI. TS 33.501 clause 5.2.5 says the SUPI "should not be transferred in clear text" over the radio network, except routing information such as the country and network codes.

The phone instead sends a SUCI (Subscription Concealed Identifier). The pieces live on the USIM and are controlled by the home operator:

• the Home Network Public Key
• a Home Network Public Key Identifier saying which key pair is in use
• a Protection Scheme Identifier
• a Routing Indicator used to pick the right authentication server
• a flag saying whether the USIM or the phone itself computes the SUCI

For an IMSI based SUPI, the SUCI carries these fields:

The spec reserves identifiers 0x3 to 0xB for future standard schemes and 0xC to 0xF for proprietary schemes chosen by an operator. It also warns that a unique scheme used by a small group of subscribers can itself make them stand out.

The two standard SUCI profiles

Annex C of TS 33.501 defines the schemes as ECIES (Elliptic Curve Integrated Encryption Scheme). The phone generates a fresh key pair for every SUCI, does a Diffie Hellman exchange with the home network's public key, derives encryption and MAC keys, encrypts the MSIN, and sends its ephemeral public key alongside the ciphertext. Because the ephemeral key changes each time, two SUCIs for the same subscriber look unrelated.

The phone and the home network's de-concealment function (the SIDF, which sits with the UDM) must implement Profile A. Proprietary schemes are capped at 3,000 octets plus the input.

When does the phone send a SUCI at all?

Rarely, which is the point. TS 33.501 clause 6.12.2 limits SUCI to three NAS messages:

1. an initial registration to a network for which the phone has no 5G-GUTI (the temporary identity)
2. a reply to an identity request from the network
3. a deregistration during an initial registration that never completed

The spec adds that in response to an identity request "the UE never sends the SUPI". Most of the time the phone uses its 5G-GUTI, a temporary identifier the network assigns and refreshes.

The null scheme: the hole operators must close

The phone must support the null scheme, which "encrypts" by copying the input. TS 33.501 says the phone uses it only when:

• it is making an unauthenticated emergency session and has no 5G-GUTI for that network
• the home network has configured the null scheme
• the home network has not provisioned the public key needed to compute a SUCI

The last two cases are operator choices. If your operator has not written a public key to your USIM, your 5G phone sends its subscriber number in clear, just as on 4G. The spec makes subscriber privacy enablement "under the control of the home network". There is no setting on the phone that turns it on.

What SUCI does not hide

SUCI protects one identifier on one link. It does not hide:

• the country and network codes, which identify your operator
• your phone's hardware identifier (the PEI) from the network; TS 33.501 only lets the phone send it after NAS security is established, except in emergency registration
• the length of a variable length network identifier, which TS 33.501 notes can leak; operators are told to pad usernames to fixed length
• your location to your own operator, which needs it to route calls
• anything above the radio layer, such as DNS lookups, app traffic or account logins

It also does nothing if the phone is lured to 4G or 2G, where the old identity procedure applies. That is why the downgrade section later matters as much as SUCI itself.

Worked example: compute a SUCI scheme output yourself

TS 33.501 Annex C.4.3.1 publishes a test vector for Profile A, using the test IMSI with MCC and MNC "274012" and MSIN "001002086" and fixed test keys. The short Python script below reproduces it with the open source cryptography package. It is a learning aid built on published test keys, not a tool for anything else.

# Reproduces the 3GPP TS 33.501 Annex C.4.3.1 test vector (ECIES Profile A).
# Test keys only. Never use these keys for anything real.
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
from cryptography.hazmat.primitives.kdf.x963kdf import X963KDF
from cryptography.hazmat.primitives import hashes, hmac
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

HN_PRIV = bytes.fromhex("c53c22208b61860b06c62e5406a7b330c2b577aa5558981510d128247d38bd1d")
EPH_PRIV = bytes.fromhex("c80949f13ebe61af4ebdbd293ea4f942696b9e815d7e8f0096bbf6ed7de62256")

def bcd_msin(msin: str) -> bytes:
    # TBCD: swap each pair of digits, pad an odd length with 0xF
    if len(msin) % 2:
        msin += "f"
    return bytes.fromhex("".join(msin[i + 1] + msin[i] for i in range(0, len(msin), 2)))

hn_pub = X25519PrivateKey.from_private_bytes(HN_PRIV).public_key()
eph = X25519PrivateKey.from_private_bytes(EPH_PRIV)
eph_pub = eph.public_key().public_bytes_raw()

shared = eph.exchange(hn_pub)
okm = X963KDF(algorithm=hashes.SHA256(), length=64, sharedinfo=eph_pub).derive(shared)
enc_key, icb, mac_key = okm[:16], okm[16:32], okm[32:]

plaintext = bcd_msin("001002086")
enc = Cipher(algorithms.AES(enc_key), modes.CTR(icb)).encryptor()
ciphertext = enc.update(plaintext) + enc.finalize()

h = hmac.HMAC(mac_key, hashes.SHA256())
h.update(ciphertext)
tag = h.finalize()[:8]

print("plaintext     :", plaintext.hex())
print("ciphertext    :", ciphertext.hex())
print("mac tag       :", tag.hex())
print("scheme output :", (eph_pub + ciphertext + tag).hex())

Run it with pip install cryptography and python3 suci_profile_a.py. We ran it against the spec and got exactly the published values:

plaintext     : 00012080f6
ciphertext    : cb02352410
mac tag       : cddd9e730ef3fa87
scheme output : b2e92f836055a255837debf850b528997ce0201cb82adfe4be1f587d07d8457dcb02352410cddd9e730ef3fa87

Read the numbers:

• The nine digit MSIN packs into five bytes, 00012080f6. Each pair of digits is swapped and the odd final digit is padded with f.
• The Scheme Output is 32 bytes of ephemeral public key, 5 bytes of ciphertext and 8 bytes of tag: 45 bytes, or 360 bits. That matches the Annex C size rule of 256 + 64 bits plus the input.
• Change the ephemeral private key to any other random value and every byte of the output changes, while the home network can still decrypt it with its private key. That is the unlinkability property in practice.

How does 5G-AKA work?

5G-AKA, specified in TS 33.501 clause 6.1.3.2, "enhances EPS AKA" from 4G "by providing the home network with proof of successful authentication of the UE from the visited network." The cast:

• UE: your phone (the ME, mobile equipment) plus the USIM
• SEAF: the security anchor function in the serving network, co-located with the AMF (access and mobility function)
• AUSF: the authentication server function in your home network
• UDM/ARPF: the home subscriber database and credential processing function, with the SIDF that decrypts SUCIs

The steps

1. The phone sends a registration request with a SUCI (or a 5G-GUTI). The serving network forwards the SUCI and its own serving network name to the home AUSF.
2. The UDM/ARPF de-conceals the SUCI, generates an authentication vector with the AMF separation bit set to 1, derives the key KAUSF, and computes XRES*, the expected response bound to the serving network name.
3. The AUSF stores XRES*, then computes HXRES*, a hash of it, and derives KSEAF. It sends only RAND, AUTN and HXRES* to the serving network. It keeps KSEAF back.
4. The SEAF sends RAND and AUTN to the phone in an Authentication Request, along with a key set identifier and the ABBA parameter.
5. The USIM checks AUTN, which proves the challenge came from the home network and is fresh. If it is acceptable, the USIM computes RES, CK and IK. The phone derives RES*.
6. The phone returns RES* to the SEAF. The SEAF hashes it into HRES* and compares with HXRES*. A match means success "from the serving network point of view".
7. The SEAF forwards RES* to the AUSF. The AUSF compares RES* with the stored XRES*. This is the home network's own check.
8. Only on success does the AUSF send KSEAF to the SEAF, along with the SUPI if a SUCI was used. The SEAF then derives KAMF from KSEAF, the ABBA parameter and the SUPI.

TS 33.501 adds a firm rule: if a SUCI was used, the SEAF does not hand keys to the AMF until it has received KSEAF and the SUPI, and "no communication services will be provided to the UE until the SUPI is known to the serving network."

Why the hash and the hold back matter

In 4G, the home network handed the visited network the expected response and the keys up front. A roaming partner, or anyone who compromised one, could claim a subscriber had authenticated. In 5G-AKA the visited network gets only a hash of the expected response, enough to check the phone's answer, and gets the anchor key only after the home network has seen the real RES*. The home network ends up with evidence that the subscriber was actually present.

The serving network name is folded into RES*, XRES* and KAUSF, so keys derived for one network are useless in another. The ABBA parameter, which stands for "Anti Bidding down Between Architectures", is folded into KAMF so that later security features cannot be silently stripped by a network that pretends to support only an older set.

The key hierarchy in one table

TS 33.501 also requires the authentication algorithms that use the subscription credentials to run inside "tamper resistant secure hardware", which today means the UICC or eUICC.

How does 5G-AKA differ from EAP-AKA'?

EAP-AKA' is the second primary authentication method in TS 33.501 (clause 6.1.3.1). It wraps the same USIM computation in the Extensible Authentication Protocol. RFC 9048, published in October 2021, is the current EAP-AKA' specification and the first to define its behaviour for 5G. It says EAP-AKA' binds derived keys "to the name of the access network" and uses SHA-256 and HMAC-SHA-256 instead of SHA-1.

Which one runs is the home operator's choice, signalled during authentication. Both give the home network control. Both rely on the same USIM secret, so neither protects you if the SIM key itself leaks.

What formal analysis found

In 2018 Basin, Dreier, Hirschi, Radomirović, Sasse and Stettler built the first full formal model of 5G-AKA in the Tamarin prover. Their abstract reports that "some critical security goals are not met" except under assumptions missing from the standard, and proposes provably secure fixes. Their work is one reason the 3GPP security group kept refining the procedure after Release 15. The lesson for defenders is general: a protocol can look sound in prose and still depend on unstated assumptions about which party binds which identifier.

Standalone vs non-standalone 5G: which protections only apply on SA?

Most early 5G launches were non-standalone (NSA). The phone attaches to an LTE cell and an LTE core (the EPC), and a 5G radio is added as a secondary carrier for extra speed. 3GPP calls this E-UTRA NR Dual Connectivity, or EN-DC. Standalone (SA) 5G uses 5G radio and the 5G core (5GC) end to end.

The 5G security features in TS 33.501 are features of the 5G core. If your session is anchored on an LTE core, you get LTE identity and authentication procedures, because that is what the core speaks.

The status bar on your phone is not a reliable guide. "5G" often appears on NSA connections. Some phones show more detail on the network information screen, and some operators publish which areas have standalone service. If identity concealment matters to you, ask your operator two questions: is my plan on standalone 5G, and has a home network public key been provisioned on my SIM?

What does user plane integrity protection cover, and why is it optional?

The user plane is your data: web pages, app traffic, DNS lookups. The control plane is signalling: registration, handovers, session setup.

Ciphering hides the content of packets. Integrity protection proves they were not changed. Without integrity, an attacker who can sit between the phone and the tower can flip bits in encrypted packets. With a stream cipher, flipping a ciphertext bit flips the same plaintext bit, so a known field such as a DNS server address can be changed without knowing the key.

The aLTEr lesson

That is the mechanism behind aLTEr, presented at the 2019 IEEE Symposium on Security and Privacy. The researchers showed that because LTE user data is encrypted but not integrity protected, a relay between phone and network could redirect DNS traffic. The research site says the setup needed special hardware and a controlled lab, that real world use would take high effort, and that likely targets are people of special interest. The fix was not a patch; it was a standards change.

What TS 33.501 requires today

• The gNB must support integrity and replay protection of user data, and activates it "based on the security policy sent by the SMF". The SMF is the session management function in the core.
• The phone must support user plane integrity protection "at any data rate, up to and including, the highest data rate supported by the UE".
• User plane integrity "is optional to use, and shall not use NIA0", the null integrity algorithm.
• All radio signalling messages, apart from listed exceptions, must be integrity protected with an algorithm other than NIA0, except for unauthenticated emergency calls. NIA0 must be disabled on the gNB where unauthenticated emergency sessions are not a regulatory requirement.

The algorithms are 128-NIA1 (SNOW 3G), 128-NIA2 (AES in CMAC mode) and 128-NIA3 (ZUC), matching the ciphers 128-NEA1 (SNOW 3G), 128-NEA2 (AES in CTR mode) and 128-NEA3 (ZUC).

Why it stays optional

The spec gives the reason in a note: integrity protection of the user plane "adds the overhead of the packet size and increases the processing load" on both the phone and the base station. Each protected packet carries a 32-bit MAC. At gigabit rates that is a real cost, and it is the operator who pays it.

So the operator decides per data session, through the user plane security policy. That makes it a configuration question, not a phone question. Users cannot turn it on. The practical defence for everyone is the one Android's security team describes: treat all networks as hostile and rely on end to end encryption. DNS over HTTPS or DNS over TLS, HTTPS everywhere and an enterprise VPN make a bit flipping attack on the radio link far less useful, because the attacker can no longer predict or change plaintext that matters.

What do eSIM and the GSMA remote provisioning architecture change?

A traditional SIM is a removable smart card. An eSIM is an eUICC, a secure element soldered into the device, into which operator profiles are downloaded. The GSMA defines the architecture in a family of specifications. The consumer specification (SGP.22) covers phones, tablets and wearables. SGP.32, the eSIM IoT technical specification, covers "IoT Network Constrained and/or User Interface Constrained Devices"; version 1.2 is dated 27 June 2024 and defines the IoT architecture, its interfaces and its security functions, with a dedicated chapter on how it relates to SGP.22.

What changes for the radio side

Nothing in the protocol. A downloaded profile holds the same subscriber key K, the same USIM application and, if the operator chooses, the same home network public key for SUCI. 5G-AKA and SUCI work identically on a physical SIM and an eSIM.

What changes for provisioning

• No card in the post. Profiles come from an operator's provisioning server over an authenticated, encrypted channel. SGP.32 alone defines certificate types for its servers and eUICC manufacturers, plus a certificate management chapter.
• The secure element carries certificates. SGP.32 defines eUICC and eUICC manufacturer certificates alongside the server certificates, so each side of a download can check who it is talking to.
• IoT gets a remote manager. SGP.32 adds an eSIM IoT remote manager (eIM) and an IoT profile assistant (IPA) on the device or the eUICC, so a fleet of headless sensors can switch operator profiles without a screen.

What does not change

The weakest point of SIM security has rarely been the cryptography. It is the operator's customer service and account recovery. Someone who talks a carrier into issuing a new eSIM for your number has done a SIM swap, and eSIM makes that possible without a physical card ever changing hands. Our posts on SIM swap, vishing and smishing and the CSRB review of SMS MFA and SIM swap findings cover that side.

CISA's Mobile Communications Best Practice Guidance, aimed at highly targeted individuals, gives the matching advice: set a telco PIN or passcode on your carrier account, add MFA to it, and migrate away from SMS as a second factor because "SMS messages are not encrypted." It also notes that enrolling an authenticator app does not automatically remove SMS from an account, which leaves a weak fallback.

What does a phone hotspot or 5G fixed wireless router expose on the LAN side?

Turn on Personal Hotspot and your phone becomes a router. Apple's support page describes it as using the cellular data connection "to create a temporary, portable Wi-Fi network that other devices can use". On the cellular side, the operator sees one subscriber. On the LAN side, your laptop, a colleague's tablet and anyone else who has the password share a small network. A 5G fixed wireless access (FWA) router does the same job with a bigger radio, Ethernet ports and a web admin page.

None of the 5G protections above reach that LAN. SUCI, 5G-AKA and NEA ciphering stop at the phone or router. What your laptop is exposed to depends on the LAN.

DHCP

When your laptop joins, it asks for an address and the hotspot assigns one from a private range, plus a gateway and DNS server. The hotspot's DHCP table now holds your device name and MAC address. Modern phones and laptops can randomise the Wi-Fi MAC per network. Hostnames are the bigger leak: "Janes-MacBook-Pro" tells every other client who you are.

DNS

Most hotspots tell clients to use the hotspot itself as the DNS server and forward queries to the operator's resolvers. Unless the client encrypts DNS, the operator sees every hostname you look up, and so does anything that can read traffic on the LAN. This is also where an aLTEr style tampering attack on an unprotected user plane would bite, which is one more reason to encrypt DNS end to end.

Admin UI

A phone hotspot has no web admin page; you configure it in Settings. A 5G FWA router almost always has one, reachable at the gateway address from the LAN. The questions to ask of any such router: is the admin password still the one on the label, is the admin page reachable from the cellular side, which remote management features are on, and when did the firmware last update? These routers run an embedded Linux with a web server, a DHCP and DNS daemon and a Wi-Fi stack, almost all of it open source.

Client isolation

Client isolation, sometimes called AP isolation, stops clients on the same access point from talking to each other at the Wi-Fi layer. The open source hostapd daemon, which many Linux based routers use, has an ap_isolate option for exactly this, and its sample configuration notes that bridging between stations is allowed by default. Some FWA routers expose the setting as "guest network" or "client isolation". Phone hotspots generally do not expose it, so assume other clients can reach your laptop and keep the laptop's own firewall on.

For a deeper look at choosing between a cellular tablet, Wi-Fi only devices and tethering, see Wi-Fi only vs cellular tablets.

How do downgrade attacks to older generations work?

In concept, a downgrade attack makes the phone leave a strong network for a weak one. A false base station can broadcast a stronger signal for an older generation, or send messages that the phone accepts before security is in place, telling it that newer service is not available. Google's Android team notes that this can be triggered remotely and silently, and that it works "regardless of whether local operators have already sunset their 2G infrastructure", because phones still support 2G.

Once on 2G, the phone faces a network that does not prove itself and may pick a null or weak cipher. The 5G protections described above simply do not exist on that link. A related attack does not change generation but persuades the phone that ciphering is not supported, producing a null ciphered connection. Google's 2023 post says recent reports found null ciphers used in commercial networks, exposing voice and SMS, including one time passwords sent by text.

TS 33.501 adds a network side mitigation: Annex E describes how operators can use the measurement reports phones already send to detect false base stations. That helps operators, not individual users.

What users and admins can switch off

Android 16 also flipped the meaning of the toggle's default position. The AOSP page is careful to say that the actual default, 2G enabled, did not change, and that a user's earlier choice is preserved. Check what "on" means on your build before telling users which way to flip it.

Lockdown Mode is a broad hardening mode, not a cellular setting. Apple describes it as protection against extremely rare and highly sophisticated attacks, and it also restricts messaging attachments, web technologies, wired connections and configuration profiles. A managed iPhone in Lockdown Mode cannot be newly enrolled in device management, which matters for enterprise rollouts.

What should an enterprise policy say about tethering and hotspots?

NIST SP 800-124 Revision 2, published in May 2023, is the reference guide for managing mobile devices in the enterprise. NIST SP 1800-33, the NCCoE's 5G cybersecurity practice guide, published its initial public draft of Volume A on 18 March 2025, drawing recommendations from 5G standards and testbed work. CISA's mobile communications guidance adds advice for highly targeted staff. Pulling those together, a short policy might read like this.

Scope. Applies to company owned and personally owned phones, tablets and 5G routers used to reach company systems.

Allowed uses. Tethering a company laptop to a company phone is allowed when no trusted Wi-Fi is available. USB tethering is preferred for a single laptop.

Hotspot configuration.

• WPA3 personal where every client supports it; otherwise WPA2 with a random passphrase of at least 16 characters, changed if shared.
• Hotspot off when not in use; no guest sharing of a company hotspot.
• Dedicated 5G routers: admin password changed from the default, remote administration from the cellular side disabled unless IT manages it, firmware updates applied within the same window as other network gear, client isolation on where available.

Traffic protection. Company laptops connect through the corporate VPN or zero trust access client on any hotspot, with encrypted DNS. Host firewalls stay on.

Cellular hardening.

• Managed Android devices: apply the 2G restriction for staff who travel to high risk locations, or fleet wide where coverage allows.
• Staff designated as highly targeted: Lockdown Mode on iPhone; 2G off and null cipher protection on Android where supported.
• Carrier account PIN and MFA set for every company line; no SMS based MFA for company systems.

Inventory. Dedicated 5G routers are listed in the asset inventory with model, firmware version and owner, so firmware advisories can be matched to devices.

Exceptions. Documented, time limited and approved by security.

Step by step: inspect and harden a hotspot you control

These steps only look at devices and networks you own or administer. They do not touch anyone else's traffic.

Step 1: see what the hotspot handed you

On macOS, after joining the hotspot (replace en0 with your Wi-Fi interface):

# Which interface carries the default route?
route -n get default

# What did DHCP give you: address, router, DNS, lease time?
ipconfig getpacket en0

# Which DNS resolvers is the system actually using?
scutil --dns | grep nameserver | sort -u

On Linux with NetworkManager:

ip route show default
nmcli device show wlan0 | grep -E 'IP4.ADDRESS|IP4.GATEWAY|IP4.DNS'
resolvectl status wlan0

Write down the gateway address. If DNS points at the gateway, the hotspot forwards your lookups to the operator.

Step 2: check whether other clients are visible

# Linux: neighbours your laptop has seen on this LAN
ip neigh show dev wlan0

# macOS
arp -a -i en0

If you see addresses other than the gateway, other clients are on the same LAN. Join a second device you own and try to reach a service on the first (for example a local web server on port 8000). If it connects, the hotspot does not isolate clients, so your laptop's firewall is your only barrier.

Step 3: look at what the router itself exposes

On a 5G FWA router you administer, check which common management ports answer on the LAN side (replace the address with your gateway):

for p in 22 23 53 80 443 8080 8443; do
  nc -z -w 2 192.168.0.1 "$p" && echo "port $p open"
done

# Is the admin UI served over plain HTTP?
curl -sI http://192.168.0.1/ | head -5

Then log in to the admin page and confirm the password is not the default, remote management is off unless you need it, unused services such as UPnP are off, and the firmware version matches the latest one the maker or carrier publishes.

Step 4: build a hardened hotspot on Linux

If you run your own hotspot from a Linux laptop or small board, NetworkManager can create one in one command:

nmcli device wifi hotspot ifname wlan0 con-name Hotspot ssid "field-kit" password "$(openssl rand -base64 18)"

The NetworkManager manual says the hotspot is secured with WPA if the driver supports it. To move it to WPA3 personal and isolate clients on recent NetworkManager versions:

nmcli connection modify Hotspot 802-11-wireless-security.key-mgmt sae
nmcli connection modify Hotspot 802-11-wireless.ap-isolation yes
nmcli connection up Hotspot

If you configure hostapd directly, the equivalent settings, taken from the option names in hostapd's sample configuration, look like this:

# /etc/hostapd/hostapd.conf (excerpt)
interface=wlan0
ssid=field-kit
hw_mode=a
channel=36
wpa=2
wpa_key_mgmt=SAE
ieee80211w=2
sae_password=use-a-long-random-passphrase-here
rsn_pairwise=CCMP
ap_isolate=1

hostapd's own comments describe ieee80211w=2 with wpa_key_mgmt=SAE as WPA3 personal only mode, with protected management frames required. Older clients that only speak WPA2 will not join, which is the trade off.

Step 5: block 2G on managed Android devices

An Android Enterprise device policy controller can set the 2G restriction that Android 14 introduced. In a device owner app, the call is short:

val dpm = context.getSystemService(DevicePolicyManager::class.java)
val admin = ComponentName(context, MyDeviceAdminReceiver::class.java)

// Android 14 (API 34) and later: stop the device from using 2G networks
dpm.addUserRestriction(admin, UserManager.DISALLOW_CELLULAR_2G)

Most teams set this through their device management console rather than code; the restriction is the same. Test it on a handful of devices in each country you operate in before a fleet wide rollout, because some regions still rely on 2G for coverage at the edges.

Step 6: confirm what you can about the cellular side

You cannot see SUCI or user plane integrity settings from the phone's normal settings. What you can do:

1. Check whether your connection is standalone or non-standalone in the phone's network details or your operator's coverage pages.
2. Ask your operator whether SUCI concealment is enabled on your SIM profile, and whether a home network public key has been provisioned.
3. Confirm 2G is off (Android) or Lockdown Mode is on (iPhone) for high risk users.
4. Run the SUCI script above if you want to see the concealment step for yourself.

Where Safeguard fits, honestly

Safeguard does not inspect cellular links, configure hotspots, manage phones or scan firmware, and it does not produce hardware bills of materials. The honest connection is the software around this topic. A 5G router's admin page, DHCP and DNS daemons and Wi-Fi stack are mostly open source components, the apps and backends that your staff reach over tethered links pull in open source dependencies, and the device management and VPN services in your own stack are built from packages like any other. Where you build or ship that software yourself, Safeguard scans repositories, container images and SBOM files for known vulnerable components, shows which projects contain a given component and version, and can open fix pull requests. Firmware inside a carrier supplied router still has to come from its maker or operator.

Common mistakes

• Treating the "5G" icon as proof of 5G security. Non-standalone 5G uses the 4G core, so SUCI and 5G-AKA do not apply.
• Assuming SUCI is always on. If the operator has not provisioned a home network public key, the phone uses the null scheme and sends the subscriber number in clear.
• Thinking encryption implies integrity. Encrypted but unauthenticated data can be changed in transit, as aLTEr showed for LTE. Use end to end encryption above the radio layer.
• Relying on the hotspot's NAT as a firewall between clients. NAT blocks inbound internet traffic, not other clients on the same LAN.
• Leaving the FWA router's admin password at the default. Anyone on the LAN can then read and change its settings.
• Sharing a hotspot passphrase widely and never changing it. Every person who ever had it can still join.
• Turning off 2G fleet wide without testing coverage. In some regions 2G still fills gaps; test first, and remember emergency calls are preserved.
• Misreading the Android 16 toggle. Its default position changed meaning, while the actual default behaviour did not.
• Keeping SMS as a silent MFA fallback. Enrolling an authenticator app does not remove SMS from the account by itself.
• Forgetting the router in the asset inventory. A device nobody owns never gets its firmware updated.

FAQ

What is SUCI in 5G?

SUCI, the Subscription Concealed Identifier, is the encrypted form of your permanent subscriber identity. The phone encrypts the subscriber number with the home operator's public key, using ECIES with X25519 or secp256r1, so a false base station cannot read it. Only the home network's de-concealment function can recover it.

Does 5G stop IMSI catchers?

Partly. On standalone 5G with a provisioned home network key, a fake tower cannot get your permanent identity by asking for it. It can still try to push your phone down to 4G or 2G, where older procedures apply, which is why disabling 2G and using standalone 5G both matter.

What is the difference between 5G-AKA and EAP-AKA'?

Both use the same SIM secret and challenge. 5G-AKA runs in 5G signalling messages and adds a home network confirmation step using a hashed expected response. EAP-AKA' runs inside EAP, with the home network acting as the EAP server, binds keys to the access network name and uses SHA-256. The home operator chooses which one to use.

Is my 5G connection standalone or non-standalone?

Usually you cannot tell from the status bar alone. Check the network details screen on Android, your operator's coverage information, or ask the operator. Non-standalone 5G uses the 4G core, so it lacks SUCI and 5G-AKA.

Is 5G user data integrity protected?

It can be. TS 33.501 requires phones and base stations to support user plane integrity protection, but using it is optional and the network decides per session through its security policy. Because of the processing and packet overhead, operators do not always switch it on.

Is eSIM more secure than a physical SIM?

The radio security is identical: same keys, same algorithms, same SUCI support. eSIM removes the physical card and uses certified secure elements and authenticated remote provisioning. It does not stop SIM swap fraud through a carrier's account recovery, so set a carrier PIN and avoid SMS based MFA.

Is it safe to use my phone's hotspot for work?

Reasonably, if you set it up well. Use WPA3 or a long WPA2 passphrase, keep the hotspot off when idle, run your company VPN and encrypted DNS on the laptop, and keep the laptop's firewall on, because other hotspot clients may be able to reach it.

How do I turn off 2G on Android or iPhone?

On Android 12 and later, open SIM or mobile network settings and use the 2G control ("Allow 2G", or "2G network protection" on Android 16). Managed Android 14 devices can have 2G blocked by an administrator. On iPhone, turning on Lockdown Mode turns off 2G and 3G support.

Can someone on my hotspot see my traffic?

Other clients cannot read your encrypted HTTPS or VPN traffic, but they can see your device on the LAN, try to connect to services it exposes, and on a poorly configured network may see unencrypted traffic such as plain DNS. The hotspot and the operator see your DNS lookups unless you encrypt them.

Does Safeguard secure 5G networks or phones?

No. Safeguard does not inspect radio links, manage phones or scan firmware. It helps with the software you build and ship, including apps and services your staff reach over 5G, by finding known vulnerable open source components and helping fix them.

Why supply chain hygiene still matters here

A phone hotspot, a 5G router and the apps that run over them are all built from open source components, from Wi-Fi daemons and web servers to the libraries in your own mobile and backend code. Firmware fixes still come from the device maker or operator, but the software your team builds and ships is where you can act directly, and the options below cover it; fork and patch is early access today.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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 first demo is a real Android session. It sends work to a computer running the Safeguard CLI and approves the command on the phone with Allow once, Allow for turn or Deny. That fits the situation in this post: you are away from your desk on a tethered connection and still want every command on your workstation to need your say so.

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

The second demo is a real Safeguard CLI session. Asked to fix a lodash CVE, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same approve each step flow applies to the apps and services your staff reach over 5G: a vulnerable dependency gets a tested version bump, not a ticket.

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

The third demo sets up the Safeguard runner on your own machine, approves it with its device code, and runs a scan from the terminal. If your team maintains the configuration tooling, VPN client builds or internal apps used on hotspots, the same flow scans that code locally without sending the repository anywhere first.

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

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• 3GPP TS 33.501 V20.3.0 (2026-09), Security architecture and procedures for 5G system (3GPP archive)
• 3GPP: 5G System Overview
• IETF RFC 9048: Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
• D. Basin et al., A Formal Analysis of 5G Authentication (arXiv 1806.10360, ACM CCS 2018)
• Rupprecht et al., aLTEr: Breaking LTE on Layer Two (IEEE S&P 2019)
• GSMA SGP.32 eSIM IoT Technical Specification, version 1.2 (PDF)
• Google Online Security Blog: Android 14 introduces first of its kind cellular connectivity security features (8 August 2023)
• Android Open Source Project: 2G connectivity toggle
• Android Developers: UserManager reference (DISALLOW_CELLULAR_2G)
• Apple Support: About Lockdown Mode
• Apple Support: Connect to the Personal Hotspot of an iPhone or iPad
• ENISA: 5G networks threat report (21 November 2019)
• CISA: 5G Security and Resilience (archived page)
• CISA: Mobile Communications Best Practice Guidance
• NIST SP 1800-33 (Initial Public Draft): 5G Cybersecurity
• NIST SP 800-124 Rev. 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise
• hostapd sample configuration (hostapd.conf)
• NetworkManager: nmcli reference manual

Last reviewed: 23 October 2026.