How to Choose the Right Data Encryption Mechanism

The right data-encryption mechanism depends first on where plaintext could be exposed and who must be unable to read it. For most systems, that means authenticated symmetric encryption for stored data, TLS 1.3 for connections, and application-level encryption only where storage controls do not cover the actual threat.

That answer remains sound, but the standards landscape has moved. A revised specification replaced the original TLS 1.3 RFC in July 2026 without changing the protocol version, while finalized post-quantum standards have turned migration into an implementation-planning issue. Neither development makes AES obsolete or turns one encryption feature into complete protection.

Start with the exposure, not the cipher name

“Encrypt the data” is not a complete design requirement. A stolen disk, a database administrator, an intercepted connection and an attacker controlling an application server encounter different forms of the data. A control that blocks one may offer little resistance to another.

Before selecting a mechanism, identify where plaintext appears, which components may decrypt it, where the keys reside and what access the assumed attacker has. Those answers determine whether encryption belongs in the storage platform, application, transport protocol or a protected execution environment.

Lost media, copied volumes or exposed snapshots: use storage, disk or database encryption with keys kept outside the affected storage boundary.
Network interception or modification: use an authenticated transport protocol, normally TLS 1.3, and verify the peer’s identity correctly.
Database access without application authority: consider application- or field-level encryption with separate key permissions.
Compromise of the running application: ordinary at-rest and transport encryption cannot conceal data after that application legitimately decrypts it.

This framing also exposes a category error: hashing, tokenization and encryption are not interchangeable. Password verification ordinarily needs a password-hashing function, while tokenization can remove a sensitive value from routine workflows. Reversible encryption is appropriate only when an authorized process must recover the original plaintext.

For stored data, match the boundary to the attacker

Disk, volume and managed database encryption are sensible baseline controls because they can cover large datasets without changing every application operation. They are especially relevant when the feared event is removal, copying or unintended exposure of the underlying storage. They do not normally prevent an authorized database or application process from reading plaintext.

Use application- or field-level encryption when the storage service should not see selected values, different fields require different access rules, or a database credential must not automatically grant access to every sensitive record. This creates more work: the application must define ciphertext formats, key identifiers, rotation behavior, error handling and the treatment of searchable or sortable fields. Encrypting a column can disrupt ordinary indexing and analytics, so the decision belongs in the data model rather than in a late security toggle.

For general application storage, OWASP’s cryptographic-storage guidance recommends AES with a key of at least 128 bits, prefers authenticated modes such as GCM or CCM, advises separating keys from encrypted data and says passwords should be hashed rather than reversibly encrypted. Those details matter more than a simplistic contest between AES-128 and AES-256: a reused nonce, exposed key or unauthenticated ciphertext can defeat the intended protection without breaking AES itself.

Envelope encryption provides a useful separation of duties. A data-encryption key protects the payload, while a separately controlled key-encryption key protects that data key. The encrypted data key can accompany the record, but permission to unwrap it should be narrower, auditable and unavailable to components that merely store ciphertext.

For data in transit, use a maintained protocol

Do not assemble a custom combination of public-key exchange, symmetric encryption and message authentication for ordinary client-server traffic. A maintained TLS implementation already coordinates negotiation, peer authentication, traffic keys, record protection and failure handling. The difficult work is configuring identity verification, certificate management and protocol policy correctly at every hop.

The current IETF specification for TLS 1.3, published in July 2026 as RFC 9846, obsoletes RFC 8446 while continuing to specify protocol version 1.3. It also forbids reusing KeyShare values between connections, prohibits negotiating TLS 1.0 and TLS 1.1, and retains authenticated-encryption algorithms for record protection. An inventory that merely says “TLS enabled” is therefore insufficient: teams should check the negotiated version, certificate validation, termination points and whether internal traffic becomes plaintext after a proxy.

TLS protects a connection, not the data’s entire lifecycle. Once a receiving service accepts and decrypts a request, subsequent queues, logs, caches and database writes require their own controls. Mutual TLS can authenticate both endpoints, but it does not decide whether an authenticated service is authorized to read a particular customer record.

Client-side encryption changes the trust boundary

Client-side or end-to-end encryption is appropriate when a server should store or relay content without possessing the keys needed to read it. It can narrow the trusted computing base, but account recovery, multi-device synchronization, sharing, search, moderation, backup and retention may all require designs that do not assume server-side plaintext.

The label alone proves little. If the provider also receives the decryption key, or a web application can deliver modified code that captures plaintext, the trust boundary differs from a client whose keys and cryptographic implementation remain independently controlled. The design should state which software creates the key, where it can be exported and which party can cause decryption.

Field-level encryption is a less sweeping alternative when only selected values need separation from the database. It can preserve normal server-side processing for nonsensitive fields while restricting decryption of high-impact data to a smaller service. That selective design is often easier to operate than encrypting every object at the client.

Data in use requires a different decision

Ordinary encryption at rest ends when an application loads data for processing. If the threat includes a cloud operator, hypervisor or neighboring workload, a confidential-computing environment may reduce the infrastructure that must be trusted by isolating code and data during execution. It does not automatically repair vulnerable application code, unsafe outputs or excessive authorization.

Homomorphic encryption and secure multiparty computation address narrower cases in which parties need a result without exposing all inputs to one another. They should be selected around an exact computation, data volume and leakage model, not treated as drop-in replacements for a database cipher. Tokenization may be simpler when downstream systems need only a stable reference rather than the original value.

Post-quantum migration does not replace bulk-data encryption

The quantum transition primarily affects public-key mechanisms used for key establishment and signatures; it does not mean organizations should discard AES for bulk-data encryption. NIST’s August 2024 announcement identifies FIPS 203 for ML-KEM key establishment and FIPS 204 and FIPS 205 for digital signatures, describes the three standards as ready for use, and urges system administrators to begin transitioning.

The practical requirement is cryptographic inventory and agility. Record where public-key algorithms are embedded in protocols, certificates, devices, libraries and stored encrypted material, then determine whether the information must remain confidential long enough for a future attacker to collect it now and decrypt it later. Adopt post-quantum mechanisms through supported, reviewed protocol implementations rather than inserting a new algorithm into an improvised format.

A defensible default architecture

For a typical web service, begin with managed storage encryption, TLS 1.3 on external and service-to-service connections, and a dedicated key-management boundary with limited unwrap permissions and audit records. Add field-level encryption only for data whose storage or administrative exposure exceeds that baseline. Use client-side encryption when withholding plaintext from the service is an explicit product requirement.

Design rotation before issuing the first key. Ciphertext should carry a non-secret key version or identifier, new writes should move to the current key, and old keys should remain available only as long as legitimate recovery requires. Suspected compromise needs a separate emergency path; calendar-based rotation cannot substitute for revoking access and investigating the exposure.

The final test is to describe the attacker and trace the data until plaintext appears. If that attacker can reach the decryption key or the authorized process using it, selecting a stronger AES key does not close the gap. The correct mechanism places encryption and key authority on opposite sides of the exposure that must be contained.

Strong AES Can Still Miss the Threat: Choose the Right Encryption Layer