Azure Cloud HSM Hardware Audit Logging GA: Verify Firmware-Signed HSM Logs

For Windows Server administrators, PKI architects running Active Directory Certificate Services (AD CS), and cloud security engineers, this launch closes an important observability gap between service-observed telemetry and hardware-attested audit trails.

Why Hardware-Level Auditing Matters for Azure Cloud HSM​

To appreciate why firmware-generated audit logs are a big deal, it helps to look at where Azure Cloud HSM sits in Microsoft's cryptographic portfolio. According to Microsoft Learn's Azure Cloud HSM documentation, the service is a single-tenant, customer-managed, highly available cluster of Marvell LiquidSecurity HSMs validated to FIPS 140-3 Level 3 standards. Each cluster synchronizes across three HSM nodes and deploys directly into a customer's private virtual network, making it a go-to migration target for IaaS workloads that rely on traditional HSM interfaces—such as AD CS, SQL Server Transparent Data Encryption (TDE) with Extensible Key Management (EKM), SSL/TLS offloading, document and code signing, and applications using Cryptography API: Next Generation (CNG), Key Storage Provider (KSP), PKCS#11, OpenSSL, or Java Cryptography Extension (JCE).

Microsoft's architecture enforces strict separation of duties. While Microsoft maintains limited appliance-level permissions to monitor health, run encrypted backups, and extract and publish immutable audit logs to customer-specified storage, Microsoft personnel have no cryptographic control over customer-allocated HSMs and cannot access or use keys stored inside customer partitions.

Until now, administrators looking at operational telemetry primarily relied on service-level event logging. With the general availability of hardware audit logging, customers can capture signed, tamper-evident records produced by the HSM firmware itself whenever management operations occur on their HSM partitions.

Hardware Audit Logs vs. Service Operation Logs​

One of the sharpest takeaways in Microsoft Learn's updated October 14, 2026 tutorial on Azure Cloud HSM operation audit logs is the clear distinction between the two diagnostic categories now available on Microsoft.HardwareSecurityModules/cloudHsmClusters resources:

Why keep both around? Think of HsmServiceOperations as the building security camera in the lobby and HsmOperations as the signed ledger inside the vault. Service logs are handy when you are troubleshooting client connectivity, checking SDK package versions (ClientSdkPackageVersion), or measuring service execution time (DurationMs). However, when an auditor or incident responder needs to prove who logged into a partition, modified quorum settings, or generated and deleted keys—and verify mathematically that the log records were not altered in transit—HsmOperations is the authoritative record.

Because HsmOperations records can contain operational identifiers like user IDs, session handles, and key handles, Microsoft explicitly warns administrators to lock down access to the destination Azure Storage account and Log Analytics workspace.

Section Summary: Azure Cloud HSM now differentiates between firmware-generated hardware audit logs (HsmOperations routed to CloudHsmHardwareOperationAuditLogs) for compliance and cryptographic verification, and service-observed logs (HsmServiceOperations routed to CloudHsmServiceOperationAuditLogs) for troubleshooting.

How Signed Batch Verification Works Under the Hood​

What makes a hardware audit log "tamper-evident" once it leaves the physical Marvell LiquidSecurity appliance and lands in Azure Monitor?

According to Microsoft Learn's tutorial for Azure Cloud HSM operation audit logs, records are retrieved from each HSM partition in batches. Each batch is cryptographically signed by the HSM using the partition certificate key. Every log entry belonging to the same batch shares a common CorrelationId. Alongside the management operation events (whose operation names begin with CN_), the table receives batch integrity and public certificate records prefixed with BATCH_:

• BATCH_BINARY_SIGNATURE: Carries the HSM-generated digital signature and SHA-256 hash covering the batch.
• BATCH_PARTITION_IDENTITY_CERT: Provides the partition identity certificate signed by the HSM.
• BATCH_HSM_DEVICE_CERT: Identifies the specific HSM hardware device.
• BATCH_HSM_MANUFACTURER_ROOT_CERT: Supplies the HSM manufacturer root certificate, acting as the trust anchor for the certificate chain.
• BATCH_HSM_OWNER_AUTH_CERT: Contains the HSM Owner Authentication Certificate identifying the hardware owner.

By pairing the management events sharing a CorrelationId with their corresponding BATCH_ signature and certificate records, security teams can independently verify the authenticity and integrity of the exported audit trail offline.

Configuring and Querying Hardware Audit Logging​

Setting up hardware audit logging follows standard Azure Monitor diagnostic workflows, though there are a few HSM-specific nuances worth noting before you fire up a terminal.

1. Prepare Your Destinations and Resource Provider​

Microsoft recommends routing HsmOperations to both a General Purpose v2 (StorageV2) Azure Storage account for long-term retention and an Azure Monitor Log Analytics workspace for Kusto (KQL) querying and alerting. Note that a supported Log Analytics workspace must have a retention period of at least 30 days.

If your subscription has not previously used Azure Monitor diagnostics, you may encounter an error stating that the subscription is not registered to use microsoft.insights. You can register the provider via Azure CLI or PowerShell:

az provider register --namespace Microsoft.Insights
az provider show --namespace Microsoft.Insights --query "registrationState" --output table

2. Enable Diagnostic Settings on the Cloud HSM Cluster​

Using Azure CLI or Azure PowerShell, create a diagnostic setting targeting your Microsoft.HardwareSecurityModules/cloudHsmClusters resource ID. Enable the HsmOperations category (and optionally HsmServiceOperations alongside it) with resource-specific destination tables enabled (--export-to-resource-specific true in Azure CLI).

In PowerShell, creating the log settings object looks like this:

$hsmOperationLog = New-AzDiagnosticSettingLogSettingsObject -Category HsmOperations -Enabled $true
$serviceOperationLog = New-AzDiagnosticSettingLogSettingsObject -Category HsmServiceOperations -Enabled $true

Keep ingestion timing in mind during testing: while logs often show up within several minutes of performing a management operation, Microsoft notes that normal Azure resource-log ingestion takes roughly 20 minutes, and initial activation of a brand-new diagnostic setting can occasionally take up to 90 minutes. Diagnostic settings also do not backfill events that occurred before the setting was created.

3. Query Management Operations with KQL​

Once records populate the CloudHsmHardwareOperationAuditLogs table, you can filter out the BATCH_ certificate rows to inspect management commands directly in Log Analytics:

CloudHsmHardwareOperationAuditLogs
| where OperationName startswith "CN_"
| project TimeGenerated, OperationName, ResultType, UserID, SessionHandle, HsmInstance, SequenceNumber, AdditionalInfo

According to Microsoft's glossary of operations, HsmOperations captures management commands across session management (CN_LOGIN, CN_LOGOUT, CN_CLOSE_SESSION, CN_APP_FINALIZE, CN_CLOSE_PARTITION_SESSIONS, CN_ENCRYPT_SESSION), partition lifecycle and quorum management (CN_SET_M_VALUE, CN_SET_POLICY, CN_SET_HSM_CONFIG, CN_SET_KBK_PRIMARY, CN_CREATE_APPLIANCE_USER, CN_CREATE_PRE_OFFICER), user administration, key creation and deletion, key import/export, and backup/restore operations. Read-only queries and unlisted commands are not recorded in HsmOperations.

4. Exporting Complete Batches for Offline Signature Verification​

Here is a critical operational trap to avoid: when exporting logs to JSON for cryptographic verification, never append take or limit operators to your KQL export query. Truncating the result set will sever management records from their matching CorrelationId siblings and BATCH_ signature records, breaking signature validation.

Instead, query all records matching the target CorrelationId values (including both CN_ and BATCH_ rows), export them to a UTF-8 JSON file, and download the AzureCloudHSM-AuditLogUtils package from the Utilities folder of the Microsoft Azure Cloud HSM SDK repository on GitHub to validate the batch signatures and certificate chain.

Section Summary: Administrators enable hardware audit logging via the HsmOperations category in Azure Monitor diagnostic settings, query management events in CloudHsmHardwareOperationAuditLogs, and verify complete CorrelationId batches using Microsoft's AzureCloudHSM-AuditLogUtils utility.

The Bottom Line for Enterprise Architects​

Hardware security modules exist for scenarios where software-only assurances are not enough. By bringing generally available, firmware-signed hardware audit logging (HsmOperations) to Azure Cloud HSM, Microsoft gives enterprise security teams a verifiable chain of custody from the physical FIPS 140-3 Level 3 partition all the way into Azure Monitor and Log Analytics. If you are running Azure Cloud HSM clusters in production, enabling HsmOperations alongside a locked-down storage account and 30-day-minimum Log Analytics workspace should be at the top of your post-deployment checklist.