GDPR and Credentials: What Encryption Actually Requires

GDPR isn't a technical standard. It doesn't say "use AES-256" or "encrypt with X25519." But it does say, fairly clearly, that encryption is one of the security measures organizations handling personal data are expected to have — and that extends, indirectly, to how you protect the credentials that grant access to that data.

This post covers what GDPR encryption requirements actually say, why API keys and tokens matter even though they aren't "personal data" themselves, and what a secrets manager can and can't fix.

What GDPR says about encryption (and what it doesn't)

Article 32: technical and organizational measures

Article 32 of GDPR requires "appropriate technical and organizational measures" to ensure a level of security appropriate to the risk. It explicitly names pseudonymization and encryption of personal data as an example — an example, not a mandatory checklist item for every case.

That has two practical implications:

• There's no closed list of GDPR-approved algorithms.
• What's required is that the measure be proportional to the risk: the more sensitive the data and the higher the impact of a breach, the harder it is to justify not encrypting.

For infrastructure credentials — API keys, database tokens, third-party secrets — the reasoning is direct: if those credentials grant access to personal data, protecting them is part of protecting that data. A leaked DATABASE_URL in a public repo isn't just a technical mishap — it's an unauthorized access path to personal data, and it falls squarely under Article 32.

Article 34: the breach-notification exemption

This is where encryption stops being a nice-to-have and starts having concrete legal weight. Article 34 requires notifying affected individuals when a breach poses a high risk to their rights — unless the data was encrypted in a way that renders it unintelligible to anyone who accessed it without authorization.

In plain terms: if your secrets are encrypted so that an attacker who steals the database can't read them, you may be exempt from a public notification that would damage user trust and your reputation. If they're sitting in plaintext in a leaked .env file or a misconfigured bucket, there's no exemption to claim.

Why API keys and tokens matter here

GDPR regulates "personal data," and an API key isn't a name, an email, or a bank account number. But in practice, most of the credentials development teams manage are the front door to systems that do hold personal data: user databases, transactional email providers, payment gateways, analytics platforms.

Thousands of secrets leak every day across public repos, logs, screenshots, and misconfigured CI builds — that's not a hypothesis, it's the most common pattern in industry incident reports. AI-generated code has accelerated this: an assistant that autocompletes a sample .env with a real key, or copies a credential from one project to another, is now one of the most common leak paths. We go deeper on this in /ai-security.

In transit, at rest, and end-to-end

Not all "encryption" is equal for compliance purposes:

• Encryption in transit (TLS): protects the secret while it travels over the network. It's table stakes, not a differentiator.
• Encryption at rest: protects the secret in the provider's database. It reduces risk, but if the provider holds the decryption key, they can still read your secrets — and so can an attacker who compromises their infrastructure.
• End-to-end (zero-knowledge) encryption: the provider only ever stores ciphertext and never has access to the decryption keys. This is the level that best supports the Article 34 exemption, because even if the provider suffers a breach, the data stays unintelligible.

Koove operates at this last level: end-to-end encryption using X25519 and AES-256-GCM (envelope encryption), built on open-source cryptographic primitives (@koove/crypto). The server stores ciphertext only; secrets decrypt only on consumers verified through mobile attestation (Apple App Attest / Google Play Integrity) plus biometrics, or on authorized backends.

What this looks like in practice

# Store a secret without it ever touching a plaintext .env
koove set STRIPE_SECRET_KEY sk_live_xxx --env prod

# See what's stored (metadata only, never the plaintext value)
koove list --env prod

# Approve a new developer's device before it can decrypt anything
koove device-approve --device-id <id>

# Rotate encryption when someone leaves the team
koove rewrap --env prod

The application code only ever references STRIPE_SECRET_KEY by name — the real value never gets written to a file or handed to an AI assistant autocompleting the repo. Full technical details are in /docs/sdk, and the architecture is documented in /security.

What encryption doesn't solve on its own

It matters to be honest about the limits, because GDPR compliance isn't achieved with a single tool:

• Encryption doesn't replace a lawful basis for processing, a record of processing activities, or a risk assessment. It's one technical control inside a broader framework.
• Revoking a device's access or rotating a secret doesn't undo access already granted. If a developer already decrypted and copied a credential before their access was revoked, that copy still exists somewhere. koove device-revoke and koove rewrap protect future access — they don't erase what's already been exposed.
• Koove doesn't replace a compliance audit. We don't hold SOC 2 or ISO certifications — if your organization needs those for a customer or auditor, you'll need to evaluate that as part of your own due diligence, not assume an encryption tool grants them automatically.

A practical checklist

• Inventory which credentials grant access to personal data — not just which ones "look sensitive."
• Check whether any secrets travel in plaintext at any point: CI/CD, logs, committed .env files.
• Prioritize end-to-end encryption for high-impact credentials (production databases, payment providers).
• Document your rotation and revocation process — GDPR values having a documented procedure, not just technology.
• Check pricing and access models in /plans before deciding what level of protection each environment needs.

If you have specific questions about attestation, devices, or recovery, /faq covers the most common cases.

Start with what you can actually control

GDPR won't tell you which algorithm to use, but it does require you to be able to show that credentials protecting personal data aren't sitting around in plaintext. It's one of the few areas where a concrete technical decision — encrypting end-to-end instead of relying on loose environment variables — has a direct legal effect.

If you want to stop managing secrets by hand and start encrypting them end-to-end from your very first koove set, you can sign up here.