A secret leak rarely starts with a dramatic break-in. More often, it starts with access that nobody questioned for months.

An Azure Key Vault audit should show who can read secrets, who can change policy, and which identities still have access after their work ended. If you wait until a secret shows up in logs, code, or a paste site, the damage is already underway.

The fastest way to lower that risk is to review access before you review anything else. Then pull the logs, compare them to real use, and cut away permissions that no longer belong.

Start with the access paths that matter most

Key Vault problems usually begin with the permission model. If you do not know whether a vault uses Azure RBAC, access policies, or both, the rest of the audit gets messy fast.

Microsoft recommends RBAC over legacy access policies in its secure your Azure Key Vault guidance. That matters because older access policy setups are easy to leave behind, and they do not fit privileged access workflows as cleanly.

Use this quick comparison to orient the audit:

Access path	What to inspect	Risk if ignored
Azure RBAC	Role assignments at vault, resource group, and subscription scope	Broad inherited access can hide extra readers
Access policies	Direct secret, key, and certificate permissions	Old entries often stay after teams move on
Custom roles	Actions tied to vault read, write, delete, and policy changes	A custom role can grant more than the owner realizes
Eligible access in PIM	Permanent versus just-in-time elevation	Standing access makes misuse easier to miss

Once you know the model, look for the obvious overreach. A user who only needs one secret should not have list access to every secret. A pipeline account that reads a certificate should not also edit vault settings.

A useful rule is simple, if a principal can change access, it can often expand its own reach later. That is why vault admins, IAM admins, and app owners deserve separate review.

Also check inherited scope. A role assignment at the subscription level can expose more vaults than the team thinks. In other words, a clean vault blade in Azure Portal can still sit behind a very wide permission path.

Pull the right logs before you review permissions

Permissions tell you who could touch the vault. Logs tell you who actually did.

For a proper audit, collect Key Vault diagnostics, Azure Activity Log entries, identity sign-ins, and any threat alerts in one place. Microsoft documents the setup in Azure Key Vault logging.

A good log review usually includes these sources:

Log source	What it shows	Why it matters
Key Vault diagnostic logs	Secret, key, and certificate operations	Shows actual data-plane activity
Azure Activity Log	Changes to vault settings, RBAC, and policies	Reveals control-plane changes
Microsoft Entra sign-in logs	Who authenticated and from where	Helps tie access to a person or workload
Microsoft Defender for Key Vault	Risk signals and suspicious behavior	Adds detection beyond raw events

Send those logs to a workspace where you can search them together. Azure Monitor and Microsoft Sentinel both work well for this. If the logs live in separate places, the audit will miss patterns that only show up when you line them up.

Pay close attention to retention. Keep enough history to compare current behavior with normal use. If your review cycle is monthly, a few days of logs will not help much.

A few events deserve extra attention right away:

• Secret reads from unfamiliar identities.
• Any secret delete or purge request.
• Access policy changes.
• RBAC changes around the vault.
• Diagnostic settings being turned off.

If you only store write events, you miss the reconnaissance that happens first. If you only store success events, you miss the failed probes that often come before a leak.

Build an Azure Key Vault audit report that shows real risk

A useful report is not a giant export. It is a short view that answers a few hard questions fast.

The report should show who has access, what type of identity they are, what they can do, and when they last used it. That gives you a way to spot stale access and risky breadth.

A solid report usually includes these columns:

• Principal name.
• Identity type, such as user, service principal, managed identity, or group.
• Vault name and scope.
• Permission type, such as read, list, set, delete, or policy change.
• Last successful access.
• Last failed access.
• Owner or app team.
• Approval or ticket reference, if one exists.

Once that report is built, sort by the most sensitive permissions first. Secret read and list are more important than general management access. Then check for principals that have access but no recent use.

Unused permissions are still permissions. In a breach, they can become the easiest door.

Look for patterns such as a group with broad access but only one active app, or a role assignment that outlived the project it was meant for. Stale group membership is one of the easiest ways for access to drift.

This is also where least privilege becomes practical. If an app only needs one secret, do not leave it with list access to every secret in the vault. If a team only needs to retrieve a certificate, do not give it delete rights.

A simple reporting idea is to compare last use with last grant date. If a principal was granted access months ago and never used it, that is a review item. If it still appears in a production vault, it deserves a ticket before the next change window closes.

Spot suspicious access patterns before they become a leak

Attackers do not usually start by stealing the secret they want. They first test the vault, probe for errors, and look for weak spots.

That makes anomaly hunting one of the most useful parts of an Azure Key Vault audit. A few small signals often show up before the real exposure.

Suspicious pattern	What it can mean	First response
Burst of SecretList calls	Reconnaissance or scripting	Check the identity, source IP, and owner
Repeated 401 or 403 failures	Bad token, stolen credential, or wrong scope	Correlate with sign-in logs and recent role changes
Access from a new region or IP	Compromised account or workload	Validate the client and compare with normal behavior
SecretGet after long silence	Dormant access woke up	Confirm whether a release, job, or script explains it
SecretDelete or purge attempts	Tampering or cleanup after access	Freeze changes and preserve logs

The biggest mistake is treating denied requests as harmless. A run of failures often means someone is mapping the vault before they find a way in. The same is true for a sudden jump in list activity.

Also watch for gaps in the logs themselves. If audit logs stop at the same time access gets weird, treat that as a signal. A quiet vault with disabled diagnostics is a problem, not a clean bill of health.

A good alert plan ties each event to an owner. That way, a security analyst does not have to guess whether a spike belongs to a deployment, a maintenance job, or an attack.

Check service principals, managed identities, and break-glass access

Human users are only part of the story. In many environments, the riskiest access comes from identities that no one watches closely.

Service principals often hold broad permissions because they support automation. Managed identities are even easier to forget, because they feel temporary even when they keep running for years. Break-glass accounts are another common blind spot, especially when they have never been tested.

Use this review list:

• Service principals with secret or key read rights across multiple vaults.
• Managed identities tied to retired apps, old pipelines, or stopped resources.
• App registrations with stale credentials or certificates.
• Group memberships that silently extend access to automation accounts.
• Break-glass accounts with standing access instead of time-bound elevation.

For service principals, check both the vault permissions and the app credentials. If the credential is old, weak, or shared, the vault may be only one step away from exposure. If the app no longer has a clear owner, remove the access until someone can justify it.

Managed identities deserve the same treatment. Teams often assume they are safe because they are tied to Azure resources. That assumption fails when the resource is no longer used but the identity still holds vault rights.

Break-glass access needs special care. Keep it separate from daily admin accounts, monitor every use, and review it often. If you can, make it eligible rather than permanent. Emergency access should look loud in the logs, not invisible in the background.

A short but effective habit is to test emergency access on a schedule. If nobody can prove the account still works, it will fail when the incident is real.

Turn the audit into alerts and controls

An audit has value only if it changes the setup afterward. Otherwise, the same risky access returns next month.

Start with alerts for the events that matter most, such as secret deletion, policy changes, failed sign-in spikes, and new role assignments on a vault. Microsoft Defender for Key Vault can help here, and Azure Monitor or Sentinel can route the alerts to the right team.

Then put control changes behind the findings:

• Remove access that no one has used in a reasonable period.
• Replace broad roles with narrower vault-scoped roles.
• Use PIM for admin access where possible.
• Separate production vaults from dev and test vaults.
• Turn on soft delete and purge protection.
• Review rotation for secrets, keys, and certificates.

If your team needs help turning findings into a working review process, Book a Discovery Call with Bud Consulting.

The best control is the one that reduces surprise. When an identity tries something unusual, the alert should fire. When a role assignment changes, the owner should know. When a vault stops sending logs, someone should ask why.

Conclusion

A leak is rarely a single event. It is usually a chain of weak access, stale identities, and missed signals.

A strong Azure Key Vault audit breaks that chain early. It shows who can reach the vault, who has not used access, which identities need a second look, and where monitoring needs to get louder.

If you can answer three questions with confidence, you are in good shape, who can read secrets, who can change access, and who gets alerted when something shifts. That is the difference between a vault that looks secure and one that stays secure.

FAQs

How often should Azure Key Vault access be audited?

Monthly works well for high-value vaults, especially if secrets support production apps or customer data. Quarterly can be enough for lower-risk environments, but only if access changes are rare and alerts are strong. Audit again after major IAM changes, app launches, migrations, or incident response work.

Should I use Azure RBAC or access policies for Key Vault?

Use Azure RBAC when you can. Microsoft recommends it over legacy access policies in current guidance. Access policies still appear in older setups, but they are easier to forget, harder to govern at scale, and less friendly to privileged access workflows.

Which permissions are most risky in a Key Vault audit?

Secret read and list rights are the biggest concern, followed by delete, purge, and policy or role change permissions. Anything that lets a principal widen access, disable logging, or alter the vault setup also deserves close review. Broad inherited scope is another common risk.

What should I alert on first?

Start with secret delete or purge events, spikes in failed access, new role assignments, policy changes, and disabled diagnostics. Those alerts catch the kinds of changes that often happen right before exposure. If possible, route them to both security operations and the vault owner.

Do managed identities need the same review as user accounts?

Yes. Managed identities can hold powerful vault access and stay active long after a project changes. Review them the same way you review users and service principals, with a focus on scope, last use, and whether the resource still needs the permission.