Unable to see Key Vault audit logs in Log Analytics

Hello Mike Rees,

You have enabled diagnostics for an Azure Key Vault with allLogs selected and connected it to a Log Analytics workspace. But your Key Vault diagnostic logs aren’t flowing into the expected tables, even though metrics are working and other services are logging fine.

Can you help confirm a few things so I can better understand the issue:

• Did you select both "AuditEvent" (or "Audit") and "AllLogs" when setting up the diagnostic settings? You mentioned only "AllLogs" was selected.
• Have there been any recent access attempts or changes to Key Vault’s policies? These actions are what typically generate audit logs.
• When you checked the AZKVAuditLogs table and saw no data, were you querying from the time diagnostics were enabled? Or did you first perform an action on the Key Vault (like retrieving or setting a secret), then wait 10–15 minutes before running the query?

Thanks,

@Bharath Y P , Sorry, that was an omission on my part.
for the diagnostic settings for AKV, all three are checked (audit, allLogs and AllMetrics)

In the categories, (and appropriately greyed out) are Audit Logs and Azure Policy Evaluation Details)

The KV is used by our production ETL processes, so there should be retrievals throughout each day.

For my query, it was with time frame first, and when I saw none, I removed the where clause entirely, and just took 10 rows (or attempted to take them)

I want to eventually see when a stored Certificate is accessed. Would this table include Certificate access? If not, what table would?

Even so, with the KV being used regularly during the day, I expect to see secrets being retrieved in this table. I did not need to delay my queries because there is expected activity throughout the day.

Hello Mike Rees,

Thanks for the update, selecting the allLogs category group automatically includes ALL underlying log categories for that resource, which in this case are Audit Logs and Azure Policy Evaluation Details.

You’re probably not seeing any Key Vault logs even though your production ETL process is running because there may be a delay in data ingestion, querying the wrong table, or a missing link between the Key Vault and the Log Analytics workspace.

Since you’ve confirmed that diagnostic settings are enabled and the correct categories are selected, here are the next steps to troubleshoot, focusing on how you're querying Log Analytics:

Depending on how your diagnostic settings are configured, logs may appear in one of two tables:

AzureDiagnostics: This is the standard table that collects logs from many different Azure services.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where Resource == "YourKeyVaultName" // Optional but recommended
| take 10

AzureKeyVaults: This is a newer, specialized table that stores logs specifically for Key Vaults, but only if you chose the resource-specific option when setting up diagnostics.

AzureKeyVaults
| take 10

If the logs exist, one of these queries will return data.

Since the diagnostic setting was created recently, one of the most common issues is that it's pointing to the wrong Log Analytics Workspace, or the ETL process hasn’t triggered a true “data plane” operation that would generate audit logs.

1. Go to the Azure Portal > Navigate to your Key Vault.
2. Select Monitoring > Diagnostic settings.
3. Open the diagnostic setting you configured.
4. Confirm that the destination workspace is the same one where you're running your KQL queries.

The certificate access events are considered data plane operations, and they should be captured in the Key Vault audit logs, assuming diagnostics are correctly configured.

The AuditEvent category in your diagnostic settings records operations like GetCertificate, , DeleteCertificate, UpdateCertificate and ListCertificate. These types of events are usually logged in the AZKVAuditLogs table.

Hello Mike Rees, kindly let us know if the solution provided was helpful. If you need any further assistance, please let us know.

Thanks.

I will. Sorry, I was unable to check back into this yesterday. I will do this today