Intel · 2026-06-08

RCS Business Messaging as an Identity Channel: Verified Sender Telemetry Beyond A2P SMS

By J. W. Bouckaert

Every identity team has spent the last decade treating SMS as if it were a neutral pipe. It was never neutral. It was a 1980s signaling protocol carrying authentication codes it was never designed to carry, with sender-attestation primitives bolted on by industry registrars a generation late. The U.S. response, A2P 10DLC, patched the worst abuses by forcing brand and campaign registration through The Campaign Registry. It did not, and structurally could not, give the receiving device a way to verify that the message it just rendered actually came from the brand on the From line.

RCS Business Messaging is the first messaging channel at scale where that question has a real answer.

This is an account of what changed in 2024 and 2025, what the verified-sender telemetry actually attests to, what it does not, and how an identity stack should consume RCS signals alongside the SIM-bound carrier evidence it already trusts.

The 2024-2025 shift that made RCS an identity channel

Three things had to be true at the same time before RCS could be treated as identity-grade telemetry: the protocol had to be standardized across carriers, the dominant handset platforms had to ship it, and the business-messaging surface had to expose verifiable sender state.

The first was settled by GSMA's Universal Profile work. Universal Profile 2.4, the baseline most operators ship today, was the convergence point. The second flipped in September 2024 when Apple released iOS 18 with RCS support based on Universal Profile 2.4. The third has been in production since Google launched RCS Business Messaging on its Jibe platform, which sits behind every major North American operator's RCS deployment for Android.

The cross-platform E2EE story closed in March 2025, when GSMA published Universal Profile 3.0, standardizing end-to-end encryption based on the IETF Messaging Layer Security (RFC 9420) protocol for RCS across platforms. Apple has publicly committed to implementing it; rollout timing is operator- and version-dependent.

Sources: GSMA UP 3.0 specifications, Apple iOS 18 launch announcement, Google RBM developer docs.

The composite effect is that for the first time, a business sending a transactional message to a U.S. consumer can plausibly assume the recipient handset has a cryptographic channel to a sender-attestation registry the recipient device trusts. SMS never had that property. A2P 10DLC never had that property. RCS does.

The verified-sender attestation

The visible artifact most users see is a small verified-sender badge in the conversation header: a brand logo, a brand name, and on Google Messages a green checkmark. It is tempting to read that badge as message-integrity. It is not.

The verified-sender state attests, narrowly, to three things:

1. Onboarding. The sending agent was onboarded through a Google-approved RBM partner and the brand passed Google's identity verification process. The same model exists in carrier-mediated RBM deployments for Apple devices, where the carrier MaaP (Messaging as a Platform) takes the registrar role.
2. Authenticated transport. The message reached the recipient device through the RBM infrastructure rather than through an SMPP gateway dressed up to look like the sender.
3. Brand binding. The brand logo, color, and display name on the conversation are the ones registered against this sender ID. The recipient is not looking at a spoofed display name.

What it does not attest to:

• Message content. The verified-sender badge does not change as a function of message body. A compromised internal system at the sender can dispatch a phishing payload through an authentic agent and the badge will still render.
• Embedded link integrity. Click-tracking redirects, shortlinks, and dynamic deeplinks pass through unchanged.
• Recipient device integrity. The badge attests the sender and says nothing about the recipient device.
• Human-in-the-loop intent. An agentic system with stolen API credentials produces the same verified-sender state as a human-triggered campaign.

This is the same boundary we draw for every other carrier-adjacent signal: a strong attestation about a narrow property, consumed as one weight in a composite trust decision, never as a single-signal trust override. The same principle applies to SIM-Swap freshness and to Number Verify: treat the primitive for exactly what it asserts.

Capability negotiation as passive device telemetry

The most underused identity signal in RCS is the capability discovery exchange, ahead of the verified-sender badge.

Per the GSMA RCS Universal Profile service definition, RCS clients exchange capability information on a per-MSISDN basis. The discovery payload includes whether the recipient device supports RCS at all, which Universal Profile version, which media types are supported, which interactive features (suggested replies, rich cards, calendar attachments) are available, and whether the user has provisioned the service on their current device.

For an identity pipeline, that exchange is a passive integrity check that runs every time a verified business agent attempts a send. The telemetry that matters:

None of those signals, on their own, justify a fraud decision. A user upgrades their phone. A user travels. A user enrolls a secondary device. False positives are a real risk and we treat them seriously. The value of the signal is its freshness profile: when capability state drifts inside the lifetime of a single user session, that drift is information that did not exist in the A2P SMS channel at all.

For the architectural pattern we use to weight this kind of low-individual-strength, high-aggregate-freshness signal, see Carrier Signal Freshness: TTL Matters More Than Strength and Carrier Signal Chaining: Correlating Multi-IMSI Events.

Encryption posture as an identity signal

End-to-end encryption is usually framed as a privacy property. In an identity context it is also a posture signal.

Google Messages has implemented end-to-end encryption for person-to-person RCS chats since the 2020-2021 rollout, using the Signal protocol. Universal Profile 3.0, published March 2025, standardizes Messaging Layer Security (RFC 9420) for cross-platform E2EE. RBM messages have a less uniform encryption story: brand-to-consumer messaging requires the sender to retain message content for compliance and analytics, and the public-facing E2EE story is still operator- and partner-dependent.

For an identity pipeline, what matters is whether the recipient device is currently capable of MLS-based E2EE on this MSISDN. That single bit, observed over time, is a useful posture signal. A handset that has been stable on UP 3.0 with MLS for months and suddenly downgrades to UP 2.4 without MLS, mid-session, is a posture change worth scoring.

This is the same idea we apply at the TLS layer for encrypted-tunnel telemetry: the cipher suite, key-exchange selection, and protocol version are not just security properties, they are stable enough across a user's lifetime that drift is informative.

RBM vs A2P SMS / 10DLC: A direct comparison

The structural differences between the channels are not subtle.

RCS does not replace SMS. The right summary is that RCS produces a class of receiver-visible attestation that A2P SMS never could. For workflows that benefit, the architecture is to send via RBM where available, fall back to SMS where not, and persist the channel-of-delivery as part of the signal record so the verifier knows which class of telemetry was actually available.

A reference architecture for RBM as an identity signal

The pattern we recommend for consuming RBM telemetry inside an identity decision is the same fusion pattern we apply to every carrier-adjacent signal, with RBM-specific inputs slotted in:

                          +--------------------------------+
                          |   Composite Trust Decision     |
                          |   (PQC-signed attestation)     |
                          +---------------+----------------+
                                          |
        +--------------------+------------+------------+----------------------+
        |                    |                         |                      |
   RBM verified-sender  RBM capability             SIM-Swap freshness     Device-bound passkey
   state (boolean +     fingerprint                via CAMARA SIM Swap    assertion (FIDO2,
   freshness)           (UP version, MLS,                                 WebAuthn) bound to
                        provisioning)                                     user agent
        |                    |                         |                      |
        +--------------------+------------+------------+----------------------+
                                          |
                          Signal weighting + freshness
                          evaluation in-request

The RBM inputs are deliberately narrow. The verified-sender state contributes a single boolean and a freshness timestamp. The capability fingerprint contributes a stable-state delta indicator and a posture-drift flag. Neither is asked to do work it cannot do. The cross-check against SIM-Swap freshness is what makes the composite hold up: if RBM capability flips, the verifier looks immediately at whether the SIM state moved at the same moment. Correlated movement is a stronger signal than either input alone.

For the deeper architectural pattern, see Carrier Signal Fusion: When One Carrier Lies, Edge-First Identity Verification, and SIM Signals + Verifiable Credentials Cross-Reference.

Failure modes

Treating RBM as an identity channel is the right move. Treating it uncritically is not.

Verified-sender does not mean verified-message. A compromised internal marketing automation platform sending through an authentic RBM agent produces a phishing campaign with a green checkmark. The badge is doing exactly what it was specified to do, and that is the problem. Defense is content-side: outbound message review, link-integrity scanning, and a deny-by-default policy on payloads that ask the user to disclose secrets.

Capability drift is noisy. Real users change phones. Real users travel. A capability-drift signal must be weighted. The right TTL is short, the right blast radius is narrow, and the right action is to raise the bar on the next assertion instead of blocking.

Fallback to SMS strips the signal. When RBM is unavailable and the message falls back to SMS, the verifier must know. Persisting the actual channel of delivery as part of the signal record is non-negotiable. A signal record that loses this distinction overstates assurance.

Carrier-mediated MaaP is not Jibe. The Apple deployment of RCS uses the carrier's MaaP for sender attestation, with no involvement from Google's Jibe registrar. The two registrars apply different verification rigor and onboarding processes. A verified-sender claim is only as strong as the registrar that issued it, and consumers of RBM telemetry need to know which path their attestation traversed.

E2EE rollout is operator-dependent. UP 3.0 with MLS is the standard. Coverage at any given moment in 2026 is not. Treating "MLS supported" as a stable property of a handset across operators and roaming states will produce false drift signals.

RBM in the carrier stack

RCS Business Messaging is one node in a much larger telemetry graph. The other nodes are CAMARA-standardized carrier signals, SIM Swap detection, Number Verify, silent number recycling, and the device-bound passkey assertion that pins the decision to a specific authenticator.

The value of RBM is less any single new signal than a new class of telemetry, visible to the recipient device, where previously the only attestation primitives were visible to the network or the originating brand. That is a different vantage point, and signal classes evaluated from different vantage points are exactly what a fusion architecture is designed to reward.

The carrier-first identity teams that have been building this discipline for a decade (see our analysis of African mobile identity) already know this instinct. The Western A2P-trained instinct, that the sending side is what matters, has to give ground. The receiving device is now an attestation surface.

A build order

For an identity engineering team starting today:

1. Onboard for RBM through a Google-approved partner if your customer base is meaningfully on Android, and pursue carrier-mediated MaaP onboarding for iOS reach. Both paths are needed for cross-platform coverage.
2. Persist channel-of-delivery in the signal record. Treat RBM and SMS as semantically different attestation classes, never coalesced.
3. Capture the capability fingerprint at first contact and treat subsequent drift as a low-weight, high-freshness signal. Pair it with SIM-Swap freshness for correlation.
4. Treat verified-sender as a precondition and nothing more. Combine with content-side outbound review and a payload policy that refuses to ask for secrets in a message body.
5. Keep MSISDNs hashed. RBM does not require expanding the PII footprint; the signal is reducible to a boolean, a freshness timestamp, a channel class, and a capability hash. See our zero-PII architecture for the reference pattern.

Summary

A2P SMS was the channel identity teams were given. RCS Business Messaging is the channel they would have designed if they had been at the table. The verified-sender attestation, the capability fingerprint, and the encryption posture are not magic, and they do not make any single identity decision by themselves. They do something more useful: they extend the telemetry graph to a vantage point that did not exist before, on devices that have already shipped, against a standard that the GSMA, Google, and Apple have aligned on.

The job of an identity stack in 2026 is to consume those signals for exactly what they assert, fuse them with SIM-bound carrier evidence and device-bound assertions, and produce a composite trust decision inside the request. That is the work. RCS makes the work easier than it has ever been on the messaging channel. It does not make the work go away.

---

PasskeyBridge consumes RBM verified-sender state, RCS capability fingerprints, CAMARA-standardized SIM Swap and Number Verify signals, and device-bound passkey assertions, fuses them under a zero-PII contract, and emits PQC-signed composite trust decisions inside the request. For the architectural backplane, see our work on carrier signal fusion, carrier signal freshness TTL, and edge-first verification. Developer-facing documentation lives at docs.passkeybridge.io.

Start free · Test the API