RCS Messaging Explained: Universal Profile, IMS, MLS and Business Chat

RCS (Rich Communication Services) is the carrier messaging standard that replaces SMS and MMS with typing indicators, read receipts, high resolution media and group chats over mobile data or Wi-Fi. The GSMA specifies it as the RCS Universal Profile, and it runs on the operator IMS core using SIP and MSRP. RCS is not automatically end-to-end encrypted: encryption depends on the app, the carrier and every participant.

This post covers the network architecture, the two generations of end-to-end encryption (a vendor specific Signal Protocol design first, then the standard Messaging Layer Security protocol in Universal Profile 3.0), what metadata still leaks, what changed when iPhones gained RCS, how verified business senders work, and what enterprises should do about archiving and one time codes. For the double ratchet and MLS basics in general, see our end-to-end encrypted messaging explainer. For SIP itself, see SIP and RTP explained; for the older signalling that SMS rides on, see SS7 and Diameter explained; and for the radio side, our 5G security architecture explainer.

Facts in this post come from GSMA, IETF, 3GPP, Google and Apple documents we fetched in October 2026. Where two of those sources disagree, we say so.

Key takeaways

• RCS is specified by the GSMA as the RCS Universal Profile. It is a carrier service: the phone number is the identity, and the operator or its hosting partner runs the servers.
• RCS runs on the IMS core defined in 3GPP TS 23.228. Sessions are set up with SIP (RFC 3261), chat messages travel over MSRP (RFC 4975), and files go to a content server and are sent as links.
• Links between clients and servers, and between servers, use TLS hop by hop. That stops eavesdroppers on the wire, not the servers themselves.
• Google Messages added end-to-end encryption first, using the Signal Protocol, with a key server hosted only by Google. It worked only when both people used Google Messages.
• On 14 March 2025 the GSMA announced Universal Profile 3.0, whose specifications define "how to apply MLS within the context of RCS". MLS is the IETF Messaging Layer Security protocol, RFC 9420 (July 2023).
• Apple added RCS in iOS 18 (September 2024) and end-to-end encrypted RCS in iOS 26.5, which Apple labels beta and which needs a supporting carrier for every participant. The GSMA announced the cross platform rollout on 11 May 2026.
• Encrypted or not, servers still see phone numbers, timestamps, IP addresses, carriers, protocol headers and attachment sizes and URLs, according to Google's technical paper.
• Business messages are a separate case. Google's RCS for Business documentation says agent messages are encrypted to and from Google's servers but are not end-to-end encrypted, because Google scans them for malicious content.
• One time codes sent by RCS or SMS stay phishable however well the channel is encrypted. Passkeys only work on the site or app they were registered for.

Timeline: RCS, IMS and MLS milestones

The dates below come from the publication metadata of each document or page.

What is RCS, who specifies it, and how does it relate to SMS and MMS?

SMS is the 160 character text service that rides on the mobile network's signalling channels. MMS added pictures and short videos with heavy compression. Neither has typing indicators, reliable read receipts, proper group membership or encryption between handsets; Apple's support page says plainly that "SMS/MMS messages aren't end-to-end encrypted".

RCS keeps the same address (the phone number) and the same default messaging app, but moves the traffic onto IP over mobile data or Wi-Fi. Apple lists "texts, high resolution photos and videos, links, and more", plus delivery and read receipts and typing indicators.

The specification owner is the GSMA, the industry association of mobile operators. Its RCS Working Group publishes the RCS Universal Profile, the common baseline that clients and networks implement so that a message from one operator and handset reaches another. The GSMA's May 2026 press release calls it "an industry specification" with "significant contributions from Apple and Google".

Three things set RCS apart from both SMS and internet messengers:

1. Identity is the phone number, authenticated by the carrier. Apple explains that the phone "communicates with your carrier and their partners to set up RCS", exchanging identifiers that include the phone number and, depending on the carrier, the IP address. The GSMA calls this "SIM-based authentication".
2. It is federated. Operators run different servers that interconnect. Google's paper calls RCS "a federated protocol implemented by a variety of client and server vendors".
3. It falls back. When RCS is unavailable, the messaging app can send SMS or MMS instead, which is the biggest single source of confusion about RCS security.

What changed in each recent Universal Profile release?

The GSMA's own words on 4.1 are worth noting: it is "not focused on introducing major new consumer-facing features" but on making encrypted messaging work consistently between clients from different providers.

How does RCS work inside the network?

IMS in one page

RCS is an IMS application. IMS, the IP Multimedia Subsystem, is the 3GPP architecture operators use for voice over LTE, voice over Wi-Fi and other IP services. 3GPP TS 23.228 is its stage 2 (architecture) specification; the current version is V20.1.0, dated September 2026. The elements that matter for messaging, described in the spec's clause 4.6:

The handset registers with SIP REGISTER, and the S-CSCF acts as registrar. The GSMA describes RCS as using "SIM-based authentication". RCS clients outside the operator's native IMS stack go through an onboarding and configuration process instead, which is what Universal Profile 3.1's changes to "connecting RCS clients to operator services" address.

SIP for signalling, MSRP for messages

Google's paper summarises the transport in two sentences: RCS "uses the standard Session Initiation Protocol (SIP) to establish a connection between two clients through a network of RCS messaging servers", and that connection "is then used to exchange messages using Message Session Relay Protocol (MSRP)".

SIP (RFC 3261, June 2002) is a text protocol modelled on HTTP. A client sends INVITE to start a session, the other side answers, and the two agree on media through an SDP offer and answer. In a voice call the media is RTP audio. In an RCS chat the media is an MSRP session.

MSRP (RFC 4975, September 2007) carries a series of instant messages within a session. Messages are sent in SEND requests that can be split into chunks, and each hop answers the requests it relays. MSRP defines an "msrps" URI scheme for sessions that run over TLS. RCS wraps each message in CPIM (Common Presence and Instant Messaging) headers carrying sender, recipient and time. Google's list of metadata visible to servers names "SIP, MSRP, or CPIM headers" explicitly, so all three layers are present in real deployments.

A simplified one to one flow:

Step 6 matters for privacy. Google describes standard RCS file transfer as uploading the attachment to "the sending user's carrier content store", then sending a link plus metadata "such as filename and size" in an XML payload.

Carrier hosted versus hub hosted RCS

Operators can run the RCS application servers themselves or use a hosted platform. Google's paper says "Most RCS server deployments are either hosted by a carrier or by Jibe Mobile from Google", and Apple's page says the phone talks to "your carrier and their partners". The server holding your undelivered messages and attachment links may not belong to the company on your bill.

When the two people in a chat are on different networks, the message crosses at least two RCS servers, "one from each carrier". Universal Profile 4.1 introduces a gRPC based, connectionless transport between networks for messages and signalling, which the GSMA says cuts overhead and improves reliability.

What TLS does and does not protect

Google's paper states that "client-to-server and server-to-server network connections are all encrypted using Transport Layer Security (TLS)". That defeats someone sniffing Wi-Fi or a transit link, but it is hop by hop: each server decrypts, processes and re-encrypts. Without end-to-end encryption, every server operator in the path, and anyone who compromises one of those servers, can read content and attachments.

How did end-to-end encryption arrive in RCS?

Phase one: Signal Protocol inside Google Messages

Google's technical paper (version 1.2, February 2022) documents the first design:

• Protocol. Messages "uses the Signal Protocol". Each client generates Curve25519 identity, signed prekey and one time prekey pairs; sessions start with X3DH, and the double ratchet changes keys on every message.
• Key server. Public keys go to a key server that "is currently only hosted by Google". The key directory was not federated.
• Ciphers. Messages use AES-256-CBC with HMAC-SHA256. Attachments are encrypted with a fresh key using AES-CTR 256 before upload to the carrier content store, with a SHA256 digest checked on download.
• Hidden message types. Text, location, reactions and read receipts use a new "rcs.encrypted" content type, so servers cannot see which kind of message it is. Typing indicators and delivery receipts kept the standard format "for RCS operational reasons".
• Verification. Users can compare a verification code, a fingerprint of both identity keys computed with 512 iterations of SHA512.
• Hard limit. "Both clients in a conversation must use Messages, otherwise the conversation becomes unencrypted RCS."

The paper describes one to one chats; Google's current help page covers "the person or group you message", so groups followed. But no other RCS client could join without implementing Google's protocol and trusting Google's key server.

Phase two: MLS in the Universal Profile

The GSMA's 14 March 2025 announcement set the direction: new specifications "that include end-to-end encryption (E2EE) based on the Messaging Layer Security (MLS) protocol". Six months earlier it had named the hard problems as "key federation and cryptographically-enforced group membership". MLS was built for exactly that: groups, many independent implementations, and a clean split between the parts of a system that deliver messages and the parts that vouch for identities.

How MLS works, in the depth you need for RCS

RFC 9420 defines the protocol; RFC 9750 (April 2025) describes the architecture around it.

Groups and epochs. RFC 9420 targets groups "ranging from two to thousands". A group shares secret state that moves forward in numbered epochs. Every change to membership or keys starts a new epoch with fresh secrets, and messages are encrypted with keys derived for the current epoch.

Clients, not people. MLS members are devices. A person with two devices is two leaves in the group, so "the same person on a new phone" is a membership change, and a good client shows it to you.

KeyPackages. To be addable while offline, a client publishes KeyPackages: signed bundles with an encryption public key, a credential binding the client to an identity, and supported versions and ciphersuites. RFC 9420 says they "are intended to be used only once", like Signal's one time prekeys.

Proposals, Commits and Welcomes. Members propose changes (add, remove, update their own key and others). A Commit applies proposals and moves the group to the next epoch. New members get a Welcome with what they need to join that epoch, and nothing from earlier ones.

The ratchet tree. Members sit at the leaves of a binary tree, and each interior node has a key pair known only to the members beneath it. An updating member replaces the keys on its path to the root and encrypts the new secrets to the sibling subtrees, so the cost of a change grows roughly with the logarithm of group size rather than linearly. That is what makes large encrypted groups practical.

Forward secrecy and post-compromise security. Old epoch secrets are deleted, so a later compromise does not expose earlier messages. A compromised member who is removed or rekeyed stops being able to read new messages. RFC 9420 names both properties as goals.

Ciphersuites. A ciphersuite fixes the HPKE key encapsulation, AEAD cipher, hash and signature algorithm. RFC 9420 registers seven and makes MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 mandatory to implement.

Authentication Service and Delivery Service. RFC 9750 separates two roles. The Authentication Service (AS) issues credentials binding identities to signature keys and lets members check them. The Delivery Service (DS) stores KeyPackages and routes messages; it may see and drop traffic but must not be able to read or forge it. In RCS, the DS role maps to the operator messaging servers, and the AS role to how phone number identities are vouched for across operators, which is the "key federation" problem the GSMA named. The cryptography is only as good as that identity layer.

Phase three: iPhone and the carrier dependency

Apple's support page, fetched in October 2026, says: "Starting with iOS 26.5, end-to-end encrypted RCS messaging (Beta) in Messages is available with supported carriers and will roll out over time." RCS conversations "can be end-to-end encrypted when all participants have carriers that support encryption". Apple's setup page adds that the feature "is on by default", with a switch under Settings, Apps, Messages, RCS Messaging, End-to-End Encryption (Beta). Apple's carrier list for the United States and Canada marks which carriers offer "End-to-end encrypted RCS messaging (beta)".

The GSMA's 11 May 2026 press release says the rollout covers conversations "between iPhone users running iOS 26.5 and Android devices running on the latest version of Google Messages", and that users will see a padlock "Once enabled by supporting mobile network operators".

Google's help page, also fetched in October 2026, still says "Currently only Google Messages supports end-to-end encrypted RCS". That sentence is out of step with Apple's and the GSMA's pages. Trust the indicator in each conversation.

What still leaks when RCS is end-to-end encrypted?

End-to-end encryption protects content, not the envelope. Google's paper lists what servers can still access for encrypted RCS:

• Phone numbers of senders and recipients
• Timestamps of messages
• IP addresses or other connection information
• Sender and recipient carriers
• SIP, MSRP or CPIM headers, such as User-Agent strings that may reveal device maker and model
• Whether a message has an attachment, and the attachment's URL on the content server
• The approximate size of messages and the exact size of attachments

Some of this is structural to any carrier service; messengers that pad messages or hide the sender from their servers protect more metadata than RCS does.

Endpoints leak too. Google says encrypted RCS messages "will continue to be stored in the device's messages database and accessible to apps with SMS permissions", and that received encrypted messages are "included in Android backup". Apps with notification access can read previews. Android system backup has been end-to-end encrypted with a key derived from the lock screen since Android P, per Google's paper. And the moment a message goes as SMS or MMS, none of this protection applies.

What changed when iPhones gained RCS?

Before iOS 18, an iPhone messaging an Android phone used SMS and MMS: compressed media, MMS group chats and no encryption between handsets. With iOS 18, Apple added RCS as a third message type. Apple's page sets out the order: iMessage between Apple devices; "If you aren't using iMessage, you can use RCS"; otherwise SMS/MMS. RCS bubbles are green, like SMS. You need iOS 18 and a carrier plan that supports RCS on iPhone, and in iOS 26 you can choose which app handles SMS, MMS and RCS.

For about a year and a half, iPhone to Android RCS was not end-to-end encrypted. iOS 26.5 changed that, with conditions: the beta label, carrier support for every participant, and a gradual rollout. Encrypted conversations show "Encrypted" with a lock icon at the top, and Apple is blunt about the alternative: "If you don't see the indicator, your RCS messages aren't protected from a third-party reading them while they're sent between devices."

iPhone to iPhone chats remain iMessage. And a mixed group is encrypted only if every participant's carrier supports encrypted RCS.

How does RCS business messaging work?

Business messaging is the commercial engine behind RCS. Instead of a short code sending plain text, a business runs an agent that sends branded messages with rich cards, media and suggested replies. Google calls its platform RCS for Business; its API is still called the RCS Business Messaging (RBM) API.

Agents, brands and launch

From Google's developer documentation:

• Agents start conversations. An agent sends the first message when an external trigger fires (an order ships, an appointment is due). Google's docs state that users "can't start conversations with your agent".
• API and webhook. The agent sends messages as HTTP requests with JSON payloads. User replies and events arrive at the business's webhook as HTTPS POST requests.
• Capability checks and fallback. Before sending, the agent can ask whether a number is RCS capable. If not, the platform returns a 404 and the agent "should fall back to another technology", typically SMS. A capability check only succeeds if the number connected to the RCS service in the last 31 days, and undelivered messages are queued for up to 31 days.
• Brand verification. An authorised representative of the brand confirms the agent's information and the partner's right to manage it. It is required before the first launch. For certain carriers, launch will also need a verification token from a recognised Verification Authority, and Google says RCS clients "will eventually begin validating verification tokens".
• Launch review. Google, the carriers, or both review the agent's assets, message triggers and opt-out (STOP) handling. Google-managed launches take 1 to 3 business days.
• Encryption. Google states that agent messages "are encrypted between RCS for Business agents and Google servers, and between Google servers and users' devices", and that partners cannot use their own keys "because Google needs to scan messages for malicious content". Its data security FAQ says RBM "does not offer end-to-end encryption".

Universal Profile 3.0 added easier management of subscriptions with business senders, and 4.0 made deep link handling and sender verification more efficient. On iPhone, Settings, Apps, Messages, RCS Messaging has a switch to turn RCS Business Messages off.

What the verified badge means, and what it does not

After an agent passes brand verification and launches, Google's docs say Google Messages "automatically displays a verification checkmark" next to the agent, and the agent's Conversation Details page shows that the sender has been verified. That means a brand representative vouched for the agent and a launch review passed. It does not mean:

• every message from that agent is benign (accounts and partner integrations can be misused),
• a link goes where the text claims,
• an unverified sender using the same name is the same business.

Treat the badge as a signal, then do what you would do with any message asking for money or a code: reach the business through an app or address you already trust.

Spam handling

Google's help says end-to-end encryption does not switch off spam detection in Google Messages. Reporting has a privacy cost worth knowing: a spam report sends the sender's number and the last 10 incoming messages from that sender to Google, and may also send a copy to your carrier. Content you report leaves the encrypted channel by design. Google says messages it detects as spam "can be dropped" and senders suspended. On iPhone, Apple's page describes Report Junk, then Delete and Report Junk.

Comparison: SMS versus RCS versus RCS with MLS versus internet messengers

Step by step: check, harden and verify

On Android with Google Messages

1. Check that RCS chats are on. In Google Messages tap your profile picture, then Messages settings, then RCS chats. "Connected" means it works. "Connecting" means your number is being verified; if it shows "Trouble connecting" for more than 30 minutes, Google suggests sending feedback from Details. Google also warns that switching RCS on and off removes you from group chats.
2. Check whether a conversation is encrypted. A lock on the send button and next to message timestamps means end-to-end encryption, and the conversation shows "RCS chat with" the contact.
3. Read the bubble colour and send icon. Google's help says messages are dark blue in the RCS state and light blue in the SMS/MMS state, and the send icon shows whether the next message goes by data, SMS or MMS.
4. Control fallback. Google's paper says eligible messages now "send over RCS and not automatically fall back to SMS/MMS"; an offline recipient's messages wait on the server and you choose whether to resend as SMS. The choice lives in RCS chats, Resend messages. Avoid "SMS with a link": Google warns the media "could be accessible by a public link".
5. Compare verification codes for sensitive contacts, in person or over a separate channel, and again after the contact reinstalls or changes phones.
6. Review which apps can read your messages. Encrypted RCS messages land in the Android messages database, readable by apps with SMS permission and, through notifications, by apps with notification access. Remove both from apps that do not need them.

On a test or managed device you own or administer, the same checks work from a terminal with Android's adb:

# Which app holds the default SMS role
adb shell cmd role get-role-holders android.app.role.SMS

# Installed Google Messages version (encryption needs a current build)
adb shell dumpsys package com.google.android.apps.messaging | grep versionName

# Apps currently allowed the READ_SMS app operation
adb shell cmd appops query-op READ_SMS allow

# Apps with notification listener access (they can read message previews)
adb shell settings get secure enabled_notification_listeners

On iPhone

1. Check versions. Settings, General, About shows the iOS version. RCS needs iOS 18; encrypted RCS needs iOS 26.5.
2. Turn RCS on and check encryption is enabled. Settings, Apps, Messages, RCS Messaging. In iOS 26.5 the End-to-End Encryption (Beta) switch is on by default. If the RCS Messaging setting is missing, Apple says RCS may not be available on your carrier.
3. Check each conversation. Blue is iMessage, green is RCS or SMS/MMS. An encrypted RCS conversation shows "Encrypted" with a lock at the top. No indicator means not end-to-end encrypted.
4. Check carrier support. Apple's carrier pages mark which carriers support encrypted RCS. Your contact's carrier matters as much as yours.
5. Decide on business messages. The RCS Business Messages switch on the same screen turns off order and transaction alerts from businesses if you do not want them.

Verifying a business sender

1. Look for the verification checkmark, then open the conversation details and confirm the page says the sender is verified.
2. Compare the phone number, website and email shown there with those on the company's own website or app, not with anything in the message.
3. If the message asks for a payment, a password or a one time code, stop. Open the company's app or type its address yourself.
4. Report impersonation as spam or junk so the platform can act on it.

For developers sending business messages

Most of the security work is API hygiene, and Google's docs spell out the key control. Webhook calls carry an X-Goog-Signature header. To check it, base64 decode the payload, compute an HMAC SHA512 over the decoded bytes using your webhook's client token as the key, base64 encode the result and compare. Reject anything that does not match. Google advises verifying traffic by signature or reverse DNS rather than IP allowlists, because its IP addresses change.

# Capability check from Google's docs: is this number reachable over RCS?
curl -X GET "https://REGION-rcsbusinessmessaging.googleapis.com/v1/phones/PHONE_NUMBER/capabilities?requestId=REQUEST_ID&agentId=AGENT_ID" \
  -H "`oauth2l header --json PATH_TO_SERVICE_ACCOUNT_KEY rcsbusinessmessaging`"

Also:

• Keep the service account key in a secrets manager and use a separate developer account for test agents, as Google recommends.
• Process webhook events asynchronously. Google warns that one failing agent webhook can delay delivery to every agent on the same partner account, and that retries back off for up to 7 days.
• Decide deliberately what falls back to SMS after a 404. Do not send by SMS anything you would refuse to send unencrypted.
• Remember that agent traffic is not end-to-end encrypted. Keep regulated data out of it; Google's FAQ says RBM is not HIPAA compliant and messages containing protected health information are prohibited.

Enterprise angle: archiving, device policy and one time codes

Compliance archiving

Regulated firms that must retain business communications have captured SMS either at the carrier or with an agent on the device. Carrier side capture of RCS content stops working once a conversation is end-to-end encrypted, because the carrier holds only ciphertext. Device side capture still sees plaintext, through the same SMS and notification permissions Google's paper describes.

So compliance teams have three honest options: keep business conversations on a sanctioned channel their archiving already covers; use managed devices with an approved capture app whose stored data is protected and access controlled; or write into policy that encrypted RCS is outside carrier archiving rather than assume capture still works.

Mobile device policy

• Require current versions: encrypted RCS needs a current Google Messages build on Android and iOS 26.5 on iPhone.
• Restrict which managed apps hold SMS and notification access.
• Treat lost device procedures as message confidentiality procedures: whoever unlocks the phone reads the plaintext.

Why one time codes over RCS or SMS remain phishable

Encryption protects a code while it travels. It does nothing once the code is on your screen. The common attack intercepts nothing: a fake login page asks for the code and the user types it in. An encrypted chat and a verified sender badge on the bank's agent both leave that path open.

Google's RCS for Business FAQ notes that an OTP sent through RBM counts as a compliant Strong Customer Authentication factor under PSD2, because it is tied to the verified number and SIM. Compliant is not the same as phishing resistant. Google's passkey documentation says passkeys "work only on their registered websites and apps" and that a user "cannot be tricked into authenticating on a deceptive site". Apple describes passkeys as "resistant to phishing". Where an account offers passkeys, prefer them. Where you must use codes, prefer an authenticator app, and tell users that no real support agent asks them to read a code back.

SIM swap and number porting also still apply wherever the phone number is the identity. Google's capability check docs note that moving a SIM to another device moves the RCS association with it. An MLS client should then show a new device or key in conversations, which is why those notices deserve attention.

The software behind RCS: a supply chain view

RCS looks like a phone feature, but every part of it is software with dependencies: the messaging app, the operator's IMS and RCS servers, the content store, interconnect gateways and every business agent and webhook. They are built on SIP and MSRP stacks, TLS libraries, HTTP and gRPC frameworks, JSON and XML parsers, media codecs and MLS implementations. The GSMA's own release notes name gRPC as the 4.1 inter network transport and the xHE-AAC codec in 3.1; both are code someone ships and patches. Media parsing is historically one of the riskiest places in any messaging stack, because received files are processed automatically, and that risk lives in libraries that get advisories.

Where Safeguard fits

Safeguard does not inspect RCS traffic, test GSMA conformance, verify business senders, archive messages, manage phones or detect spam. Its fit here is indirect and specific: it works on the software you build. If you build a business messaging integration, a webhook service, an RCS server component or an Android or iOS app, you can scan the repository, a container image or an SBOM file (safeguard scan --dir ., --image, --sbom), match components against vulnerability databases, use reachability analysis to see whether the vulnerable code paths in, say, a media or XML parsing library are actually called, and see which projects contain a given component and version. Policies and gates in CI can Block, Warn or Notify when a build brings in a known vulnerable library, with approvals handled through exceptions. Autonomous remediation, switched off by default, can open fix pull requests. It does not replace the vendor's patch for a phone OS, a messaging app you install from a store, or an operator platform you do not build.

Common mistakes

1. Assuming RCS means encrypted. Encryption needs supporting clients, current builds and, on iPhone, supporting carriers for everyone. Check the indicator per conversation.
2. Missing fallback to SMS. An SMS or MMS message is readable by carriers in transit. Do not tap resend as SMS for anything sensitive.
3. Trusting a branded sender badge alone. Verification confirms who registered the agent, not that each message or link is safe.
4. Using messages for MFA codes when passkeys are available. Codes are phishable however the channel is encrypted.
5. Treating hop by hop TLS as end-to-end. It stops wire eavesdroppers, not servers.
6. Forgetting metadata. Encrypted RCS still exposes who, when, from which IP and carrier, and attachment sizes and URLs.
7. Granting SMS permission casually. Apps with it can read decrypted RCS messages in the Android messages database.
8. Assuming business chats are end-to-end encrypted. Per Google, agent messages are not.
9. Assuming mixed groups are encrypted. On iPhone, every participant's carrier must support encryption.
10. Assuming carrier archiving still captures everything. It cannot capture encrypted RCS content.

FAQ

Is RCS end-to-end encrypted?

Sometimes. RCS uses TLS hop by hop, which is not end-to-end. Google Messages encrypts RCS end-to-end between Google Messages users, and since iOS 26.5 (beta) iPhone to Android RCS can be encrypted with MLS when every participant's carrier supports it. Look for the lock or "Encrypted" indicator.

What is the RCS Universal Profile?

The GSMA's common RCS specification set, implemented by clients and networks so RCS works across operators and devices. Recent versions are 3.0 (March 2025, MLS encryption), 3.1 (July 2025), 4.0 (March 2026) and 4.1 (July 2026).

Are RCS business messages end-to-end encrypted?

No. Google's RCS for Business documentation says agent messages are encrypted between the agent and Google's servers and between those servers and your phone, but not end-to-end, because Google scans them for malicious content.

Is RCS more secure than SMS?

Yes, in both forms. Plain RCS adds TLS on each link, which SMS lacks, though servers can still read content. Encrypted RCS also hides content from servers. Both still expose metadata.

Can my carrier read my RCS messages?

Without end-to-end encryption, the carrier's RCS servers or hosting partners can access content. With it, they see only metadata.

What is MLS in RCS?

Messaging Layer Security, the IETF protocol in RFC 9420 for end-to-end encrypted group messaging. The GSMA adopted it in Universal Profile 3.0 so that different RCS clients, such as Apple's and Google's, can encrypt to each other.

Why does my iPhone RCS chat not show a lock?

Your iOS is older than 26.5, your carrier or a contact's carrier does not support encrypted RCS yet, the rollout has not reached you, or the encryption switch is off. Without the indicator, Apple says the chat is not end-to-end encrypted.

How do I know an RCS business message is real?

Look for the verification checkmark, open the conversation details, and compare the contact details with the company's own website. Even then, do not act on a request for money or a code from the message; go through the company's app or site.

Are one time passwords sent by RCS safe?

They are protected in transit when the chat is encrypted, but still phishable: a fake site can ask you to type the code. Use passkeys where offered, then an authenticator app.

What metadata does RCS still reveal with encryption?

Per Google's technical paper: numbers, timestamps, IP or connection information, carriers, SIP, MSRP and CPIM headers including User-Agent strings, whether there is an attachment and its URL, and approximate message and exact attachment sizes.

Supply chain hygiene still matters here because every piece of RCS, from the messaging app to the operator's servers to a business's webhook, is built from open source libraries that receive advisories. The fit is indirect: none of the steps below touch RCS encryption or sender verification, but they do apply to the dependencies and container images in the messaging software you build and run.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and remediation workflows on the software you build. They do not show RCS traffic, encryption or business sender verification. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo is a real CLI session: you ask it to fix the lodash CVE in a repository, and it reads the finding and the advisory, asks before any command that changes something, moves lodash to 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow applies when a webhook service that receives RCS business message replies carries a vulnerable JSON, XML or HTTP library.

Click through it at your own pace, or open it full screen.

This demo is a real Android session: you send work to a computer running the Safeguard CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It is the same phone you would use to check your RCS settings, put to work approving a dependency fix while you are away from your desk.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given version of a media codec, gRPC or XML library, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IETF RFC 9420: The Messaging Layer Security (MLS) Protocol (July 2023)
• IETF RFC 9750: The Messaging Layer Security (MLS) Architecture (April 2025)
• IETF RFC 4975: The Message Session Relay Protocol (MSRP) (September 2007)
• IETF RFC 3261: SIP, Session Initiation Protocol (June 2002)
• 3GPP TS 23.228 V20.1.0 (2026-09), IP Multimedia Subsystem (IMS), Stage 2 (archive)
• 3GPP: TS 23.228 specification page
• GSMA: RCS Now in iOS, a New Chapter for Mobile Messaging (17 September 2024)
• GSMA: RCS Encryption, a Leap Towards Secure and Interoperable Messaging (14 March 2025)
• GSMA: Elevating the messaging experience with RCS Universal Profile 3.1 (25 July 2025)
• GSMA: From rich text to video, RCS Universal Profile 4.0 has arrived (26 March 2026)
• GSMA press release: iOS 26.5 brings E2EE for RCS (11 May 2026)
• GSMA: RCS Universal Profile 4.1, stronger foundations for secure messaging (28 July 2026)
• Google: Messages End-to-End Encryption Overview, technical paper version 1.2 (February 2022)
• Google Messages Help: How end-to-end encryption in Google Messages provides more security
• Google Messages Help: Turn on RCS chats in Google Messages
• Google Messages Help: Report spam in Google Messages
• Google for Developers: RCS for Business, how it works
• Google for Developers: RCS for Business brand verification
• Google for Developers: RCS for Business launch approval
• Google for Developers: RCS for Business capability checks
• Google for Developers: RCS for Business webhooks
• Google for Developers: Data security for RCS for Business
• Google for Developers: Passkeys
• Apple Support: What is the difference between iMessage, RCS, and SMS/MMS?
• Apple Support: Turn on RCS messaging on your iPhone
• Apple Support: Wireless carrier support and features for iPhone in the United States and Canada
• Apple Support: About the security of passkeys

Last reviewed: 25 October 2026. Encrypted RCS is still rolling out by carrier and by country; check the indicator in each conversation and your carrier's support page for current status.