Data Attribute Encryption
FirstHive can now encrypt individual sensitive fields, such as national IDs and financial account numbers, so they stay protected even from people and systems that can query the database.
The problem
FirstHive already encrypts data at the infrastructure level: whole disks, databases, backups and file storage. That protects against stolen disks or a compromised server. But anyone with query access to the database still sees every field in plain text, so a leaked application password or an over-privileged query can expose the most sensitive data.
Regulators increasingly expect more than “the disk is encrypted” for high-risk data like national IDs and financial account numbers. The options were poor:
- Encrypt everything: costly, slower, and it breaks search and analytics.
- Encrypt nothing beyond the disk: today’s state, and not enough for the most sensitive fields.
How it solves the problem
Data Attribute Encryption adds a second, targeted layer of protection on top of disk encryption, applied only to the fields that need it.
- Driven by Data Discovery: Data Discovery continuously finds and classifies sensitive fields across your data. Each one appears automatically as an encryption candidate, tagged with its sensitivity level.
- You decide what gets encrypted: an Owner-level admin reviews the candidates and turns on encryption by sensitivity tier or field by field, confirmed with multi-factor authentication. Nothing is encrypted automatically, so no search or report breaks by surprise.
- Uses your existing keys: fields are encrypted with the same key options you already use (FirstHive-managed, AWS KMS or HashiCorp Vault), with keys rotated every 90 days by default.
- Invisible to authorised users: authorised users and services see the real value automatically. Everyone else sees only encrypted data.
- Covers existing data too: a background job encrypts values already stored, without downtime.
- Consistent everywhere: when a field is copied into other FirstHive stores, encryption applies in every one of them.
- Honest warnings: before you encrypt a field used in search, reporting, segments or identity matching (such as email or mobile), FirstHive tells you what will stop working and asks you to confirm.
- Fails safe: if the key service can’t be reached, the read or write is blocked. Plain text is never returned or stored as a fallback.
- Fully audited: every change and backfill is logged, and admins can see each field’s status, key version, last rotation date and backfill progress.
- Right to delete still works: encrypted fields are deleted on request just like any other data.
Use cases
| Who | Use case |
|---|---|
| DPO or platform admin | Encrypt every field Data Discovery classifies as highly sensitive, such as PAN, Aadhaar and bank account numbers, in one action |
| Compliance or legal | Show a regulator or auditor that specific high-risk fields are individually protected, not just the disk |
| Banking or insurance brand | Protect financial and health-related fields to support DPDP Act compliance, while marketing keeps working on non-sensitive data |
| Engineering | Read sensitive values when authorised, without building encryption into every service |
Good to know: this is encryption, not tokenisation. Encrypted fields can’t be used for full-text search or reporting aggregations in this release, and identity fields like email and mobile should stay unencrypted until a matching method for encrypted values is available.