Device linking is the feature that lets you run the same messenger on your phone, your laptop, and a tablet at once. It is genuinely useful, and on well-built messengers it is implemented with real cryptographic care. It is also, structurally, the easiest legitimate path to reading someone's encrypted messages, which is why it has become a favored target for attackers who cannot break the protocol.
What linking actually does
End-to-end encryption delivers messages to endpoints, not to accounts. When you link a desktop client to your phone, you are enrolling a new endpoint: the new device generates its own key material, your phone signs off on it, and from then on senders encrypt every message to your desktop's keys as well as your phone's. Protocols handle the bookkeeping differently. The Signal Protocol family manages per-device sessions through its Sesame algorithm, while MLS can represent each device as a group member. The user-facing result is the same: a linked device is a full cryptographic participant in your conversations.
That is worth stating plainly because it explains the attack. Nothing about linking is an exploit. The QR code you scan encodes a linking request containing the new device's public keys, and scanning it is an authorization. A victim who scans an attacker's linking QR code has, as far as the protocol can tell, deliberately added a new computer to their own account. The encryption then does its job faithfully for an audience of one too many.
Linking abuse does not break end-to-end encryption, and it is not a backdoor. It is authorization phishing: the same category of attack as tricking someone into approving an OAuth grant or an MFA push. The encryption did its job throughout; the failure happened at endpoint enrollment, which is part of the security boundary whether or not the threat model drew it there.
The campaigns that proved the point
The campaigns Google documented in February 2025 targeted Ukrainian military and government personnel. The attackers built phishing pages that mimicked group invites, security alerts, and even military applications, each embedding a linking QR code where a victim expected an ordinary "join group" code. Some lures were distributed as shortened links that resolved to the messenger's own linking flow. In at least one documented case, devices captured on the battlefield were linked to attacker infrastructure before being returned or exploited.
Signal responded through the spring of 2025 with changes that are now the reference design for this problem: linking requires authenticating on the primary device, newly linked devices trigger prominent notifications, and the linked-device list prompts periodic review. Other messengers with QR-based linking, including WhatsApp, have faced variants of the same lure for years in the form of fake "web login" pages.
The reason attackers bother is durability. A stolen password gets reset. A hijacked session token expires. A linked device keeps receiving message content until the victim notices it in a settings screen most people never open.
Desktop clients raise the stakes
Linking usually means a desktop, and a desktop is a softer place to keep secrets than a modern phone. Phones ship hardware-backed keystores and aggressive app sandboxing. A desktop operating system runs your messenger's key material alongside every browser extension, game mod, and npm install you have ever agreed to.
Signal Desktop illustrated the gap concretely: for years it stored the key that encrypts its local message database in a plaintext configuration file, meaning any process running as your user could copy your message history. After renewed public criticism in 2024, it moved that key into the operating system's credential store. That is an improvement, though an infostealer running in your user session can often still reach whatever your user session can reach. The general point survives the specific fix: a linked desktop extends your most private conversations onto your least defended hardware.
Auditing your own devices
The defense is unglamorous and takes about two minutes.
- Open the linked-devices screen and read it. Signal, WhatsApp, and every messenger with companion support has one. Anything you do not recognize, or a device you no longer own, gets removed now. Removal revokes the device's keys, and it stops receiving anything sent afterward.
- Treat linking QR codes like passwords. The only legitimate place to encounter one is inside the desktop app you are setting up, on hardware in front of you. A linking code that arrives in a chat, an email, or a "group invite" page is an attack. QR codes hide their contents by design, so the context has to carry the judgment the pixels cannot.
- Notice enrollment notifications. If your messenger announces a new linked device and it was not you, act immediately: unlink it, then assume everything received in the interim was read.
- Shrink the set. Every linked device is an endpoint you are defending. If the tablet client was an experiment you stopped using in March, unlink it. Message history already delivered to a device stays on that device, which is one more reason not to accumulate them.
The design lesson
There is a quieter conclusion here for anyone comparing messengers. The security of an end-to-end encrypted system is bounded by its endpoint enrollment story: how hard it is to add a device, how loudly the system announces it, and how easy the resulting list is to audit. A protocol audit that stops at the cryptography misses this entirely, which is why what E2EE protects has to be answered by looking at the whole system around the cryptography. When you evaluate a secure messenger, open the device management screen before you read the whitepaper. How a product treats the moment a new key joins your identity tells you most of what the marketing will not.