18 mei 2026 · encryption · post-quantum · product

The Lock Icon appeared. Now read the fine print.

RCS messaging just gained cross-platform end-to-end encryption between iPhone and Android. We unpack what the announcement actually means technically, and why "encrypted" still isn't enough for regulated enterprise environments.

May 2026. RCS finally delivers cross-platform end-to-end encryption between iPhone and Android. That's genuinely good news. But before adding this to your compliance checklist, it's worth understanding exactly what that lock icon promises, and what it quietly doesn't.

What just happened

After years of fragmentation, Android users had E2E encryption between themselves via Google Messages, while iPhone to Android chats fell back to unencrypted carrier infrastructure. Google and Apple have now shipped cross-platform E2E encryption for RCS, rolling out in beta.

In practice: the content of a text message between an iPhone and an Android phone is now encrypted on the sender's device and decrypted only on the recipient's. The carrier in the middle sees ciphertext. So does the platform server routing the message. That's a real and meaningful improvement over where we were.

So what's still missing?

The protocol question that wasn't answered

Google's announcement doesn't name the encryption protocol. That silence matters. Based on the GSMA's RCS E2E specification work, the implementation almost certainly builds on MLS (Messaging Layer Security, RFC 9420), the IETF standard designed for scalable encrypted group messaging.

MLS is a well-designed protocol. It provides forward secrecy, post-compromise security, and efficient key updates in large groups. The key exchange it uses, however, is X25519, elliptic curve Diffie-Hellman (ECDH). Which means: a sufficiently capable quantum computer can break it retroactively.

This is the harvest-now, decrypt-later problem. Nation-state adversaries are actively collecting encrypted traffic today with the explicit intent to decrypt it once quantum hardware matures. For a consumer text about weekend plans, that's not a credible threat. For regulated enterprise data like medical records, legal documents, or merger communications, it is. The EU's NIS2 directive and NEN 7510 are starting to reflect this. Post-quantum cryptography isn't a future concern for these environments; it's a present design requirement.

Databeamer uses hybrid key encapsulation: X25519 + ML-KEM-768 (NIST FIPS 203). The hybrid design means you get the security of classical crypto and post-quantum hardness simultaneously, so even if your threat model doesn't include quantum adversaries yet, you don't pay anything to be safe against them.

What the lock icon doesn't protect

End-to-end encryption secures content. It says nothing about metadata, and metadata is often the most valuable intelligence.

When you send an RCS message, Google and Apple still see:

  • Who you're talking to
  • When, and how frequently
  • Message size (a rough proxy for content type)
  • Your location via IP address

This isn't hypothetical exposure. The Salt Typhoon breach in late 2024 showed exactly how carrier and platform-level metadata can be weaponized even when message content is locked. For regulated industries under GDPR or NEN 7510, metadata about who communicates with whom about what kind of matter is often itself sensitive personal data.

A zero-knowledge design, where the server cannot construct a communication graph even in principle, requires architectural decisions that RCS, as a carrier-anchored protocol, structurally cannot make.

The key custody question

Where does your private key live? On an iPhone, it's tied to your Apple ID and backed up to iCloud. On Android, to your Google account. Both platforms offer hardware-backed key storage when the device supports it, but the backup path is a policy decision controlled by the platform, not by you.

In enterprise contexts, this matters acutely: who holds the key when an employee leaves? What happens in a legal hold? RCS has no answer to these questions because it wasn't designed for them.

Databeamer's key model is explicit: your master key is never stored. It's reconstructed from a 2-of-3 Pedersen VSS split across device, server, and mnemonic shares, so recovery is always possible but the key itself never exists at rest anywhere. The server holds a share, not the key.

What this means for enterprise

For personal use, cross-platform RCS encryption is a genuine step forward. Use it. It's better than SMS by a large margin.

For enterprise collaboration in regulated environments, whether file transfer, data requests, legal communications, or anything touching PII or PHI, the threat model is fundamentally different:

  • Content and metadata must be protected
  • Quantum-harvest attacks are in scope
  • Key custody must be auditable and controlled
  • Communication must generate verifiable, tamper-evident audit trails

These aren't compliance theater. They're the actual attack surface for the adversaries that EU enterprises in healthcare, legal, and finance face today.

The lock icon is a start. But a lock on the front door doesn't secure the rest of the house.

Databeamer is designed from the ground up for organizations where "encrypted" isn't enough, where zero-knowledge, post-quantum safety, and compliance-grade audit trails are load-bearing requirements, not features.