Encrypted Doesn’t Always Mean Private
When a cloud app tells you your data is encrypted, most people assume that means it is private. That the vendor cannot see it. That if the platform were breached, an attacker could not read it either.
In most cases, none of that is true.
Encryption is not a single thing. It is an architecture — and the details of that architecture determine who, ultimately, holds the keys to your data. Most cloud applications are encrypted in a way that protects data in transit and at rest, but leaves it fully readable by the vendor, their engineers, their cloud provider, and anyone who successfully compromises their systems.
Understanding why requires a short explanation of how encryption actually works in practice — and why the location of the encryption key matters more than the encryption itself.
The Lock and Key Problem
Encryption works by transforming readable data into unreadable ciphertext using a cryptographic key. To read the data again, you need the key. This is straightforward in principle. The complexity — and the vulnerability — lies in where that key is stored and who controls it.
Most cloud applications encrypt your data using keys that they manage themselves. The keys sit alongside the data, in the same system, controlled by the same platform. This means the platform can decrypt your data at any time — to display it to you, to index it for search, to process it for features, or simply because an engineer needs to investigate a support issue.
It also means that anyone who gains access to that system — whether through a breach, a misconfiguration, a malicious insider, or a legal compulsion — gains access to both the data and the keys needed to read it. The encryption is real. The privacy it implies is not.
Why Most Cloud Apps Are Built This Way
This is not negligence. It is a deliberate architectural choice driven by practicality, and it is the dominant model across the industry for a simple reason: it is much easier to build.
When the platform holds the encryption keys, it can do things that would otherwise be impossible — full-text search across documents, AI-powered features, automated processing, seamless collaboration, instant access from any device. All of these capabilities require the platform to be able to read the data. If the data were truly encrypted in a way the platform could not access, none of these features could work.
The result is that most cloud applications — including many that prominently advertise encryption — are built on a model where the vendor is, by design, a trusted party with full access to your content. Their privacy policy tells you they won’t look. Their architecture gives them no choice but to be able to.
The implications of this are significant. It means a developer investigating a bug could, in principle, read your documents. It means a database administrator running a query could see your messages. It means a disgruntled employee with the right access level could exfiltrate your data without touching the encryption layer at all. And it means that in the event of a breach, an attacker who reaches the data layer reaches readable data.
What Application-Level Encryption Actually Means
Application-level encryption takes a different approach. Rather than encrypting data at the infrastructure level — where the platform manages the keys — encryption happens within the application itself, before the data is written to storage. The data arrives at the storage layer already encrypted, in a form the storage system cannot read.
The critical difference is where the encryption keys live. In a properly implemented application-level encryption architecture, the keys are held separately from the data — in a dedicated key management system, a hardware security module (HSM), or a customer-controlled key vault. The application requests a key when it needs to encrypt or decrypt something, uses it for that operation, and does not store it alongside the data.
This separation is the entire point. The data and the keys that unlock it never coexist in the same place. A breach that reaches the data layer finds ciphertext. A breach that reaches the key vault finds keys with no data to unlock. Compromising the system completely requires simultaneously breaching two separate, independently secured environments — a vastly harder task than compromising one.
The Hardware Security Module: A Physical Guarantee
A hardware security module is a dedicated, tamper-resistant physical device designed specifically to generate, store, and manage cryptographic keys. Unlike software key management, which can be compromised by anyone with sufficient access to the underlying system, an HSM provides a physical security boundary that cannot be bypassed in software.
Keys generated inside an HSM never leave it in an unencrypted form. Cryptographic operations happen inside the device. Even the administrators of the system that uses the HSM cannot extract the raw keys — they can only request that the HSM perform a specific operation using a key it holds. If the HSM detects tampering, it destroys its contents.
This is the highest standard of key protection available. It means that even in a scenario where an attacker gains full administrative access to the application and its database, the encryption keys remain physically inaccessible. The data is protected not by a policy or a permission, but by physics.
Customer-Controlled Keys: The Final Step
Application-level encryption with a vendor-managed key vault is a significant step up from standard cloud encryption. But it still places the keys under the vendor’s control — which means the vendor could, if compelled or compromised, access them.
The strongest architecture goes one step further: customer-controlled keys, where the key vault is operated by the customer rather than the vendor. In this model, the vendor’s platform can request that a key be used for an operation, but the customer’s key vault decides whether to honour that request. The vendor never has direct access to the keys. They cannot decrypt customer data without the customer’s active participation.
The practical consequences of this are significant. A legal demand served on the vendor cannot unlock customer data, because the vendor does not hold the keys. A breach of the vendor’s systems cannot expose plaintext data, because the keys are not there. A disgruntled employee at the vendor cannot access customer content, because the access that would enable it does not exist.
The customer retains genuine control — not as a contractual promise, but as a cryptographic fact.
What This Means in Practice for a Breach
The difference between these two models becomes starkest in the scenario both are designed to prevent: a data breach.
In a standard cloud encryption model
An attacker who breaches the database, the storage layer, or the application server gains access to data that the platform can decrypt — which means data the attacker can decrypt, using the same keys the platform uses. Depending on the architecture, this may mean immediate access to plaintext content, or access to encrypted data alongside the keys needed to unlock it. Either way, the encryption provides limited protection once the perimeter is breached.
In an application-level encryption model with HSM or customer key vault
An attacker who breaches the database finds encrypted ciphertext with no keys present. An attacker who breaches the application server finds an application that can request key operations but cannot extract raw keys. To access plaintext data, they would need to simultaneously compromise the application, the data layer, and a separately secured HSM or customer-controlled key vault — three independent security boundaries, each of which would need to be breached without triggering the monitoring and alerting that would shut down the attack.
In practice, this means that application-level encryption with properly managed keys does not just make a breach harder. It makes a breach largely pointless from the attacker’s perspective. The data they can reach is not the data they want.
Why This Also Matters for Insider Threats
External breaches attract headlines. Insider threats are statistically more common and often more damaging.
In a standard cloud architecture, a database administrator, a senior engineer, or a support team member with elevated access can query the database and read customer data. This is not a hypothetical — it is a routine operational capability that most cloud platforms build in, because without it, debugging and support become very difficult. The safeguard is policy: employees are told not to look at customer data without authorisation. The technical capability to do so exists regardless.
In an application-level encryption architecture with separated keys, that capability does not exist. A database administrator querying the data layer sees ciphertext. An engineer with application access cannot retrieve plaintext without triggering a key operation that is logged, audited, and in a customer-key model, requires the customer’s own infrastructure to authorise. The safeguard is not policy. It is architecture.
This distinction matters enormously for any organisation handling sensitive client data — legal, financial, medical, or personal. The question to ask of any cloud platform is not “do you encrypt our data?” Almost all of them do. The question is: “who holds the keys, and what would it take for someone to use them without our knowledge?”
The Standard You Should Expect
Encryption is table stakes. It is the minimum, not the standard. The meaningful question is not whether your data is encrypted but whether the architecture ensures that encryption actually translates into privacy — for you, from the vendor, from the vendor’s infrastructure provider, and from anyone who might compromise any of them.
Application-level encryption with keys held in an HSM or a dedicated key vault — ideally one you control — is the architecture that answers that question with confidence. It is not the easiest architecture to build or operate. It is the one that makes the encryption promise real.
The difference between encrypted and private is where the key lives. Make sure you know where yours are.
