Most articles answering this question predate May 2026 and are now wrong in the direction that matters. Cross-platform end-to-end encryption is no longer a proposal, it shipped. What has not changed, and is the part businesses actually need, is that end-to-end encryption applies to private conversations between two people, not to messages sent by a brand.
What changed in May 2026
The GSMA defined cross-platform end-to-end encryption in RCS Universal Profile 3.0, published in March 2025 and built on the Messaging Layer Security protocol (GSMA). Apple worked on the specification and then implemented it: with the release of iOS 26.5 on 11 May 2026, RCS conversations between an iPhone and an Android phone became end-to-end encrypted for the first time (Apple). Google Messages has offered end-to-end encryption on RCS for years, so the gap was always the Apple side (Google).
Apple still describes the feature as beta, and that word is doing real work. The rollout is staged, it depends on the carrier as much as the handset, and it covers personal chats only.
Is RCS fully end-to-end encrypted?
No, and the honest answer is worth stating plainly because "RCS is encrypted" gets repeated without its conditions. RCS is end-to-end encrypted for personal conversations when several things are true at once, and it is never end-to-end encrypted for business messages.
| Message type | Encrypted in transit | End-to-end encrypted |
|---|---|---|
| Person-to-person RCS, Android to Android | Yes | Yes |
| Person-to-person RCS, iPhone to Android | Yes | Yes, from iOS 26.5, where both carriers support it |
| Business RCS (RBM) | Yes | No, and by design |
| SMS or MMS fallback | No | No |
Three conditions have to hold together for a personal chat to be end to end encrypted. Both people need a client that supports it, which means a current Google Messages on Android and iOS 26.5 or later on iPhone. Both carriers need to support Universal Profile 3.0, which is a separate qualification from carrying RCS at all. And Apple still labels the cross-platform case beta. Miss any one of those and the conversation is transport-encrypted rather than end to end.
The row most people overlook is the last one. When RCS cannot be delivered the message falls back to SMS or MMS, and that leg carries no encryption at all, end to end or otherwise. So a programme described as encrypted is only encrypted for the share of recipients who actually received it as RCS. How RCS falls back to SMS explains when that happens.
None of this makes RCS weak. Transport encryption plus a verified sender is a stronger position than SMS has ever offered, and it is the same security model as every other business channel you already use. It simply is not the same claim as "fully end to end encrypted", and a business that repeats that phrase to a customer or a regulator is overstating it.
How RCS encryption actually works
Two different mechanisms get collapsed into one word, which is why the answers online contradict each other.
Transport encryption protects the message on the wire, between the handset, the carrier's RCS server, and the platform at the other end. It is TLS, the same thing protecting a bank's website. It has always been part of RCS, it covers every message including business messages, and it means nobody sitting on the network in between can read the traffic. What it does not do is hide the message from the servers relaying it.
End-to-end encryption goes further. The message is encrypted on the sending device with keys the servers never hold, and decrypted only on the receiving device. Carriers, Google, Apple, and any provider in between carry ciphertext they cannot open. This is what Universal Profile 3.0 added, using Messaging Layer Security, an open IETF standard (RFC 9420) rather than a proprietary scheme. Because MLS is standardised, an iPhone and an Android phone can agree keys without either vendor adopting the other's protocol, which is precisely why cross-platform encryption became possible at all.
In both Google Messages and the iPhone Messages app, an end-to-end encrypted thread is marked with a lock icon, on the send button or beside the timestamp depending on version. No lock means the conversation has fallen back to transport encryption only, or to SMS.
Is RCS encrypted between iPhone and Android?
Since iOS 26.5, yes, but three conditions all have to hold at once:
- iOS 26.5 or later on the iPhone. Earlier releases support RCS, from iOS 18.1 in 2024, but not the encryption layer.
- A current version of Google Messages on the Android device. Google Messages is the client that implements MLS; other Android texting apps generally do not.
- Carrier support for Universal Profile 3.0 at both ends. This is the condition most people miss, and it is the subject of the next section.
Where all three hold, encryption is on by default. There is nothing to switch on and nothing to opt into, which is the practical difference from the previous generation of secure messengers, and the reason the change reached hundreds of millions of people in a single software update.
The carrier catch worth knowing about
Carrier support for RCS and carrier support for RCS encryption are two separate qualifications. A carrier can already be carrying RCS traffic without having implemented the Messaging Layer Security layer that Universal Profile 3.0 added. That is why two people can both be on iOS 26.5 and still not see a lock icon, and it is the single most common reason the feature appears to be missing.
AT&T, T-Mobile, and Verizon are all on Apple's supporting-carrier list, so most US conversations qualify. Smaller networks, MVNOs, and many carriers outside the US are further behind. Which carriers support RCS tracks the current state.
What is encrypted, and what is not
| Message type | Encrypted in transit | End to end | Who can read the content |
|---|---|---|---|
| Personal chat, both ends on UP 3.0 | Yes | Yes | The two devices only |
| Personal chat, one end unsupported | Yes | No | The devices, plus the relaying servers |
| Business (A2P) RCS | Yes | No | The devices, plus the sending platform |
| SMS fallback | Minimal | No | The devices, carriers, and anyone with network access |
Why business RCS is different, and why that is fine
An application-to-person message has to be processed by the sending platform in order to exist at all. The platform renders the rich card, checks whether the recipient can receive RCS, routes the message, records delivery and read events, and fails the message over to SMS when it must. None of that is possible on content nobody but the two endpoints can read. So business RCS relies on strong transport encryption rather than end-to-end encryption.
This is not a weakness peculiar to RCS. It is the same model as every other business channel: SMS, email, and WhatsApp Business all work this way, for the same reason. Any vendor claiming end-to-end encrypted business RCS is either describing transport encryption or describing something that would not function.
What RCS adds on top, and what SMS entirely lacks, is verified sender identity. The brand name, logo, and checkmark are drawn by the phone from the approved sender record, so they cannot be faked by an attacker who simply puts your brand name in message text. For most real-world threats against consumers, that identity guarantee prevents more harm than encryption would, because the dominant attack on SMS is impersonation rather than interception.
What this means for what you send
Treat RCS as a well-secured professional channel rather than a vault. The practical rule is unchanged by the 2026 encryption news, because the news was about private chats:
- Do not send full card numbers, government identifiers, credentials, or clinical detail in the message body.
- Do use a suggested action to move the customer into an authenticated destination in one tap, which is both safer and better converting than asking them to log in from memory.
- Do keep protected health information out of the thread entirely. Is RCS HIPAA compliant covers how that is normally designed.
- Do protect your own side: API keys, webhook endpoints, and who in your organisation can send.
- Do not market on encryption you do not have. Describing a business campaign as end-to-end encrypted is a claim a regulator can test.
- All RCS messages are encrypted in transit, on every device and carrier that carries the channel.
- Person-to-person end-to-end encryption came from GSMA Universal Profile 3.0 (March 2025), built on Messaging Layer Security, the open IETF standard RFC 9420.
- Apple enabled cross-platform end-to-end encryption by default, in beta, with iOS 26.5 on 11 May 2026; Google Messages has supported it for years.
- Encrypted RCS between iPhone and Android needs three things at once: iOS 26.5 or later, a current Google Messages, and carrier support for Universal Profile 3.0 at both ends.
- Carrier support for encryption is a separate qualification from carrying RCS at all, and is the usual reason a lock icon is missing.
- Business RCS is transport-encrypted and platform-processed, not end to end, in common with SMS, email, and WhatsApp Business.
Sources
- Apple Newsroom, End-to-end encrypted RCS messaging begins rolling out today in beta, 11 May 2026.
- GSMA, RCS Encryption: A Leap Towards Secure and Interoperable Messaging, on Universal Profile 3.0 and MLS.
- Google, E2EE RCS messaging rolls out for Android and iPhone.
- Google Messages Help, Use end-to-end encryption in Google Messages.
- Electronic Frontier Foundation, Victory! End-to-end encrypted RCS comes to Apple and Android chats, May 2026.