Coming Soon: Envelope Encryption for Passwords with Customer-Managed Keys
March 9, 2026 · GrantFlow Team
GrantFlow is adding envelope encryption for account passwords. Every credential will be encrypted with a tenant-specific encryption key before it is written to Azure Key Vault — and enterprise customers can bring their own key (BYOK) for complete control over encryption and decryption.
INFO
This feature is currently in development. Implementation details described in this article may change before the final release.
Why Envelope Encryption?
Today, GrantFlow stores account passwords as Azure Key Vault secrets. Key Vault already encrypts secrets at rest, but the passwords themselves are stored as plaintext secret values inside the vault. Enterprise customers — especially in the DACH region and regulated industries — need stronger guarantees:
- Data sovereignty — Even if GrantFlow's Key Vault were compromised, the stored values would be useless without the encryption key.
- Compliance — SOC 2 Type II, ISO 27001, GDPR, and BSI C5 all benefit from demonstrable customer control over encryption keys.
- Key lifecycle control — Customers can rotate, revoke, or destroy the encryption key on their own schedule, independent of GrantFlow.
- Audit visibility — Every encrypt and decrypt call is logged in the customer's own Azure Key Vault, providing a tamper-resistant audit trail.
How It Works
Envelope encryption adds a layer of protection by wrapping each password with your tenant's encryption key before the result is stored. Only encrypted ciphertext is stored in GrantFlow's vault — the encryption key stays in the key owner's vault.
When storing a password — for example during password rotation — GrantFlow encrypts the value with your tenant's key and stores only the encrypted result. When you retrieve a password — for example during account checkout — GrantFlow decrypts it on demand using the same key. The plaintext is never persisted.
Three Encryption Modes
The feature supports three modes so every customer can choose the right balance of simplicity and control:
| Mode | Key Location | Description |
|---|---|---|
| Managed (default) | GrantFlow's Key Vault | GrantFlow creates and manages the RSA key. No customer setup required. |
| Customer Vault | Customer's Key Vault | The customer's RSA key in their own Azure Key Vault, accessed via cross-tenant federated identity. |
| Customer Service Principal | Customer's Key Vault | The customer's RSA key accessed via a service principal the customer provides. |
In all three modes, the encrypted ciphertext is stored in GrantFlow's Key Vault. The difference is who owns and controls the RSA key that performs the encryption.
Cross-Tenant Access
For the Customer Vault mode, GrantFlow authenticates to your Key Vault using federated identity — no shared secrets are exchanged between tenants. GrantFlow only needs the Key Vault Crypto User role on your key — it never accesses your Key Vault secrets and cannot export the key material. All encrypt and decrypt operations are logged in your Azure Key Vault audit trail.
Validation Before You Go Live
Before switching to a customer-managed key, GrantFlow performs a round-trip validation: it encrypts a test payload with your key, decrypts it, and confirms the result matches. If permissions are misconfigured, the validation response tells you exactly what role or operation is missing and how to fix it.
Migrating Existing Passwords
When you enable envelope encryption on an existing tenant, you have three options:
- Gradual — New and rotated passwords are encrypted with the new key. Existing passwords keep working as-is until their next rotation.
- Bulk migration — Re-encrypt all existing passwords in one operation. The migration runs in batches, tracks progress, and can be configured to stop or continue on errors.
- Rollback — Switch back to managed encryption at any time by re-encrypting secrets with GrantFlow's key.
Passwords remain accessible throughout the migration. Existing secrets without envelope encryption continue to work unchanged — GrantFlow detects whether a secret is envelope-encrypted and handles both paths transparently.
Security Guarantees
| Threat | Mitigation |
|---|---|
| GrantFlow database compromise | Stored references point to ciphertext — useless without the encryption key |
| GrantFlow Key Vault compromise | Secrets contain encrypted ciphertext, not plaintext — the encryption key lives in the customer's vault |
| Customer revokes key access | Decryption fails gracefully; admin is notified; ciphertext is preserved and recoverable when access is restored |
| Key rotation | Existing secrets are re-encrypted with the new key version |
| Replay attacks | Industry-standard padding ensures identical plaintexts produce different ciphertexts |
Every encrypt and decrypt operation is audit-logged with the key identifier. Plaintext values are never written to any log.
Compliance Coverage
| Standard | How Envelope Encryption Helps |
|---|---|
| SOC 2 CC6.1 | Envelope encryption layered on at-rest encryption in Azure Key Vault |
| ISO 27001 A.10.1.1 | Customer-controlled key lifecycle — rotation, revocation, destruction |
| GDPR Art. 32 | Data sovereignty — the customer holds the only decryption key |
| BSI C5 | Encryption keys reside in the customer's own Azure tenant |
What to Expect
Once this feature ships, you will find a new Encryption section in the GrantFlow admin portal where you can:
- Choose an encryption mode (managed, customer vault, or customer service principal).
- Enter your Key Vault URL and key name and run the built-in validation.
- Trigger and monitor bulk migration of existing passwords.
- View encryption statistics — how many secrets are encrypted with which key.
No changes are required for the managed (default) mode. GrantFlow will begin encrypting new passwords automatically and existing passwords will be encrypted on their next rotation.
Questions about BYOK or want to plan an early adoption? Reach out at info@grantflow.cloud.