Azure Key Vault Mistakes That Expose Sensitive Secrets
Key Vault was meant to be the centralised, audited and access controlled home for secrets across an Azure estate. In the best implementations it does exactly that. In the worst it becomes a single place that holds every important credential the organisation owns, configured with access policies generous enough to give half the engineering team a clean route to administrative privileges. The technology is sound. The configurations are where it goes wrong.
Access Policies Versus RBAC
Older Key Vault instances use access policies, the legacy permission model that grants vault wide rights to identified principals. Modern instances should use Azure RBAC for finer grained control. Mixing the two creates confusion and frequently leaves principals with both kinds of permission active at once. Pick one model, ideally RBAC, and migrate the older vaults across deliberately. A focused Azure pen testing should highlight any vaults still on the legacy model and review the principals that hold permissions on each one.
Secrets That Never Rotate
Secrets stored in Key Vault are only as good as the rotation policy applied to them. A secret created in 2021 that has never been rotated is effectively a permanent credential with the security properties of any other long-lived credential. Where the underlying service supports it, automatic rotation should be configured. Where it does not, a calendar based rotation process should be enforced. The discipline rarely fails because the technology is hard. It fails because the process never got designed.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
A finding we report repeatedly is a Key Vault holding production secrets that has both diagnostic logging disabled and the firewall set to allow all networks. The first means we cannot see when secrets were accessed. The second means anyone with valid permissions can access them from any IP address on the planet. Neither is the default any more, but old vaults carry old habits.
Secret Sprawl Beyond Key Vault
Many secrets that should live in Key Vault live elsewhere instead. Application configuration files, environment variables, source code repositories and chat platform message histories all collect credentials over time. Hunt for these alternative homes regularly and migrate the secrets you find into proper secret management. The hunt is more effective when it includes the development team rather than running purely as a security exercise. Worth pairing this hunt with consistent enforcement of secret scanning on every commit to source control. The two activities together close most of the routes that lead to credential leakage in modern engineering environments.
Network Restrictions Are Available For A Reason
Key Vault supports firewall rules and private endpoints. Both should be in active use for vaults holding production secrets. Anything that limits the contexts from which a vault can be reached cuts the impact of a stolen credential or a compromised workstation. Combine network restrictions with a vulnerability scan services approach that periodically verifies the controls are still in effect and the configuration has not drifted.
Key Vault is one of those services where small misconfigurations have outsize consequences. Worth the time to get right. Secret management hygiene is the kind of work that pays back during incidents you never have to investigate. Worth the investment well ahead of need. Cloud security is a shared responsibility model in name and a fully owned responsibility model in practice. The configuration choices that matter live on your side of the line, regardless of how the provider markets the platform.
