What is envelope encryption and does a payments startup need it?

Envelope encryption uses two layers of keys. A data encryption key (DEK) encrypts your records, and a key encryption key (KEK) encrypts the DEK. You rotate or revoke the KEK without re-encrypting every record. Most payments startups that store sensitive fields on a managed cloud benefit from it.

The two key layers

A DEK is the key that touches your data. It might encrypt one customer record, one file, or one database column. A KEK never touches the data itself. It just wraps, meaning encrypts, the DEKs, and the wrapped DEKs are stored next to the ciphertext they protect.

The OWASP Key Management guidance describes the same split: where several keys are used, such as separate data encrypting and key encrypting keys, they should be fully independent of each other. If a DEK is generated from the same material as the KEK, the layering buys you nothing.

Why the layering helps a small team

Rotation is where envelope encryption pays off. OWASP notes that to retire a KEK you re-wrap the stored DEKs under the replacement KEK before destroying the old one. Re-wrapping leaves the DEKs unchanged, so you do not re-encrypt the underlying data. That makes KEK rotation a quick job instead of a migration project.

There is a catch, and it is worth knowing before an audit conversation. Re-wrapping does not reset a DEK's cryptoperiod or usage limits. If you need to replace a DEK for existing ciphertext, you must re-encrypt that data. Treat the two rotations as separate procedures with separate runbooks.

A second benefit is access separation. Application code can be allowed to ask a key service to unwrap a DEK for a specific record, while engineers have no standing permission to read the KEK at all. That fits the least privilege advice in the OWASP secrets guidance, which says engineers should not have access to all secrets.

When you probably need it

You likely want envelope encryption if you:

1. Store sensitive fields yourself, such as bank account details or identity documents.
2. Need to revoke access to one customer's data without touching others.
3. Use a managed key service and want rotation to be automatic.
4. Expect a partner bank or large customer to ask how keys are separated from data.

You can probably skip it if you hand all sensitive data to a payment processor and never store it. OWASP's storage guidance is blunt on this: the strongest protection for sensitive information is not storing it in the first place.

A short adoption plan

1. List what you store and mark which fields truly need encryption at the application level.
2. Choose where encryption happens. OWASP lists application, database, filesystem and hardware levels, and says the right choice depends on your threat model. Disk encryption does nothing against an attacker who compromises the running server.
3. Use an authenticated mode such as GCM through a maintained library. Do not write your own algorithm.
4. Store a key ID with every ciphertext so old and new keys can coexist.
5. Write down both rotation procedures and rehearse them in a test environment.
6. Log every unwrap request. OWASP asks that you audit who requested a secret, for what system, and whether the request was approved.

Where Safeguard fits

Safeguard does not hold or manage your keys. It helps on the code side: dependency scanning and reachability analysis show whether the crypto libraries you rely on carry known flaws that your code actually reaches, and policy gates can stop a risky library change before it merges. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• OWASP Cryptographic Storage Cheat Sheet
• OWASP Key Management Cheat Sheet
• OWASP Secrets Management Cheat Sheet

Last reviewed: 19 October 2026.