O RCS ganhou criptografia de ponta a ponta. A especificação não diz até onde ela vai.

O que foi anunciado, e o que ficou de fora do anúncio

A GSMA anunciou que o RCS passa a ter criptografia de ponta a ponta usando MLS, o Messaging Layer Security padronizado no IETF. É uma mudança grande para um canal que nasceu como sucessor do SMS e que, até aqui, não tinha nada parecido. O mesmo texto do anúncio também trata de melhorias para mensagem de negócio, e as duas coisas aparecem lado a lado, no mesmo documento, sem uma linha que separe uma da outra.

O que o anúncio não faz é desenhar essa linha. Ele não diz que o tráfego A2P — o de campanha, o de notificação transacional, o código de verificação que chega quando alguém entra na conta — está dentro do escopo da criptografia. E também não diz que está fora. A entrada do IETF de abril de 2025, publicada pelo corpo que padroniza o MLS, tampouco delimita esse escopo: ela trata da adoção do protocolo, não do recorte de quais mensagens ele cobre no RCS.

Vale dizer com clareza que isso não é acusação de omissão. Especificação em fase de implantação raramente delimita tudo no texto de anúncio, e o RCS está exatamente nessa fase. Anunciar a direção antes de fechar cada borda é como padrão de telecomunicação sempre funcionou, e provavelmente é como tem de funcionar — a alternativa seria anunciar nada até que tudo estivesse pronto, e aí ninguém se prepararia.

A afirmação deste texto é outra, e é bem mais estreita: existe gente que precisa dessa resposta hoje, antes de a borda fechar, porque alguém lhe entregou uma planilha com uma célula esperando sim ou não. É sobre essa pessoa que vale a pena escrever.

O que é MLS, e por que ele entra nessa conversa

MLS é um protocolo de criptografia para mensagens em grupo, padronizado no IETF. O problema que ele resolve é específico e difícil: manter uma conversa cifrada de ponta a ponta quando o grupo muda de tamanho — gente entrando, gente saindo, aparelho novo sendo adicionado — sem que cada mudança custe uma renegociação com todo mundo. É um trabalho de anos, feito às claras, e a escolha dele pelo RCS é um sinal de seriedade, não de marketing.

O detalhe que importa aqui é o que um protocolo desse tipo define e o que ele não define. Ele define como as chaves são acordadas entre os participantes e como o estado do grupo evolui de forma segura. Ele não define, sozinho, quem é participante de qual conversa em um sistema específico. Essa é uma decisão de arquitetura de quem implementa, e é ela que responde a pergunta do questionário.

É por isso que "o RCS usa MLS" e "a sua mensagem de negócio é fim a fim" são duas afirmações diferentes, e a primeira não implica a segunda. A distância entre elas não é retórica: é o espaço exato onde a especificação anunciada ainda não colocou uma frase, e é o espaço que este texto está descrevendo em vez de preencher com palpite.

A2P não é categoria de marketing, é um caminho diferente

A2P quer dizer application-to-person: a mensagem que sai de um sistema, não de uma pessoa digitando. O código de verificação, o aviso de entrega, a confirmação de consulta. Ela nasce numa aplicação, é entregue a uma plataforma, e a plataforma a coloca no canal. Isso é a definição do termo, não uma interpretação dele — se a mensagem viesse de alguém digitando, seria P2P e a conversa seria outra.

Essa diferença de origem já é suficiente para explicar por que a pergunta é razoável. Uma conversa entre duas pessoas tem dois pontos claros, e o significado de "ponta a ponta" é intuitivo. Uma mensagem que nasce num sistema, passa por um provedor e chega a um aparelho tem mais de dois candidatos a ponta — e qual deles conta é exatamente o que uma especificação precisa dizer para a pergunta ter resposta.

O que não vamos fazer é completar a frase. Existe uma explicação circulando de que o tráfego A2P ficaria fora do escopo por causa de processamento na operadora, para filtro antifraude e retenção regulatória. Ela é plausível, ela pode estar certa, e ela vem de blog de fornecedor. Escrever isso aqui como fato seria publicar o texto de outra empresa com a nossa marca embaixo, e afirmar como estabelecido algo que nenhuma especificação publicou.

Por que uma lacuna de especificação vira problema operacional

Questionário de segurança de cliente corporativo pergunta se as mensagens são criptografadas de ponta a ponta, e espera sim ou não. Quem responde assina embaixo. A resposta vira anexo de contrato, e daí em diante ela não é mais uma opinião técnica: é uma declaração que alguém pode cobrar.

Responder que sim, apoiado no anúncio, afirma mais do que a fonte sustenta. O anúncio fala do RCS como canal; o questionário pergunta pelo tráfego daquele cliente naquele canal. São perguntas diferentes, e usar a resposta de uma para preencher a outra é o tipo de atalho que ninguém percebe até o dia em que alguém percebe.

Responder que não afirma algo que nenhuma especificação publicou, e tem o custo inverso: você entrega ao cliente uma limitação que talvez não exista, e perde a conversa por um motivo que você mesmo inventou. As duas respostas confortáveis são, hoje, indefensáveis a partir da fonte — e a única coisa que as separa é qual delas dá mais trabalho depois.

Sobra a terceira, que é a honesta: dizer o que a fonte primária diz, e dizer onde ela para. Numa auditoria, uma resposta que cita a fonte e marca o próprio limite vale mais que uma resposta redonda sem lastro, porque a primeira sobrevive a alguém abrir o link e a segunda não.

Como responder sem inventar

A resposta que a gente usa tem três partes, e nenhuma delas exige saber o que ainda não foi publicado. A primeira é o fato: o RCS adota criptografia de ponta a ponta por MLS, conforme o anúncio da GSMA. A segunda é o limite: as fontes primárias consultadas não delimitam se o tráfego A2P está no escopo dessa criptografia. A terceira é a data da consulta, porque uma ausência tem prazo de validade e quem lê precisa saber de quando ela é.

Isso costuma bastar, e quando não basta, o que a pessoa do outro lado quer não é a palavra "sim": é entender o risco. Aí a conversa muda de assunto e melhora, porque passa a ser sobre o que de fato protege aquele fluxo — quem tem acesso ao conteúdo em cada trecho, o que fica retido e por quanto tempo, o que é registrado, quem pode consultar. Essas perguntas têm resposta hoje, e são as que importam para a decisão que o cliente precisa tomar.

Há um efeito colateral que vale nomear: dizer "a especificação não responde" custa uma reunião a mais e compra confiança que dura mais que o contrato. Quem já foi pego afirmando demais sabe o preço da outra escolha, e ele não é cobrado no dia em que a afirmação é feita.

O que faria a gente reescrever esta página

Afirmar que uma fonte não diz algo parece frágil, e é o contrário: qualquer pessoa confere em dois minutos, abrindo os dois documentos. Uma ausência verificável é falsificável, e é justamente isso que a torna uma afirmação forte em vez de uma esquiva. Ela aponta para onde olhar e aceita ser derrubada.

Então fica registrado o que muda esta página: uma publicação da GSMA, ou do corpo que padroniza o MLS, que delimite o escopo do tráfego A2P na criptografia do RCS. Não é blog de fornecedor, não é declaração em conferência, não é o que um engenheiro contou a outro. É documento público, citável por qualquer um que precise responder à mesma pergunta. No dia em que sair, este texto muda, e o histórico da mudança fica visível.

Vale separar, por fim, duas conversas que costumam virar uma só. O RCS traz o Brand Agent verificado, que ataca a falsificação de remetente — o problema mais caro do SMS, e o que mais dinheiro tira de gente comum. É um avanço real e ele merece ser dito. Mas escopo de criptografia e autenticidade de remetente são assuntos diferentes, e progresso no segundo não responde a pergunta do primeiro. Tratar os dois como um só é como a confusão começa.