Azure Key Vault is where your secrets, certificates, and encryption keys live. When it drifts, attackers stop hunting for credentials in code repos and start reading them straight out of the vault. These seven patterns show up in almost every subscription we audit.

1. Public Network Access Left On

Most vaults default to "all networks." Anyone with a valid token can hit the data plane from anywhere in the world. Restrict the vault to selected networks or private endpoints, then layer on Conditional Access for human access.

2. Access Policies Instead of RBAC

Legacy access policies grant flat, all-or-nothing permissions and don't show up in standard RBAC reviews. Migrate to Azure RBAC for Key Vault. You get scoped roles, PIM eligibility, and a proper audit trail across the same plane as the rest of your subscription.

3. Soft Delete Without Purge Protection

Soft delete recovers an accidentally deleted secret. Purge protection stops an attacker (or a panicked admin) from permanently destroying the vault during the soft-delete window. Both should be on. Purge protection is the one people forget.

4. Secrets That Never Expire

Connection strings and API keys sitting in vaults with no expiration date, no rotation schedule, no owner. The vault is doing its job. The process around it is not. Set expiration on every secret and alert on anything within 30 days of expiry.

5. Diagnostic Logs Going Nowhere

Key Vault writes detailed logs about every secret access. Most vaults send them to a Log Analytics workspace nobody reads, or to a storage account that quietly aged out. Forward to Sentinel or your SIEM and alert on bulk reads, off-hours access, and unfamiliar service principals.

6. Service Principals With Get and List on Everything

A pipeline only needs one secret. Yet the service principal it uses can list and read every secret in the vault. Scope permissions down to specific secrets where possible, and at minimum split read access by workload so a compromised pipeline doesn't hand over the whole vault.

7. No Private Endpoint for Sensitive Vaults

Vaults holding production database passwords, signing keys, or customer-managed encryption keys should not be reachable over public Azure endpoints, even with firewall rules in place. Private endpoints take an hour to configure and eliminate an entire class of exposure.

Why It Keeps Happening

Key Vault is treated like a checkbox. A developer creates it, drops in a secret, moves on. Nobody owns the long-term posture, and the defaults are not safe enough on their own. SecValley flags all seven patterns across its 500+ controls so you find them before an incident does. The vault is only as safe as the configuration around it.