Technology explainer
How Can a SIM Card Send Commands to a Phone?
A SIM is a secure computer that uses standardized proactive commands to request limited actions from the modem. The feature becomes dangerous when firmware forwards SIM-controlled input into privileged AT commands without strict validation and authorization.
Short answer: a SIM is a small secure computer, not passive memory. Through standardized proactive-SIM and SIM Toolkit mechanisms, it can ask the phone's modem to perform actions such as displaying text, opening a channel, sending a message, or updating files. These capabilities support legitimate carrier services, but unsafe modem interfaces can let a compromised or hostile SIM reach commands that should remain restricted.
What a SIM actually contains
A physical SIM or its eSIM equivalent stores a subscriber identity, authentication secrets, network preferences, files, and executable applets. It has a processor, memory, an operating environment, and a command protocol. The phone supplies power and communicates with it through electrical or embedded interfaces.
The SIM authenticates the subscriber to the mobile network without normally revealing its long-term secret key. It can also host carrier applications and update selected data over the air.
The phone is split into security domains
Modern phones contain an application processor that runs iOS, Android, or another operating system, and a baseband processor or modem that handles radio protocols and SIM communication. The modem is highly privileged because it controls cellular connectivity and sometimes exposes diagnostic or control interfaces.
Separating domains limits damage, but boundaries vary by device. Commands may pass from the SIM to the modem, from the modem to system services, and occasionally toward the application processor. Every bridge needs strict validation and authorization.
How the normal conversation works
- The phone resets and selects the SIM. It exchanges low-level application protocol data units (APDUs).
- The phone reads files and requests authentication. The SIM computes a response using protected keys.
- The network and handset establish service. The modem registers using the authenticated identity and negotiated security.
- Toolkit applets can request actions. A proactive command tells the terminal that the SIM has an instruction waiting.
- The terminal checks capability and policy. It performs, modifies, prompts for consent, or rejects the request and returns a result.
What legitimate proactive commands can do
| Capability | Legitimate use | Security concern |
|---|---|---|
| Display text or menu | Carrier account and service menus | Misleading prompts or social engineering |
| Send SMS or USSD | Provisioning, balance, and service activation | Unauthorized messages or hidden signaling if consent checks fail |
| Open a data channel | Managed service communication | Network access from a trusted hardware position |
| Launch a browser or URI | Direct users to carrier support | Phishing or unsafe scheme handling |
| Provide local information | Adapt service to network or location context | Privacy exposure if access is too broad |
| Refresh SIM state | Apply updated files and network settings | Connectivity disruption or unexpected modem behavior |
Standards define user-notification and permission behavior for sensitive actions. Security failures often appear when an implementation skips checks, accepts a malformed command, or exposes a vendor-specific path not intended for the SIM.
Where AT commands enter the picture
AT commands began as text commands for controlling modems and remain common for configuration, diagnostics, calls, messaging, radio state, and vendor-specific functions. They are usually intended for trusted host software or technicians, not arbitrary SIM applets.
If a modem firmware component incorrectly translates SIM-controlled input into AT commands, or exposes a command-forwarding feature without an allowlist, the SIM can cross a trust boundary. Impact ranges from changing network settings and dropping connectivity to reading data or exploiting memory-safety flaws, depending on the command and device.
How a malicious SIM could be introduced
- A user inserts a physical card supplied or modified by an attacker.
- An attacker compromises a SIM supply or personalization process.
- A vulnerable over-the-air SIM applet is remotely instructed by someone who possesses the required carrier keys or exploits a flaw.
- An eSIM profile from an untrusted source is installed through a compromised provisioning chain.
- A researcher uses a programmable test card to audit the modem.
These paths have different feasibility. Discovering a bug with a programmable SIM does not mean an attacker can remotely compromise every ordinary subscriber card.
Physical SIM versus eSIM
An eSIM replaces the removable card with an embedded secure element that downloads managed profiles. The profile still performs SIM functions, so many logical trust issues are similar. The main differences concern provisioning, profile lifecycle, remote management, and the difficulty of physically swapping the component.
eSIM remote provisioning uses authenticated management infrastructure. An eSIM is not inherently immune to hostile profiles or implementation bugs, but attackers cannot simply mail or insert a modified plastic card into a sealed device.
A 26-device security study
Researchers tested 26 phones and cellular IoT modules with a hostile programmable SIM and found that nine accepted modem commands from it. Demonstrated effects ranged from lost connectivity to code execution in affected environments. Vendors patched or hardened several systems. Read Nine of 26 Tested Devices Took Commands From Their SIM Cards.
The finding established vulnerable implementations, not a universal SIM backdoor. Exploitation generally required control of the inserted SIM or eSIM profile, and impact differed by modem, firmware, interface exposure, and mitigations.
Why cellular IoT devices may be exposed
IoT modules often expose AT-command interfaces to a host microcontroller and may remain deployed for years with limited update paths. Manufacturers integrate a modem, SIM, firmware, cloud service, and application from different vendors, which makes ownership of the trust boundary unclear.
A small module can also lack the isolation and exploit mitigations of a flagship phone. Conversely, a narrowly configured IoT system may expose fewer high-level services. Security must be assessed per architecture rather than inferred from device category.
How vendors defend the boundary
- Allow only standardized SIM commands required for the product
- Block generic or vendor AT-command forwarding from SIM-controlled input
- Validate length, encoding, state, and sequence of every message
- Require explicit user consent for sensitive proactive actions
- Sandbox SIM Toolkit handlers and minimize privileges
- Use memory-safe components or exploit mitigations in modem firmware
- Authenticate eSIM provisioning and over-the-air updates
- Log abnormal commands, provide firmware updates, and support long-lived IoT deployments
What users and operators can do
Users should obtain SIMs and eSIM profiles from trusted operators, avoid unknown physical cards, keep phone and modem firmware updated, and treat unexpected carrier menus or connectivity changes cautiously. Enterprises should control profile enrollment, inventory modem versions, restrict diagnostic interfaces, and include cellular modules in vulnerability and patch management.
Replacing a SIM after a suspicious event can remove the hostile card, but it does not repair modem firmware already compromised. High-risk investigations may require device reimaging, firmware verification, credential rotation, and carrier coordination.
The mental model
Think of the SIM as a trusted tenant with a standardized service window into the modem. It needs that window to authenticate and provide carrier features. Security depends on the window exposing a narrow menu of validated requests rather than becoming a tunnel into the modem's administrator console.
First appeared in
Nine of 26 Tested Devices Took Commands From Their SIM Cards
