Encryption in transit and at rest.
Data lives in two everyday situations, and each one needs its own kind of lock. One scrambles data while it moves. The other scrambles it while it sits still. You want both.
Encryption in transit protects data crossing a network. Encryption at rest protects data stored on a disk, in a database, or in a backup. We walk the field the way it is built: what these two states are, why the keys are the hard part, how the standards work, what they unlock, and where it is heading. The source standards behind each idea are linked, so you can read them yourself.
Two situations, two locks.
Data is in transit when it moves across a network. It is at rest when it sits still on a disk, in a database, or in a backup. Each needs its own protection.
Encryption in transit scrambles data while it travels, so anyone who taps the wire sees noise. The dominant standard is Transport Layer Security, current version TLS 1.3 (RFC 8446). Encryption at rest scrambles data while it is stored, so anyone who walks off with the drive, or the backup file, sees noise too. The workhorse cipher is the Advanced Encryption Standard, AES (FIPS 197).
A useful picture: in transit is the armored truck that carries the cash between buildings. At rest is the vault the cash sits in once it arrives. An armored truck is no help if the vault is left open, and a sealed vault is no help if the truck is an unmarked van anyone can flag down. There is a third state, data in use, computing on data while it stays encrypted. That is its own frontier, covered in Secure enclaves.
One line on the math. Bulk data is encrypted with fast symmetric keys (AES). Slower asymmetric, or public-key, math is used mainly to agree on or wrap those symmetric keys, which is what the TLS handshake and envelope encryption both do. And confidentiality alone is not enough: real systems use authenticated encryption, or AEAD, so a tampered message is rejected rather than silently decrypted. AES-GCM (NIST SP 800-38D) is a common choice.
The cipher is the easy part. The keys are the work.
AES and TLS are public, peer-reviewed, and decades deep in analysis. The failures in practice are almost never the cipher. They are configuration, protocol, and key handling.
Encryption moves the problem to the keys.
Encryption converts a data-protection problem into a key-protection problem. NIST SP 800-57 exists precisely because managing keys over their full lifecycle, generation through destruction, is where the difficulty concentrates.
A key next to its data buys little.
If the key sits beside the data it unlocks, encryption at rest does not help much against an attacker who reaches the storage. This is why keys are separated from data and pushed into dedicated systems and hardware.
Is one tenant separated from another?
In multi-tenant software, the meaningful question is not only "is it encrypted" but "is one customer's data cryptographically isolated from another's." Per-tenant keys are one way the field expresses that boundary. Stated here as a field concept, not a product claim.
Rotation and revocation never stop.
Keys must change on a schedule and be retired without re-encrypting petabytes by hand. Doing this without downtime or data loss is a design problem in itself.
The pitfalls are subtle.
Nonce or IV reuse in GCM, weak randomness, downgrade attacks, expired or mis-issued certificates, and keys logged or backed up in the clear are the recurring real-world failures. The standards exist to remove these footguns, but only if followed.
It is table stakes for a security review.
Regulated data and contractual commitments increasingly require both states encrypted and keys managed to a documented standard. A review rarely stops at "is it encrypted." It asks how keys are generated, stored, separated, and rotated.
How the locks actually work.
First the channel for data on the move. Then the cipher for data at rest. Then the pattern that lets a handful of keys protect millions of records, and lets you rotate or destroy them cleanly.
1The channel, in transit
Prove who you are, agree on a key, then scramble.
The TLS handshake does three things. The two parties authenticate, usually the server via a certificate. They agree on fresh shared keys using public-key key exchange, Diffie-Hellman. Then they switch to fast symmetric AEAD encryption for the actual traffic. TLS 1.3 streamlined this to one round trip and removed the old, weak options.
It also uses ephemeral key exchange, which gives forward secrecy: each session's keys are temporary, so recording today's traffic does not let an attacker decrypt it later even if a long-term key is later exposed. Worth one clarification: encryption in transit is not the same guarantee as end-to-end encryption. They protect different things.
- Authenticate
Validate the server’s certificate and identity.
- Agree session keys
Use the handshake to derive fresh shared secrets.
- Protect application data
Authenticated encryption protects confidentiality and detects tampering.
2The vault, at rest
A symmetric cipher, run in an authenticated mode.
AES is a symmetric block cipher: 128-bit blocks, with 128, 192, or 256-bit keys. For stored data it is run in an authenticated mode such as GCM, so the data is both secret and tamper-evident. The same record that read plainly to the application is, on disk, just ordered ciphertext to anyone without the key.
The honest note the standard itself makes: the cipher is the easy part. NIST SP 800-38D is largely about using GCM correctly, and a single misuse, reusing a nonce, can undo the guarantee. Strong primitives do not save a careless deployment.
Account 482: renewal terms
ciphertext + authentication tagValid key and tag
Modified ciphertext
Authentication check fails.
3How keys scale
Envelope encryption: a small key locks the data, a master key locks that.
You do not protect millions of records with one master key. A per-object or per-tenant Data Encryption Key, the DEK, encrypts the data. The DEK is then itself encrypted, or "wrapped," by a Key Encryption Key, the KEK. The wrapped DEK is stored next to the ciphertext; the KEK stays in a central, guarded place. The Google Cloud KMS docs are a clean reference for the pattern.
The KEK lives in a Key Management Service, a KMS, typically backed by a Hardware Security Module, an HSM: tamper-resistant hardware where the key is generated and used but never leaves in the clear. That is the de-privileging move. Data and the master key are deliberately kept apart.
- Data encryption key (DEK)
Encrypt the bulk record or object.
- Key encryption key (KEK)
Wrap the DEK under a separately controlled key.
- Store
Keep ciphertext with its wrapped DEK and key reference.
4Separation of duties
Keep the key away from the lock it opens.
When keys sit in a KMS or HSM separate from data, access to data and access to keys become two different doors. Whoever runs the storage cannot, by itself, read the content. An intruder through the storage door finds only ciphertext.
This is also where tenant isolation becomes something you can point to. Per-tenant KEKs give a concrete answer to "is my data separated from other customers'." As an illustration of the field, picture a sales co-pilot holding one company's call recordings, pipeline, and pricing: per-tenant keys are how the field keeps one client's data cryptographically isolated from another's. A field concept, not a description of any one product's plumbing.
Storage service
- Contains
- Ciphertext and wrapped data keys.
- Permission
- Read or write encrypted objects.
Key service
- Controls
- Use of the wrapping key.
- Permission
- Authorize unwrap or decryption operations.
5Rotation and retirement
Change the master key without touching the data.
Because only the small DEKs are wrapped by the KEK, rotating the KEK means re-wrapping DEKs, not re-encrypting the data. Per-tenant KEKs let one customer's keys be rotated, or destroyed, independently of everyone else's.
That last point unlocks crypto-shredding: destroy the key and the data it protected becomes unrecoverable ciphertext. As a field illustration, deleting a tenant's KEK turns "delete all my data" from a long, hard-to-prove batch job into a fast, auditable act. The mechanics of doing this safely sit with NIST SP 800-57, which is the reference for the full key lifecycle.
- Rotate the wrapping key
- Rewrap data keys under the new key without rewriting every bulk object.
- Destroy required key material
- Make remaining ciphertext unreadable only if no usable key copies or plaintext copies remain.
What both states, well managed, give you.
At the field level: a defensible baseline, separation of duties, tenant isolation you can point to, clean offboarding, and the evidence a security review asks to see.
A stolen disk or sniffed wire yields noise.
Both states encrypted with public standards means a stolen disk, a sniffed network, or a leaked backup gives an attacker ciphertext, not content.
Running the storage is not reading it.
Keeping keys in a KMS or HSM, apart from data, means whoever operates the storage cannot, by itself, read what is in it.
A concrete answer on separation.
Per-tenant keys give a field-level answer to "is my data separated from other customers'." For product specifics, the right place is Security.
"Delete my data," made fast and verifiable.
Crypto-shredding turns a long, hard-to-prove batch job into "destroy the key," which is quick and auditable.
Exactly what a review asks for.
Documented algorithms, key lifecycles, and rotation policies are the artifacts a SOC 2, ISO 27001, or GDPR review wants to see.
Necessary, not sufficient.
Encryption protects data from the wire and the disk. It does not by itself solve access control, authorization, or who-can-see-what inside the application.
Why this matters for a sales evaluator. Sales conversations carry sensitive material: call recordings, customer names, pipeline, pricing, what was actually said. A security review will ask whether that data is encrypted moving and at rest, where the keys live, and whether one customer's data is separated from another's. This page exists so a technical evaluator can reason about those questions on the field's own terms. For our actual approach, algorithms, key custody, tenant isolation, hosting, and residency options, the place to look is Security.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
Upgrading the handshake.
A future quantum computer threatens today's public-key key exchange, the handshake step. NIST standardized post-quantum algorithms (FIPS 203 / 204 / 205, 2024), and the next key-management guidance (SP 800-57 Rev. 6, in draft) folds them in. Expect hybrid classical-plus-PQC key exchange in TLS during the transition.
Why the migration is being pushed now.
Long-lived sensitive data encrypted in transit today could be recorded and decrypted later. That is why PQC migration is moving now, not at the moment quantum hardware arrives. The cipher at rest holds up; it is the handshake being upgraded.
More control over the master key.
Bring-your-own-key and hold-your-own-key models give enterprises more control over the KEK, including the ability to cut access by withdrawing the key.
Encryption closer to the data.
Encryption at rest and in transit is increasingly default-on at the platform layer, with the interesting work moving up to key custody and to protecting data in use. See Secure enclaves.
The standards behind this page.
- IETF, E. Rescorla (2018). RFC 8446 · The Transport Layer Security (TLS) Protocol Version 1.3.
- NIST (2001, updated 2023). FIPS 197 · Advanced Encryption Standard (AES).
- NIST (2007). SP 800-38D · Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
- NIST (2020). SP 800-57 Part 1 Rev. 5 · Recommendation for Key Management: General. (Rev. 6, adding post-quantum, is in draft.)
- Google Cloud (documentation). Envelope encryption (Cloud KMS). Cited as a neutral reference for the DEK / KEK pattern.
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
Sensitive sales data deserves enterprise-grade handling by a team that understands the standards and where they are going. See the product on a real call, and find the specifics on Security.
No app required. Just your phone number.