Cellular Baseband Firmware Explained: Modem OS, Isolation and Updates

Cellular baseband firmware is the separate operating system that runs on a phone's modem. It drives the radio, implements the 2G, 3G, 4G and 5G protocol stacks and hands calls, SMS and data to Android or iOS through a narrow interface. Because it parses untrusted input from the air, it is signed, hardened and patched through your normal OS updates.

The modem is a second computer inside your phone, and the first code to touch every signalling message a cell tower (or something pretending to be one) sends. This guide goes one level deeper than our posts on the Android verified boot chain of trust and how a smartphone is made. We read Google's baseband hardening and cellular security posts, AOSP's telephony documentation and radio HAL source, the September and October 2026 Android and Pixel bulletins, the August 2026 Apple Platform Security guide, Apple's Lockdown Mode and carrier settings articles, and 3GPP TS 33.501 version 19.7.0. Every interface name, flag, setting and date below comes from those sources. Chipset makers do not publish their modem internals, so where a detail is vendor specific we say so instead of guessing.

Key takeaways

• A phone has at least two main processors. The application processor (AP) runs Android or iOS. The baseband processor, also called the modem or cellular processor (CP), runs its own firmware that handles all cellular communication.
• On Android the AP and modem meet at the Radio Interface Layer. Today that is the AIDL radio HAL, split into config, data, IMS, messaging, modem, network, SAP, SIM and voice interfaces, implemented by the device or chipset maker.
• The main exposure is code that decodes over the air signalling, especially messages a false base station can send before any authentication, plus IMS, IP stacks and SMS and MMS handling. Google's Vulnerability Rewards Program treats remote code execution in the baseband as Critical.
• Published hardening includes Clang's bounds and integer overflow sanitizers in trapping mode, stack canaries, control flow integrity and zero initialised stack variables (shipped together on Pixel 9), plus a long term move to Rust for new parsers.
• Android lets users disable 2G at the modem level (Android 12, Radio HAL 1.6 or later), lets enterprises enforce it (Android 14, DISALLOW_CELLULAR_2G) and added a null cipher toggle in Android 14. iPhone and iPad turn off 2G and 3G in Lockdown Mode.
• Baseband firmware is signed and ships inside the phone maker's OS update. On iPhone the baseband performs its own secure boot with signed software. On Android, modem fixes appear in the monthly bulletins under chipset supplier components and in device maker bulletins such as the Pixel Update Bulletin.
• 3GPP TS 33.501 gives 5G mutual authentication (5G AKA and EAP-AKA') and a concealed subscriber identifier (SUCI). It defines protocol security. It says nothing about memory safety inside the modem, how firmware is signed, or how long a device gets updates.

What is the baseband processor, and what runs on it?

The baseband processor is the part of a phone's silicon that speaks the cellular radio protocols. Google's Pixel team defines it plainly as "the processor on the device responsible for handling all cellular communication (such as LTE, 4G, and 5G)". In many phones it lives on the same system on chip (SoC) package as the application processor, as a separate block with its own cores and memory. In others it is a discrete modem chip next to the SoC. Either way, from the software point of view it is a separate computer.

The software stack inside the modem

What runs on the baseband is not Android, Linux or iOS. Modem firmware is a vendor built image, usually written in C and C++, that combines a small real time operating system with the protocol stacks. Chipset makers do not publish their modem operating systems, so the exact kernel varies by vendor and is not documented publicly. What every modem has to implement is set by 3GPP, and the layers are well known.

Google's 2023 hardening post names these same areas (over the air parsers, ASN.1, XML and DNS decoders, IMS, TCP and IP stacks, SMS and MMS) as the first places to apply sanitizers. It is the best public summary of what lives in a modem.

Why it is a separate processor

Phone makers keep the modem separate for practical reasons, each with security consequences.

1. Real time behaviour. Radio protocols have strict timing. A modem has to answer the network on a schedule that a general purpose OS with a busy scheduler cannot guarantee. Google's post repeatedly notes how sensitive basebands are to CPU overhead: "even very small increases in CPU load can have a substantial impact in some environments."
2. Power. The modem has to keep listening for paging messages while the application processor sleeps. A small, separate processor can do that cheaply. AOSP's RIL documentation shows how much design effort goes into not waking the AP needlessly, down to which side holds a wakelock during a slow request.
3. Certification. Radio firmware goes through regulatory and carrier certification, which is easier for a separate, versioned image.
4. Supplier boundaries. The modem stack is usually written by the chipset supplier, not the phone maker or the OS vendor. A separate image with a defined interface keeps that boundary clean.

The security consequence is that the phone contains a large, complex, vendor written C and C++ code base that sits on the network edge, processes input from anyone within radio range (or anyone who can reach the IMS service), and runs outside the protections of the main OS. Google's December 2023 post sums it up: the baseband has a "unique combination of running in an elevated privilege and parsing untrusted inputs that are remotely delivered into the device."

How does the baseband connect to Android and iOS?

The modem and the main OS have to exchange a lot: commands to dial or hang up, SMS, signal strength, network registration state, SIM status, and the actual IP packets for mobile data. How that happens has two halves: a physical link between the two processors, and a software interface on top of it.

The physical link

The physical link is chosen by the SoC or device maker and is not standardised by Android or 3GPP. Integrated designs commonly use shared memory and interrupts; discrete modems commonly use a bus such as PCIe or USB. Treat any claim about "the" interface as device specific.

What matters for security is whether the modem can reach memory it should not. A peripheral that does direct memory access (DMA) can, in principle, read or write any physical memory it can address. The standard control is an input output memory management unit (IOMMU), which translates and restricts a device's DMA to the pages the OS has mapped for it.

Apple's Platform Security guide is explicit about this control for Wi-Fi: it says Apple operating systems "protect the device from vulnerabilities in network processor firmware", that each Wi-Fi network processor sits on its own isolated PCIe bus, and that an IOMMU on each bus limits the processor's DMA to the memory holding its packets and control structures. The guide also says Apple silicon contains an IOMMU for each DMA agent on Mac. For the cellular baseband, the guide's published statement is about boot integrity rather than DMA: on devices with cellular access, "a cellular baseband subsystem performs additional secure booting using signed software and keys verified by the baseband processor." We did not find a statement in the current guide that describes the baseband's memory isolation in the same detail as Wi-Fi, so we do not claim one.

On Android, IOMMU configuration for the modem belongs to the SoC and the device maker. AOSP documents the software interface, not the hardware isolation, and we found no AOSP page that specifies how a modem's DMA must be restricted.

The software interface on Android: the Radio Interface Layer

On Android the boundary is the Radio Interface Layer (RIL). The telephony framework, which AOSP's documentation calls "RIL Java" on the app processor side, sends requests down and receives responses and unsolicited indications back. Below the framework sits a hardware abstraction layer implemented by the vendor, and below that the vendor's code talks to the modem over the physical link.

The RIL has evolved over the years:

The AIDL interfaces show the shape of the boundary. IRadioModem has a getBasebandVersion call whose documentation says it returns a string "indicating baseband version, eg response from AT+CGMR", a reminder that the AT command heritage of modems still shows through. IRadioNetwork carries the security controls that matter most for this post: setAllowedNetworkTypesBitmap (used for the 2G toggle), setNullCipherAndIntegrityEnabled, setCellularIdentifierTransparencyEnabled and setSecurityAlgorithmsUpdatedEnabled. Each of those is a request from Android to the modem. Android decides the policy; the modem firmware enforces it, because only the modem sees the radio messages.

So when you turn off 2G, Android does not inspect radio traffic; it asks the modem not to use 2G and trusts it to comply. The same is true for null ciphers.

Two more interfaces sit next to the radio HAL:

• ImsService. Android 9 introduced ImsService, a System API that AOSP describes as "a well-defined interface between the Android platform and a vendor or carrier-provided IMS implementation." Depending on the hardware, the IMS stack can live in the modem or in an app on the AP. AOSP notes that a preinstalled IMS app "can also be configured to be Play Store updatable."
• Carrier configuration. Since Android 6.0, carrier configuration has been a public API: a set of key value pairs that carrier apps holding UICC carrier privileges can supply dynamically, instead of static overlays baked into the framework. Carrier configuration changes how the platform behaves on a network. It is not modem firmware.

The software interface on iOS

Apple does not publish an equivalent of the RIL. Its Platform Security guide treats the baseband as part of the secure boot chain: "Each step of the startup process contains components that are cryptographically signed by Apple to enable integrity checking", and the list of those components includes "the bootloaders, the kernel, kernel extensions (kext), and cellular baseband firmware." How those updates are authorised is covered in the signing section below.

What attack surface does the baseband have?

This section describes the risks conceptually, as Google and 3GPP describe them. It contains no exploit detail.

Over the air signalling before authentication

A phone cannot know whether a base station is genuine before it talks to it. Google's August 2023 post says it directly: "a smartphone cannot reliably know the legitimacy of the cellular base station before attempting to connect to it." A false base station (FBS, also called an IMSI catcher or cell site simulator) can broadcast system information and send signalling messages that the modem must decode before any mutual authentication has happened. Bugs in the code that decodes those messages are reachable by anyone with suitable radio equipment nearby. This is why Google singles out "functions handling pre-authentication messages that can be injected with a false/malicious base station" as the first place to add runtime checks.

Legacy 2G and downgrade

2G GSM, first deployed in 1991 according to Google, has no mutual authentication. Android's own UserManager documentation states that "2g has no mutual authentication between a device and cellular base station and downgrading a device's connection to 2g is a common tactic for several types of privacy and security compromising attacks that could allow an adversary to intercept, inject, or modify cellular communications." Google adds that downgrade can be "remotely triggered in a malicious attack, silently inducing devices to downgrade to 2G-only connectivity", and that this happens "regardless of whether local operators have already sunset their 2G infrastructure." In other words, the 2G code in your modem is reachable even if no carrier in your country runs 2G.

Null ciphers

Cellular link encryption is chosen by the network. Google points out that circuit switched voice and SMS "are strictly protected only by the cellular link layer cipher, which is fully controlled by the network without transparency to the user." Every generation has a null algorithm: the radio HAL lists A5/0 and GEA0 for 2G, UEA0 and UIA0 for 3G, EEA0 and EIA0 for 4G, and NEA0 and NIA0 for 5G. Google notes that some false base stations can trick phones into a null cipher, exposing SMS such as one time passcodes.

IMS, VoLTE and SMS

IMS moves voice and messaging onto IP. That brings SIP parsing, codecs and IP stacks into the picture, and it changes reach: Google notes that for protocols like IMS, injecting crafted traffic "can be executed remotely from any global location using an IMS client." SMS and MMS handling is a long standing remote entry point on every generation.

How serious is it?

Three public signals show the scale:

• Google's Vulnerability Rewards Program classifies remote code execution in the cellular baseband as Critical severity, a change Google says it made after seeing "the severity and apparent abundance of these vulnerabilities."
• Google's October 2024 Pixel post states that zero day baseband exploits have been used to deploy commercial spyware, and that exploit marketplaces list baseband exploits "often with relatively low payouts, suggesting a potential abundance of such vulnerabilities."
• The bulletins show a steady flow of modem fixes. The September 2026 Android Security Bulletin lists 16 entries with the subcomponent "Modem", all rated High, in the sections for two chipset suppliers whose details are "available directly from" those suppliers. The September 2026 Pixel Update Bulletin lists five Modem entries, two rated Critical and three High, with types including remote code execution, denial of service and elevation of privilege.

A modem compromise does not automatically give control of Android or iOS. An attacker would still have to cross the isolation between modem and AP, through the HAL, shared memory or DMA, which is why IOMMU configuration and a narrow, well validated interface matter.

What hardening has been published?

Compiler sanitizers in the baseband

Google's December 2023 post is the most detailed public guide to hardening modem firmware. It focuses on two checks from Clang's Undefined Behavior Sanitizer that work on bare metal targets because they do not need OS or architecture support:

• Integer Overflow Sanitizer (IntSan) aborts on signed and unsigned integer overflows unless the overflow is made explicit. Unsigned overflow is defined behaviour in C, but it often leads to bad array indexes, so IntSan treats it as a bug unless annotated.
• BoundsSanitizer (BoundSan) adds bounds checks to array accesses where the compiler cannot prove safety and the array size is known at run time. Google notes that for correctly written C and C++, BoundSan "should produce no false positives."

The post recommends a three stage rollout: detect and fix violations, measure and reduce overhead, then soak in pre-production. It gives the two modes as compiler flags. Diagnostics mode recovers and reports:

# Diagnostics mode: for testing only, recovers after each violation
-fsanitize=signed-integer-overflow,unsigned-integer-overflow,bounds -fsanitize-recover=all

Trapping mode stops execution on a violation and is the one that ships:

# Trapping mode: the production configuration
-fsanitize=signed-integer-overflow,unsigned-integer-overflow,bounds -fsanitize-trap=all

Because Clang has no UBSan runtime for bare metal targets, the firmware team supplies its own handlers at link time for diagnostics mode. Hot functions can be excluded with -fsanitize-ignorelist after review, and Google suggests the physical layer may be a candidate to leave out entirely if overhead is prohibitive. The same post urges teams to modernise their toolchains, because old compilers carry their own bugs, and to write new parsers in Rust, which "is ready for bare-metal environments such as the baseband."

What Pixel ships

Google's October 2024 post lists the mitigations in the Pixel 9 modem, which it calls "the most hardened baseband we've shipped yet":

On a trap the modem restarts rather than continuing, turning a potential code execution bug into a dropped connection.

Android platform controls

In every case emergency calls are exempt. The UserManager documentation says that with 2G disabled "Emergency calls are an exception and are never impacted", and the radio HAL says the modem "must bypass" the null cipher setting for an emergency call. Each control also depends on the device's modem and HAL supporting it, which is why Google wrote that it expects the null cipher feature "to be available in more devices over the next few years."

Apple platform controls

Apple's published controls for the baseband are the signed secure boot of the baseband subsystem, described above, and Lockdown Mode. Apple's support article for Lockdown Mode says that when it is on, "2G and 3G cellular support is turned off for iPhone and iPad." The Platform Security guide describes Lockdown Mode as "an optional, extreme protection" for people who might be "personally targeted by some of the most sophisticated digital threats", available in iOS 16 and later, with additional protections from iOS 17. The guide does not describe a separate 2G toggle outside Lockdown Mode.

How is baseband firmware signed, delivered and updated?

Signing

On iPhone and cellular iPad, baseband firmware is among the components signed by Apple and verified at boot. Apple's guide says updates use the same hardware root of trust, that its installation authorization server personalises each update to the device's Exclusive Chip Identification (ECID) with an anti-replay value, so firmware from one device "can't be copied to another", and that Apple can "stop signing older operating system versions with known vulnerabilities and help prevent downgrade attacks."

On Android, the modem image is signed by its supplier and loaded by the SoC's own boot chain. Android Verified Boot (covered in our verified boot post) protects the Android partitions; the modem's own signature check is part of the SoC vendor's secure boot and is not specified by AOSP. In practice the device maker controls which modem image ships with which OS build.

Delivery

For both platforms, the important practical point is the same: you do not update the baseband separately. It arrives inside the phone maker's OS update.

• iPhone. Baseband firmware is part of the iOS or iPadOS update that Apple signs and personalises. Carrier settings updates are separate and smaller; Apple's support article says the carrier settings version is shown under Settings, General, About, "next to Carrier."
• Pixel. Google says Pixel devices "start receiving OTA updates on the same day the monthly bulletin is released", that "it takes about one and a half calendar weeks for the OTA to reach every Google device", and that firmware images are published on the Google Developer site. Pixel bulletins list modem fixes alongside platform fixes.
• Other Android devices. Device makers integrate fixes from the chipset supplier into their own builds. The Android Security Bulletin says fixes "from SOC manufacturers are available directly from the manufacturers", and its FAQ notes that device and chipset makers may publish their own bulletins.

Reading the monthly bulletin for modem entries

The Android Security Bulletin is published "on the first Monday of each month unless that Monday falls on a holiday." Google notifies Android partners "of all issues at least a month before publishing the bulletin." The bulletin index now says platform fixes are merged into AOSP "24 to 48 hours after the quarterly security bulletin is released (March, June, September, December)." Each bulletin has two security patch levels (SPLs):

Two details are easy to miss. First, the chipset supplier sections usually say the "severity assessment of these issues is provided directly by" the supplier, and that "further details are available directly from" it, so the Android bulletin is an index, not the full advisory. Second, the bulletin's reference prefixes tell you whose bug it is: A- for an Android bug ID, and prefixes such as QC-, M-, N-, B- and U- for individual chipset suppliers. An asterisk means the issue is not public and the fix is "generally contained in the latest binary drivers."

The device maker bulletins add more. The Pixel Update Bulletin FAQ says vulnerabilities in device and partner bulletins "are not required for declaring a security patch level." That means a phone's SPL tells you about the Android bulletin, not about everything its maker fixed.

End of support

Because modem fixes travel inside OS updates, a phone that stops receiving OS updates also stops receiving modem fixes. There is no separate channel. For fleets this is the single most important lifecycle fact in this post.

What does 3GPP TS 33.501 add for 5G, and what does it not cover?

TS 33.501, "Security architecture and procedures for 5G System", is the 3GPP specification for 5G security. It was created for Release 15 in 2017 and is still under change control. Our 5G core post covers the network side; here we focus on what reaches the phone. The ETSI publication we read is version 19.7.0 (August 2026, Release 19); the 3GPP archive also carries Release 20 versions. Its scope covers "the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio."

What it adds

• Mutual authentication. The specification says the purpose of primary authentication is "to enable mutual authentication between the UE and the network", and that the UE and serving network "shall support EAP-AKA' and 5G AKA." The resulting anchor key, K_SEAF, is provided by the home network's authentication server function (AUSF) to the serving network, which gives the home network control over authentication even when roaming.
• SUPI concealment. The permanent identifier (SUPI) is protected over the air as a SUCI, a "privacy preserving identifier containing the concealed SUPI." The phone encrypts the subscriber part of the identity using a Home Network Public Key stored on the USIM. Annex C defines two ECIES profiles: Profile A uses Curve25519 and Profile B uses secp256r1. Operators can also have the USIM compute the SUCI itself.
• When concealment does not happen. The phone uses the "null-scheme" (no concealment) only for an unauthenticated emergency session without a 5G-GUTI, when the home network has configured the null scheme, or when the home network "has not provisioned the public key needed to generate a SUCI." In plain words, SUCI protects you only if your operator provisioned it.
• Temporary identifiers. A new 5G-GUTI is sent only after NAS security is active, and the phone "never sends the SUPI" in response to an Identity Request.
• Ciphering and integrity requirements. The UE "shall implement" NEA0, 128-NEA1 and 128-NEA2, and may implement 128-NEA3. NIA0 (null integrity) "shall be disabled" in the gNB and AMF where unauthenticated emergency sessions are not required.
• False base station detection. Annex E (informative) describes how networks can use phones' measurement reports to detect false base stations, for example from signal strength, location, inconsistent cell identifiers or frequencies.

What it does not cover

TS 33.501 describes the protocol. It does not tell a modem vendor how to write a safe ASN.1 decoder, require sanitizers or memory safe languages, define how modem firmware is signed or updated, set a support period, or specify how the modem is isolated from the application processor. A 5G phone also still carries 4G, 3G and often 2G stacks, and 5G non standalone (NSA) deployments run on a 4G core, where the SUCI procedure in TS 33.501 does not apply. Many of the messages that hit the modem first, including broadcast system information, are processed before authentication completes in every generation. The protocol can be perfectly specified and the implementation can still crash on a malformed field.

Comparison tables

Baseband isolation and controls by platform (from vendor documentation only)

2G, 3G, 4G and 5G by authentication and identifier protection

The radio HAL's own documentation supports the identity column: Android's identifier disclosure feature tracks when "IMSI, IMEI, or unciphered SUCI (in 5G SA) appears in one of the following UE-initiated NAS messages before a security context is established," across 2G, 3G, 4G and 5G.

Step by step: check baseband version, read the bulletin and disable 2G

These steps are read only checks and settings changes on a device you own or manage. Nothing here modifies firmware.

Step 1: find the baseband version and patch level on Android

On the phone:

1. Open Settings, tap About phone, then Android version. Google's help page says this screen shows the Android version, the Android security update, the Google Play system update and the build number.
2. On most devices the same screen shows Baseband version. The exact location varies by device maker.

From a computer with Android platform tools and USB debugging enabled on a test or personal device:

# Android security patch level (the SPL the bulletin refers to)
adb shell getprop ro.build.version.security_patch

# Baseband (radio firmware) version string reported by the vendor RIL
adb shell getprop gsm.version.baseband

# Device and build, for matching against the maker's bulletin
adb shell getprop ro.product.model
adb shell getprop ro.build.fingerprint

Apps can read the same baseband string through android.os.Build.getRadioVersion(), which AOSP documents as returning "the version string for the radio firmware" and which "May return null (if, for instance, the radio is not currently on)."

Step 2: find the modem and carrier versions on iPhone

1. Open Settings, tap General, then About.
2. Find the Modem Firmware entry. Note it with the iOS version.
3. Find the carrier settings version, which Apple says appears "next to Carrier." Tap it for more detail.

The iOS version is the authoritative patch indicator.

Step 3: read the bulletins for modem entries

Start with the Android Security Bulletin for the month, then your device maker's bulletin. A quick way to see whether a month carries modem entries:

# Count Modem subcomponent entries in the September 2026 bulletins
curl -s https://source.android.com/docs/security/bulletin/2026/2026-09-01 \
  | grep -o '>[[:space:]]*Modem[[:space:]]*<' | wc -l

curl -s https://source.android.com/docs/security/bulletin/pixel/2026/2026-09-01 \
  | grep -o '>[[:space:]]*Modem[[:space:]]*<' | wc -l

Then read the matching sections. For each modem entry, note the severity, the supplier section and whether your devices use that supplier's modem. Compare with your devices' SPL: modem fixes in the Android bulletin are in the -05 level, so a device at YYYY-MM-01 does not have them. For anything outside the Android bulletin, check the maker's bulletin and its own patch notes.

Step 4: disable 2G on Android

On a personal device running Android 12 or later with a supporting modem, open the SIM's settings under Network and internet and turn off Allow 2G. Menu names vary by device maker. Emergency calls still work over 2G.

For managed fleets, set the user restriction from your device policy controller. The restriction can only be set by a device owner or the profile owner of an organisation owned managed profile, and it applies to the whole device:

// In a device owner (or org-owned profile owner) DPC on Android 14+
val dpm = context.getSystemService(DevicePolicyManager::class.java)
val admin = ComponentName(context, MyDeviceAdminReceiver::class.java)
dpm.addUserRestriction(admin, UserManager.DISALLOW_CELLULAR_2G)

Most organisations set this through their device management console. Check coverage first: the UserManager documentation warns that a device will lose connectivity "if the device is in an area where only 2g networks are available."

Step 5: on iPhone, decide on Lockdown Mode

iPhone has no separate 2G switch in Apple's documentation. If your threat model calls for it, Lockdown Mode turns off 2G and 3G support. Apple's steps are: Settings, Privacy and Security, scroll down to Lockdown Mode, Turn On Lockdown Mode, then Turn On and Restart and enter the passcode. It also changes how Messages, Safari, FaceTime and other features behave, so try it before you require it.

Common mistakes

• Assuming airplane mode removes all radio code paths. Airplane mode is a state the OS asks the modem to enter. The modem firmware is still loaded and is the same code that will parse radio traffic as soon as cellular service returns, and users can re-enable Wi-Fi or Bluetooth while airplane mode is on. What each radio does in airplane mode is device specific, and even "off" can be nuanced, as our post on whether an iPhone is really off explains.
• Reading the SPL as "fully patched". A device at the -01 level does not have the vendor and chipset fixes that sit in -05. And device maker bulletin fixes are "not required for declaring a security patch level," so even -05 is not the whole picture.
• Ignoring modem firmware in end of support planning. When a phone leaves its update window, its modem stops getting fixes too. For each model in a fleet, record the modem supplier, SPL, baseband version and the maker's end of support date.
• Confusing carrier settings with modem firmware. A carrier settings update on iPhone, or a carrier configuration change on Android, adjusts network behaviour. It is not a baseband firmware update.
• Assuming 5G means 5G protections. SUCI only protects you when the operator provisioned a public key, it does not apply on 5G NSA with a 4G core, and the phone still carries older stacks for fallback.
• Turning off 2G without checking coverage. In areas with only 2G service the phone will lose service, except for emergency calls. Test before enforcing.
• Relying on the cellular link for confidentiality. Google says Android "does not rely on link-layer encryption" and expects network traffic to be end to end encrypted. Use end to end encrypted apps rather than trusting the radio link.

FAQ

What is baseband firmware on a phone?

It is the operating system and protocol software that runs on the phone's modem. It handles 2G to 5G radio signalling, calls, SMS and mobile data, and passes results to Android or iOS through a defined interface.

Can a baseband be hacked over the air?

Google states that baseband remote code execution has been demonstrated and exploited, and treats it as Critical in its rewards program. The risk is real, which is why vendors add sanitizers, CFI and other mitigations and why monthly bulletins regularly list modem fixes. Keeping the phone updated is the main defense for users.

How do I update my phone's modem firmware?

Install your phone's normal OS updates. On iPhone the baseband ships inside the iOS update. On Android it ships inside the device maker's update. There is no separate, safe consumer channel for modem firmware.

How do I check my baseband version on Android?

Go to Settings, About phone, Android version, and look for Baseband version on most devices. With USB debugging enabled you can run adb shell getprop gsm.version.baseband.

Should I turn off 2G on my Android phone?

If you live where 4G or 5G coverage is good, turning off 2G removes a legacy stack with no mutual authentication. Emergency calls still work. If you travel to areas with only 2G service, you will lose normal service there until you turn it back on.

Does iPhone let me disable 2G?

Apple documents one way: Lockdown Mode, which turns off 2G and 3G and restricts other features too.

Does 5G fix IMSI catchers?

5G standalone conceals the permanent identifier as SUCI and uses mutual authentication, which defeats the simplest identity requests. It depends on operator provisioning, does not apply on NSA deployments with a 4G core, and does not stop downgrade to older generations on its own. That is why Android added 2G and null cipher controls.

Do security patches cover the modem?

On Android, modem fixes from chipset suppliers are usually in the -05 security patch level and in device maker bulletins. On iPhone, they arrive with iOS updates. A device that no longer receives OS updates no longer receives modem fixes.

Where Safeguard fits

Safeguard does not analyse modem firmware, scan phones, manage devices or check what runs on a baseband. The fit here is indirect, and it is about the software around the phone. Teams that build mobile apps, telephony backends, device management tooling or firmware build pipelines ship open source dependencies, and Safeguard can scan those repositories and container images for known vulnerable components, record an SBOM and apply policies and gates in CI. It does not replace the phone maker's update, which is the only route for a baseband fix.

Fix it without waiting for upstream

Baseband fixes come only from the phone maker, but the software that runs around your phones does not. The mobile app you ship, the backend it talks to and the tooling that builds firmware all pull open source dependencies, and those you can fix on your own schedule.

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 each command on the phone with Allow once, Allow for turn or Deny. For a mobile team, that means a dependency fix in the app repository can be reviewed and approved from the same phone you just checked for its baseband version.

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

The second demo is a Safeguard CLI session in a repository: it reads a vulnerability finding and the advisory, asks before each command, edits the dependency, runs the install and tests with your approval and pushes nothing. The same flow applies to an Android app's build files or a telephony backend.

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 a device code and scans from the terminal. Firmware and device tooling repositories often live on build hosts kept off shared CI, and a local runner scans them where they already are.

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

Download the apps at https://safeguard.sh/download and read the CLI documentation at https://docs.safeguard.sh/docs/cli .

Quick check

Sources

• Google Online Security Blog: Hardening cellular basebands in Android (12 December 2023)
• Google Online Security Blog: Pixel's Proactive Approach to Security: Addressing Vulnerabilities in Cellular Modems (3 October 2024)
• Google Online Security Blog: Android 14 introduces first-of-its-kind cellular connectivity security features (8 August 2023)
• Google Online Security Blog: I/O 2024: What's new in Android security and privacy (15 May 2024)
• AOSP: Connectivity
• AOSP: RIL refactoring
• AOSP: Implement IMS
• AOSP: Carrier configuration
• AOSP source: AIDL radio HAL, hardware/interfaces/radio/aidl
• AOSP source: IRadioNetwork.aidl
• AOSP source: IRadioModem.aidl
• Android Security Bulletins
• Android Security Bulletin, September 2026
• Android Security Bulletin, October 2026
• Pixel Update Bulletins
• Pixel Update Bulletin, September 2026
• Pixel Update Bulletin, October 2026
• Android Developers: UserManager (DISALLOW_CELLULAR_2G)
• Android Developers: TelephonyManager
• Android Developers: Build (getRadioVersion)
• Android Help: Check and update your Android version
• Apple Platform Security guide (web)
• Apple Platform Security guide, August 2026 (PDF)
• Apple Support: About Lockdown Mode
• Apple Support: Manually update carrier settings on your iPhone or iPad
• 3GPP: TS 33.501 specification page
• ETSI TS 133 501 V19.7.0 (2026-08), 3GPP TS 33.501 Release 19 (PDF)
• 3GPP: TS 33.401 specification page
• 3GPP: TS 33.102 specification page

Last reviewed: 24 October 2026. Modem fixes appear every month and platform controls depend on each device's modem and radio HAL; check the current bulletins and your device maker's documentation for the devices you run.