Field-level encryption (FLE) encrypts individual sensitive values, such as a Social Security number, card number or diagnosis code, so they stay ciphertext while the rest of the record remains usable. Only components that hold the right key can read the protected fields. Everything else, including database administrators, backups and logs, sees encrypted data. This guide explains how FLE works, how it relates to column-level and application-level encryption, what it costs in searchability and engineering effort, and how to run keys safely.
TL;DR
- Field-level encryption protects selected values inside a record, so a leaked database dump or a compromised replica exposes ciphertext rather than regulated data.
- Column-level, data-field and application-level encryption overlap: the first two describe what is protected, the last describes where the cryptography runs.
- Encrypted fields trade away some querying. Randomized encryption blocks lookups, deterministic encryption allows exact matches but leaks patterns, and blind indexes sit between the two.
- Key management decides whether FLE is real protection. Separate key administration from data access, audit key use, and plan rotation before launch.
- FLE is cheapest to design in at the start of a build, when the data model, the key hierarchy and the query patterns can be settled together.
What field-level encryption actually does
Full-disk and table-level encryption protect data at rest in bulk. They are valuable, but once the database is running and a user or process is authenticated, everything is readable. Field-level encryption narrows the blast radius: it selects specific fields and encrypts them separately from the surrounding data.
AWS documents the pattern clearly in its CloudFront feature. Field-level encryption selectively encrypts sensitive fields in a request rather than the entire request. The fields are encrypted at the edge, remain encrypted throughout the application stack, and only applications holding the credentials to decrypt them can access the plaintext. The same documentation notes that this feature handles up to 10 individually specified fields in a request, a reminder that FLE is designed for a small set of high-value values, not for blanket coverage.
That design principle carries beyond any one product. The goal is to encrypt as early as practical and decrypt as late as practical, only inside the service that genuinely needs the plaintext. AWS’s security guidance on the data lifecycle describes the same approach: encrypt at ingestion and keep the data encrypted until a specific application with the right credentials needs it.
Which fields deserve it
A useful filter is to ask what a breach of each field would cost. Good candidates usually include:
- Government identifiers, such as SSNs and tax IDs
- Payment card numbers and bank account details
- Health information and insurance identifiers
- Authentication secrets, API tokens and recovery codes
- Personal contact data that triggers breach notification duties
Fields used only for display or free-text notes often belong in the same list when they routinely contain such data. Fields used heavily in joins, range filters and reporting are the hard cases, and the searchability section below covers them.
Field-level, column-level, data-field and application-level encryption
These four terms appear interchangeably in search results, and the confusion is understandable because they describe different axes of the same design.
Column-level encryption is a database-scoped idea: selected columns in a table are encrypted. Field-level encryption can mean the same thing, but it more broadly covers individual values within records, including attributes in document stores and key-value items. Academic treatments reflect this overlap. A Springer chapter on database encryption groups transparent, column-level and field-level approaches together, and treats a relational field as a column entry.
Data-field encryption is simply another phrasing of field-level encryption, common in compliance documents.
Application-level encryption (ALE) answers a different question: where does the cryptography happen? According to InfoQ’s architecture overview of application-level encryption, it can run on clients, can provide end-to-end encryption when servers lack the keys, or can protect certain fields, in which case it is field-level encryption. So ALE is the location, and FLE is the granularity. A system can have one without the other.
| Term | What it describes | Typical place encryption runs |
|---|---|---|
| Column-level encryption | Selected columns in a relational table | Database engine or application |
| Field-level encryption | Individual values within records | Application, edge or driver |
| Data-field encryption | Same as field-level, compliance phrasing | Varies |
| Application-level encryption | Where cryptography runs in the architecture | Application code or client |
The practical consequence: database-native column encryption is tied to the database where it is configured. Application-side encryption encrypts values before they reach the database, which means the database never holds plaintext, but your code or driver has to integrate the cryptography.
Layering rather than choosing
Field-level encryption does not replace database encryption. Salesforce’s architecture shows how the two stack: FLE protects selected data in the application tier, while database encryption protects writes in the transactional database tier, and each has different functionality and query limits. For teams working in that ecosystem, Salesforce security and data protection practices are a useful companion to the architecture reference.
The layered view is the right default. Disk or database encryption covers the whole estate against lost media and stolen snapshots. Field-level encryption covers the few values where an authenticated but over-privileged reader, a SQL injection or a leaked dump would be most damaging. Our guide to encryption at rest with KMS, envelope encryption and backups covers the base layer.
Where data is encrypted, and who sees plaintext
Every FLE design answers two questions: at which point does a value become ciphertext, and which identities can turn it back?
In Salesforce Shield, encryption happens in the application layer directly before database storage. Data is decrypted as it is materialized, and it appears as plaintext to the user who requested it. That is a deliberate choice: the database tier holds ciphertext, while authorized users keep a normal experience.
In the CloudFront model, a public key encrypts the specified POST fields at the edge. The values travel through the origin stack as ciphertext, and only components with the matching private key can decrypt them. The practical benefit is that intermediate services, such as load balancers, web servers and message queues, never handle plaintext. For payment flows, where data passes through several hands before settlement, the same logic applies to edge encryption and data flow in card acceptance.
When you design your own flow, draw the path of one sensitive value from entry to storage to use, and mark every component that sees it in the clear. Each mark is an attack surface. The goal is to shrink the number of marks to the smallest set of services that truly need plaintext, such as a payment service that submits a charge or a compliance service that produces a report.
Searching, filtering and indexing encrypted fields
This is where most FLE projects meet resistance. Strong encryption deliberately destroys structure, and structure is what databases use to search.
Randomized encryption
Randomized (probabilistic) encryption produces different ciphertext each time, even for identical plaintext. Salesforce explains that probabilistic FLE uses a random initialization vector and restricts some functionality. Its help documentation adds that probabilistic encryption generally restricts filtering, sorting and grouping. Equality lookups fail because two identical values no longer look alike. This is the strongest option and the right default for fields you never need to query.
Deterministic encryption
Deterministic encryption uses a field-specific static initialization vector so identical inputs produce identical outputs. That allows exact-match filtering, with, in Salesforce’s words, a corresponding decrease in encryption strength. The compromise is that equal values become visible as equal: an attacker with the data can see which records share a value and how often a value repeats, even without decrypting anything. Pattern matching, prefix searches and ordering are generally not available on deterministically encrypted fields.
Use deterministic encryption for fields with high cardinality and a genuine exact-match need, such as an account number lookup. Avoid it for low-cardinality fields like a status flag or a state code, where frequency analysis can reveal the underlying values quickly.
Blind indexes
A third approach separates the searching from the stored value. GEICO’s engineering team describes a searchable field-level encryption design in which the application generates a blind index for a query, the database searches that index, and only the matching encrypted fields are decrypted. The database never sees the plaintext value. The index is a keyed hash of the value, so it is only useful to someone holding the index key.
Blind indexes are not free. They still reveal that two records share a token, and they support exact matching only. They also add a second piece of derived data that must be protected, rotated and kept in sync with the primary value.
Choosing by query pattern
| Need | Suitable approach | What you give up |
|---|---|---|
| Never queried, only displayed | Randomized encryption | Filtering, sorting, grouping |
| Exact match on a high-cardinality value | Deterministic encryption or blind index | Hides less: equality and frequency patterns show |
| Range or partial-match search | Store a separate non-sensitive derived field, or decrypt in the application | Extra design work and possible performance cost |
| Analytics on sensitive values | Tokenize or aggregate in a controlled service | Raw access for most users |
List your queries before choosing the cipher mode. Retrofitting a mode after launch usually means re-encrypting every existing record.
Key management is the real security boundary
Encrypting a field with a key stored beside the data is theater. The protection is only as strong as the controls around the keys.
NIST’s key management recommendation (SP 800-57 Part 1, Revision 5, May 2020) states that effective cryptographic security depends on key strength, the mechanisms and protocols around it, and the protection of key material. Its guidance covers generation, storage, distribution, use, cryptoperiods, accountability, audit and destruction. In practice, that translates into a short checklist:
- Keep keys in a managed service. Use a key management service or hardware security module where practical, so key material is not exportable into application memory or config files.
- Separate duties. The people and services that administer keys should not be the same ones that read data.
- Apply least privilege. Grant decrypt permission per service and per field class, not per environment.
- Audit every key operation. Log who used which key, when, and for what.
- Plan rotation up front. Version your keys and store the key version with each ciphertext.
AWS’s lifecycle guidance, using a Lambda@Edge example, shows what this looks like with a managed service: IAM and key policies, cross-account access, CloudTrail auditing, HSM key generation, non-exportable private keys, and scheduled key disablement or deletion.
Rotation without downtime
Rotation is where designs fail quietly. If old ciphertext cannot be decrypted after a new key goes live, you have an outage. If you never rotate, a single compromise exposes years of data. The safe pattern is versioned keys with an overlap period: new writes use the new key, old reads still work with the archived one, and a background job re-encrypts old records until the previous key can be retired. Salesforce supports this model by allowing multiple FLE keys to be used simultaneously, with rotated keys archived unless destroyed. Product behavior differs, though. Some platforms rotate automatically, others require bulk re-encryption, so confirm which applies before you commit.
For teams building a hardware-backed setup, our four-phase HSM rollout walks through standards-based key management, and our guide to break glass access covers emergency accounts so that recovery procedures do not undermine key separation.
Performance and operational tradeoffs
Planning for FLE means planning for work in several places at once.
Application integration. Application-layer encryption protects against malicious database administrators and SQL injection, but it requires integration, development effort and resources. Every service that touches a protected field needs the library, the key access and the error handling.
Latency. Encrypting and decrypting a handful of fields per request is usually small compared with network and database time, but a report that decrypts a million rows is not. Batch decryption, caching of data keys and envelope encryption keep that cost predictable.
Data model. Ciphertext is larger than plaintext and often changes data types. Plan column sizes, encodings and validation. Encrypting after validation means your database can no longer enforce formats such as length or numeric checks.
Logging and observability. Plaintext leaks through logs, error traces and analytics events more often than through databases. Scrub or tokenize sensitive values before they reach logging pipelines.
Access control interplay. Field-level encryption controls who can read a value, while row-level controls decide which records a user can see. They work well together, and our practical guide to row-level security shows how to combine them.
Testing and recovery. Test restores with keys, not only data. A backup that restores to ciphertext no one can decrypt is not a backup.
A rollout sequence that holds up
- Inventory sensitive fields and classify them by regulatory exposure and business impact.
- Map queries against each field to pick randomized, deterministic or blind-index treatment.
- Define the key hierarchy: a master key in a managed service, data keys per field class or tenant, and a documented owner for each.
- Choose the encryption location: edge, application service or client, based on which components must never see plaintext.
- Build a thin encryption service or library so cryptography lives in one place and is not reimplemented per team.
- Migrate existing data in batches, with a version tag on every ciphertext and a rollback plan.
- Verify with tests that confirm the database, backups and logs contain no plaintext for protected fields.
- Operate: monitor key use, rehearse rotation, and review the field list as the product grows.
For financial systems, where several of these controls are audit requirements, our financial data security best practices and fintech security guide for IT leaders put FLE in the wider control set. Teams shaping their secure development process can also use our software development security guide.
Our perspective: design encryption into the foundation
We see the same pattern in most projects that come to us after a security review: encryption was added to a finished product, so it had to fit around queries, reports and integrations that had already assumed plaintext. That is the expensive path.
Field-level encryption is cheapest when it is part of the modular foundation. If the financial module, the CRM records and the workflow automation share one encryption service and one key hierarchy, each new feature inherits the protection instead of reinventing it. That is what we mean by accelerating work without accelerating chaos.
Our approach is to start projects with up to 60% of the baseline system pre-built, which frees engineering time for the decisions that are specific to your business: which fields are regulated, which queries are essential, who may decrypt what. Our modules are designed to be audit-ready and to support self-hosted deployment, so key custody and data residency can stay under your control rather than being relocated into a vendor relationship.
Our view is that a modular foundation, with cryptography owned by your team and documented for your auditors, is the most dependable way to protect sensitive fields over the life of a system.
Bitecode
Build it into your system with Bitecode
If you are planning a financial platform, a CRM holding customer identities, or a blockchain-based settlement system, field-level encryption is easier to get right when it is designed with the data model. We build custom business software from ready-made modules, including financial, CRM and automation modules, and can scope an engagement around your regulated fields, key custody and audit needs.
To discuss a project, see our custom business software services or start from the Bitecode homepage.
FAQ
Is field-level encryption the same as column-level encryption?
They overlap heavily. Column-level encryption is the database-scoped version, where selected columns in a table are encrypted. Field-level encryption can also cover individual values within documents or records, and it is often performed in the application rather than the database.
Is application-level encryption the same as field-level encryption?
No. Application-level encryption describes where cryptography happens: in the application or on the client rather than in the database. Field-level encryption describes what is encrypted: specific values. An application can encrypt whole files with ALE, or only selected fields, which is field-level encryption.
Can I still search encrypted fields?
Yes, within limits. Deterministic encryption allows exact-match lookups but reveals when values are equal. Blind indexes let the database search a keyed token while the application decrypts only matching records. Randomized encryption gives the strongest protection but generally blocks filtering, sorting and grouping.
Does field-level encryption replace database encryption?
No, they work as layers. Database or disk encryption covers the entire data store, while field-level encryption protects chosen values even from readers with database access. Salesforce’s architecture documentation describes the two as separate mechanisms with different functionality and query limits.
How often should field encryption keys be rotated?
The interval depends on your risk assessment, regulations and the cryptoperiods you define under NIST’s key management guidance. More important than the number is the mechanism: version your keys, keep old versions available during migration, and rehearse rotation before you need it in an incident.
Sources
- AWS CloudFront: Use field-level encryption to help protect sensitive data
- AWS Security Blog: How to protect sensitive data for its entire lifecycle
- InfoQ: Application Level Encryption for Software Architects
- Springer Nature Link: Disk, File and Database Encryption
- Salesforce Shield Platform Encryption Architecture
- Salesforce Help: Learn About Database Encryption
- GEICO Tech Blog: Searchable field-level encrypted customer PII
- NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management
