For years, the divide between iPhone and Android users was defined by a simple, frustrating visual: the green bubble. While iMessage users enjoyed high-resolution media and read receipts, those texting across platforms were relegated to the aging architecture of SMS. The arrival of RCS (Rich Communication Services) in iOS 18 was supposed to be the Great Unification, bringing modern messaging features to every chat, regardless of the operating system.
However, for users in the Low Countries, the rollout has revealed a surprising security gap. While RCS has technically arrived, the most critical feature—end-to-end encryption (E2EE)—is not being distributed equally. Recent findings indicate that while Belgian mobile providers have enabled encryption for RCS messages on iOS, their Dutch counterparts have not, leaving a significant number of users with “modern” messages that lack modern privacy protections.
As a former software engineer, I find this particular discrepancy telling. It highlights a recurring theme in the tech world: a feature is only as functional as the weakest link in its deployment chain. In this case, the link isn’t Apple’s software or Google’s protocol, but the carrier configurations sitting in the middle.
The Encryption Gap in the Low Countries
The discrepancy first gained traction via reports from Tweakers, noting that iPhone users on Belgian networks are seeing the security indicators that signify their RCS chats are encrypted. In contrast, Dutch users on major networks are finding that while they have the “bells and whistles” of RCS—such as typing indicators and high-quality photo sharing—the actual content of their messages remains unencrypted.
In other words that for a Dutch iPhone user texting an Android user via RCS, the messages are essentially traveling in a way that could, theoretically, be intercepted or viewed by the carrier. Here’s a stark contrast to iMessage or WhatsApp, where the encryption keys are held only by the sender and receiver.
The frustration for users is compounded by the lack of transparency. For many, the “RCS” label in the text field is interpreted as a wholesale upgrade in quality and security. In reality, the security layer is an optional addition to the RCS Universal Profile, and its presence depends entirely on whether the carrier has implemented the necessary backend support.
Why Your Carrier Holds the Key
To understand why a user in Brussels has a more secure experience than a user in Amsterdam, we have to look at the architecture of RCS. Unlike iMessage, which is a proprietary Apple service, RCS is a standard. Apple has adopted the “Universal Profile,” a baseline set of rules that ensures an iPhone can talk to a Samsung or a Pixel without a hitch.
The problem is that the original Universal Profile did not mandate end-to-end encryption. Google eventually developed its own encryption layer for RCS (used in Google Messages), but for that to work seamlessly across different devices and carriers, there must be a coordinated effort between the OS vendor and the network operator.
When a carrier supports the encrypted version of the protocol, the “handshake” between the two devices establishes a secure tunnel. If the carrier is only supporting the baseline Universal Profile, the message is delivered as “plain text” (relatively speaking) across the network. The Belgian providers have effectively flipped the switch on this advanced security layer. the Dutch providers have not.
RCS Feature Breakdown: Baseline vs. Encrypted
| Feature | Standard RCS (Dutch Carriers) | Encrypted RCS (Belgian Carriers) |
|---|---|---|
| High-Res Media | Supported | Supported |
| Typing Indicators | Supported | Supported |
| Read Receipts | Supported | Supported |
| End-to-End Encryption | Not Supported | Supported |
The Privacy Stakes of the ‘Green Bubble’ Transition
For the average user, the lack of encryption might seem like a technicality. However, from a cybersecurity perspective, it is a meaningful vulnerability. Without E2EE, the carrier acts as a “man-in-the-middle.” While it is unlikely that a carrier is actively reading every text, the absence of encryption means the data is susceptible to subpoenas, government surveillance, or internal data breaches.
This creates a tiered privacy system. Users who stick to third-party apps like Signal or WhatsApp remain protected, but those attempting to use the native “Messages” app for cross-platform convenience are inadvertently trading privacy for a better user interface. For professional users or those discussing sensitive information, this gap is more than a nuance—it is a risk.
The Path Toward a Unified Standard
The current situation is a transitional phase. Apple’s decision to support RCS was largely driven by regulatory pressure, particularly from the European Union, to ensure interoperability. However, interoperability is not the same as security. The goal is a world where the “Universal Profile” is updated to include mandatory encryption, removing the carrier’s role as the gatekeeper of privacy.
Until that happens, the experience remains fragmented. The fact that Belgian carriers have already implemented this suggests that the technical hurdles are low and the capability exists within the current infrastructure. The delay in the Netherlands is likely a matter of configuration, priority, or negotiations between the carriers and the protocol providers.
For now, users in the Netherlands who prioritize security should continue to use encrypted third-party messaging apps for sensitive conversations. The “green bubble” may be more functional than it used to be, but it isn’t yet a fortress.
The next major checkpoint will be the subsequent point-releases of iOS 18 and corresponding carrier settings updates. Industry analysts are watching for a broader push from the GSMA (the global organization representing mobile operators) to standardize E2EE across all RCS implementations to prevent this kind of regional security lottery.
Do you notice a difference in your messaging security? Let us know in the comments or share this story with your fellow iPhone and Android users.
