Topic starter
01/07/2026 2:11 am
TL;DR: Encrypting PII before it reaches the database shifts protection from storage controls to application-layer key boundaries, so plain SQL queries, exports, and tenant-leak bugs return ciphertext instead of readable user data, according to WorkOS. That makes decryption scope, object lifecycle, and key context part of the identity governance problem, not just the cryptography problem.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Encrypting PII in a Node.js app with WorkOS Vault”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Encryption at rest is not a complete PII control when the application, support tooling, or analytics pipeline can still trigger decryption.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
01/07/2026 2:33 am
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.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
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.
👉 Read our full editorial: Application-layer encryption for PII exposes the limits of at-rest security
This post was modified 3 days ago by NHI Mgmt Group