Secure Communication: The Encrypted Messaging Guide

What "encrypted" is actually claiming

When a vendor says a product is encrypted, one of four very different things is true. The first is transport encryption: traffic between the client and the server runs over TLS, so someone on the same Wi-Fi cannot read it. Almost every service from the last fifteen years has this, including ones with no security posture at all, because TLS is table stakes and free. The second is encryption at rest: the provider's disks and backups are encrypted, which protects against a stolen drive or a careless storage bucket. Both of these are real controls against specific threats, and neither prevents the provider from reading your messages, because the provider's server is the endpoint that decrypts.

The third claim is end-to-end encryption, where the keys exist only on the participating devices and the server relays ciphertext it cannot open. This is the only one of the four that changes the answer to "what happens if the provider is compelled, breached, or simply decides to look". The fourth claim, which vendors rarely make explicitly but often imply, is that the channel is safe: that the person you are talking to is who the interface says, that no one has inserted themselves in the middle, that the device on the other end is not compromised, and that the history is not sitting decrypted in a backup somewhere. Encryption does not deliver any of that on its own.

Put the same message through the hops it actually takes - your device, the network, the provider's infrastructure, a push notification service, the recipient's device - and ask at each hop whether the bytes are readable by someone other than the two of you. In a properly implemented end-to-end system the answer at every intermediate hop is no. In a system that encrypts in transit and at rest, the answer at the provider's hop is yes, and one subpoena, one insider, one misconfigured backup export or one breach of that hop exposes the entire history. Microsoft Teams, for example, encrypts data in transit and at rest and offers end-to-end encryption only for one-to-one calls, which is a defensible design for a collaboration product whose whole purpose is organisational search and retention - and it is not the same product as Signal, whatever the comparison table says.

The five properties that decide whether a channel is safe

Cryptographers do not evaluate a messenger by asking whether it is encrypted. They ask which properties the protocol provides, because the properties determine which attacks fail. Five matter for anyone choosing a channel or writing a procurement requirement.

Confidentiality is the obvious one: an eavesdropper with the full transcript cannot recover the plaintext. Integrity and authentication is the one users never think about and attackers exploit constantly: each message is bound to a key, so a message cannot be altered in flight and a participant cannot be impersonated without detection. Without authentication, confidentiality is theatre - a man in the middle who can substitute keys can read and rewrite everything while both parties see a reassuring padlock.

Forward secrecy means that compromise of a long-term key does not decrypt past traffic, because each message or session was protected by an ephemeral key that has already been destroyed. This is why seizing a phone today does not necessarily expose a conversation from last year, and why a provider compelled to surrender its long-term secrets cannot reconstruct old sessions. Post-compromise security, sometimes called future secrecy or healing, is the mirror image: after an attacker obtains a session key, the protocol recovers to a state the attacker cannot read, typically within one round trip. A protocol can have one without the other, and marketing claims conflate them constantly.

The fifth is metadata minimisation, and it is where almost every real-world deployment is weakest. The Signal protocol's double ratchet is what delivers forward secrecy and post-compromise security: a Diffie-Hellman ratchet advances the key with every change of direction in the conversation, while a symmetric ratchet advances it with every message, so a stolen key opens one window rather than the archive. That is a mechanical property you can reason about. Metadata is a policy property, and policy can quietly undo the cryptography - a channel that encrypts content perfectly while logging who called whom at 2 a.m. is a surveillance system with good hygiene.

Metadata: the part your encryption does not touch

Signal publishes what it retains, and the list is short by design: a phone number, a registration date, a last-connection date, and the push tokens needed to wake the app. It states that it does not store your contacts, your social graph, your conversation list, your group memberships, your group titles or your location. Sealed Sender goes further and hides the sender's identity from the service itself: the client attaches a short-lived sender certificate that the recipient can verify, but the relay that routes the message does not learn who sent it. The result is a service that can route a message without being able to answer "who is talking to whom" in useful detail.

Most messengers do not do that. The default architecture records the sender, the recipient, the timestamp, the message size, the IP address and the device identifier, because those records are what make abuse detection, spam filtering, business analytics and lawful-access compliance work. Even when that data is never sold, it exists, it is retained for some period, and it is reachable by legal process, by an insider, or by a breach. A content-encrypted channel with a full metadata record still reveals the structure of a relationship: who a journalist talks to, when an executive calls a lawyer, which employee is in contact with a competitor, and - through timing correlation with an event - who leaked.

Traffic analysis is not exotic. If an attacker can observe both ends of a conversation at the network level, the pattern of message sizes and timings is often enough to infer content type, agreement, or the existence of a relationship, even with perfect content encryption. Push infrastructure adds another observer: Apple and Google deliver the notifications that wake your app, and while a well-built app sends only an encrypted payload and a generic wake signal, the delivery itself is a timestamped event tied to a device token.

The practical consequences are modest but real. Turn off message previews on the lock screen, because a notification that renders the text has moved the plaintext to a place the encryption was never designed to defend. Turn off cloud contact syncing for apps where the contact graph is the sensitive part. Prefer a channel whose provider sits in a jurisdiction you have actually thought about, and understand that "we do not sell your data" is not the same statement as "we do not have your data".

How the modern protocols work, without the maths

Three protocol families cover almost everything a business or an individual will encounter in 2026, and they are not interchangeable.

The Signal protocol is the reference design and the most widely deployed: an initial key agreement (X3DH, extended as PQXDH for post-quantum key establishment) followed by the double ratchet described above. WhatsApp, Signal itself, Google's RCS implementation and Skype all descend from it. Its strength is per-message forward secrecy and fast healing; its cost is that group messaging built on pairwise sessions does not scale gracefully, which is why WhatsApp uses a Sender Key scheme for large groups - each member distributes a group key to the others, which preserves confidentiality but trades away some per-message forward secrecy and makes membership changes the interesting attack surface.

Messaging Layer Security, standardised as RFC 9420, solves the group problem properly. Keys are derived from a tree of participants, so a group of a thousand people needs logarithmic rather than quadratic work to add or remove a member, membership changes are authenticated by the group, and the protocol provides forward secrecy and post-compromise security for the group as a whole. It is asynchronous, which matters on mobile networks where members are offline for hours. Wire, Webex and RingCentral have shipped it. If you are buying secure collaboration for teams larger than a handful of people, "does it use MLS" is a much better question than "is it encrypted", because it tells you whether group membership is cryptographically enforced or merely administered.

iMessage's PQ3 is Apple's post-quantum extension, introduced in February 2024 with iOS 17.4 and described by Apple as the first messaging protocol to reach what it calls Level 3 quantum security - the initial key establishment is post-quantum and the ratchet itself is periodically re-seeded with post-quantum key material, so a future quantum adversary cannot retroactively recover a long session. The distinction between Level 1, where only the handshake is post-quantum, and Level 3, where the ratchet is too, is the useful part of that vocabulary, and it is the right question to ask any vendor claiming quantum resistance.

The 2026 post-quantum shift, and what harvest-now means for you

Post-quantum cryptography stopped being a research topic for messaging in 2023 and became a shipped feature. Signal made PQXDH the default for new conversations in September 2023, so the initial key agreement combines the classical X25519 exchange with a post-quantum KEM (Kyber, now ML-KEM after NIST standardised it as FIPS 203 in August 2024). Apple shipped PQ3 in iOS 17.4. Then in October 2025 Signal published the Sparse Post-Quantum Ratchet, SPQR, which addresses the awkward part: making the ongoing ratchet post-quantum without attaching a large post-quantum key encapsulation to every message.

SPQR is worth understanding at a conceptual level because it is the state of the art and it clarifies what a vendor means when it says "post-quantum". A dense post-quantum ratchet would repeat a KEM operation on every message, which is expensive on a phone battery and produces large ciphertexts. SPQR is sparse: it maintains a tree of keys, advances ordinary messages with cheap symmetric operations, and periodically performs the post-quantum work at a coarser granularity, while still guaranteeing that a compromise heals - the property that makes post-compromise security useful. Signal's framing is that the sparse ratchet keeps the recovery guarantee without paying the full post-quantum cost on every message.

The threat that justifies all this is harvest-now-decrypt-later: an adversary records encrypted traffic today, stores it, and waits for a cryptographically relevant quantum computer. Nothing about that attack can be detected, and nothing can be done about it retroactively, which is why the migration question is "when do we start" rather than "when do we need it". Mosca's inequality makes the timing concrete: if the shelf life of the data (X) plus the migration time (Y) exceeds the time until a quantum computer is available (Z), the data is already at risk. For a message about a meeting next week, that inequality is comfortable. For a ten-year medical record, a merger negotiation, a source's identity or a whistleblower's complaint, it is not.

What to ask, and what to record in the answer: is the key establishment hybrid (classical plus post-quantum) rather than post-quantum alone, so that a new attack on the KEM does not remove all protection at once? Is the ratchet periodically re-seeded with post-quantum material, or only the handshake? Do calls, attachments, group messages and backups inherit the same protection, or is the post-quantum story limited to text? What is the migration date for anything still using RSA or plain elliptic-curve key exchange, and does it align with the published guidance your regulators follow - the US National Security Agency's CNSA 2.0 timeline, for instance, expects new national-security systems to be quantum-resistant by 2030 and full transition by 2035, and most large enterprises are working to a similar shape even where they are not bound by it.

The delivery layer moved: encrypted RCS and its conditional promises

The most consequential change for ordinary users in 2026 was not a new app. It was the arrival of end-to-end encryption across the platform boundary that had been the biggest practical hole in mobile messaging: the plain-text SMS that people fall back to when the recipient is on a different operating system. In May 2026 Google and Apple announced that RCS messages between Android's Google Messages and iOS 26.5 would be end-to-end encrypted, using the GSMA's RCS Universal Profile plus an MLS-based scheme for the cross-platform group case.

The promise is real and it is narrower than the headlines suggested, in three specific ways. It requires both ends to be using the stock messaging client with encryption enabled - a third-party SMS app, an older OS, or a carrier implementation that has not been updated gets no encryption at all. It requires RCS to be the channel that actually ran; when RCS registration fails or the recipient's device does not support it, the message downgrades to SMS or MMS, which are plaintext on the network and stored in carrier systems. And it does not cover every message type: media, reactions, read receipts and group edge cases have all been the hard part of these rollouts.

The practical rule is the one security engineers apply to every negotiated protocol: verify the state, not the brand. Look for the encryption indicator in the conversation, and if the app shows a plain SMS thread, treat the content as postcard-readable. When a message matters and the channel has downgraded, move it to a client where you control the encryption - Signal or WhatsApp - rather than trusting that "RCS is encrypted now" describes the thread in front of you.

An honest app-by-app reading

Comparison articles usually rank messengers by feature list. The useful comparison is by threat model, because each of these products was built to answer a different question.

Signal answers "how do I communicate without the service learning anything". Open-source clients and server, the protocol described above, sealed sender, no contact graph, no cloud message store, and secure backups that are opt-in and end-to-end encrypted under a 64-character recovery key generated on the device and never sent to Signal - a key you can lose, at which point the archive is unrecoverable, including by Signal. The costs are real: registration requires a phone number, there is no multi-device message store apart from that backup, and the network effect means the people you need are often not on it.

WhatsApp answers "how does everyone I know get encryption by default". It runs the Signal protocol with E2EE on by default for messages and calls, and it is the largest deployment of the protocol in existence. What it does not do is minimise metadata: the account is tied to a phone number and to Meta's infrastructure, the contact graph is uploaded by default, and business messaging through the WhatsApp Business platform terminates in an organisation's own systems, so the confidentiality guarantee there is the business's, not the protocol's. Backups are end-to-end encrypted only if you turn that on and keep the 64-digit key.

iMessage answers "how does encryption look like nothing at all". It is end-to-end encrypted and now post-quantum at the ratchet, with an excellent key-verification UI that most users never open. Two caveats matter: conversations with non-Apple devices fall back to SMS or, in 2026, to encrypted RCS only when both conditions above are met; and iCloud Backup of Messages is only end-to-end encrypted where Advanced Data Protection is available - which, since 21 February 2025, it is not for new users in the United Kingdom.

Google Messages answers "how do we fix SMS". RCS with E2EE between Google Messages users, carrier-dependent, and a clean upgrade path for Android users who will not install anything. The exposure is the fallback and the client landscape: anything that is not the stock encrypted path is plaintext.

Telegram answers "how do we make messaging fast and feature-rich". Its cloud chats are stored on Telegram's servers and are not end-to-end encrypted - the company says so plainly - and groups and channels are never end-to-end encrypted. Secret Chats are end-to-end encrypted, device-bound and unavailable for groups. It is a reasonable product with a security model closer to a social network than to Signal, and treating it as a confidential channel is a category error that recurs in leak investigations.

Matrix and Element answer "how do we own the server". Federated, end-to-end encrypted by default in direct messages and private rooms, self-hostable, and therefore popular with public-sector and privacy-sensitive organisations. The metadata trade is different rather than absent: your homeserver operator sees who is in which room on their server, and federation means the room state is replicated across servers that other people administer.

Enterprise collaboration - Teams, Slack, Webex, Google Workspace chat - answers "how do we keep the record". These are compliance instruments as much as communication tools: messages are indexed, searchable, retained under policy and exportable for eDiscovery, which means an administrator can read them and a court can obtain them. Webex has shipped MLS for meeting and messaging encryption; Teams limits E2E encryption to one-to-one calls. None of that is a defect if the product is being used for business records - it is a defect if someone uses it for the conversation they would not want in a discovery production.

Verification is the step nearly everyone skips

End-to-end encryption protects a session between keys. It does not, by itself, tell you that the key on the other end belongs to the person you think it does. That gap is where the classic attack lives: an adversary who can influence key distribution - through a compromised server, a malicious client build, an SS7 weakness in the carrier network, or a device that has been re-registered - substitutes their own key and reads everything while the interface shows a perfectly normal conversation. This is not hypothetical; it is the standard attack model that safety numbers exist to close.

Signal shows a safety number derived from both parties' identity keys, and WhatsApp exposes the same thing as a security code in the contact's details plus a key-change notification. Verification means comparing that value out of band - in person, or over a different channel such as a video call where you can see the person reading the digits - and confirming the match. Verify once per device pair. Re-verify when the app tells you the key changed, because that notification is the single most valuable security signal a messenger produces and it is routinely dismissed as a nuisance.

For an organisation, verification scales badly as a manual step and has to become a policy: high-value channels are verified at setup and on change, the verification event is recorded with a timestamp and the method used, and key-change notifications are routed to a monitored address rather than left to the individual. That record is also what turns "we use end-to-end encryption" into evidence: a screenshot of a verified safety number with a date on it is worth more in an incident review than any configuration export.

Backups are where end-to-end encryption usually dies

You can run a perfect encrypted conversation and then destroy the guarantee with one checkbox in a settings menu. Backups are the most common failure because they are the point where convenience writes the plaintext somewhere outside the endpoint, and because the default in most products has historically been "readable by the platform".

WhatsApp lets you encrypt the Google Drive or iCloud backup end-to-end, but the feature is opt-in and it generates a 64-digit key you must store. Without it the backup is encrypted in storage by the provider but readable by the provider - which is to say it is one legal request away from being read. Turn it on, write the key down somewhere that is not your phone, and test that you can restore.

iCloud is the clearest illustration of a jurisdictional single point of failure. Apple's Advanced Data Protection extends end-to-end encryption to iCloud backups, photos and notes, and without it an iCloud backup of Messages is readable by Apple on legal demand. On 21 February 2025 Apple withdrew ADP for new users in the United Kingdom rather than comply with a technical capability notice issued under the Investigatory Powers Act 2016, and it has been litigating that notice at the Investigatory Powers Tribunal since. The lesson generalises: any architecture whose confidentiality depends on a vendor's toggle in your jurisdiction can be changed server-side, without a software update, on a Friday.

Signal now offers opt-in Secure Backups: daily, end-to-end encrypted, stored without a direct link to the account, unlockable only with a 64-character recovery key generated on the device. The free tier covers your text history and 45 days of media; longer media retention is the first paid feature Signal has shipped. The design has a sharp edge worth stating plainly: lose the key and the archive is gone, because Signal cannot recover it. Store it in a password manager, not in a note on the phone.

For businesses, the backup question becomes a key-management question: who holds the keys that decrypt the archive, for how long, under what dual control, and what happens when the person who held them leaves. A backup that only one administrator can decrypt is an availability incident waiting to happen; a backup that any administrator can decrypt without a record is an insider-risk incident waiting to happen.

Device compromise beats cryptography every time

Every practical attack on encrypted messaging that we see in investigations targeted the endpoint rather than the cipher. The reason is arithmetic: breaking the protocol is not feasible, and reading the screen is trivial if you already have code running on the device.

The mechanisms are unglamorous. A malicious app with notification access reads your messages as they arrive. A screen recorder or accessibility-service abuse captures them as they are read. Stalkerware - commercial spyware installed by someone with brief physical access - exfiltrates keystrokes, screenshots and clipboard contents. A compromised cloud account yields the backup. A forensic tool applied to an unlocked device yields everything, including messages the app believed it had deleted. On a shared or corporately managed machine, the desktop client stores a local copy of your history in a database that is as protected as the disk encryption and the login password.

This is why the controls that matter most are boring: a strong device passcode with a short auto-lock, full-disk encryption, current operating-system patches, an app inventory you actually recognise, and no sideloaded builds of a messenger whose source you have not read. It is also why "the messages are encrypted" is not an answer to "the phone was seized unlocked" - and why any serious threat model has to include the possibility that the endpoint is lost.

Groups, admins and membership consistency

Groups are where encryption gets sociologically complicated, because the hard problem is not the maths but agreeing on who is in the room. A group key is shared among members; when a member is added or removed, the key must change and every remaining member must learn the new epoch. If an attacker can add a device or a participant without the others noticing, they receive the new key and read everything that follows. Academic work on WhatsApp groups demonstrated exactly this class of attack - a participant silently added to a group in a way the UI did not surface - and it is the reason membership consistency is a protocol property, not merely a settings page.

MLS handles this by construction: membership changes are authenticated, all members commit to the same view of the group, and a member who is added receives keys only from a valid commit. Sender-Key designs common in large consumer groups handle it administratively, which is why the administrative controls matter more in those products: restrict who can add participants, require admin approval for new members, review the member list on a schedule, and never keep a group alive after the project it supported has ended.

Two habits are worth adopting. First, distinguish a channel for coordination from a channel for secrets: a 40-person WhatsApp group is a broadcast tool, not a confidential space, because the membership is only as trustworthy as the least careful member and the history sits on 40 devices. Second, treat any group that suddenly gains a member you do not recognise as an incident, not a mistake - audit the member list, check for linked devices on your own account, and if the group carried anything sensitive, assume it was read.

Phones are not the only endpoint: desktop, web and linked devices

The most common real-world compromise of a WhatsApp or Signal account is not a cryptographic break. It is a linked device. Scanning a QR code creates a session token that gives a browser or desktop app access to the account's message stream, and if that session is established by someone else - through a phishing page disguised as "WhatsApp Web", a shared computer left signed in, or brief physical access - the attacker reads every message as it arrives, in parallel with you, often without the phone showing anything at all.

WhatsApp lists linked devices under Linked Devices, and the list itself is the control: open it monthly, recognise every entry, and log out anything you cannot account for. Signal's linked devices work the same way. Both apps let you require approval on the phone for new links, and both are worth configuring so that a link event is visible.

The desktop clients also change the threat model in ways people do not anticipate: the message history is cached locally in a database, the browser tab persists a session, extensions can read page content, and a screenshot defeats every cipher in existence. On a managed corporate laptop, the endpoint may be instrumented by design - which is legitimate, should be disclosed, and means that confidential personal conversations do not belong there.

Disappearing messages: what they do not do

Ephemeral messaging is a retention control, not a confidentiality control. Signal's disappearing messages, WhatsApp's disappearing messages and view-once media all delete the message from the participating devices after a timer, and none of them can reach a screenshot, a screen recording, a notification captured on a locked screen, a photograph of the screen, or a backup taken before the timer expired. If the recipient's device is offline when the timer expires, deletion happens when the app next runs; a forensic image taken in between contains the message.

Signal is explicit about the interaction with backups: view-once messages and messages scheduled to disappear within the next 24 hours are excluded from secure backups, which is a sensible design that also tells you the backup is not a reliable record of ephemeral content.

The legal caveat is the one that catches organisations. Deleting messages can constitute spoliation of evidence once litigation is reasonably anticipated, and in the United States Federal Rule of Civil Procedure 37(e) provides for curative measures and, where intent to deprive is shown, an adverse inference or dismissal. In financial services, using an ephemeral channel for business records is exactly the conduct that produced the largest recordkeeping penalties on record: the SEC's 27 September 2022 settlements with 16 firms for more than USD 1.1 billion, a further USD 710 million from the CFTC the same day, and JPMorgan's USD 200 million in December 2021 - roughly USD 2.01 billion in total for off-channel communications that were never preserved. Disappearing messages belong in a personal threat model and in a whistleblowing channel. They do not belong anywhere a retention obligation applies.

Enterprises: retention, eDiscovery and the E2EE conflict that is really a design problem

Most compliance commentary frames end-to-end encryption and recordkeeping as irreconcilable. They are not. They are two requirements that have to be satisfied by an architecture rather than by a policy nobody follows, and there are five workable patterns - each with a cost you should choose deliberately.

Approved channel with server-side capture. The organisation standardises on a platform designed to be retained: Teams, Slack, Workspace chat, or an enterprise messaging product with compliance export. Messages are readable by the platform because that is the product's function, capture is automatic, and the record survives employee deletion. This is the correct default for anything that is a business record, and it should be paired with a technical block on consumer messaging apps on managed devices - an MDM policy that removes the app, or at minimum a DNS and network control that prevents it - because a policy alone is the control that produced the USD 2 billion in penalties cited above.

Encrypted content with compliant capture at the endpoint. Some products offer end-to-end encryption with archiving by capturing the message on the managed device before it is sent - the employee is informed, the capture happens under device-management policy, and the archive holds plaintext while the transport remains encrypted. It satisfies both requirements, and it depends entirely on the notice being genuine and the capture being complete; a device that is not enrolled is a gap that the archive will not reveal.

Segregated channels. The organisation designates one channel for business records with full retention, and a separate, genuinely private channel for a defined purpose - the whistleblowing hotline under the EU Whistleblower Directive, an employee assistance line, an HR complaint channel. Confidentiality there is a legal requirement, not an oversight, and E2EE is the right design. The discipline is documentation: which channel, which purpose, which population, and why retention does not apply.

Key escrow inside a defined retention window. The platform holds encrypted message content and releases keys to the organisation only under a defined process, typically dual control plus a warrant or a documented eDiscovery request, with the escrow residency chosen to match the jurisdiction. This is the pattern that makes E2EE defensible in a regulated entity, and it is also the pattern that most requires honesty: if the organisation can obtain the key on its own authority, the channel is not end-to-end encrypted against the organisation, and the staff notice must say so.

Prohibition with evidence. Where the other four are unavailable, the fallback is an explicit prohibition plus the artefacts that show you tried: a written policy, an attestation cycle, device-level controls, monitoring for consumer messaging traffic on corp networks, and a disciplinary procedure that is actually applied. Regulators accept a defensible programme; they do not accept a policy document and silence.

The practical decision tree is short. Is this communication a business record that must be produced to a regulator or a court? If yes, it goes on a captured channel, and the encryption on that channel is a control against outsiders rather than against the organisation. If no, name the exception in writing - privilege, whistleblowing, HR, safety - and use a channel whose encryption the organisation genuinely cannot break, because a half-private channel is worse than either option: it invites candid conversation while preserving it for discovery.

Regulated sectors: DORA, NIS2, GDPR and the evidence you need

Three European instruments now make encrypted communication a compliance topic rather than an IT preference, and each asks for something slightly different.

GDPR treats encryption as the example of an appropriate technical measure in Article 32(1)(a), and Article 34(3)(a) removes the obligation to notify data subjects of a breach where the data was encrypted with a state of the art algorithm and the keys were not compromised. That is a powerful incentive with a documentation requirement attached: to rely on it you must be able to show what was encrypted, with what, and that the key was not exposed - which is a design and evidence question, not a settings question.

NIS2, in Article 21(2)(h), requires a cryptography and encryption policy as one of the ten baseline measures that management bodies must approve and supervise, alongside access control, incident handling and supply-chain security. The policy has to exist as a document with an owner, cover which data is encrypted at rest and in transit and with which algorithms, define key management, and be reviewed. A messenger rollout without that policy is an audit finding waiting to be written.

DORA treats messaging infrastructure as an ICT service provided by a third party. That pulls it into the register of information, the contractual requirements on the provider, the concentration-risk analysis, and the exit plan. The question "what happens if our messaging provider withdraws a feature or a region" is precisely the scenario the Apple ADP withdrawal created, and DORA expects an answer on file before it happens.

Lawful compulsion: what a provider can and cannot be made to do

Anyone designing a communications architecture needs a realistic view of legal compulsion, because the failure mode is not "the government breaks the cipher" but "the provider is ordered to help and complies".

What can be compelled varies by jurisdiction but follows a pattern. A provider can be required to produce what it holds: account records, metadata, stored content, and backups it can decrypt. It can be required to assist with the interception of future communications where a lawful authority has authorised it. Individuals can be required to disclose keys or passwords - the United Kingdom's Regulation of Investigatory Powers Act 2016, section 49, provides for a notice requiring disclosure of a key to protected information, with penalties that escalate for national-security and child-sexual-abuse cases. Device unlocking obligations differ sharply between countries and are being litigated continuously, which is why "the phone is encrypted" is a weaker statement than people assume.

What cannot be compelled, in a well-designed system, is content the provider never possesses in readable form. When Signal has been served with subpoenas and grand jury demands in the United States, the material it could produce was limited to account registration and last-connection information - because that is all it holds. That asymmetry is the entire practical argument for end-to-end encryption: not that it defeats a lawful order, but that it makes the order unable to reach the content.

The jurisdictional exception is the one that matters for planning. A technical capability notice can compel a provider to build a capability, and the provider's choices are then to comply, to withdraw the feature, or to litigate. Apple withdrew Advanced Data Protection in the United Kingdom in February 2025 rather than build the capability, which protected users' data from that particular demand and simultaneously removed a protection 35 million UK users had been relying on. If your threat model includes a state with jurisdiction over your provider, the only architecture that holds is one where keys exist solely on endpoints you control, and where the loss of a vendor feature does not silently downgrade the guarantee.

This is also where the lawful framing belongs. We do not help anyone evade lawful process, and this guide is not a manual for doing so. The legitimate work is the opposite: helping an organisation demonstrate that it meets its obligations, that its records are preserved where the law requires, and that its confidential channels are genuinely confidential where the law permits.

Account takeover and SIM swap: the actual attack path

If you want to know how encrypted messaging is attacked in practice, look at the account rather than the cipher. A messaging account is anchored to a phone number, and a phone number is one of the weakest identity anchors in common use.

SIM swap is the classic. An attacker persuades or bribes a carrier representative to port the victim's number to a SIM they control, or uses a compromised carrier credential to do it directly. The number now receives the SMS one-time codes for every account that trusts it, including the code that re-registers a messaging account on a new device. From the outside it looks like the victim lost signal; from the inside the attacker is now receiving the account's messages and a notification that the account was registered elsewhere.

Verification-code social engineering is cheaper. The attacker triggers a registration attempt for the victim's number and then contacts the victim, posing as support, a colleague or a delivery driver, and asks them to read back the six-digit code that just arrived. The code is the account. A variation targets the SMS forwarding settings on the phone itself, so codes are silently copied without any prompt at all.

Linked-device pairing, described above, requires a QR scan rather than a code and is often the least visible of the three. Number recycling is the slow version: a carrier reassigns a dormant number, and whoever receives it can register the messaging account tied to that number, sometimes inheriting cloud backup material.

Defences are specific and mostly free. Turn on the app's own registration protection - WhatsApp's two-step verification with a PIN and a recovery email, Signal's registration lock PIN - because that PIN is the control that defeats a SIM swap for that app. Ask your carrier for a port-out PIN and a port freeze if it offers one, and move the number off SMS-based two-factor authentication for every account that supports something better. Then treat any unexpected "your account was registered on a new device" message as a live incident, because that is what it is.

The response sequence, in order: re-establish control of the number with the carrier; re-register the app and set the PIN; review and revoke linked devices and active sessions; warn contacts that messages from the account in the last few hours may not be yours, and ask them to verify out of band; check whether the cloud backup was accessed or restored; preserve evidence - screenshots with timestamps, the carrier's porting record, the app's notification history; and report to the platform and, where personal data was exposed, to the relevant authority inside the statutory clock. If the account was used to defraud contacts, the fraud report goes to the police in the jurisdiction of the loss, not the jurisdiction of the attacker.

A 30-minute hardening programme for an individual

This sequence is ordered by risk removed per minute spent. Do it on the device you actually use, and do not skip the boring middle steps in favour of the interesting last one.

1. Audit linked devices (5 minutes). Open Linked Devices in WhatsApp and Signal and log out everything you cannot name. Turn on the setting that requires phone approval for new links. This single step closes the most common takeover path.
2. Set the app PIN (3 minutes). WhatsApp two-step verification with a PIN and a recovery email; Signal registration lock. Write the PIN in your password manager, not in your head, because a forgotten PIN after a phone loss is a lockout.
3. Turn on backup encryption (5 minutes). WhatsApp, Settings, Chats, Chat backup, end-to-end encrypted backup, and store the 64-digit key outside the phone. For Signal, enable Secure Backups and store the 64-character recovery key the same way.
4. Kill lock-screen previews (2 minutes). Set notification previews to "when unlocked" or off for every messenger. The lock screen is where an encrypted message becomes a visible one.
5. Verify your two most important contacts (5 minutes). Compare safety numbers in person or over a video call. Do this for the conversations where impersonation would actually cost you something.
6. Harden the device (5 minutes). Strong passcode, biometrics plus passcode rather than swipe, auto-lock at one minute, full-disk encryption on, operating system updated, and a look through installed apps for anything you do not recognise.
7. Set the ephemeral default deliberately (5 minutes). Disappearing messages on for casual and organising threads, off for anything you may need as a record. Know which is which before the situation forces the choice.

Two habits finish the job: never read a verification code to anyone who contacts you, whatever the story, and move the sensitive half of a conversation to Signal when the other party's channel is a plain SMS thread or a platform you cannot reason about.

A 90-day hardening programme for an organisation

For a business the sequence is a quarter of work in four phases, and each phase produces an artefact rather than a feeling.

Days 1-14: discovery. Inventory every messaging channel in use, including the ones nobody approved. Survey the population rather than guessing, because the gap between the sanctioned list and the real list is where the risk lives. Produce a register with owner, population, data classification and retention status, and a one-page statement of what you found. This document is the baseline for everything that follows, and it is the first thing a regulator or an acquirer will ask for.

Days 15-45: policy and legal basis. Write the cryptography and encryption policy NIS2 asks for, the retention matrix that maps each channel to an obligation or a written exception, and the DPIA for messaging. Decide the five design patterns from the enterprise section explicitly - which channels are captured, which are segregated, which are prohibited - and get the decisions signed by the management body rather than an IT manager. Record the jurisdiction analysis for each provider, including what happens if a feature is withdrawn in your country.

Days 46-70: technical implementation. Deploy the controls: compliance capture on the approved channels, device management policy that removes consumer messaging apps from managed devices or confines them to a work profile, mandatory app PINs, backup encryption with keys in the corporate vault, and verification procedures for high-value channels. Where the organisation genuinely cannot inspect content, implement the key-escrow pattern and disclose it in the staff notice. Test one restore and one export end to end - an untested backup is a hypothesis.

Days 71-90: evidence and rehearsal. Run a tabletop exercise on a messaging compromise: an executive's account is taken over during a deal, twenty minutes of messages go to an attacker, and a regulator asks for the incident timeline. Time the statutory notifications, produce the first draft report, and fix what the exercise exposes. Then set a quarterly review with named owners for the encryption policy, the linked-device audit, the retention matrix, and the provider exit plan.

If a programme stalls, it is almost always at the second phase, because the decisions there are political rather than technical: a channel that is captured is a channel the organisation can read, and someone has to say that out loud to the workforce. The organisations that get through it write the notice in plain language, keep the exceptions genuinely narrow, and treat the whistleblowing channel as sacred rather than as a loophole.

Metrics that tell you whether any of this works

Security programmes fail quietly when they are measured by activity. "We deployed encrypted messaging" is an activity. Five measurements describe whether the control is real.

Channel coverage: the share of business communications that occur on a captured channel, sampled from eDiscovery exports, email metadata and network logs rather than from the policy document. If the sanctioned channel is used for a third of traffic, the programme has not been adopted and the rest is exposure.

Verification coverage: the share of high-value channels with a current, recorded safety-number verification and the number of key-change alerts in the period. A flood of key-change alerts is not noise; it is either re-installs or interception, and it should be investigated until the cause is known.

Linked-device hygiene: the share of accounts with no unrecognised linked device at the quarterly audit, and the median time to revoke one that is unrecognised.

Backup recoverability: the share of encrypted backups that have been restored successfully in a test. A backup you have not restored is a claim, not a control, and the single most common finding in a real incident is that the key was stored somewhere nobody can reach.

Time to contain: the elapsed time from "an account was taken over" to "sessions revoked, contacts warned, evidence preserved". This is the number that decides how bad the incident was, and it is measurable in a tabletop before it is measurable in an incident.

Where this breaks, and what to do first when it does

The failure modes are predictable enough to list in order of how often they appear in real investigations.

An unapproved channel with the sensitive conversation on it. The most common finding by a wide margin. The response is not to confiscate phones; it is to make the approved channel good enough that people choose it, then narrow the exception list to the cases that genuinely need privacy.

A promise that turned out to be conditional. The thread that silently downgraded to SMS, the group that was never encrypted, the backup that was never encrypted, the business API message that terminated in a vendor's CRM. The response is to verify the state of the channel before the sensitive content goes into it, and to record which channels were verified for a given matter.

A compromised endpoint. The phone was unlocked, the laptop was shared, the linked device was live, the screenshot exists. The response is containment first - revoke sessions and links, change credentials from a clean device - then evidence preservation, then the root-cause work, in that order.

Key material lost rather than stolen. The recovery key was never stored, the administrator with the escrow left, the device holding the only copy died. This is an availability incident and it is the one teams are least prepared for, because encryption training focuses on secrecy and not on custody.

A vendor decision you did not model. A feature withdrawn in a jurisdiction, an API deprecated, a provider acquired, a protocol downgraded for a market. The mitigation is not cynicism; it is an exit plan with a named replacement and a tested export, reviewed annually alongside the register of ICT third parties that DORA expects.

Conclusion: the channel, the endpoint and the record

Encrypted communication is not one decision, it is three. The first is the channel: whether the encryption is end-to-end, whether the metadata is minimised, and whether the protocol provides authentication, forward secrecy and post-compromise security rather than merely promising confidentiality. In 2026 that question has a better answer than it did a few years ago - the Signal protocol and MLS are mature, iMessage runs a post-quantum ratchet, and encrypted RCS has closed the worst hole in ordinary mobile messaging, conditionally. The second is the endpoint: whether the device holding the plaintext is patched, locked, unlinked and free of anything that reads the screen. The third is the record: whether the conversation is a business record that has to survive, in which case the encryption should be designed around capture and disclosure rather than in spite of it.

Most of the failures we get called about sit in the second and third decisions, not the first. An organisation has impeccable encryption on a channel where the real deal conversation happened on someone's personal WhatsApp; an individual has Signal installed and a linked device they have never looked at; a team has ephemeral messages on and a retention obligation it forgot. None of those are cryptographic problems, and all of them are solvable with the checklists above.

Where the topic meets the rest of our guides: the transport side of the same problem is in the email security assessment guide, the network-level view is in VPN and network privacy for enterprises, the key custody question is in how password managers actually protect you, and the containment sequence is in the incident response plan guide. The Italian version of this guide is at comunicazioni sicure e messaggistica crittografata.