The Gap Between Claim and Architecture
Updated for 2026
Every cloud vendor says the same thing: "We encrypt your data." That claim is almost always true. It is almost always not enough.
The LastPass breach of 2022 is the best example. LastPass encrypted user password vaults. They used real encryption. The claim was accurate. And yet 25 million users had their vaults stolen. By 2025, $438 million had been taken from LastPass users in crypto heists. Coinbase Institutional tracked this figure.
The UK Information Commissioner's Office fined LastPass's UK entity £1.2 million in December 2025. The reason: "failure to implement appropriate technical and organisational security measures." The encryption was real. But it did not meet the required standard.
The LastPass case changes the key question for any cloud privacy tool. Not "do they encrypt our data?" but: "can they decrypt our data?"
Four Questions That Actually Matter
Four questions reveal whether a vendor's zero-knowledge claim holds up.
1. Where does key derivation happen?
In true zero-knowledge design, key derivation happens on the client. This means in the browser or desktop app, before any data is sent. The key encrypts data locally. Only ciphertext reaches the vendor's servers.
If the vendor derives keys on their servers, they hold the keys. If they hold the keys, they can decrypt. The claim may be accurate — but it misleads.
2. Does the vendor ever see plaintext?
Some tools encrypt data at rest. But they decrypt it for processing. This can happen to run AI models, search indexes, or audit logs. During that window, plaintext is on the vendor's systems. An attack at that moment exposes unencrypted data.
3. What happens under legal process?
A vendor with server-side keys can be forced to hand over decrypted content. A vendor with true zero-knowledge can only produce ciphertext. They have nothing useful to hand over, even under a subpoena.
4. What does a full server compromise expose?
In a genuine zero-knowledge system, a full compromise yields only encrypted blobs. The attacker gets ciphertext with no keys. In a vendor-key system, an intrusion exposes both keys and data at once.
The LastPass Implementation Gap
The LastPass incident revealed one specific flaw. Older accounts used PBKDF2 with as few as 1 iteration for key derivation. The safe count is 600,000 iterations. That weak setting made brute-force attacks on stolen vaults feasible.
This shows why checking the design alone is not enough. A vendor can use a zero-knowledge design and still implement it poorly. Ask about both: where keys are derived, and how strong the algorithm is.
A Different Failure Mode: Okta
In October 2023, Okta disclosed a leak of 600,000+ customer support records. Okta is an identity platform. This was not a weak zero-knowledge design. It was a support system intrusion that held customer data.
The 300% SaaS attack surge in 2024 (AppOmni/CSA) reflects both failure types. Zero-knowledge design addresses the first type. It does not remove all risk. But it ensures a full system compromise exposes no decryptable customer data.
What a Real Evaluation Looks Like
Here is a practical checklist for procurement teams.
Architecture review:
- Ask where key derivation occurs — on the client or on the vendor's server
- Ask for the encryption algorithm, key length, and iteration count
- Confirm plaintext is never sent to vendor servers
Compromise scenario test:
- Ask what a full server compromise would expose
- The only correct answer: "encrypted ciphertext we cannot decrypt"
- Any other answer means the claim is not real zero-knowledge
Legal process review:
- Ask whether the vendor can comply with a subpoena for customer plaintext
- A real zero-knowledge vendor cannot produce what they do not have
Compliance check:
- Request the vendor's GDPR Article 32 documentation
- ISO 27001 — specifically Annex A cryptographic controls — gives external verification
The £1.2 million LastPass ICO fine shows regulators now check whether encryption claims meet a required standard. Procurement teams can apply the same test before an incident happens.
See our security and compliance overview for how anonym.legal handles zero-knowledge. The compliance documentation covers GDPR Article 32 in full. For common questions, see the zero-knowledge FAQ.