There is an icon that showed up this year in the default chat app of millions of phones and that almost nobody looks at twice: a small padlock with the word “Encrypted” next to it. Behind that padlock sits a quiet but fairly deep change. The messages an iPhone and an Android exchange over RCS finally stopped being text a carrier can read from end to end. Since 11 May 2026, Apple and Google have been rolling out end-to-end encryption over RCS, the standard meant to replace SMS, and they are doing it with a protocol the IETF published in July 2023: MLS, Messaging Layer Security, RFC 9420.
Two things get mixed up all the time here, so it is worth separating them. RCS was already encrypted: SIP and MSRP over TLS to carry messages, HTTPS for capability provisioning and file transfer. That protects the hop between the phone and the carrier’s server, but the server is still in the middle and still sees the content in the clear. End-to-end encryption means something else: the text, the photo or the file leaves the device already encrypted with a key only the people in the conversation hold. The carrier, Google and Apple move opaque blocks around, and anyone who intercepts them gets nothing readable.
Encrypting two people is easy; encrypting a group is not
With two parties the problem was solved years ago: a shared secret is negotiated and a fresh key is ratcheted per message using a double ratchet (two derivation chains, one per direction). With groups, the naive approach — a separate session with every other person — stops scaling: in a group of n members that is n-1 sessions per participant, on the order of n² in total, and every join or leave means pushing fresh material down many paths at once. Ten people is fine; a hundred is not; a thousand is not even attempted.
The approach WhatsApp popularised, sender keys, fixes the cost: each member hands out their own symmetric key and everyone decrypts with it. But it comes with a known design trade-off. Removing a member is not guaranteed by the cryptography itself: it depends on every client processing the revocation, and a device that lags behind can keep decrypting. For a two-person chat that is irrelevant; for a hundred-person group it is a crack that widens with size.
A tree instead of a list
MLS drops the list and organises the group as a binary tree. Each member sits on a leaf and publishes a signed KeyPackage: identity, public key material and capabilities. Internal nodes are not people but secrets shared by the members hanging below them, encapsulated with HPKE (RFC 9180). The root holds the group secret.
The core mechanism is called TreeKEM. To rotate the key, a member does not talk to everyone: they refresh their own leaf, derive new secrets node by node up to the root, and publish only the values each peer needs to rebuild that path, encrypting each node’s secret under the child key the group already shared. The cost is logarithmic: in a group of 1,024 people, on the order of ten public-key operations instead of more than a thousand. A newcomer receives a Welcome message carrying the group state already encrypted for them; changes are agreed as proposals — add, remove, update — and closed by a signed Commit that opens a new epoch.
The server that shuffles the envelopes — the Delivery Service, in MLS jargon — never needs to understand the content: it orders messages, stores the tree and acts as a blind broker. In RCS that role is played by the carrier infrastructure; on Discord, by its voice gateway.
What MLS guarantees, and what it does not
The protocol was designed against explicit goals and went through formal analysis during its time in the IETF. Three of them show up in daily use:
- Forward secrecy: if someone steals your phone today, they cannot decrypt yesterday’s conversations. Each epoch’s key is wiped when it is replaced.
- Post-compromise security: if an attacker ever got hold of key material, they lose it as soon as a member sends an Update. The group heals itself; nothing has to be reinstalled.
- Control over membership: nobody joins without the rest validating the admission, and every member knows exactly who will receive each message.
There are also limits worth stating out loud, because the padlock in the icon does not cover them. MLS does not promise deniability: it does not guarantee that a recipient cannot prove to a third party that a message came from you, something two-party schemes do offer. And encryption does not hide structure. The tree is public material in every epoch, so the delivery service knows who is in the group, when its make-up changes and at what time messages are typed. That is precisely the kind of metadata messaging services have been collecting for years and which, as the EFF noted while celebrating the rollout, does not disappear just because the content is now protected.
What RCS adds on top
MLS is the engine; RCS is the car. The GSMA specification — Universal Profile 3.0, published in March 2025, with a dedicated encryption specification built on MLS — defines how the protocol is applied to the carrier world: which message carries proposals and commits, how files and transfers are handled, how the other party is identified through the SIM-based authentication RCS already used, and how two clients from different vendors negotiate an encrypted conversation. It is the first time a large-scale messaging service has achieved interoperable encryption between implementations from different companies, something neither iMessage nor WhatsApp had to solve because they controlled both ends.
The requirement stacks across four layers, which is why the rollout arrives in dribs and drabs: operating system version (iOS 26.5 on the iPhone), app version (an up-to-date Google Messages on Android) and carrier support for UP 3.0 at both ends of the conversation. If any one is missing there is no padlock: the message falls back to the TLS-only transport and the server sees it again. And three gaps remain that the standard does not close: business messages and chatbots (A2P) are not end-to-end encrypted, neither is the automatic fallback to SMS when RCS is unavailable, and a cloud backup can end up storing in the clear what was encrypted in transit.
The same engine encrypting voice
RCS is not the only place MLS has become routine. In March 2026 Discord finished migrating all of its voice and video calls to end-to-end encryption — direct messages, group calls and Go Live streams included — with its DAVE protocol, also built on MLS. The approach shows how flexible the mechanism is: a per-sender symmetric key is exported from the MLS group and ratcheted, and the frames already encoded by the codec are encrypted in the browser using the WebRTC Encoded Transform API, without touching the codec or the transport. The library is open source (libdave) and the design went through an external audit by Trail of Bits. The IETF also lists Webex, Wire and even drone swarms as users of the protocol.
There is one deeper reason not to fall asleep on this. MLS accepts new cryptographic suites without any redesign, and there are drafts to fold post-quantum key exchange into the same skeleton: the same precaution TLS and VPNs are taking, on the grounds that encrypted traffic can be recorded today and decrypted in fifteen years. In a protocol that has just landed in the default chat apps of half of humanity, that open door matters more than any throughput figure. The padlock is here; what remains open is everything that travels outside the envelope.
