Episode 28 · Module 7 · Data Protection

Encryption at Rest vs. in Transit

19 May 2026 · 9:57 · Security for Legal SaaS

9:57 9:57

Data exists in two states: at rest (stored on a disk, in a database, on a backup tape) and in transit (moving between your browser and a server, between microservices, between data centres). Each state faces a different threat: You need both. Encrypting data in transit without encrypting it at rest means a stolen database backup exposes everything in plaintext. Encrypting at rest without encrypting in transit means an attacker on the network can read data as it flows between services. For legal SaaS platforms handling privileged client communications, both are non-negotiable.

Today’s Lesson

Security for Legal SaaS — Episode 28: Encryption at Rest vs. in Transit

Two States of Data, Two Threats

Data at rest is vulnerable to physical theft (stolen laptop, decommissioned hard drive), unauthorized database access, and backup exposure
Data in transit is vulnerable to eavesdropping, man-in-the-middle attacks, and network interception

You need both. Encrypting data in transit without encrypting it at rest means a stolen database backup exposes everything in plaintext. Encrypting at rest without encrypting in transit means an attacker on the network can read data as it flows between services. For legal SaaS platforms handling privileged client communications, both are non-negotiable.¹

Symmetric vs. Asymmetric Encryption

Before diving into implementation, two fundamental encryption approaches — both referenced throughout this series:

Type	How It Works	Speed	Use Case
Symmetric	Same key encrypts and decrypts. AES-256 is the standard	Fast — suitable for bulk data	Encrypting database records, files, backups
Asymmetric	Different keys for encryption (public key) and decryption (private key). RSA, ECDSA	Slow — computationally expensive	Key exchange, digital signatures, TLS handshakes

In practice, most systems use both: asymmetric encryption to securely exchange a symmetric key, then symmetric encryption for the actual data. This is exactly how TLS works, as we covered in Episode 13.²

AES-256 (Advanced Encryption Standard with 256-bit keys) is the industry standard for symmetric encryption. NIST approved it for protecting classified information up to the Secret level. No successful attack against AES-256's core algorithm has ever been demonstrated in over two decades of cryptographic analysis.³

Encryption at Rest

Transparent Data Encryption (TDE)

The simplest form of encryption at rest is Transparent Data Encryption — encryption handled by the database engine itself, invisible to the application. PostgreSQL, MySQL, SQL Server, and all major cloud databases support TDE:⁴

Database	TDE Support
AWS RDS / Aurora	Enabled by default since 2022. AES-256 using AWS KMS keys
Azure SQL	Enabled by default. AES-256 with service-managed or customer-managed keys
Google Cloud SQL	Enabled by default. AES-256 with Google-managed or customer-managed keys
PostgreSQL (self-hosted)	Via `pgcrypto` extension or filesystem-level encryption

TDE encrypts the entire database at the storage level — data files, transaction logs, and backups are all encrypted on disk. When the database engine reads data, it decrypts it transparently. The application code is completely unaware that encryption exists.

Limitation: TDE protects against physical theft of storage media and unauthorized file system access. It does not protect against an attacker who has valid database credentials — they query the database through the normal interface, and TDE decrypts the data for them automatically. TDE is a floor, not a ceiling.⁵

Application-Layer Encryption

For stronger protection, sensitive fields can be encrypted at the application layer before they reach the database. The database stores ciphertext — encrypted data that is meaningless without the encryption key:

Client communication stored as:
  AES-256-GCM(key, "Privileged strategy discussion: recommend settling for...")
  → stored in database as: "xK7mQ2p9bR4..." (ciphertext)

With application-layer encryption, even a database administrator with full access sees only ciphertext. The decryption key never exists in the database — it's held in a separate key management system.

Tradeoff: Application-layer encryption breaks database features that need to read the plaintext — full-text search, sorting, range queries, and indexing on encrypted fields. For legal SaaS, this means you may need a separate, encrypted search index (like we discussed in Episode 25 for ethical walls) or selective encryption that protects the most sensitive fields while leaving searchable metadata unencrypted.⁶

Envelope Encryption: The Key Management Pattern

The fundamental question with encryption at rest is: where do you keep the key? If the encryption key is stored next to the encrypted data — in the same database, on the same server — then stealing the server gives the attacker both the lock and the key. This is security theatre.

Envelope encryption solves this by creating a key hierarchy:⁷

Master Key (KEK — Key Encryption Key)
  └── stored in a Hardware Security Module (HSM) or KMS
  └── never leaves the HSM / KMS
  └── encrypts/decrypts Data Encryption Keys

Data Encryption Key (DEK)
  └── unique per record, per table, or per tenant
  └── encrypts the actual data
  └── stored alongside the data — but encrypted with the Master Key

The flow:

To encrypt data: generate a new DEK → encrypt the data with the DEK → encrypt the DEK with the Master Key → store the encrypted DEK alongside the encrypted data
To decrypt data: retrieve the encrypted DEK → send it to the KMS to decrypt using the Master Key → use the decrypted DEK to decrypt the data → discard the DEK from memory

The Master Key never leaves the hardware security module. The DEK is only in memory briefly during encryption/decryption operations. Even if an attacker steals the entire database — encrypted data and encrypted DEKs — they cannot decrypt anything without access to the KMS.⁸

AWS KMS, Google Cloud KMS, and Azure Key Vault all implement this pattern. They manage the master keys in FIPS 140-2 Level 3 certified HSMs and provide APIs for envelope encryption operations. For legal SaaS on any major cloud provider, there is no reason to build your own key management — use the provider's KMS.⁸

Encryption in Transit

We covered TLS in depth in Episode 13. The key points for this discussion:

Requirement	Standard
Minimum TLS version	TLS 1.2 (NIST SP 800-52 Rev. 2). TLS 1.3 preferred
Cipher suites	AES-256-GCM with ECDHE key exchange for forward secrecy
Certificate management	Automated via Let's Encrypt / ACME protocol
Internal traffic	mTLS between microservices (covered in Episode 15)

For a legal SaaS platform, encryption in transit covers:

Browser to server: HTTPS (TLS) for all client-facing traffic — no exceptions, no mixed content
Server to database: TLS-encrypted database connections. Most cloud databases enforce this by default
Service to service: mTLS between microservices, as covered in Episode 15
Server to external APIs: TLS for all outbound connections (e-filing systems, court APIs, document services)

Callout: Don't forget internal traffic. Many teams encrypt browser-to-server traffic but leave internal service-to-service communication unencrypted. In a zero-trust architecture (Episode 26), all traffic is encrypted — there is no "trusted internal network."⁹

Legal Requirements

Multiple regulatory frameworks mandate encryption for legal technology:

Regulation	Encryption Requirement
ABA Model Rule 1.6(c)	"Reasonable efforts" to prevent unauthorised access — encryption is increasingly the expected standard
GDPR Article 32	Encryption listed as an appropriate technical measure for data protection
HIPAA Security Rule	Encryption required for ePHI (electronic protected health information). AES-256 minimum. NIST SP 800-111 for at rest, SP 800-52 for in transit
SOC 2 Type II	Encryption in transit and at rest required for Trust Services Criteria CC6.1 and CC6.7
PCI DSS 4.0	Encryption of cardholder data in transit and at rest. AES-256 or equivalent
Singapore PDPA	Encryption recommended as a reasonable security arrangement under Section 24

For legal SaaS specifically, the convergence is clear: every framework your clients care about requires encryption. The question is not whether to encrypt, but how thoroughly.¹⁰

Performance Impact

A common concern is that encryption adds latency. In practice:

Operation	Performance Impact
TLS handshake	~1-2ms with TLS 1.3 (one round trip). Amortised across session — negligible
TDE (database)	1-5% CPU overhead on modern hardware with AES-NI instruction support. All major cloud instances include AES-NI
Application-layer encryption	Per-field AES-256-GCM: microseconds per operation. Negligible for individual records
Envelope encryption	One KMS API call per decrypt operation (~5-20ms for network round trip). Mitigated by caching DEKs in memory for short periods

Modern CPUs include dedicated hardware instructions for AES encryption (Intel AES-NI, ARM AES extensions). On a server with AES-NI, TDE is essentially free — the CPU can encrypt and decrypt at memory speed. The only non-trivial cost is the KMS API call for envelope encryption, which can be mitigated by caching decrypted DEKs in memory with a short TTL.¹¹

When encryption costs: The main performance concern is not CPU but searchability. Application-layer encryption of database fields eliminates the ability to query, sort, or index those fields at the database level. For legal SaaS, this means careful architectural decisions about which fields to encrypt at the application layer (client names, communication content, strategy notes) versus which to protect only at the TDE level (timestamps, matter IDs, status flags).⁶

What's Next

Episode 29 covers Key Management and Rotation — the operational practices that determine whether your encryption is actually secure, including key hierarchies, rotation strategies, and the disaster recovery question: "what if we lose the key?"

Sources & Further Reading

Sources & references

Censinet, Encryption at Rest vs. Encryption in Transit: Differences — comprehensive comparison.
Kiteworks, Beyond AES-256 Encryption: Multi-Layer Protection — symmetric and asymmetric encryption in practice.
NIST, Advanced Encryption Standard (AES) — FIPS 197, the AES specification.
Microsoft, Azure Data Encryption at Rest — TDE implementation on Azure.
Google Cloud, Default Encryption at Rest — Google's encryption-by-default architecture.
Netwrix, Securing Data at Rest, in Use, and in Motion — comprehensive data protection guide.
AWS, AWS KMS Cryptographic Details — envelope encryption and key hierarchy architecture.
AWS, AWS KMS Key Hierarchy — master keys, data keys, and HSM-backed storage.
NIST, SP 800-52 Rev. 2: Guidelines for TLS Implementations — TLS version and cipher suite requirements.
FDG Web, NIST Encryption Standards for PHI — NIST standards mapped to regulatory requirements.
FileCloud, Data at Rest vs. in Transit: Encryption & Security Guide — performance considerations and implementation guidance.
NIST, SP 800-111: Guide to Storage Encryption Technologies for End User Devices — encryption at rest standard.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 28 — encryption at rest versus encryption in transit. Alice, we've talked about TLS back in Episode 13. Now we're doing the full picture on data encryption. Where do we start?

Alice: With the basic question: where is your data, and who could steal it? Data exists in two states. At rest — sitting on a hard drive, in a database, on a backup tape. And in transit — moving between the user's browser and your server, between your microservices, between your application and the database. Each state has different threats. Data at rest is vulnerable to physical theft — a stolen laptop, a decommissioned drive that wasn't wiped, an attacker who gets file system access to your database server. Data in transit is vulnerable to eavesdropping — someone on the network intercepting traffic between your services.

Dan: Right. And you need encryption for both?

Alice: Both. No exceptions. If you encrypt data in transit but not at rest, a stolen database backup gives the attacker everything in plaintext. If you encrypt at rest but not in transit, someone intercepting network traffic between your services reads data as it flows. For a legal SaaS platform storing privileged client communications, leaving either gap is indefensible — literally, in the regulatory sense.

Dan: Mm. Let's start with encryption at rest. What's the simplest way to do it?

Alice: Transparent data encryption — TDE. This is encryption handled by the database engine itself, completely invisible to your application. Every major cloud database — AWS RDS, Azure SQL, Google Cloud SQL — has TDE enabled by default. It uses AES-256, which is the industry standard symmetric encryption algorithm. NIST approved AES for protecting classified information. No successful attack against it has been demonstrated in over twenty years of analysis.

Dan: Mm-hmm. So the database encrypts everything on disk, and decrypts it when you query?

Alice: Exactly. Your application code doesn't change at all. The database handles encryption and decryption transparently. Data files, transaction logs, backups — all encrypted at the storage level. And the performance impact is negligible — modern CPUs have dedicated hardware instructions for AES encryption. On a server with Intel AES-NI, TDE adds maybe one to five percent CPU overhead. Basically free.

Dan: Hmm. But what does TDE actually protect against?

Alice: Physical theft of storage media and unauthorised file system access. If someone walks off with a hard drive or gets access to the raw database files, they see encrypted bytes. But — and this is the important limitation — TDE does not protect against someone who has valid database credentials. They query the database through the normal interface, and the database decrypts the data for them automatically. TDE is a floor, not a ceiling.

Dan: Right. So what's the ceiling?

Alice: Application-layer encryption. Instead of letting the database handle encryption, your application encrypts sensitive fields before they reach the database. The database stores ciphertext — encrypted data that's meaningless without the key. Even a database administrator with full access sees only gibberish. The decryption key lives in a separate system — a key management service — that the database never has access to.

Dan: Mm. That sounds stronger. What's the tradeoff?

Alice: <sigh> Searchability. If a field is encrypted at the application layer, the database can't query it, sort by it, or index it. You can't do a full-text search across encrypted client communications. You can't sort by encrypted client names. So you have to make architectural choices about which fields get application-layer encryption — privileged communications, litigation strategy notes, confidential financial data — and which get TDE-only protection — timestamps, matter IDs, status flags that the database needs to query against.

Dan: Yeah. That's a real design decision. Now, where does the encryption key live? That seems like the critical question.

Alice: It is the critical question. If the key is stored next to the data it protects — in the same database, on the same server — then stealing the server gives the attacker both the lock and the key. That's security theatre, not security. The solution is called envelope encryption. There's a hierarchy of keys. At the top is the Master Key — also called the Key Encryption Key. This lives in a Hardware Security Module, an HSM — a tamper-resistant piece of hardware specifically designed to store cryptographic keys. The master key never leaves the HSM.

Dan: Mm. And below that?

Alice: Below that are Data Encryption Keys — DEKs. Each one is unique — per record, per table, or per tenant. The DEK encrypts the actual data. Then the DEK itself is encrypted using the Master Key. The encrypted DEK is stored alongside the encrypted data. To decrypt, you send the encrypted DEK to the key management service, which decrypts it using the Master Key inside the HSM, gives you the plaintext DEK, and you use that to decrypt the data. Then you discard the DEK from memory.

Dan: Right. So even if an attacker steals the entire database — the encrypted data and the encrypted DEKs — they can't decrypt anything without access to the KMS.

Alice: Exactly. And AWS KMS, Google Cloud KMS, and Azure Key Vault all implement this pattern. The master keys live in certified hardware security modules. For legal SaaS on any major cloud provider, there's no reason to build your own key management. Use the provider's KMS. It's one of the few areas in security where the cloud provider's solution is genuinely better than anything you'd build yourself.

Dan: Mm-hmm. Let's switch to encryption in transit. We covered TLS in Episode 13. What's the summary?

Alice: Four requirements. First, TLS 1.2 as the minimum version — TLS 1.3 preferred. Second, strong cipher suites — AES-256-GCM with ECDHE key exchange for forward secrecy. Third, automated certificate management — Let's Encrypt and the ACME protocol make this free and automatic. Fourth — and this is where teams slip up — encrypt internal traffic too. Browser to server is obvious. But service-to-service communication within your infrastructure needs mTLS — mutual TLS, which we covered in Episode 15. In a zero-trust architecture, which we covered last episode, there is no trusted internal network.

Dan: Yeah. No "we're behind the firewall so it's fine."

Alice: Exactly. Every connection encrypted. Browser to load balancer. Load balancer to API server. API server to database. API server to search service. If it crosses a network boundary — any network boundary — it's encrypted.

Dan: Mm. What about the regulatory side? Is encryption legally required?

Alice: Every framework your clients care about requires it. ABA Model Rule 1.6(c) demands "reasonable efforts" to prevent unauthorised access — encryption is increasingly the expected standard for "reasonable." GDPR Article 32 lists encryption as an appropriate technical measure. HIPAA requires encryption for electronic health information. SOC 2 requires encryption for Trust Services Criteria. PCI DSS requires it for cardholder data. Singapore's PDPA recommends it. The convergence is total — the question isn't whether to encrypt, it's how thoroughly.

Dan: Right. Quick summary for builders. TDE as the baseline — it's basically free on cloud databases. Application-layer encryption for the most sensitive fields. Envelope encryption to keep keys separate from data. TLS everywhere, including internal service traffic. And use your cloud provider's KMS — don't build your own.

Alice: And one more thing. The performance concerns that stopped people from encrypting ten years ago are mostly gone. Modern hardware has AES built into the CPU. TLS 1.3 handshakes take one to two milliseconds. The only non-trivial cost is the KMS API call for envelope encryption — about five to twenty milliseconds — and you can cache decrypted keys in memory briefly to amortise that. Encryption is no longer expensive. Not encrypting is.

Dan: Next episode — Key Management and Rotation. How you actually manage those encryption keys over time, including the scary question: what happens if you lose the key?

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.