1 min lesson
CMEK: customer-managed encryption keys
Work through this: "A teammate says the customer-data store is secure because everything is encrypted at rest with an AES key kept in the application's config so the app can decrypt fast. What's wrong and how would you fix it?"
Step 1 of 2
CMEK: customer-managed encryption keysCursor offers this to enterprise
Cursor offers customer-managed encryption keys to enterprise customers, so be ready to explain the model. With CMEK, the customer controls the key that encrypts their data, often in their own cloud KMS and grants the provider scoped permission to use it.
- Control
- The customer holds the master key; you use it under a grant you don't own.
- Revocation
- If trust breaks, the customer revokes key access and their data-at-rest becomes unreadable - a hard kill switch.
- Auditability
- Decrypt calls show up in the customer's own KMS logs, not just yours.
- The catch
- Key availability becomes a shared dependency: if the customer's KMS is down or the grant is revoked, your service can't decrypt either. Design for that operationally.
Before you call any encryption design done, answer three questions out loud: where is the key, who can use it to decrypt and is every decrypt logged. If the key sits in the same trust boundary as the data with no access controls, you've encoded the data, not protected it.