Field‑level encryption / pseudonymization support for PII (ISO 27001 A.8.11 compliance)

## 🧩 Description.

ISO 27001:2022 Control A.8.11 (Data Masking) require that sensitive user data—like email, name, phone—must be **masked, pseudonymized, or encrypted at the field level**, so it cannot be read directly even by DBAs or storage admins
Currently, Authentik does **not support this** for PII in its user storage layer, exposing live PII in the database even if disk encryption or TLS is used—thus failing to meet these standards.

---

## ✅ Proposed solution:

Support **field-level encryption or pseudonymization** of user attributes. Possible options include:

- **Native encryption for core attributes**, like email, firstName, lastName, using symmetric or asymmetric keys.
- **Pluggable SPI or integration hooks** to intercept PII writes and reads, enabling deployers to handle encryption/decryption themselves.
- **Built-in pseudonymization/tokenization support**, optionally format-preserving, to allow reversible masking.

---

## 🔄 Alternative approaches

- **Disk-level encryption (e.g., full‑disk/TDE):** insufficient, as it doesn’t mask data in a live database—doesn't meet A.8.11 requirements.
- **External middleware:** possible but adds deployment complexity and duplication; better managed inside Authentik.
- **Store encrypted PII elsewhere:** works, but needs consistent application encryption; having this built-in would greatly simplify compliance.

---

## 📚 Additional context

Implementing field-level encryption or pseudonymization within Authentik would:
- Enable compliance with **ISO 27001 A.8.11** data masking/control.
- Support GDPR‑style pseudonymization and tokenization best practices.
- Reduce exposure risk when DB snapshots, backups, or live database sessions are accessed.
- Align with similar capabilities in other platforms (e.g. Keycloak SPI encryption plugins, field‑level encryption via Postgres).

---

The issue names no files, tests, or entry points. Start by mapping Authentik’s user storage layer and determining whether native encryption, pluggable hooks, or pseudonymization is in scope. Done requires an agreed design and implementation that protects the listed PII fields while supporting reads and writes.

Written by the indexing model from the issue text.