Azure Key Vault

Use Key Vault to manage the secrets and cryptographic material supported by your release. In Customer-managed Azure, your organization owns vault policy and service identities.

Design principles

• Give each service identity only the permissions it requires.
• Separate secret owners from routine application identities.
• Use versioned references where the consuming service supports them.
• Monitor reads, writes, deletes, recoveries, purges, and access-policy changes.
• Keep emergency access time-limited and reviewed.
• Test rotation and recovery before retiring a version.

Common uses

Supported uses include authentication and deployment signing, outbound request signing keys, content-protection keys, proof-provider credentials, and integration secrets. Check the release runbook for the items your deployment requires and their exact names and formats.

Managed identity

A managed identity removes the need for a client secret in application configuration. It does not remove the need to review role assignments, network access, token scope, and audit logs.

Rotation

Identify each consuming service and check how long it caches the secret. Confirm version selection, any supported overlap, and the recovery path before rotation.

After switching versions, test the affected workflow. Retain old material when existing records still require it, following the key’s retention and deletion rules.

Deletion

Soft delete and purge protection affect recovery timing. Align vault policy with the approved deletion, legal-hold, incident, and disaster-recovery processes.