Apple cifra i messaggi RCS con Android, ma la protezione non è ancora universale

Per anni, su iPhone, il colore dei messaggi ha indicato anche un livello di sicurezza. Le conversazioni in blu — quelle via iMessage — viaggiano con crittografia di default tra dispositivi Apple. Quelle in verde, prima affidate agli SMS tradizionali e poi all'RCS, sono sempre state un compromesso: più compatibilità con Android, meno garanzie sulla riservatezza. Con la terza beta pubblica di iOS 26.5, Apple prova a cambiare questa equazione, introducendo la crittografia end-to-end anche per i messaggi RCS.

In termini pratici, la crittografia end-to-end — spesso abbreviata in E2EE — garantisce che il contenuto di un messaggio possa essere letto solo dai dispositivi del mittente e del destinatario. Nessun operatore telefonico, nessun server intermedio, nessun fornitore di rete può accedere al testo. È lo stesso principio che rende sicure app come WhatsApp e Signal, e che ha sempre contraddistinto iMessage rispetto agli SMS. Finora, questa protezione era assente nei messaggi RCS scambiati tra iPhone e Android.

La bolla verde diventa più sicura

L'RCS è nato per modernizzare l'esperienza degli SMS: ricevute di lettura, indicatori di digitazione, scambio di foto e video in qualità migliore, chat di gruppo più funzionali. Apple lo ha introdotto su iPhone con iOS 18, riducendo molte delle frizioni storiche nelle conversazioni tra iPhone e Android, ma lasciando aperta la questione più delicata: chiunque trasportasse il traffico poteva potenzialmente leggerne il contenuto. Con l'E2EE, almeno in linea di principio, testo e allegati diventano accessibili solo ai dispositivi coinvolti nella conversazione.

Nell'interfaccia di iOS 26.5 beta, l'opzione si trova in Impostazioni > App > Messaggi > Messaggistica RCS, con un apposito interruttore per attivare la funzione, ancora contrassegnata come "Beta". Apple ha scelto di etichettare visivamente i messaggi cifrati, così l'utente può capire in ogni momento se la protezione è attiva o meno. Non è un dettaglio secondario: in materia di sicurezza, la chiarezza dell'interfaccia conta quanto la solidità tecnica sottostante. Se chi scrive non sa in che modalità si trova, rischia di comportarsi come se fosse protetto anche quando non lo è.

La crittografia sui messaggi vale poco se l'utente non sa quando è attiva

Uno standard condiviso, non un'invenzione di Apple

La novità tecnica alla base di questa funzione non è stata inventata da Apple, ma è il frutto di un lavoro di standardizzazione internazionale. Il protocollo di riferimento si chiama MLS, uno standard pubblicato dall'IETF come RFC 9420 nel luglio 2023. In parole semplici, MLS è progettato per gestire la crittografia anche nelle chat di gruppo, aggiornando continuamente le chiavi di cifratura e limitando i danni in caso di compromissione: se un attaccante riesce a ottenere una chiave, non può risalire a tutti i messaggi precedenti né leggere quelli futuri una volta che la chiave viene rinnovata. Non è un'aggiunta cosmetica, ma un cambio di architettura.

Nel marzo 2025, la GSMA — l'organismo internazionale che coordina gli standard per la telefonia mobile — ha annunciato nuove specifiche RCS che includono la crittografia end-to-end basata su MLS, inserendola nel cosiddetto Universal Profile 3.0. La specifica punta a una crittografia interoperabile, cioè non legata a una singola app o a un singolo produttore: l'obiettivo è che un iPhone e uno smartphone Android possano scambiarsi messaggi cifrati indipendentemente dall'app usata. Apple sta dunque seguendo una strada già tracciata dall'industria, cercando di integrarla in modo coerente con la propria reputazione sulla privacy.

Vale la pena ricordare che Google aveva già percorso una parte di questo cammino in modo autonomo. Google Messages ha introdotto la crittografia end-to-end per le chat RCS uno-a-uno già nel 2021, estendendola poi ai gruppi negli anni successivi. Quella soluzione, però, funzionava solo all'interno dell'app di Google: un passo avanti per chi usava Google Messages, ma inutile per chi si trovava su un'altra piattaforma. Il risultato era una frammentazione confusa, in cui alcune conversazioni erano cifrate e altre no, spesso senza che l'utente capisse perché.

Perché non basta accendere un interruttore

La differenza rispetto al passato è che Apple non sta costruendo una soluzione proprietaria, ma sta cercando di far funzionare uno standard aperto in un ecosistema che deve allinearsi su più fronti. La crittografia end-to-end su RCS non è garantita per ogni conversazione, ma solo dove tutta la catena — operatore, dispositivi, versione del software — la supporta davvero. È una distinzione importante, perché sposta l'incertezza dall'individuale al sistemico: non dipende solo dall'app che si usa, ma da quanti attori si sono aggiornati.

Su iPhone, la disponibilità dell'RCS varia già oggi per paese e per operatore telefonico: ogni carrier deve abilitarlo e integrarlo nella propria rete. Due utenti con lo stesso iPhone e la stessa versione di iOS possono avere esperienze diverse a seconda dell'operatore o del paese in cui si trovano. L'E2EE aggiunge un ulteriore livello di dipendenza: serve che anche l'altra parte — tipicamente uno smartphone Android — supporti lo stesso standard.

C'è poi un aspetto che il marketing tende a trascurare: la crittografia end-to-end protegge il contenuto dei messaggi durante la trasmissione, ma non elimina i metadati. Chi scrive a chi, quando, con quale frequenza — queste informazioni possono restare visibili a parti dell'infrastruttura anche con E2EE attiva. E la protezione non si estende automaticamente a ciò che accade «ai bordi»: backup del telefono, notifiche sullo schermo, accesso fisico al dispositivo. Sono limiti che contano poco nella comunicazione commerciale e molto nella sicurezza reale.

La crittografia protegge il viaggio del messaggio, non tutto ciò che sta intorno

Un test che dura più di un ciclo beta

Un segnale rilevante sulla complessità di questa integrazione viene dalla storia recente della funzione stessa. La crittografia RCS era già comparsa in una versione beta di iOS 26.4, ma non era poi arrivata al rilascio stabile, ed è ricomparsa ora in iOS 26.5 beta. Questo ciclo iterativo suggerisce che la difficoltà non sia implementare il protocollo in sé, ma farlo funzionare in modo affidabile nelle combinazioni reali di reti, operatori e dispositivi Android. Più che una funzione, è un'integrazione di ecosistema. Il fatto che lo standard RCS continui a evolversi spiega anche perché i rilasci siano graduali e dipendenti dalla versione del profilo supportata da ciascun operatore.

Alcune segnalazioni indicano che l'opzione potrebbe essere attiva di default dove supportata, in linea con l'approccio Apple di rendere la sicurezza una scelta predefinita. Ma questo aumenta anche il rischio di un equivoco: se l'utente vede l'interruttore attivo e dà per scontato che ogni chat RCS sia cifrata, la differenza tra «supportato» e «non supportato» diventa una trappola. La comunicazione chiara dello stato di protezione — proprio quella che Apple sta cercando di costruire con le etichette nell'interfaccia — diventa quindi cruciale.

Cosa cambia davvero, e per chi

Se l'E2EE su RCS raggiungerà stabilità e diffusione reale, cambierà la logica con cui si sceglie come comunicare tra piattaforme diverse. Oggi il ragionamento implicito di molti utenti iPhone è: iMessage per sicurezza, RCS (o WhatsApp) per parlare con chi ha Android. Domani, quella distinzione potrebbe attenuarsi, con RCS che si avvicina alle garanzie di base di iMessage almeno sul fronte della cifratura.

Il percorso, però, dipende meno dall'annuncio di Apple e più dalla velocità con cui operatori e produttori Android adotteranno MLS e l'Universal Profile nella quotidianità. La domanda rilevante non è se la crittografia arriverà, ma quanto sarà prevedibile e trasparente per chi manda un messaggio senza pensarci — che è, in fondo, la stragrande maggioranza delle persone.