RCS Just Got End‑to‑End Encryption on iPhone—So Why Can Your Carrier Still Rebuild Your ‘Private’ Chats From Metadata?
E2EE locks the message body, not the envelope. Even with encrypted RCS, routing metadata can reveal relationships, routines, and “shadow chat” timelines—at scale.
By TheMurrow Editorial
April 3, 2026
Key Points
- 1Understand the limit: RCS E2EE on iPhone can protect message content, but the metadata “envelope” still exists for delivery.
- 2Expect uneven rollout: encryption may depend on iOS version, carrier deployment, and whether the other person’s RCS client supports the same standard.
- 3Assume inference risk: carriers can’t decrypt plaintext, but metadata can still map relationships, routines, group changes, and conversation intensity over time.
When Apple added RCS support to the iPhone in iOS 18 (released September 2024), millions of people got a better version of “green bubble” texting overnight: typing indicators, read receipts, sharper photos, and group chats that don’t crumble into MMS chaos. It felt, to many users, like a peace treaty.
Then came the more loaded claim: RCS is getting end-to-end encryption on iPhone. The phrase lands like a guarantee. If messages are encrypted end-to-end, the thinking goes, nobody in the middle—not Apple, not Google, not your carrier—can see anything.
That’s the part that needs correction. End-to-end encryption (E2EE) protects message content. It does not erase the message “envelope.” The envelope—who messaged whom, when, how often, and roughly how much data moved—still has to exist for a network to function. And the envelope, at scale, can tell a story that feels uncomfortably close to the conversation itself.
“End-to-end encryption hides the words. It doesn’t hide the relationship.”
— — TheMurrow Editorial
What follows is a clear-eyed guide to what “RCS end-to-end encryption on iPhone” actually means, what it doesn’t, and why “your carrier can still rebuild your chats” is both wrong in the literal sense—and disturbingly plausible in the practical one.
What “RCS E2EE on iPhone” actually means—and what it doesn’t
RCS—Rich Communication Services—is the carrier industry’s intended successor to SMS/MMS. The point is simple: keep phone-number messaging relevant in a world dominated by apps. Apple’s adoption of RCS in iOS 18 (September 2024) finally made iPhone↔Android messaging feel modern in ways users immediately notice: richer media, more reliable group chats, and the familiar “typing…” feedback loop.
The missing piece: standardized encryption across platforms
Historically, RCS encryption has been fragmented. Google, for example, implemented end-to-end encryption in Google Messages years ago, but that experience didn’t automatically translate into a universal, interoperable standard for every RCS client and carrier. Ars Technica captured the practical reality in its coverage of Google’s approach: encryption was real, but bounded by client support and implementation details—not a global switch flipped for every RCS message.
The shift now underway is standards-based. The GSMA—the industry group behind RCS profiles—published a formal E2EE specification: RCC.16 “RCS – End-to-End Encryption Specification.” It builds on Messaging Layer Security (MLS), an IETF protocol designed specifically for secure group messaging at scale. MLS is standardized as RFC 9420, published July 2023.
The shift now underway is standards-based. The GSMA—the industry group behind RCS profiles—published a formal E2EE specification: RCC.16 “RCS – End-to-End Encryption Specification.” It builds on Messaging Layer Security (MLS), an IETF protocol designed specifically for secure group messaging at scale. MLS is standardized as RFC 9420, published July 2023.
September 2024
Apple added RCS support to iPhone in iOS 18—modernizing iPhone↔Android texting with read receipts, typing indicators, and better media.
RFC 9420
Messaging Layer Security (MLS) was standardized by the IETF for secure group messaging at scale; published July 2023.
What Apple has said—and what “available” can mean
Apple has publicly signaled support for standardized RCS E2EE in a future software update, and reporting has suggested it has appeared in certain iOS betas, with carrier-dependent realities. That distinction matters. “Supports the standard” is not the same as “every RCS conversation on every iPhone is encrypted today.”
Practical takeaway for readers: treat RCS E2EE on iPhone as an implementation milestone, not a blanket guarantee. Whether encryption is active can depend on software version, carrier deployment, and whether the party on the other end is using a compatible RCS client.
Practical takeaway for readers: treat RCS E2EE on iPhone as an implementation milestone, not a blanket guarantee. Whether encryption is active can depend on software version, carrier deployment, and whether the party on the other end is using a compatible RCS client.
“Encryption ‘support’ isn’t a promise. It’s a dependency chain.”
— — TheMurrow Editorial
Encryption protects content. Networks still run on metadata.
Most confusion around encrypted messaging comes from a single category error: mixing up content with metadata.
The content is the chat. The metadata is the system that delivers it.
- Content: message text, images, videos, voice notes, and the payload users think of as “the conversation.”
- Metadata (the “envelope”): information needed to deliver and manage communications—sender and recipient identifiers (often phone numbers), timestamps, routing and delivery events, message size characteristics, and sometimes device or session events.
Even proponents of encrypted RCS acknowledge this split. Ars Technica’s reporting on RCS encryption summarized a widely cited practical reality: even when the content is end-to-end encrypted, third parties may still see metadata like the phone numbers involved, time sent/received, and approximate message size.
- Metadata (the “envelope”): information needed to deliver and manage communications—sender and recipient identifiers (often phone numbers), timestamps, routing and delivery events, message size characteristics, and sometimes device or session events.
Even proponents of encrypted RCS acknowledge this split. Ars Technica’s reporting on RCS encryption summarized a widely cited practical reality: even when the content is end-to-end encrypted, third parties may still see metadata like the phone numbers involved, time sent/received, and approximate message size.
Why metadata is so revealing
A single timestamp is banal. A month of timestamps is a behavioral fingerprint. At scale, metadata can reveal:
- Social graphs (who talks to whom, and how often)
- Routines (morning check-ins, nightly calls, travel-related shifts)
- Event-driven spikes (a medical emergency, a job interview, a relationship break)
None of that requires reading a single word. It requires only consistent logging of who connected to what, and when.
Practical takeaway: E2EE is still worth wanting—it prevents intermediaries from reading your message content. But E2EE does not mean “no one can tell anything about my communications.”
- Social graphs (who talks to whom, and how often)
- Routines (morning check-ins, nightly calls, travel-related shifts)
- Event-driven spikes (a medical emergency, a job interview, a relationship break)
None of that requires reading a single word. It requires only consistent logging of who connected to what, and when.
Practical takeaway: E2EE is still worth wanting—it prevents intermediaries from reading your message content. But E2EE does not mean “no one can tell anything about my communications.”
Key Insight
End-to-end encryption (E2EE) protects content, not metadata. The “envelope” still exists—and at scale it can reveal relationships, routines, and behavioral patterns.
The standard behind RCS E2EE: MLS—and why it matters
The GSMA’s RCS E2EE spec is notable not just because it exists, but because of what it chose to build on: Messaging Layer Security (MLS).
MLS, briefly, without the hype
MLS (IETF RFC 9420, July 2023) was designed for secure group messaging—where people join, leave, add devices, and rotate keys without collapsing security or usability. Technical readers will recognize why MLS is attractive: group messaging is exactly where older “pairwise” encryption models get unwieldy.
MLS is engineered to provide properties like:
- Forward secrecy (past messages remain protected even if a current key is compromised)
- Post-compromise security (a system can recover security after a compromise via key updates)
Those goals are the difference between “encrypted” as a label and encryption as a sustained guarantee under real-world conditions.
MLS is engineered to provide properties like:
- Forward secrecy (past messages remain protected even if a current key is compromised)
- Post-compromise security (a system can recover security after a compromise via key updates)
Those goals are the difference between “encrypted” as a label and encryption as a sustained guarantee under real-world conditions.
Standards also create… standards-compliant signals
The GSMA’s RCC.16 document doesn’t just define ciphers. It defines how encrypted messages are packaged and how clients coordinate. It includes details such as CPIM headers and an “Epoch-Authenticator” used in messages carrying encrypted content.
Readers don’t need to memorize those terms. The point is more human: even when payloads are encrypted, the system still produces observable events. Group joins, leaves, retries, key updates, and device enrollments can all generate signaling that a service must process—and that intermediaries can often log.
Readers don’t need to memorize those terms. The point is more human: even when payloads are encrypted, the system still produces observable events. Group joins, leaves, retries, key updates, and device enrollments can all generate signaling that a service must process—and that intermediaries can often log.
“Modern encryption doesn’t eliminate signals. It reorganizes them.”
— — TheMurrow Editorial
Practical takeaway: standardized encryption is a meaningful upgrade, but it doesn’t turn messaging into a featureless black box. It turns messaging into a black box with a visible delivery apparatus.
RCC.16
GSMA’s formal “RCS – End-to-End Encryption Specification,” built on MLS to push interoperable encryption across RCS implementations.
“Your carrier can rebuild your chats”: what that claim gets wrong—and what it gets right
The sensational version of the claim—carriers can rebuild your chat from encrypted RCS—is generally wrong if E2EE is correctly implemented and keys aren’t compromised. Metadata alone should not allow a carrier to recover plaintext content.
But the calmer version is true, and it’s the one that matters: carriers can often rebuild a functional shadow of your chats.
But the calmer version is true, and it’s the one that matters: carriers can often rebuild a functional shadow of your chats.
What “rebuild” can mean in practice
From metadata, an intermediary may be able to infer:
- Conversation timelines: when messages were exchanged, how rapidly, in what clusters
- Conversation structure: whether a thread is one-to-one or a group, and changes over time
- Engagement intensity: frequency and volume patterns (including approximate size changes)
- Relationship mapping: durable contact pairs and groups across weeks and months
This shadow can be enough to answer questions many people assume are “private”: Who do you speak to most? When did a relationship start? Who is in your closest circle? What nights were you awake and communicating? Which days were chaotic?
### A real-world way to think about it
Imagine two scenarios:
1. You can’t read a couple’s texts, but you see that two phone numbers exchanged messages every morning at 7:05, every night after 11, and then stopped abruptly for three days—followed by a burst of longer messages.
2. You can’t read a team’s group chat, but you see a group thread surge at 2 a.m., then add a new number the next day, then spike again right before a major deadline.
No content is required to infer context. The “shadow chat” won’t quote anyone, but it can still describe their lives.
Practical takeaway: E2EE prevents content inspection. It does not prevent behavioral inference. If your threat model includes behavioral surveillance, encryption is necessary but insufficient.
- Conversation timelines: when messages were exchanged, how rapidly, in what clusters
- Conversation structure: whether a thread is one-to-one or a group, and changes over time
- Engagement intensity: frequency and volume patterns (including approximate size changes)
- Relationship mapping: durable contact pairs and groups across weeks and months
This shadow can be enough to answer questions many people assume are “private”: Who do you speak to most? When did a relationship start? Who is in your closest circle? What nights were you awake and communicating? Which days were chaotic?
### A real-world way to think about it
Imagine two scenarios:
1. You can’t read a couple’s texts, but you see that two phone numbers exchanged messages every morning at 7:05, every night after 11, and then stopped abruptly for three days—followed by a burst of longer messages.
2. You can’t read a team’s group chat, but you see a group thread surge at 2 a.m., then add a new number the next day, then spike again right before a major deadline.
No content is required to infer context. The “shadow chat” won’t quote anyone, but it can still describe their lives.
Practical takeaway: E2EE prevents content inspection. It does not prevent behavioral inference. If your threat model includes behavioral surveillance, encryption is necessary but insufficient.
Key Insight
“Rebuild” usually doesn’t mean decrypting plaintext. It means inferring timelines, groups, intensity, and relationships from routing metadata over time.
7:05 / 11 p.m.
Repeated timestamps alone can reveal routines and relationship rhythms—without exposing a single word of message content.
Why carriers still see what they see: routing, operations, and the envelope
Carriers are not optional bystanders in phone-number messaging. RCS is, by design, a carrier-anchored ecosystem. Even when encryption is end-to-end, delivery still requires coordination.
Routing requires identifiers and timing
To deliver a message, a network generally needs to know at least:
- Who is sending and who is receiving (often phone numbers or identifiers tied to them)
- When events happen (submission, delivery attempt, success/failure)
- Where to route (serving infrastructure and path selection)
- How much data is being handled (for reliability, throttling, and diagnostics)
Ars Technica’s summary of what remains visible under RCS E2EE—numbers, timestamps, approximate size—maps neatly onto this operational reality. Networks that can’t see any envelope data can’t route, can’t troubleshoot, and can’t bill or manage abuse. That’s not a moral defense; it’s a systems fact.
- Who is sending and who is receiving (often phone numbers or identifiers tied to them)
- When events happen (submission, delivery attempt, success/failure)
- Where to route (serving infrastructure and path selection)
- How much data is being handled (for reliability, throttling, and diagnostics)
Ars Technica’s summary of what remains visible under RCS E2EE—numbers, timestamps, approximate size—maps neatly onto this operational reality. Networks that can’t see any envelope data can’t route, can’t troubleshoot, and can’t bill or manage abuse. That’s not a moral defense; it’s a systems fact.
“But Apple/Google won’t log it” isn’t the point
Some readers will reasonably ask: if the envelope exists, does it have to be retained? Policies vary. Retention can be limited. Access can be controlled. Regulators can require or constrain practices in different jurisdictions.
But the envelope’s existence is a separate issue from the envelope’s retention. Even if a carrier promises minimal logging, the mere fact that metadata is generated and processed means it can be logged, requested, leaked, or abused under the wrong conditions.
Practical takeaway: when evaluating privacy, ask two questions:
1. What must be visible for the system to work?
2. Who can record what’s visible, and for how long?
But the envelope’s existence is a separate issue from the envelope’s retention. Even if a carrier promises minimal logging, the mere fact that metadata is generated and processed means it can be logged, requested, leaked, or abused under the wrong conditions.
Practical takeaway: when evaluating privacy, ask two questions:
1. What must be visible for the system to work?
2. Who can record what’s visible, and for how long?
A smarter privacy check
- ✓What must be visible for the system to work?
- ✓Who can record what’s visible, and for how long?
The iPhone-to-Android reality: better messaging, uneven guarantees
Apple’s RCS move in iOS 18 fixed a decade of cross-platform friction. It didn’t magically unify security policies across the mobile industry.
Cross-platform encryption depends on interoperability
For E2EE to work end-to-end, both ends must:
- Support the same encryption standard (here, GSMA’s MLS-based approach)
- Implement it correctly
- Participate in the necessary key management and group membership flows
That’s why early reports of “it’s live” can be misleading. Even if Apple enables the feature in software, carriers and counterpart clients must align. Rollouts can be staged, regional, or limited to certain provider configurations.
- Support the same encryption standard (here, GSMA’s MLS-based approach)
- Implement it correctly
- Participate in the necessary key management and group membership flows
That’s why early reports of “it’s live” can be misleading. Even if Apple enables the feature in software, carriers and counterpart clients must align. Rollouts can be staged, regional, or limited to certain provider configurations.
Multiple perspectives: usability vs. maximal privacy
- The pro-standards view: adopting MLS through a GSMA spec is serious engineering. It’s the path toward interoperable, modern encryption rather than siloed implementations.
- The privacy maximalist view: phone-number messaging is structurally metadata-rich. Even with MLS, you’re still relying on telecom plumbing that has always been legible to intermediaries.
Both perspectives can be true at once. Standards-based E2EE is a win. It also doesn’t turn RCS into Signal.
Practical takeaway: if you need the strongest privacy properties, choose a service designed to minimize metadata in addition to encrypting content. If you want the best default experience for phone-number messaging, RCS improvements matter—and encryption progress is still progress.
- The privacy maximalist view: phone-number messaging is structurally metadata-rich. Even with MLS, you’re still relying on telecom plumbing that has always been legible to intermediaries.
Both perspectives can be true at once. Standards-based E2EE is a win. It also doesn’t turn RCS into Signal.
Practical takeaway: if you need the strongest privacy properties, choose a service designed to minimize metadata in addition to encrypting content. If you want the best default experience for phone-number messaging, RCS improvements matter—and encryption progress is still progress.
RCS with E2EE vs. privacy-maximalist messengers
Before
- Better default phone-number messaging
- richer media
- interoperability goals
After
- Stronger privacy properties
- more metadata minimization
- often less carrier dependence
What readers should do now: practical checks and smarter expectations
You don’t need to become a cryptographer to make good decisions about RCS privacy. You need a clearer checklist.
Set the right expectation: what E2EE will and won’t do
E2EE will help protect you against:
- Intermediaries reading message content
- Passive network inspection of the payload
E2EE will not automatically protect you against:
- Metadata-based inference (relationships, schedules, intensity)
- Compelled disclosure of logs that intermediaries retain
- Device compromise (if your phone is taken over, encryption is moot)
- Intermediaries reading message content
- Passive network inspection of the payload
E2EE will not automatically protect you against:
- Metadata-based inference (relationships, schedules, intensity)
- Compelled disclosure of logs that intermediaries retain
- Device compromise (if your phone is taken over, encryption is moot)
A case-study mindset for your own risk
Consider two everyday examples:
Example 1: Journalists and sensitive sources
Even if content is encrypted, a pattern of calls or messages between a reporter and a source number—especially at telling times—can be revealing. E2EE helps, but metadata can still create risk.
Example 2: Family group chats
Most people don’t need to fear metadata analysis of their dinner plans. For them, E2EE’s key benefit is limiting content exposure through intermediaries and reducing the risk of mass interception.
Practical takeaway: match the tool to the risk. RCS with standardized E2EE is a meaningful improvement for mainstream use. For high-stakes contexts, consider additional protections that address metadata and device security, not just message content.
Example 1: Journalists and sensitive sources
Even if content is encrypted, a pattern of calls or messages between a reporter and a source number—especially at telling times—can be revealing. E2EE helps, but metadata can still create risk.
Example 2: Family group chats
Most people don’t need to fear metadata analysis of their dinner plans. For them, E2EE’s key benefit is limiting content exposure through intermediaries and reducing the risk of mass interception.
Practical takeaway: match the tool to the risk. RCS with standardized E2EE is a meaningful improvement for mainstream use. For high-stakes contexts, consider additional protections that address metadata and device security, not just message content.
Quick expectation reset
- ✓E2EE helps protect message content from intermediaries.
- ✓E2EE does not automatically block metadata-based inference.
- ✓Logging/retention, legal demands, and device compromise can still defeat “privacy.”
Conclusion: encryption is not invisibility—and that’s the honest promise
RCS arriving on iPhone with iOS 18 (September 2024) improved day-to-day communication for an enormous number of people. The push toward a standardized, interoperable encryption model—via the GSMA’s MLS-based RCC.16 specification and MLS in RFC 9420 (July 2023)—is the kind of unglamorous progress that actually matters.
But the phrase “end-to-end encrypted” has become a cultural shorthand for “private.” Networks don’t work that way. Even in an encryption-enabled RCS world, the system still needs an envelope: identifiers, timestamps, message-size characteristics, and operational events that keep delivery functioning.
So can your carrier “rebuild your chats”? Not in plaintext, if encryption is properly implemented and keys remain secure. Yet carriers—and other intermediaries with visibility into transport and service events—can often rebuild something else: a shadow transcript of relationships and rhythms.
The adult way to read encryption claims is neither cynical nor credulous. Celebrate what encryption protects. Stay realistic about what it can’t. Privacy is not a single feature; it’s a chain of design choices, standards, implementations, and policies—and the chain still includes the envelope.
But the phrase “end-to-end encrypted” has become a cultural shorthand for “private.” Networks don’t work that way. Even in an encryption-enabled RCS world, the system still needs an envelope: identifiers, timestamps, message-size characteristics, and operational events that keep delivery functioning.
So can your carrier “rebuild your chats”? Not in plaintext, if encryption is properly implemented and keys remain secure. Yet carriers—and other intermediaries with visibility into transport and service events—can often rebuild something else: a shadow transcript of relationships and rhythms.
The adult way to read encryption claims is neither cynical nor credulous. Celebrate what encryption protects. Stay realistic about what it can’t. Privacy is not a single feature; it’s a chain of design choices, standards, implementations, and policies—and the chain still includes the envelope.
“Celebrate what encryption protects. Stay realistic about what it can’t.”
— — TheMurrow Editorial
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering technology.
Frequently Asked Questions
Is RCS available on iPhone now?
Yes. Apple added RCS support to iPhone in iOS 18, released September 2024. It improves cross-platform texting with features like read receipts, typing indicators, better group messaging, and higher-quality media compared with SMS/MMS. Availability can still vary depending on carrier support for RCS features.
Does RCS on iPhone automatically mean my messages are end-to-end encrypted?
Not automatically. The industry has a GSMA specification for RCS E2EE using IETF Messaging Layer Security (MLS), and Apple has signaled support for standardized RCS E2EE in a future update. Whether encryption is active can be dependent on software version, carrier implementation, and the other person’s RCS client compatibility.
If RCS is end-to-end encrypted, what can my carrier still see?
Even with E2EE, carriers and intermediaries may still see metadata needed for routing and operations—often including phone numbers/identifiers, timestamps (sent/received), and approximate message size characteristics. Encryption primarily protects message content, not the envelope.
Can my carrier read my encrypted RCS messages?
If end-to-end encryption is correctly implemented and encryption keys aren’t compromised, carriers should not be able to read the plaintext content of encrypted messages. The bigger remaining exposure is metadata: who communicated with whom, when, and how frequently.
What is MLS, and why is it being used for RCS encryption?
Messaging Layer Security (MLS) is an IETF-standard protocol for secure group messaging, published as RFC 9420 in July 2023. It’s designed for real-world group chat needs like membership changes and key updates. The GSMA’s RCS E2EE spec builds on MLS to standardize encryption across implementations.
Does end-to-end encryption eliminate all tracking or surveillance risk?
No. E2EE reduces the risk of content interception by intermediaries, but it doesn’t eliminate risks from metadata, logging/retention policies, legal demands, or device compromise.
