End-to-end multi-device

A user expects to be able to use their profile from all their devices. They want to be able to start a chat on one device, then naturally continue it on another. From their contacts’ point of view, this must be seamless. In particular, a user adding a device must not require any manual operation on the part of their contacts.

The device list: a matter of security

Without end-to-end encryption, the technical solution can be trivial:

• Users register each of their devices with the server (typically by authenticating with a login and password from each device).
• When a contact sends a message, the server distributes that message to all registered devices.

With an end-to-end encrypted messaging app, it is a different story. Each device of each user must establish a secure communication channel with each device of each recipient. When a user sends a message to one of their contacts, the message is actually encrypted for each of the recipient’s devices. The means used to encrypt for several devices vary from one messaging app to another, but in all cases the idea is to encrypt the content of messages only once and to give each recipient device the means to decrypt it. But how does the application know the exact list of devices?

A naive approach would be to proceed much like the trivial solution above, relying entirely on the solution’s server to tell our contacts the list of our devices and the encryption keys to use for each of them. This approach carries a major risk: the server could maliciously add a fictitious device to the device list of a user A, distributing an encryption key it controls so as to decrypt all the communications received by that device. The attack is perfectly silent: user A’s contacts dutifully encrypt a copy of each message for that fictitious device, as they would for any legitimate device, with no way of telling anything is wrong. This is the key-substitution attack described on the identity substitution page, transposed this time to the device list.

Tying devices to the identity, not to the server

In an end-to-end approach, one naturally refuses to place any trust in the server, which rules out the naive approach. The application must recognize a contact’s devices on its own. But this requirement runs into another one, practicality: the user cannot be asked to manually validate each device of each of their contacts, nor can their contacts be required to do anything every time they add a device. The solutions that reconcile these two requirements have one thing in common: they tie a user’s devices to their cryptographic identity, the one their contacts have already authenticated, rather than to a list held by the server. The trust granted once to the identity thus extends to its devices, without the server having any say. The means of achieving this vary:

• Olvid: all of a user’s devices share the same long-term key pair (the one that constitutes their identity). A contact who has authenticated that identity can trust all of its devices without needing to verify anything more; internally, a secure channel is established between each pair of devices from that shared key.
• Signal and WhatsApp: each device has its own key, but a “primary” device signs the others’ keys with its long-term key. The contact trusts that primary device, the identity they know, and that signature is then enough for their application to accept the other devices.
• Matrix: the protocol provides a mechanism called cross-signing, where the user has a single certification key that signs all of their devices; a contact can thus validate all of them by verifying that one key. But the protocol does not make this mechanism mandatory: depending on the Matrix client and its configuration, verification may not be enabled, and the server (the “homeserver”) then becomes, in effect, the authority that declares which devices belong to the user. The guarantee is therefore not systematic.

The case of browser access

The question of end-to-end multi-device also arises for messaging apps that offer access from a browser: each browser, on each computer, is in fact a new device and also requires secure channels. If the user can access their chats from a browser by authenticating with the server alone (with a login and password, for example), then end-to-end encryption is simply not there: for a browser in which no key yet exists to be able to display messages, the server must be able to provide what is needed to decrypt them. Web access is not necessarily incompatible with end-to-end encryption, but it then requires that an already legitimate device authorize this new access, exactly as for any other device.

There is another, more limited approach: the “mirror” device. Threema’s client for computers (desktop application or web client), for instance, is not an autonomous device but a window onto the phone: pairing requires scanning a QR code from the mobile app, the phone must stay connected for the whole session, and the synchronized messages are wiped from the computer as soon as the session ends^archived. This approach places (as far as encryption keys are concerned) no trust in the server: it really is a legitimate device that authorizes the access. SimpleX’s approach is similar: its desktop application is a remote control for the mobile app, to which it links directly, without any server involved, which requires the two devices to be on the same local network. In both cases, there is a cost in convenience: the computer holds no identity of its own and depends entirely on the phone, so this is not true multi-device.

Browser access will always pose an additional problem, even when well designed: the web client’s code is reloaded from the server at every session, so the operator (or anyone compromising its web server) can serve a modified, potentially malicious version to a targeted user, without anything being easily detectable. An installed application does not suffer from this problem, so the mirror model, in its desktop-application form, escapes it, whereas its “web client” version remains exposed.

Web 2.0 and SaaS applications have made it customary to use the browser in place of native applications, but that model assumes you trust the server that hosts both the data and the application. In a model where one seeks end-to-end security and does not want to trust the server, that no longer holds. Using a dedicated desktop application achieves a level of security that browser access cannot.

Adding a device: a critical operation

In all the approaches described above, it is an already legitimate device that authorizes the new one. All multi-device security therefore rests on this procedure for adding a device: if an attacker manages to get their own device registered on the victim’s account, they obtain the equivalent of a copy of all of the victim’s future conversations. This is not a theoretical risk, since phishing campaigns have exploited^archived Signal’s device-linking procedure, by getting users to scan a QR code that actually linked the attacker’s device to their account. A CERT-FR advisory^archived (in French) was even published on the subject in March 2026.

This risk imposes a counterintuitive requirement: the procedure for adding a device must not be too simple. The user must not be able to trigger it, let alone complete it, without understanding what they are doing. A good procedure for adding a device is an unusual experience, one that jolts the user out of autopilot and forces them to think before confirming. A device is added a small number of times in the life of an account (typically when buying a new phone). Nothing therefore justifies making the operation fast. Conversely, a mere sequence of confirmation screens protects against nothing, however many warnings are displayed: the user will click through them mechanically to get it over with. And above all, this procedure must not be triggerable from the outside, by a link or by scanning a QR code received from a third party, which is precisely what the attacks against Signal exploited.

Applying this criterion

✅Good if the app offers true multi-device (each device is autonomous, not a mirror of the phone) and the link between a device and its user is guaranteed by the user’s cryptographic identity.