SMS_RECEIVED is an Android broadcast intent sent when an incoming SMS message is received by the device. Apps can register for it to process text messages, but access is tightly controlled on modern Android because SMS contents may carry sensitive authentication or recovery data.
What SMS_RECEIVED Means on Android
SMS_RECEIVED is a broadcast intent, so it represents an event rather than a permission or a data store. When Android delivers that event, any app that has been allowed to observe it can react to an incoming text message, but modern platform restrictions sharply limit who can do so because the message body may contain codes, recovery links, or other sensitive content.
That design matters because broadcast delivery creates a security boundary as much as a programming convenience. If the wrong app can observe the intent, it may gain visibility into high-value messages without needing to compromise the messaging app itself.
How Android Uses the SMS_RECEIVED Broadcast
On Android, broadcast intents are the platform’s way of announcing that something happened. SMS_RECEIVED is triggered when the device gets a new text message, which lets an app parse message content, trigger automation, or support message-based workflows such as verification flows and inbox organization.
Because the event is system-generated, the main security question is not whether the broadcast exists, but which apps are permitted to register for it. That control is intentionally narrow on current Android versions, especially where SMS handling could expose one-time passwords, account recovery codes, or business-sensitive notifications.
Why Access to SMS_RECEIVED Is Restricted
Android treats incoming SMS as sensitive because the contents often function as authentication material. A message may contain a one-time code, a password reset link, or a recovery token, so the broadcast is closely guarded to reduce accidental disclosure to unrelated apps.
For developers, this means SMS_RECEIVED is best understood as a privileged integration point, not a general event bus. Apps that depend on it must satisfy platform policy, user expectations, and the principle of minimal access to message content.
Common Uses and Security Implications
Legitimate uses usually fall into narrowly defined categories, such as SMS-based verification, transaction alerts, or message parsing for user-facing features. Even then, the application should only process the content it truly needs and avoid retaining the full message longer than necessary.
Security implications follow directly from the message’s sensitivity. A design that reads SMS_RECEIVED should assume the payload may reveal identity confirmation codes, password resets, or other recovery paths, and should avoid turning that signal into a broader collection or forwarding channel.
Risk and Threat Considerations
SMS_RECEIVED is attractive to attackers because SMS often carries authentication and recovery data. If an app, plugin, or misconfigured privilege path can observe the broadcast, the attacker may capture codes or recovery links without breaking the user’s primary account directly.
Failure mechanism: The device delivers a sensitive SMS to an app that has broader visibility than intended, or malware abuses an allowed SMS-reading capability to intercept the contents before the user acts on them.
Impact: Stolen codes or recovery messages can enable account takeover, session hijacking, or unauthorized password resets, especially where SMS is still used as a fallback factor.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SMS_RECEIVED can carry one-time codes and recovery data used as authenticators. |
| IA-2 — Identification and Authentication (Organizational Users) | SMS messages may support user authentication flows that depend on controlled access to codes. | |
| AC-6 — Least Privilege | Apps should receive only the SMS visibility needed for a specific function. | |
| Recommendation — Limit SMS-based authenticators to necessary workflows and protect their lifecycle as sensitive credentials. Restrict who can observe SMS-derived authentication events and reduce reliance on SMS where possible. Grant SMS-reading capability only to the smallest set of approved app functions. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | Restricting SMS observation is an access-management decision tied to sensitive authentication data. |
| Recommendation — Apply access governance so only approved functions can read SMS-triggered authentication data. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | SMS_RECEIVED often supports authentication flows that can be abused if intercepted. |
| Recommendation — Treat SMS-based verification as a weak authentication path and harden or replace it where feasible. | ||
Practitioner Guidance
Why practitioners should care: Treat SMS_RECEIVED as a high-sensitivity integration point whenever an application depends on it. The design choice can affect both user trust and account security because the broadcast may expose credentials, verification codes, or recovery data.
Governance implication: Keep SMS access narrowly scoped, review which product workflows truly require it, and prefer alternatives when the use case does not justify message visibility. Where SMS is unavoidable, minimize retention and avoid secondary processing that expands the exposure of message content.
Practitioner takeaway: If an app only needs to know that a message arrived, it should not collect or persist more of the SMS than that purpose requires.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org