End-to-End Encryption E2EE

End-to-end encryption means that content is encrypted on the device that sends it and decrypted only on the device that receives it. The keys needed to read it exist at those two ends and nowhere else. The service that carries or stores the content handles it in scrambled form.

Suppose a firm sends a draft contract to a client through an end-to-end encrypted service. The file is encrypted on the lawyer's computer before it leaves. The provider's servers pass on a block of data they cannot open. The client's device holds the key that turns it back into the contract.

The test is who holds the keys. If the provider can produce readable content, for instance to reset a forgotten password and restore the files, then the provider holds a key, and the service is not end-to-end encrypted in the strict sense. Published standards and open protocols exist for the encryption itself, and a provider should be able to say which it uses.

The three differ in where the data is readable and in who holds the keys. Encryption in transit protects data while it travels between a device and a server. Encryption at rest protects data stored on a disk. In both, the provider's systems usually hold the keys and work with readable content at some point. With end-to-end encryption they never do. The table sets the three side by side.

The three are not alternatives. A service can use all of them. A provider that says its service is encrypted should be asked which kind it means.

End-to-end encryption protects content on the way and at the provider. It does not protect the two ends. A file is readable on the sender's device before encryption and on the recipient's device after decryption. Malware on either device, a laptop left open or a stolen password reaches it there.

It does not prove who is at the other end. Encryption guarantees that only the holder of a key can read the content. Whether that key belongs to the client or to someone posing as the client is a question of identity and has to be settled separately.

It does not usually hide the information around the content. A provider may still see who communicated with whom, when, and how much data passed. It does not control what the recipient does next: a decrypted file can be forwarded, printed or saved somewhere unprotected. Copies made outside the encrypted service, such as an unencrypted backup of a device, are outside it too.

The GDPR and the articles of the NIS2 Directive require appropriate security and name encryption as one measure. Neither uses the words end-to-end in an obligation.

Article 32(1)(a) of the GDPR lists "the pseudonymisation and encryption of personal data" among the measures a controller and a processor implement "as appropriate" to reach a level of security appropriate to the risk. The firm decides, on its own risk assessment, what kind of encryption that calls for. Article 34(3)(a) gives encryption a concrete effect. After a personal data breach, the people concerned need not be informed where the affected data was unintelligible to anyone not authorised to access it, "such as encryption".

Article 21(2)(h) of the NIS2 Directive requires essential and important entities to have "policies and procedures regarding the use of cryptography and, where appropriate, encryption". The directive mentions end-to-end encryption only in recital 98. The recital says its use should be promoted and, where necessary, should be mandatory for providers of public electronic communications networks and services. A recital explains a law and creates no duty by itself.

For financial entities, Article 9 of DORA requires policies that protect data "at rest, in use or in transit" (Article 9(2)) and protection measures for cryptographic keys (Article 9(4)(d)). It leaves the method to the entity's own data classification and risk assessment.

The firm gains confidentiality against its own provider and takes on the care of the keys.

The provider cannot read the content. A breach of the provider's servers exposes scrambled data, and the provider's staff cannot open client files. Asked to disclose content, the provider can hand over only what it holds: encrypted data and whatever surrounding information it keeps.

Losing the key means losing the data. A provider that holds no key cannot reset access. The firm needs its own recovery arrangement, such as a recovery key kept safely or a second authorised person, and it must test it. Records that the law requires the firm to keep have to stay readable for the whole retention period, so the keys must be kept as long as the records.

Functions that need readable content on the server stop working or move to the device. Full-text search, virus scanning, document previews and automated checks of content are examples. A firm should ask a provider how each of these works under its design.