I work with Azure Key Vault in a lot of customer environments, and one thing keeps coming up: Key Vault hardening involves far more than moving to RBAC. I still find vaults open to "All Networks", or firewall exceptions that were never closed because a developer or an automation "needed it working quickly". That might hold up for a while. For sensitive secrets and keys, though, it will cause problems sooner or later. Once RBAC is in place, the actual hardening work has only just started.

A firewall or a private endpoint actually locks down network access

The most important step after RBAC sits in the Key Vault blade under Settings → Networking: "Public network access: Disabled". With that setting, even a stolen admin token won't get anyone into your vault from outside, unless there's a private endpoint. If a few VNets or subnets need legitimate access, use explicit firewall rules. What I see a lot is the “Allow trusted Microsoft services” exception left on, because turning it off can break Azure services such as Automation or Logic Apps. In that situation you have to decide how much functionality you need and how much risk you're willing to accept. Complete isolation only comes with private endpoints.

Private endpoints bring their own problems, mostly with DNS. If the privatelink.vaultcore.azure.net private DNS zone isn't set up correctly, apps in the VNet may not be able to resolve the vault at all. I covered these DNS traps in detail in my post on common private endpoint DNS mistakes in Azure. This diagram shows the network flow once Key Vault hardening is in place:

flowchart TD
    Client["Client in VNet"] --> DNS["DNS resolve privatelink.vaultcore"]
    DNS --> PrivateEndpoint["Private Endpoint"]
    PrivateEndpoint --> KeyVault["Azure Key Vault"]
    Extern["external client"] -->|"access blocked"| Firewall["Key Vault Firewall"]
    Firewall -.->|"no access"| KeyVault

Figure: Network flow for a hardened Key Vault with private endpoint and firewall

Soft delete and purge protection stop permanent deletion

Without deletion protection, Key Vault hardening is incomplete. Since 2022, purge protection has been enforced by default on all new vaults, and you can't switch it off. Soft delete means a vault or secret is only gone for good after a retention period. Purge protection goes further and prevents even a compromised admin from destroying it immediately. People often ask me how to get back secrets that were "accidentally deleted". As long as the soft delete period hasn't run out, you can recover them, usually with the Azure CLI or the REST API. Microsoft explains the logic and its caveats clearly in the docs (https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview).

AuditEvent logs belong in Log Analytics

You can't harden what you can't see. Turn on diagnostic settings (Azure portal → Key Vault → Diagnostic settings) and send them to a Log Analytics workspace. Depending on how diagnostics are configured, the logs end up either in AzureDiagnostics or in the more specific AZKVAuditLogs table. AzureDiagnostics can be enough for small setups. Once you have several vaults, AZKVAuditLogs gives you a much cleaner picture. To find every failed secret access attempt, for example, go to Log Analytics workspace → Logs and run:

// Prerequisites: Log Analytics Reader on the workspace, diagnostic setting AuditEvent enabled
AZKVAuditLogs
| where OperationName == "SecretGet" and Status != "Success"
| project TimeGenerated, Caller, Resource, Status, ResultReason

Tip from the field: In production, create an alert that fires on multiple failed access attempts per hour. It warns you early about compromised accounts or apps with a broken configuration.

The official docs go deeper into network security and firewalling (https://learn.microsoft.com/en-us/azure/key-vault/general/network-security).

Azure Policy and Defender for Key Vault automate compliance

Once you're managing a larger number of vaults, you really need the Azure Policy built-ins. They let you require disabled public network access and enforce private endpoints across the board. The one I use most is “Azure Key Vault should have firewall enabled and public network access disabled”, which catches the gaps people open by accident. Microsoft Defender for Key Vault (requires Defender for Cloud Plan 2 or the Key Vault add-on) adds alerts for suspicious activity, such as mass secret dumps or access from unusual sources.

Still on classic access policies? My migration guide, based on real projects, is here: moving Azure Key Vault from access policies to RBAC.

In my view, hardening is never a one-time job

Key Vault hardening is a good example of how cloud security works in practice. Lots of small details together give you solid protection. DNS for private endpoints tends to be the hardest part, and plenty of outages wouldn't happen with a correct setup. I still come across public vaults, left that way out of convenience or because someone misunderstood the settings. If you get network access, logging and deletion protection right, you've dealt with the main risks. Microsoft keeps improving its tools, but what counts is how well the basics are done in your own tenant.