08: Cloud Storage and Backups: Who Holds the Keys?

June 11, 2026

Cloud Storage and Backups: Who Holds the Keys?

“Encrypted in the cloud” is not one security model. The important questions are who controls the encryption keys, how access can be recovered, and whether the provider can decrypt the files.

The question readers are really asking

If my files are encrypted in the cloud, are they safe from a future quantum computer—and from the cloud provider itself?

It depends on what “encrypted” means.

Many cloud services use strong encryption such as AES-256 for stored data. That remains important after Q-Day. But encryption alone does not determine who can read a file. Someone must hold the keys, operate recovery, and decide when decryption is allowed.

The useful question is:

Who can decrypt this file, and what happens if I lose access?

The short answer

Cloud encryption commonly falls into five categories:

encryption in transit;
provider-managed encryption at rest;
customer-managed keys;
client-side encryption; and
true end-to-end encryption.

A service may use several at once. They do not provide the same confidentiality, recovery options, or protection against provider access.

AES-256 cloud storage encryption can remain strong after Q-Day. The more immediate issue is whether the provider, the customer, or only the user’s devices control the keys.

1. Encryption in transit

Encryption in transit protects files while they travel between your device and the cloud service, usually through HTTPS or another secure network protocol.

It helps prevent ordinary eavesdropping on Wi-Fi and internet connections. But it does not answer what happens after the provider receives the file. In a typical service, the provider decrypts the connection at its servers to store, display, search, share, or process the file.

The public-key parts of these connections will gradually migrate to post-quantum cryptography. Users should receive those upgrades through browsers, apps, and cloud services rather than through manual configuration.

2. Provider-managed encryption at rest

Provider-managed encryption at rest means that the cloud provider encrypts data on its disks and manages the keys itself.

This is valuable. It helps protect against stolen drives, improperly retired hardware, and some infrastructure-level attacks. But it usually does not make the provider unable to read the files. The provider holds, or can access, the keys needed to decrypt data for authorized service functions.

This model also supports convenient features such as browser access, password recovery, previews, search, collaboration, and backup restoration. It is real encryption; it is simply not provider-blind encryption.

3. Customer-managed keys

With customer-managed keys, an organization controls more of the key lifecycle. It may create, rotate, disable, or revoke keys through a cloud key-management service or an external system.

This can improve governance, auditing, separation of duties, and the ability to cut off access. It is useful for institutions with formal security or compliance requirements.

But customer-managed keys do not automatically mean that the provider cannot decrypt files. In many designs, the cloud service can decrypt data while the customer-authorized key remains available and a permitted request is made. The customer has greater control over when keys are available; it does not necessarily hold the only decryption capability.

“Customer-managed” is not always the same as “customer-held” or “provider-blind.”

4. Client-side encryption

Client-side encryption means that a file is encrypted on the user’s device before upload. The provider stores ciphertext rather than ordinary readable files.

This can create a stronger privacy boundary, but details matter. A service may offer client-side encryption while also keeping a recovery key, providing web access, or offering account-recovery features that affect who can decrypt the data.

For sensitive archives, ask:

Are files encrypted before upload?
Where are the decryption keys stored?
Does the provider hold a recovery key or other access path?
What happens if every device and recovery method is lost?

5. True end-to-end encryption

End-to-end encryption, in the strongest sense, means that only authorized devices—or intended recipients’ devices—hold the ordinary ability to decrypt content. The provider stores and transports ciphertext but cannot normally read it.

This is the strongest provider-blind confidentiality model. It also changes recovery: if no provider-held recovery key exists, losing the passphrase or recovery information may mean permanent loss of the data.

End-to-end encryption does not eliminate every risk. A provider may still see metadata, such as account identities, storage size, timestamps, and sharing relationships. Malware, screenshots, malicious browser extensions, or a recipient who exports a document can expose the contents after decryption.

Why key control matters after Q-Day

Cloud storage at rest is often protected by symmetric encryption, such as AES-256. That part remains useful after Q-Day. The post-quantum transition matters more directly for public-key systems used to establish secure connections, manage identities, distribute keys, and verify signatures.

But key control matters now. Strong encryption does not provide provider-blind confidentiality if the provider can obtain the key. Conversely, a client-side encrypted archive can resist provider access but become unrecoverable if its keys, passphrase, or recovery codes are lost.

The right model depends on the data:

Routine working files may benefit most from convenience and recovery.
Long-lived sensitive records may justify client-side or end-to-end protection.
Institutional data may require customer-managed keys, audit records, documented recovery, and contractual controls.

A practical backup model

Do not place every copy, key, and recovery method in one account or one device.

Original device
     ↓
Locally encrypted archive
     ↓
Cloud copy + offline backup + separate recovery information

In practice:

keep working files on an encrypted device;
create a locally encrypted archive for important records;
store one encrypted copy in a reputable cloud service;
keep another encrypted copy offline, such as on a disconnected external drive; and
store recovery information separately from both copies.

A cloud account should not be the only place for the files, the decryption password, and recovery codes. Test the process occasionally: a backup that cannot be restored is not a backup.

What readers should do now

Identify long-lived sensitive files. Health, legal, financial, research, personnel, and private family records may need stronger protection than routine documents.
Learn which cloud encryption model your service uses. Look beyond “encrypted at rest” and ask who controls keys and recovery.
Keep a separate encrypted backup. A cloud sync folder is not a complete backup plan.
Protect cloud-account access. Use a password manager, a unique password, and strong multi-factor authentication.
Protect recovery information separately. Do not store it only in the same cloud account as the encrypted archive.
Keep software current. This is how future post-quantum upgrades will reach users.

What readers do not need to do

Most people do not need to abandon cloud storage, encrypt every routine file manually, or assume that provider-managed AES-256 encryption is worthless.

Match protection to the data. Use convenient cloud services for ordinary work, but treat long-lived sensitive records differently. Know who holds the keys, keep independent encrypted backups, and plan carefully for recovery.

Takeaway: Strong cloud encryption is important, but the decisive question is key control. A provider can encrypt your files and still be able to decrypt them; provider-blind confidentiality requires client-side or end-to-end encryption and a reliable plan for recovery.