As reported by The Hacker News, researchers from the University of Birmingham and security firm Fuzzware have uncovered a deeply concerning attack surface: a malicious or compromised SIM card can issue commands that execute arbitrary code within the modem firmware of cellular IoT modules. When those modules sit inside critical infrastructure like EV charging stations, industrial routers, or automotive telematics units, the consequences extend far beyond data theft.

Threat Alert: As reported by The Hacker News, researchers from the University of Birmingham and security firm Fuzzware have uncovered a deeply concerning attack surface: a malicious or compromised SIM card can issue commands that execute arbitrary code within the modem firmware of cellular IoT modules.

Why This Research Changes the IoT Threat Model

The cellular modem has long been treated as a trusted hardware boundary — a commodity component that simply ferries data between device and network. This research shatters that assumption. The SIM-to-modem communication channel, governed by standards like SIM Application Toolkit (STK) and ETSI TS 102.223, was designed decades ago when the threat landscape looked nothing like it does today. Commands issued over this channel are processed at a privileged layer of the modem firmware that sits below the application operating system — meaning endpoint detection tools, device management agents, and even the host OS are essentially blind to what's happening.

This isn't a theoretical edge case. The attack surface is the SIM card itself — a component that operators, enterprises, and device manufacturers implicitly trust because it's provisioned by telecoms. But SIM supply chains are complex. eSIM provisioning platforms, SIM vendors, and mobile virtual network operators (MVNOs) all represent potential injection points for a motivated attacker or nation-state actor.

Who Is Actually Exposed

The affected ecosystem is broader than headlines suggest. Consider the following deployment categories:

Who Is Actually Exposed
EV Charging Infrastructure: Public and commercial chargers using cellular backhaul for billing, monitoring, and firmware updates. Compromise here could enable billing fraud, denial of service, or manipulation of charging session data at scale.
Industrial IoT Routers: Devices bridging OT and IT networks in manufacturing, utilities, and logistics. Modem-level compromise could provide persistent network access that bypasses traditional segmentation controls.
Vehicle Telematics: Fleet management units and connected-vehicle modules that report location, diagnostics, and in some cases interact with vehicle CAN bus systems. A hijacked telematics module is a foothold into the vehicle itself.
Medical and Smart Grid Devices: Any cellular-connected device using commodity modules from the tested vendors faces analogous risk — the modem firmware vulnerability class is architectural, not device-specific.

The Supply Chain Dimension

What makes this particularly difficult to defend against is that the attack vector is the SIM card — something device owners rarely control end-to-end. In enterprise IoT deployments, SIMs are procured from carriers, activated through provisioning platforms, and sometimes managed by third-party IoT connectivity providers. Each of those handoffs is a potential compromise point. A rogue insider at a SIM vendor, a compromised eSIM provisioning server, or a man-in-the-middle during remote SIM provisioning (RSP) could all result in malicious STK applications landing on devices in the field.

The modem has effectively become the new BIOS — a privileged execution environment that the rest of the stack trusts unconditionally. Attackers who can write to it win the device.

Detection Is the Core Challenge

Unlike traditional firmware attacks, there is no straightforward hook for defenders. Host-based security tools cannot observe SIM Application Toolkit command execution. Network traffic anomaly detection may catch behavioral changes post-compromise, but by that point the attacker already has a foothold. Cellular network operators could theoretically filter or audit STK traffic at the core network level, but this capability is not uniformly deployed and varies significantly by carrier and region.

Shield53 Recommendations

For IoT Device Manufacturers and Integrators

  • Audit your cellular module selection: Demand explicit documentation from module vendors on which SIM Toolkit command classes are enabled in firmware and whether they can be disabled or restricted at the modem configuration level.
  • Enforce SIM allowlisting: Where supported by your module, configure IMSI or SIM vendor restrictions so the device will not authenticate or accept commands from unapproved SIM cards.
  • Review modem firmware update processes: Ensure that modem firmware (separate from application firmware) is included in your vulnerability management and update cadence. Many OEMs treat it as a black box.
  • Implement network behavioral baselines: Deploy traffic monitoring at the cellular gateway or APN level to detect anomalous outbound connections from fleet devices — a post-compromise indicator that something in the modem layer has changed behavior.

For Fleet Operators and Critical Infrastructure Owners

  • Treat SIM procurement as a supply chain risk: Vet SIM and eSIM vendors with the same rigor you apply to software suppliers. Ask about their security practices, provisioning platform access controls, and insider threat programs.
  • Segment cellular IoT devices aggressively: Devices that use cellular backhaul should be on isolated APNs or VPNs with strict egress filtering. Assume the modem layer can be compromised and design your network accordingly.
  • Engage your mobile operator: Ask your carrier or MVNO whether they have visibility into STK application traffic and whether anomalous STK command patterns can trigger alerts.

For Security Researchers and Red Teams

  • This research opens a meaningful new category for hardware security assessments. Cellular IoT penetration tests should now explicitly include SIM Toolkit command injection as a test case against target modem models.
  • Coordinate with vendors before publication — but push hard for firmware-level mitigations, not just advisories. The architecture needs to change, not just the documentation.

The broader implication here is that critical infrastructure security cannot stop at the application layer, the OS, or even the hardware enclosure. As this research demonstrates, the SIM — a component so mundane it's rarely discussed in threat models — can be the entry point for full device compromise. The industry needs to catch up fast, because adversaries absolutely will not wait.