What Is Encryption?

Encryption is the operation — converting readable data into ciphertext that only a key can reverse. The underlying discipline is cryptography; this entry is about applying it, and about the question that determines whether it protects anything: who holds the key, and who can use it?

That question matters because encryption is routinely deployed in a configuration that protects against one narrow threat while being described as though it protects against all of them.

The three states, and what each actually defends

At rest protects stored data. In its default cloud and full-disk forms it defends against physical theft of the media and very little else, because the platform transparently decrypts for anyone authorised to read the file. See encryption at rest.

In transit protects data moving between systems, and is the most consistently well-implemented of the three because TLS made it a default rather than a decision.

In use protects data while it is being processed, which is the hardest and least mature. Approaches such as homomorphic encryption and confidential computing address it with significant performance or architectural cost.

Why encryption so often protects less than expected

Because the threat most organisations face is not someone stealing a disk. It is a compromised credential, an over-permissive role or a misconfigured storage container — and against all three, encryption with a platform-managed key offers nothing at all. The attacker is authorised, so the data decrypts for them.

Encryption becomes a meaningful access control only when using the key is a separate permission from reading the data, administered by different people and logged independently. That is the whole argument for customer-managed keys, and it is the part most commonly skipped.

Practical decisions that matter

Prefer authenticated encryption, which protects integrity as well as confidentiality — unauthenticated ciphertext can be altered in ways that change the decrypted result. Never reuse an initialisation value that must be unique. And do not confuse encoding with encryption: base64 is neither a secret nor a control.

For anything you are relying on, establish where the key lives, who can use it, and what is logged when it is used. Those three answers describe the protection; the algorithm name does not.

Encryption is not access control, and not integrity either

Two adjacent misconceptions cause real problems. The first is treating encryption as though it controls access — it does only where key use is a separately administered permission, and otherwise the access decision is made entirely elsewhere.

The second is assuming encryption protects against modification. Unauthenticated ciphertext can often be altered in ways that produce predictable changes in the decrypted result, without the attacker ever reading it. That is why authenticated encryption is the correct default and why bolting a separate integrity check onto an unauthenticated mode is a classic source of error.

Both misconceptions lead to the same place: a system described as encrypted, satisfying an auditor, and protecting considerably less than everyone involved believes.

Where to start

Take your most sensitive data store and establish whether the people who administer its encryption key are the same people who can read the data. If they are, the encryption is documentation rather than a control.

See encryption everywhere and cloud key management. GuardsArm runs security risk assessments.