Application Layer Encryption Guide: Encryption as a Service, Vault Transit and Field Level Encryption

Disk, storage and transparent database encryption protect data from someone who steals the media, but they decrypt it for anyone who can query the database, which is exactly the access an attacker with stolen application or administrator credentials has. Application layer encryption moves encryption into the application tier, so sensitive fields are encrypted before they reach the datastore and only callers with access to the key can read them. This guide covers when that extra layer is worth its cost, the three main ways to build it (an encryption service such as HashiCorp Vault Transit, client-side field level encryption libraries, and database-integrated client encryption), how to keep fields searchable, and how to roll it out and monitor it. It is written for application architects, security engineers and platform teams. Key wrapping itself is covered in the Envelope Encryption and KMS Integration Patterns Guide; this page is about where to encrypt in the application. Products are named as examples and listed alphabetically; this is not a ranking.

Key takeaways

• Choose the layer by the attacker. Storage and TDE stop stolen disks and backups; only application layer encryption stops a database administrator, a compromised database account or a leaked read replica from seeing plaintext.
• Encrypt fields, not everything. Field level encryption costs query features, so apply it to the small set of values whose disclosure would be a reportable incident: national identifiers, card data, health data, secrets and recovery codes.
• The key, not the algorithm, is the control. The protection is only as good as the separation between whoever can read the database and whoever can call decrypt; put that boundary in a KMS, HSM or encryption service with its own access policy.
• Searchability is a security trade-off. Deterministic encryption and blind indexes allow equality lookups but leak which records share a value; use randomised encryption by default and deterministic only where a lookup is required.
• Decrypt calls are your audit trail. Logging and rate-limiting decrypt operations per service identity turns bulk data theft into a detectable event.

Where encryption sits and what each layer stops

The OWASP Cryptographic Storage Cheat Sheet lists four places to encrypt (application, database, filesystem and hardware) and says the right choice depends on the threat model. The table makes that concrete. For the general model of protecting data in its three states, see Encryption at Rest vs In Transit vs In Use.

Microsoft's TDE documentation is explicit about the database layer's limits: pages are decrypted when read into memory, FILESTREAM data and buffer pool extension files are not encrypted, and the protecting certificate must be backed up or the database cannot be opened elsewhere. That makes TDE a good baseline for media and backup theft and a poor control against SQL injection or a stolen connection string. For database layer options in depth, see the Database and Storage Encryption Guide.

Deciding whether you need application layer encryption

• You need it when: people who administer the database should not see the data (outsourced DBAs, managed database providers, shared platforms); data is copied to replicas, data lakes or test environments; a regulation or contract asks you to render data unreadable to those without a need to know; or one tenant's data must stay unreadable to others in a shared schema.
• TDE plus access control is usually enough when: the main risks are lost media and backups, the database is single-purpose with few administrators, and the cost of losing range queries, sorting and full-text search on the fields would be high.
• Do not encrypt what you can avoid storing: OWASP's first recommendation is not to store sensitive data at all. Passwords are hashed with a password hashing function, never reversibly encrypted. Card numbers can often be replaced with a token from a payment provider; see the Network Tokenisation for Payments Guide.
• Small organisations: a managed database with TDE, strong IAM and encryption of a handful of fields through a cloud KMS or an encryption SDK is a realistic target. Running your own encryption service only pays off with several applications and a platform team to operate it.
• Large organisations: centralise cryptography in an encryption service or a standard SDK with approved key types, so teams stop writing their own AES code and auditors have one place to review.

Three ways to build it

Encryption as a service: HashiCorp Vault Transit

Vault's Transit secrets engine is a widely used example. Its documentation describes it as handling cryptographic functions on data in transit: Vault does not store the data sent to it, and the application stores the returned ciphertext. Points that matter for design:

• Key types: symmetric aes256-gcm96 is the default; aes128-gcm96 and chacha20-poly1305 are also offered, plus RSA, ECDSA, Ed25519 and HMAC keys. In FIPS 140-3 mode the documentation says not to use chacha20-poly1305 or ed25519.
• Ciphertext format: output looks like vault:v1:..., where v1 is the key version. Storing the prefix lets you find records still encrypted under old versions.
• Rotation and rewrap: rotating adds a key version for new encryptions while old ciphertext stays readable. The rewrap endpoint re-encrypts to the newest version without exposing plaintext to the caller, and raising min_decryption_version retires old versions once rewrap is complete.
• Usage limits: the documentation cites NIST guidance to rotate AES-GCM keys before about 2³² encryptions per key version; at 40 million operations a day, quarterly rotation is enough.
• Derived and convergent keys: key derivation takes a context value (for example a tenant ID) to produce per-context keys; convergent mode makes the same plaintext and context give the same ciphertext, which enables lookups at the cost of revealing equality. Use the current convergent version, which Vault describes as resistant to offline plaintext-confirmation attacks.
• Request size: the HTTP API has a 32 MB default maximum request size. For large objects, ask Transit for a data key and encrypt locally (envelope encryption) rather than sending the object.
• Format-preserving needs: where a field must keep its length and character set, Vault's Transform engine (Vault Enterprise with the Advanced Data Protection Transform module) offers FPE, masking and tokenisation. Its documentation states FF3-1 is deprecated from Vault 2.2.0 in favour of FF1.

See the HashiCorp Vault Guide for operating Vault itself.

Client-side libraries

The AWS Database Encryption SDK (formerly the DynamoDB Encryption Client) is an open-source, Apache 2.0 library that encrypts chosen attributes in each record with a unique data key and signs the record to detect added, deleted or swapped fields. You configure which fields are encrypted and signed, signed only, or ignored. Its hierarchical keyring caches KMS-protected branch keys to cut KMS calls, and it supports searchable encryption and per-tenant key material. It is available for DynamoDB in Java, .NET and Rust. Similar patterns can be built with general libraries such as Google Tink, keeping to authenticated encryption as OWASP recommends (AES-GCM or CCM first; see the Authenticated Encryption and Block Cipher Modes Guide).

Database-integrated client encryption

• MongoDB Queryable Encryption: fields are encrypted on the client and stored as fully randomised ciphertext; the documentation lists equality, range, prefix, suffix and substring queries, with decryption only on the client. Expect diagnostic commands and query logs to redact some fields, which affects performance troubleshooting.
• SQL Server Always Encrypted: a column encryption key encrypts the column and a column master key, held outside the database in Azure Key Vault, the Windows certificate store or an HSM, protects it. Deterministic encryption supports equality lookups, joins, grouping and indexing; randomised encryption supports none of these unless secure enclaves (SQL Server 2019 and later, Azure SQL Database) are used. Values must be passed as parameters, and replication and some column types are not supported.

Keeping encrypted fields usable

Microsoft's Always Encrypted documentation warns that deterministic encryption leaks patterns, especially for low-cardinality values such as True or False. Treat any searchable scheme as a deliberate, documented leak, and record it in the threat model.

Binding, integrity and key design

• Bind ciphertext to its record: pass the table, column and record ID as associated data or encryption context, so a ciphertext copied into another row or tenant fails to decrypt. The envelope encryption guide covers encryption context in detail.
• Separate keys by purpose and tenant: one key per data class (for example identity documents, payment data, health data) and, where tenants share a schema, per tenant. This limits blast radius and lets you crypto-shred a tenant by destroying its key.
• Keep keys apart from data: OWASP recommends storing keys separately from the data they protect and never in source code or version control. A key in the same database, config file or backup set defeats the design. The GoTo breach shows the result: encrypted backups were stolen together with the key for part of them.
• Version everything: store the key identifier and version with each ciphertext so rotation can be tracked and rewrap jobs can find old records.
• Plan for agility: the cipher, key size and library should be configuration, not code, so a change does not require touching every call site. See the Crypto-Agility Guide.

Where identity fits

Application layer encryption turns data access into key access, and key access is held by non-human identities: the service account, workload identity or Vault token that the application uses to call encrypt and decrypt. Give each service its own identity and its own policy, allowing encrypt-only for services that write data and decrypt only for the few that must read it. Use short-lived credentials such as cloud workload identity or Vault auth methods instead of static tokens, because a leaked long-lived token with decrypt rights reverses the whole design. See the AWS KMS Security Guide and the Secrets Management Guide.

Implementing application layer encryption

1. Classify fields: list the columns and attributes that hold sensitive data, using your data classification scheme, and decide for each whether to delete, tokenise, encrypt or leave under TDE only.
2. Write the threat model: state which actors the encryption must stop (DBAs, a stolen replica, another tenant) and which queries each field must still support.
3. Pick one pattern per platform: an encryption service, an approved SDK or database-integrated encryption. Publish a short internal standard naming the key types, modes and libraries allowed.
4. Build the key hierarchy and identities: create keys per data class or tenant in the KMS, HSM or encryption service, with encrypt and decrypt permissions granted to separate service identities.
5. Dual-write in a pilot: add an encrypted column beside the plaintext one, write both, and verify reads from the encrypted column in a pilot service. Rollback is switching reads back to plaintext.
6. Backfill and cut over: encrypt existing rows in batches (Always Encrypted requires this to happen outside the database unless enclaves are used), switch reads, then drop the plaintext column and purge it from backups and replicas according to retention.
7. Clean the side channels: check logs, error messages, caches, search indexes, analytics exports and message queues for plaintext copies of the field.
8. Exercise rotation and recovery: rotate a key, rewrap a sample, and restore a backup in a separate environment to prove that keys and ciphertext can be brought back together.

Detection and measurement

• Decrypt volume per identity: baseline decrypt calls per service and alert on spikes, new callers or decrypts from unexpected networks. Bulk decryption is the signature of data theft through a compromised application.
• Policy and key changes: alert on changes to key policies, encryption service policies, key deletion scheduling and lowered min_decryption_version values.
• Denied operations: repeated decrypt failures can mean a misconfigured service or an attacker probing with a stolen token.

Metrics that show the programme is working:

• Percentage of fields classified as restricted that are encrypted at the application layer.
• Number of service identities with decrypt rights, and the share with encrypt-only rights.
• Percentage of ciphertext on the current key version, from the version prefix or key ID.
• Plaintext copies found in logs, exports and lower environments per quarter, trending to zero.
• Median added latency per encrypted request, to keep the design acceptable to product teams.

Common failure patterns

• Calling TDE application encryption: a compliance answer says "encrypted at rest" while every DBA and injected query reads plaintext.
• Key next to the data: the data key or encryption service token lives in the same config file, database or backup as the ciphertext.
• Deterministic everywhere: teams make every field deterministic to keep queries working, which reveals value frequency and lets anyone with one known plaintext find every matching record.
• Plaintext leaking around the edges: request logging, ORM debug output, search indexes and data lake exports keep the cleartext the encryption was meant to remove.
• One identity with every right: a single shared service account can encrypt and decrypt every data class in every environment, so any compromised service can read everything.
• Untested rotation: keys are never rotated because nobody knows whether old ciphertext will still decrypt, so a compromise leaves no clean recovery path. The Encryption Key Compromise Playbook covers the response.

Framework mapping

Practitioner checklist

• Write down which attackers each encrypted field must be protected from, and confirm that TDE alone does not already meet that need.
• Encrypt restricted fields with randomised authenticated encryption by default; justify each deterministic field or blind index.
• Keep keys in a KMS, HSM or encryption service, never in the database, source code or the same backup set as the data.
• Bind ciphertext to table, column and record using associated data or encryption context.
• Give each service its own short-lived identity, with encrypt and decrypt rights split.
• Store key ID and version with every ciphertext and run rewrap jobs after rotation.
• Remove plaintext copies from logs, caches, search indexes, exports and lower environments.
• Log and baseline decrypt calls per identity, and alert on spikes and new callers.
• Test key rotation and a full restore of data plus keys at least once a year.

Standards and references

• OWASP: Cryptographic Storage Cheat Sheet
• NIST: SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations
• HashiCorp: Vault Transit secrets engine
• HashiCorp: Vault Transform secrets engine
• AWS: What is the AWS Database Encryption SDK?
• MongoDB: Queryable Encryption
• Microsoft Learn: Always Encrypted
• Microsoft Learn: Transparent Data Encryption (TDE)

Related NHI Mgmt Group resources: Envelope Encryption and KMS Integration Patterns Guide · Database and Storage Encryption Guide · Cryptographic Key Management Guide · Data Masking and Tokenisation Buyer's Guide · Encryption Guide