Can a vendor read 'encrypted' data? It depends on which encryption.

"Encrypted" is the most overloaded word in workspace marketing. Every major SaaS tool advertises encryption. Slack is encrypted. Notion is encrypted. Dropbox is encrypted. Gmail is encrypted. Most of them can also read your data. Both statements are true.

The reconciliation is that there are several distinct types of encryption a workspace tool can use, and only one of them prevents the vendor from accessing content. Understanding the difference is the difference between trusting a policy and trusting a property.

TLS (the "https://" in your browser bar) encrypts data on the network between your device and the vendor's servers. Without TLS, anyone sniffing the network could read what you sent — a former problem of the open-WiFi era. Modern web traffic is almost universally TLS-encrypted.

What it protects you from: passive network observers, untrusted WiFi, ISP-level snooping of content. What it doesn't protect you from: the vendor's servers themselves. Once your data arrives at the vendor, it's decrypted and the vendor can read it.

When data sits in the vendor's databases or file storage, it's typically encrypted at rest — meaning the disk blocks holding your data are encrypted with a key the vendor manages. AWS KMS, Azure Key Vault, Google Cloud KMS, or self-managed equivalents handle this. If an attacker physically stole the vendor's disks, they couldn't read them without the keys.

What it protects you from: physical-disk theft, certain classes of cloud-storage misconfigurations, some backup-tape exposures. What it doesn't protect you from: the vendor's services. When a Slack server needs to render a message, it asks KMS for the key, decrypts the row, and reads it. Encryption-at-rest is a property of the storage, not of the data flow.

Some enterprise tiers (Microsoft 365 Customer Key, Google Workspace external KMS, AWS SSE-C) let the customer supply the encryption keys for data at rest. The vendor's services still decrypt at runtime — they ask the customer's KMS for the key, decrypt the data, operate on it, re-encrypt before storing. The customer-managed-key model adds a checkpoint where the customer's KMS can refuse, log, or revoke key access.

What it protects you from: at-rest exfiltration (an attacker who steals disks can't decrypt without the customer's key), some classes of insider threat (a rogue vendor employee can't decrypt without going through the customer KMS path). What it doesn't protect you from: anything the vendor's services can do at runtime, including reading content for product features.

Google Workspace Client-Side Encryption (CSE) is the most prominent example. Data is encrypted on the user's device before it's uploaded to Google. Google never sees the cleartext. The customer's Key Service holds the keys; the customer's IT team manages the deployment.

What it protects you from: vendor-side cleartext access at every layer — storage, services, support staff, AI. The vendor truly holds ciphertext for covered surfaces. What it doesn't protect you from: surfaces not covered by CSE (most of the workspace, by surface count), the cost of running a Key Service, the complexity of managing the customer-managed-key lifecycle.

Signal, Koaich, Proton Mail, and a few others use end-to-end encryption with keys held on the user's device — not by an IT team's central KMS, but on the actual device. Encryption happens before data leaves the device; decryption happens only on the recipient's device. The vendor holds ciphertext at every layer, with no recoverable key.

What it protects you from: every class of vendor-side access. The vendor cannot read content for product features, AI, support, or legal demands — not because they choose not to, but because they don't have the key. What it doesn't protect you from: a compromise of your own device (an attacker with your device has your keys), or loss of your own keys without recovery setup (your data is gone, by design).

When a vendor says "your data is encrypted" without specifics, the default is: TLS in transit + server-side encryption at rest with vendor-held keys. This is the standard SaaS posture. The vendor's runtime services can read your content; everything the vendor does at runtime depends on cleartext access.

Look for: who holds the keys (vendor, customer, user) and at which layer encryption happens (transit, storage, server-side runtime, customer-side, user-device). The combination of those two answers tells you what the vendor can do with your data — not the marketing claim.