Is TLS the same as encryption at rest?

No. TLS is encryption in transit (data moving between systems). Encryption at rest protects data stored on disk. You need both; enterprise questionnaires ask about them separately.

Do we need BYOK to sell to enterprise?

Rarely, and only when specifically demanded. Most enterprise buyers accept provider-managed KMS with clear documentation of which cloud and which region. BYOK requests concentrate in financial services, healthcare, defense, and some EU public sector — a small slice of the market. Do not build it speculatively.

How do we prove encryption is actually on?

Screenshots of AWS/GCP console showing encryption enabled, KMS key ARNs referenced, CloudTrail logs of encrypt/decrypt operations, and infrastructure-as-code (Terraform) that mandates the setting. SOC 2 auditors will ask; have the evidence ready.

Encryption at Rest: KMS, Envelope Encryption

Every enterprise security questionnaire asks about encryption at rest.

Encryption at Rest: Beyond the Checkbox in the Security Questionnaire

Encryption at rest protects data written to disk from an attacker who bypasses application-layer access controls — a stolen backup tape, a mispermissioned S3 bucket, an insider with storage access. Modern cloud providers make baseline encryption free and automatic. The interesting decisions are about key management: who holds the keys, who can revoke them, and whether the customer gets any control.

The baseline every cloud already gives you

AWS S3, EBS, RDS, DynamoDB; GCP GCS, Persistent Disk, Cloud SQL, Bigtable; Azure Blob, Disk, SQL — all encrypt data at rest by default using provider-managed AES-256 keys. Supabase Storage and Postgres inherit this from the underlying cloud. Answering 'yes, all data is encrypted at rest with AES-256' is honest and sufficient for most security questionnaires. What is NOT sufficient: claiming customer data is encrypted while backups, snapshots, log storage, message queues, or third-party subprocessors are not. The commitment is only as strong as the weakest surface.

Envelope encryption and KMS

Rather than one key encrypting all data (dangerous — rotation requires re-encrypting everything), use envelope encryption: a Key Management Service (AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault) holds a Customer Master Key (CMK); the CMK encrypts per-object or per-tenant Data Encryption Keys (DEKs); the DEKs encrypt the actual data. Rotation of the CMK requires only re-wrapping the DEKs, not re-encrypting terabytes of data. KMS operations produce audit logs (CloudTrail) showing every decrypt call — invaluable for incident forensics. Cost: fractions of a cent per operation.

Field-level encryption for sensitive columns

Disk-level encryption protects against stolen disks; it does not protect a Postgres row from an engineer with SELECT permission or from a SQL injection. For truly sensitive fields (SSN, government ID, financial account numbers, source-of-truth secrets), add application-layer encryption: the value is encrypted with a DEK before INSERT and decrypted only in the specific code paths that need it. Search becomes harder (blind indexes, deterministic encryption for equality lookup only, no LIKE/range). Apply narrowly to the fields that warrant it; do not blanket-encrypt everything or you will lose query power without adding real protection.

Customer-Managed Keys and BYOK

Enterprise customers, especially in regulated verticals, may request Customer-Managed Keys (CMK) or Bring-Your-Own-Key (BYOK): the customer provisions a key in their own KMS, grants your application access, and can revoke that access to render their data unreadable ('crypto-shredding'). Architecturally: your app calls the customer's KMS to unwrap per-tenant DEKs; you cache DEKs briefly in memory only; revocation propagates within the cache TTL (target 5-15 minutes). Only worth building for six-figure-plus deals where it is a stated requirement — it adds meaningful complexity, cross-cloud KMS support, and support burden.

Key rotation and incident handling

CMKs should rotate at least annually; KMS providers automate this. Application-layer DEKs rotate on a schedule appropriate to their sensitivity (annual for PII, faster for payments per PCI). On suspected key compromise: rotate immediately, invalidate cached DEKs, force re-decryption path (which now uses new keys), audit the KMS decrypt log for the incident window, notify affected customers per your incident response plan. Test this drill annually — a rotation that has never been rehearsed is not a control, it is a wish.

Frequently asked questions

Is TLS the same as encryption at rest?: No. TLS is encryption in transit (data moving between systems). Encryption at rest protects data stored on disk. You need both; enterprise questionnaires ask about them separately.
Do we need BYOK to sell to enterprise?: Rarely, and only when specifically demanded. Most enterprise buyers accept provider-managed KMS with clear documentation of which cloud and which region. BYOK requests concentrate in financial services, healthcare, defense, and some EU public sector — a small slice of the market. Do not build it speculatively.
How do we prove encryption is actually on?: Screenshots of AWS/GCP console showing encryption enabled, KMS key ARNs referenced, CloudTrail logs of encrypt/decrypt operations, and infrastructure-as-code (Terraform) that mandates the setting. SOC 2 auditors will ask; have the evidence ready.