Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: Encrypting PII in a Node.js app with WorkOS Vault
Questions worth separating out
Q: How should security teams protect PII when database encryption at rest is not enough?
A: Move the protection boundary into the application so sensitive values are encrypted before they reach the database.
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: What do teams get wrong about deleting encrypted PII?
A: They often delete the plaintext row but leave copies behind in backups, analytics extracts, logs, or secondary tables.
Practitioner guidance
- Store opaque Vault IDs in your application database Persist only the returned object IDs for email, phone, and address fields.
- Bind each PII object to the correct organisation context Set the Vault context to the user's organisation ID for every create and update operation.
- Use describeObject for metadata checks only Check existence, version, and audit metadata without decrypting values unless plaintext is required.
What's in the full article
WorkOS's full tutorial covers the operational detail this post intentionally leaves for the source:
- Step-by-step Node.js code for createObject, readObject, updateObject, and deleteObject calls.
- Full vault.ts module structure for storing, reading, updating, and deleting user PII fields.
- Version-check handling for optimistic concurrency when multiple processes edit the same record.
- Practical examples for listing user PII objects before account deletion and erasure workflows.
👉 Read WorkOS's tutorial on encrypting PII with Vault in Node.js →
PII encryption at the application layer: what IAM teams should notice?
Explore further
01/07/2026 2:33 am
Application-layer encryption is the right response when storage-layer trust has already failed. Encryption at rest protects hardware loss, not database query privilege, API leakage, or internal export abuse. Once a team accepts that engineers, pipelines, and attackers can reach the data plane, the real control becomes where plaintext is allowed to exist. The implication is that identity governance must account for read paths, not just storage locations.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: How can organisations reduce unnecessary decryption of sensitive fields?
A: Use metadata-only operations for existence checks, version checks, and audit review, and decrypt only when a workflow actually needs the plaintext. That keeps sensitive values out of memory and logs for most requests. It also makes access review easier, because you can separate object management from data disclosure.
👉 Read our full editorial: Application-layer encryption for PII exposes the limits of at-rest security
