RCS got end-to-end encryption. The spec doesn't say how far it reaches.

What was announced, and what the announcement left out

The GSMA announced that RCS is gaining end-to-end encryption using MLS, the Messaging Layer Security standard from the IETF. That is a substantial change for a channel that started life as the successor to SMS and has had nothing of the kind until now. The same announcement text also covers improvements to business messaging, and the two subjects sit side by side, in one document, with no line drawn between them.

What the announcement doesn't do is draw that line. It doesn't say that A2P traffic — campaigns, transactional notifications, the verification code that lands when someone signs in — falls inside the encryption scope. It doesn't say it falls outside either. The IETF post from April 2025, published by the body that standardises MLS, doesn't delimit that scope: it covers the adoption of the protocol, not which messages it wraps inside RCS.

It is worth saying plainly that none of this is an accusation of omission. A specification mid-rollout rarely settles every boundary in its announcement text, and RCS is exactly mid-rollout. Announcing direction before closing every edge is how telecoms standards have always worked, and probably how they have to work — the alternative is announcing nothing until everything is final, and then nobody can prepare.

The claim in this piece is narrower than that. There are people who need the answer today, before the edge closes, because somebody handed them a spreadsheet with a cell waiting for yes or no. That person is who this is written for.

What MLS is, and why it enters this conversation

MLS is an encryption protocol for group messaging, standardised at the IETF. The problem it solves is specific and hard: keeping a conversation end-to-end encrypted while the group changes size — people joining, people leaving, a new device being added — without every change costing a renegotiation with everyone. It is years of work done in the open, and RCS choosing it is a signal of seriousness rather than marketing.

The detail that matters here is what a protocol like that defines and what it doesn't. It defines how keys are agreed between participants and how group state evolves safely. It does not, on its own, define who counts as a participant in which conversation inside a specific system. That is an architecture decision made by whoever implements it, and it is the decision that answers the questionnaire's question.

This is why "RCS uses MLS" and "your business message is end-to-end encrypted" are two different statements, and the first does not imply the second. The distance between them isn't rhetorical: it is exactly the space where the announced specification has yet to place a sentence, and it is the space this piece describes instead of filling in with a guess.

A2P isn't a marketing category, it's a different path

A2P means application-to-person: the message that leaves a system rather than a person typing. The verification code, the delivery notice, the appointment confirmation. It originates in an application, is handed to a platform, and the platform puts it on the channel. That is the definition of the term, not an interpretation of it — if a person were typing, it would be P2P and this would be a different conversation.

That difference in origin is already enough to explain why the question is reasonable. A conversation between two people has two obvious ends, and "end-to-end" is intuitive. A message that originates in a system, passes through a provider and arrives at a handset has more than two candidates for an end — and which of them counts is precisely what a specification has to state for the question to have an answer.

What we are not going to do is finish the sentence. There is an explanation circulating that A2P traffic would fall outside the scope because of carrier-side processing for anti-fraud filtering and regulatory retention. It is plausible, it may well be correct, and it comes from vendor blogs. Writing it here as fact would be publishing another company's text under our name, and asserting as settled something no specification has published.

Why a gap in a spec becomes an operational problem

Enterprise security questionnaires ask whether messages are end-to-end encrypted, and they expect yes or no. Whoever answers signs their name to it. The answer becomes a contract annex, and from that point on it stops being a technical opinion: it is a declaration somebody can hold you to.

Answering yes on the strength of the announcement claims more than the source supports. The announcement is about RCS as a channel; the questionnaire asks about that customer's traffic on that channel. Those are different questions, and using the answer to one to fill in the other is the kind of shortcut nobody notices until the day somebody does.

Answering no asserts something no specification has published, and carries the inverse cost: you hand the customer a limitation that may not exist, and lose the conversation for a reason you invented yourself. Both comfortable answers are, today, indefensible from the source — and the only thing separating them is which one causes more trouble later.

That leaves the third one, which is the honest one: say what the primary source says, and say where it stops. In an audit, an answer that cites its source and marks its own limit is worth more than a tidy answer with nothing behind it, because the first survives someone opening the link and the second does not.

How to answer without inventing

The answer we use has three parts, and none of them requires knowing what hasn't been published. The first is the fact: RCS adopts end-to-end encryption over MLS, per the GSMA announcement. The second is the limit: the primary sources consulted do not delimit whether A2P traffic falls within the scope of that encryption. The third is the date of the check, because an absence has a shelf life and the reader needs to know how old it is.

That is usually enough, and when it isn't, what the person on the other side wants is not the word "yes": it is to understand the risk. At that point the conversation changes subject and improves, because it becomes about what actually protects that flow — who has access to content on each leg, what is retained and for how long, what is logged, who can query it. Those questions have answers today, and they are the ones that matter to the decision the customer has to make.

There is a side effect worth naming: saying "the specification doesn't answer this" costs one extra meeting and buys trust that outlasts the contract. Anyone who has been caught over-claiming knows the price of the other choice, and it isn't charged on the day the claim is made.

What would make us rewrite this page

Claiming that a source doesn't say something sounds weak, and it is the opposite: anyone can confirm it in two minutes by opening both documents. A verifiable absence is falsifiable, and that is exactly what makes it a strong claim rather than a dodge. It points at where to look and it accepts being knocked down.

So here is what changes this page, on the record: a publication from the GSMA, or from the body that standardises MLS, delimiting the scope of A2P traffic within RCS encryption. Not a vendor blog, not a conference remark, not what one engineer told another. A public document, citable by anyone who has to answer the same question. The day it appears, this text changes, and the change stays visible.

Finally, it is worth separating two conversations that tend to collapse into one. RCS brings the verified Brand Agent, which attacks sender impersonation — the most expensive problem in SMS, and the one that takes the most money from ordinary people. That is real progress and it deserves saying. But encryption scope and sender authenticity are different subjects, and progress on the second does not answer the question about the first. Treating them as one is how the confusion starts.