Application-layer encryption for PII exposes the limits of at-rest security

At a glance

What this is: This is a tutorial on encrypting PII at the application layer with Vault, with the key finding that at-rest encryption alone still leaves data readable to anyone who can query the database.

Why it matters: IAM, IGA, and security teams need to treat decryption scope, object lifecycle, and key context as governance controls, not just cryptography details, because those decisions determine who can actually see PII.

Context

Encryption at rest protects stored data from physical loss, but it does not stop authorised database access from exposing plaintext PII. In a multi-tenant SaaS model, the real control boundary is not the database file, but the place where the application decides whether data is decrypted at all.

This article focuses on application-layer encryption for PII, where the application stores Vault object IDs instead of values and ties key context to organization identity. That changes the identity governance question from storage protection to decryption authority, lifecycle handling, and tenant separation.

The operational problem is familiar across IAM and NHI programmes: if engineers, analytics jobs, or compromised database credentials can query rows, then storage-only encryption does not reduce the blast radius enough. The reader should treat the tutorial as a pattern for narrowing who or what can ever see plaintext.

Key questions

Q: What breaks when PII is encrypted only at rest?

A: At-rest encryption still leaves plaintext available wherever the application, analytics job, or engineer can query and decrypt it. That means the storage layer looks protected while the real exposure persists in the application path, exports, and support workflows. Governance has to move to the decryption boundary, not stop at the disk.

Q: Why does tenant-bound key context matter for encrypted user data?

A: Tenant-bound key context matters because it prevents one organisation's data from being decrypted with another organisation's key material. In multi-tenant systems, the critical failure is cross-tenant exposure, not just data loss. Matching the key boundary to the tenancy boundary turns encryption into an isolation control, not just a storage control.

Q: How do security teams know whether encryption monitoring is actually working?

A: They should measure how quickly misconfigured buckets, expired keys and unexpected access patterns are detected and remediated across all clouds. If drift persists for days or is found only during audits, monitoring is too fragmented. Effective programmes show short exposure windows, clear ownership and repeatable remediation outcomes.

Q: How should teams handle PII deletion when data lives in Vault objects?

A: Delete each Vault object, then remove the stored object IDs from the application database so there is no lingering pointer to recover later. That approach aligns erasure with object lifecycle rather than table cleanup, which is important when data is split across multiple fields and organisations.

Technical breakdown

Why at-rest encryption does not stop database exposure

Encryption at rest protects storage media, backups, and lost disks. It does not protect data after the application has already decrypted it for a query, export, support workflow, or API response. In practice, the trust boundary shifts from the database engine to the application and its key-handling logic. If the application can read plaintext, so can any actor that reaches the same execution path, including engineers with production access or attackers using stolen database credentials. The central mechanism is simple: storage encryption controls where data sits, while application-layer encryption controls whether the row ever contains readable PII.

Practical implication: move the control point from database storage to the application path that decides whether plaintext is ever produced.

How Vault object IDs and key context separate data from access

The pattern described here stores Vault object IDs in the application database and keeps the encrypted value in Vault itself. That means a database query returns identifiers, not PII, and decryption only occurs when the application calls back into Vault. The context field, tied to organizationId, creates a cryptographic boundary between tenants so that a value encrypted for one organisation is not decryptable in another tenant's context. This is identity governance by cryptographic scope: the subject, the tenant, and the data object all have to line up before plaintext exists.

Practical implication: bind key context to tenancy and ensure the database only stores references, never readable fields.

Why describeObject and versionCheck matter to governance

describeObject returns metadata such as name and versionId without decrypting the value, which lets the application check existence, audit state, or prepare an update without exposing plaintext unnecessarily. updateObject with versionCheck adds optimistic concurrency control so a stale write cannot silently overwrite a newer value. That matters because PII governance is not only about access, but also about how many times data is decrypted and whether concurrent workflows can corrupt the record. The control surface is the CRUD lifecycle, not just encryption at creation time.

Practical implication: use metadata-only reads for checks and enforce version-controlled updates to reduce unnecessary decryption and silent overwrite risk.

Threat narrative

Attacker objective: The objective is to obtain readable PII from systems that were presumed safe because the database was encrypted at rest.

1. Entry occurs when an engineer, analytics job, misconfigured endpoint, or attacker with database access issues a query against stored user records and reaches fields that still decrypt to plaintext.
2. Escalation occurs when that access extends from a single row lookup to exports or tenant-crossing mistakes, turning a database credential into broad PII exposure.
3. Impact occurs when readable PII is revealed in support workflows, analytics pipelines, or cross-tenant leaks, because storage encryption never limited what the application could decrypt.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Application-layer encryption creates an identity boundary, not just a cryptographic one: the decisive question is which actor can cause plaintext to exist, not whether the database volume is encrypted. When keys are separated from the data store, PII governance shifts into lifecycle, context, and access-scope decisions. That is why the control conversation belongs inside IAM and IGA, not only in the encryption team.

Object IDs in the database are a useful reduction of blast radius, but only if the object lifecycle is governed: storing references instead of values removes plaintext from routine SQL paths, exports, and analytics jobs. But the protection only holds if every create, read, update, and delete operation is scoped to the correct tenant context. The practitioner implication is that data minimisation now depends on access design and lifecycle discipline.

Cryptographic key context becomes the new tenancy enforcement layer: tying encryption context to organization identity is effectively a policy decision about who may ever reconstruct the data. That makes key context a governance control, not a backend implementation detail. For multi-tenant programmes, the practical consequence is that tenant isolation has to be verified at the point of decryption, not assumed from the storage tier.

Version-controlled updates expose a broader control gap around silent data drift: if PII can be overwritten without a freshness check, the programme has no assurance that the stored value reflects the latest authorised state. Vault-style version checks therefore matter because they preserve integrity as well as confidentiality. The implication for practitioners is that PII controls must cover concurrency, not only encryption.

Application-layer PII encryption is a named pattern worth reusing: it describes the shift from storage-centric security to object-centric governance, where decryption scope and object lifecycle define exposure. That pattern is especially relevant where engineers, support staff, and automation can query production data. The practitioner conclusion is that at-rest security should be treated as necessary but not sufficient.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Application-layer encryption changes the governance unit from the database row to the encrypted object: once plaintext never lands in the application database, the practical question becomes which workflows are allowed to invoke decryption. That shifts control design toward tenant context, service-layer checks, and auditability rather than storage-only assumptions.

The key lesson for IAM and NHI programmes is that query access is not the same as data visibility. A database credential can still expose PII if the application preserves decryption rights too broadly, so the boundary must be defined by object lifecycle and context, not by storage location alone.

Vault sprawl can still undermine this model if object lifecycle is not disciplined: 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs. That makes reference hygiene, context binding, and deletion discipline part of the security control set, not administrative cleanup.

For practitioners

• Separate plaintext from the database Store Vault object IDs in application tables and keep the encrypted value outside the relational record so routine queries return references, not readable PII.
• Bind decryption to tenant context Use a context such as organizationId for each Vault operation so one tenant's encrypted objects cannot be decrypted under another tenant's key scope.
• Limit plaintext reads to true business need Use readObject only when the application genuinely needs the decrypted value, and use describeObject for existence checks, metadata, and audit state.
• Add optimistic concurrency to PII updates Read version metadata before updating and pass versionCheck into updateObject so stale writes do not silently overwrite a newer authorised value.
• Treat deletion as object lifecycle, not row cleanup Call deleteObject for every stored field, then null out the database references so erased PII is not recoverable through leftover Vault IDs.

Key takeaways

• Encryption at rest is not a complete PII control when the application, support tooling, or analytics pipeline can still trigger decryption.
• The real security boundary is the object context that determines when encrypted data becomes readable and under which tenant it can be opened.
• PII governance improves when teams store references in the database, restrict plaintext reads, and treat deletion as a lifecycle operation.

Key terms

• Application-layer encryption: Application-layer encryption means sensitive data is encrypted before it is written to storage, rather than relying only on disk or database encryption. The application decides when plaintext is created, while the encryption boundary is enforced outside the database, which reduces exposure from queries, exports, and backup copies.
• Key Context: A set of metadata values that tells a key service which encryption boundary applies to an object, such as tenant ID or data class. In practice, it lets the system derive the correct key without a manual registry, while keeping the boundary stable and auditable.
• Vault object ID: A non-sensitive identifier returned by the encryption service after a value is stored. The application keeps the ID in its own database and uses it later to read, update, describe, or delete the protected object without keeping the plaintext in row storage.
• Optimistic concurrency: Optimistic concurrency is a control pattern that prevents silent overwrites when multiple processes update the same object. A version check confirms the object has not changed since it was last read, so the application can reject or retry conflicting writes instead of losing data unnoticed.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.