RCS is not automatically safer than SMS

RCS is not automatically safer than SMS

Rich Communication Services have been the SMS-replacement-in-waiting for more than a decade. The promise got concrete in 2024 when Apple shipped RCS Universal Profile support in iOS, closing the long-running coverage gap that had kept RCS from becoming the default messaging protocol on consumer handsets worldwide. The marketing narrative that followed was predictable: RCS is more secure, RCS supports end-to-end encryption, RCS carries verified sender identity, and therefore RCS is the safe channel for the messages SMS could not carry safely.

Each of those claims has a specific, narrow truth behind it. None of them add up to the broader claim that RCS is automatically safer than SMS. The peer-reviewed research on RCS security shows that the protocol has documented weaknesses, that the rich content making RCS commercially interesting also expands the fraud surface in ways SMS does not, and that industry-scale spam-and-fraud filtering for RCS remains an active research problem.

This post compares the two protocols on their actual attack surfaces rather than on the claim summaries.

What RCS actually fixes

RCS does genuinely improve on SMS in specific dimensions. Message transport is over IP rather than circuit-switched signalling, which removes a class of SS7-layer interception vulnerabilities that affect SMS OTP delivery. Rich media, read receipts, typing indicators, and long-form content are capabilities SMS does not provide. Verified Business Messaging (RBM) attaches a registered brand identity to messages sent by participating businesses, which reduces one class of sender-ID impersonation in the brands that register and the markets that enforce the registration.

These are real improvements. They matter for the specific use cases they address, and a careful RCS product page can describe them accurately. The failure mode in most marketing is over-generalising from these specific improvements to a blanket safety claim.

What the research actually says

Zhao and colleagues published the first in-depth security study of RCS in 2022, empirically validated against four major US mobile carriers. The paper documents a cellular-identity binding weakness: RCS binds the user's service session to their cellular identity more loosely than the protocol's security model implies, and the looseness creates an attack path where an adversary can hijack a victim's RCS service. The attack survives end-to-end encryption where it is enabled, because the weakness is in the pre-encryption binding rather than in the encrypted payload itself.

The empirical validation is what turns this from a theoretical concern into a deployment issue. The paper's attacks worked on production deployments at four of the largest North American carriers. The defences the paper proposes were not, at publication time, deployed at the protocol level. They require changes to the RCS binding mechanism that operators and the RCS standardisation bodies control. Some of those changes have rolled in since 2022. Not all have.

The 2012 Cook paper in Computer Fraud & Security anticipated a related concern over a decade earlier. RCS was designed with SMS-gateway interoperability, so an attacker targeting the RCS-to-SMS gateway has a vector that does not exist in pure-SMS or pure-RCS environments. One-to-many delivery at scale, which RCS supports natively and SMS does not, creates a spam amplification primitive that the author flagged explicitly in 2012 as an opportunity for attackers who adapt to RCS before defenders do. The warning aged well.

The ML-based RCS content-filtering research is more hopeful. HMM and CNN classifiers on real industrial RCS traffic show that the text-field structure RCS exposes (as opposed to SMS, where payload is an opaque 160-character blob) enables richer feature extraction and more accurate spam detection. The optimistic reading is that better content filtering is possible in RCS than in SMS. The matching observation is that better content filtering is needed in RCS than in SMS, because the underlying abuse surface is larger.

The fraud surface the rich-content features create

Every feature that makes RCS more useful than SMS also adds something an attacker can exploit.

Links: RCS lets a brand send clickable URLs inline with the message. SMS has URLs, but there is no brand identity attached, so users treat SMS URLs with appropriate scepticism. RCS URLs come with a verified-brand badge in the cases where the sender has registered through RBM. An attacker who compromises or spoofs the brand binding can send URLs that inherit the user's trust in the verified sender. The verified badge becomes a phishing amplifier rather than a trust anchor.

Buttons and interactive UI: RCS messages can include buttons that launch application flows, open URLs, or initiate calls. An attacker who gets a message into a user's RCS inbox with plausible brand styling has a pre-built social-engineering interface in the user's most-trusted messaging channel. The friction between receiving a scam and acting on it is lower in RCS than in SMS.

Carousels, cards, and rich media: the visual fidelity of RCS allows attackers to build messages that look like legitimate transactional content from a known brand. SMS attackers have to rely on plain text. RCS attackers can render pixel-perfect clones of a brand's legitimate message template.

Verified business profile spoofing: the RBM registration model intends to prevent this by cryptographically binding a sender identity to a registered brand. The weakness documented in the Zhao paper breaks that binding under specific attack conditions, and the commercial pressure on brands to deploy RCS quickly in markets with immature RBM enforcement means that a meaningful share of RCS traffic is sent with less-than-complete brand verification. The gap is the attacker's opportunity.

What "end-to-end encryption" means in practice

The most frequently misunderstood claim is that RCS's support for end-to-end encryption makes the protocol safer by default. The claim is narrowly true and broadly misleading.

Where Google Messages and the RCS implementations that follow its client pattern apply end-to-end encryption, the payload of a conversation between two endpoints is cryptographically protected from operators and intermediaries. This is a real property and a real improvement over SMS. Businesses sending A2P RCS to consumers, however, operate under a different model, since the business-side endpoint is the RCS Business Platform rather than a specific handset. The encryption properties that apply to person-to-person RCS do not transfer uniformly to the business messaging that most enterprise integrators care about.

The Zhao paper's finding about cellular-identity binding is orthogonal to encryption. The attack does not require breaking encryption. It operates on the identity binding that precedes the encryption envelope. A message that is encrypted end-to-end can still be delivered to an attacker who successfully hijacked the service binding, because the hijack redirects the delivery path before the encryption layer applies. "End-to-end encrypted" does not mean "safe from the attack class documented in the literature."

Comparing the two protocols by attack family

SMS OTP interception over SS7 or Diameter: SMS is vulnerable. RCS is not, because the RCS transport bypasses the SS7 layer. RCS wins this comparison for users whose home operator's signalling firewall posture is weak.

SMS OTP interception via endpoint malware with READ_SMS: SMS is vulnerable. RCS messages do not flow through the SMS database, so the same malware class does not capture them. RCS wins this comparison for users with compromised Android endpoints.

Sender-ID spoofing in unregistered markets: SMS is vulnerable. RCS is partially vulnerable, because RBM registration addresses the legitimate-brand side but does not prevent attackers from using RCS-over-SMS gateways to exploit the bridge. RCS wins partially.

Service hijacking via cellular-ID binding weakness: this attack class does not exist on SMS. RCS is vulnerable per the Zhao paper. SMS wins this comparison in the specific sense that the attack class does not exist on it.

Rich-content phishing (buttons, carousels, verified-brand spoofing): the primitives do not exist in SMS, so SMS is not vulnerable. RCS is vulnerable because the primitives exist. SMS wins this comparison.

Spam and abuse at scale: both protocols are vulnerable. RCS has the richer filter-feature set and the richer abuse surface. The net is open and depends on whether the filtering keeps pace with the abuse.

No channel strictly dominates. Each has specific attack surfaces the other does not. The marketing claim "RCS is safer than SMS" reduces this landscape to a single bit and loses the information that matters for a deployment decision.

How Tensormobile ships RCS

Tensormobile ships RCS as a TensorConnect channel with an explicit disclosure that RCS is a different security model rather than a strictly safer one. For markets and use cases where the SMS attack surfaces (SS7 interception, READ_SMS malware, weak sender-ID regimes) are the dominant concern, RCS can be the preferred channel. For markets and use cases where the RCS-specific surfaces (service hijacking via cellular-ID binding, rich-content phishing, RBM spoofing in immature enforcement regimes) are the dominant concern, SMS is sometimes the safer fallback.

Tensormobile's product documentation calls out the Zhao 2022 paper and the RCS-to-SMS gateway concerns from Cook 2012 because these are the primary research anchors a serious integrator should be aware of when evaluating RCS deployments.

The operator-side mitigations applied to TensorConnect RCS traffic are specific and auditable. Route integrity at the RCS gateway ensures that the RBM traffic delivered originated from a registered sender, with sender verification at each hop, which reduces the gateway-exploitation class of attack described by Cook. Network-layer binding checks use the cellular-session and registration-state data Tensormobile holds as the home operator, which partially addresses the binding-weakness class of attack described by Zhao. Anti-spam ML filtering on message content uses the feature set the RCS protocol exposes. These mitigations narrow the attack surface but do not eliminate it.

The claim Tensormobile makes on the product page is specific: TensorConnect RCS addresses the attack surfaces documented in Zhao 2022 and Cook 2012 through named operator-side mitigations. The blanket "RCS is safer than SMS" framing is not a claim the research supports, and the product page does not use it. Whether RCS is the right channel for a given deployment depends on which attack surfaces dominate, what the local regulatory regime enforces, and which mitigations the vendor actually applies. The product documentation explains those dependencies.