Azure Managed HSM Gains IP Network Firewall Controls in Public Preview

Microsoft has announced the public preview of IP Network Firewalls for Azure Key Vault Managed HSM, a security feature that enables granular network-level access controls for cryptographic operations. The capability is now available in East US, West US, West US 2, West Central US, UK South, and West Europe.

What Changed: Network-Level Access Controls for HSM

Until now, Azure Managed HSM relied primarily on Azure RBAC and private endpoints for access control. The new firewall feature introduces IP-based restrictions at the data plane level, meaning it controls who can perform cryptographic operations against the HSM, not who can manage the HSM resource itself.

When you configure the firewall, you create an allowlist of IPv4 CIDR ranges. Any request originating from outside those ranges is blocked from accessing data plane operations. This is particularly useful for services with static IP addresses or well-known IP ranges, such as:

• On-premises applications that need to perform encryption/decryption
• Third-party services with predictable IP infrastructure
• Specific VM subnets dedicated to cryptographic workloads
• CI/CD pipelines that need to access secrets during deployment

The current preview supports up to 10 CIDR ranges per HSM, and only IPv4 addresses are supported. IPv6 support is likely to come later, though Microsoft has not yet announced a timeline.

Control Plane vs Data Plane: Understanding the Boundary

A critical distinction in this feature is what it does—and does not—control. Firewall rules apply only to data plane operations, which include:

• Key operations (encrypt, decrypt, sign, verify, wrap, unwrap)
• Key retrieval for cryptographic operations
• Secret operations (get, list when using key-backed secrets)

Control plane operations remain unrestricted by the IP firewall. These include:

• Creating, updating, or deleting HSM instances
• Managing RBAC assignments
• Configuring firewall rules themselves
• Backup and restore operations

This separation means that while you can lock down who uses your HSM for cryptography, you cannot prevent authorized users from managing the HSM resource through the Azure portal or Azure CLI from any location. However, to access data plane operations through tools like the Azure portal, you must be on a machine within the trusted IP boundary you establish.

Practical Configuration Example

Let's say you have an application running in an on-premises data center that needs to encrypt sensitive data using Azure Managed HSM. Your outbound traffic appears from a static NAT gateway at 203.0.113.0/24. You would:

1. Navigate to your Managed HSM resource in Azure portal
2. Go to the Firewall settings under Network Security
3. Add the CIDR range 203.0.113.0/24 to the allowlist
4. Enable the firewall

Now, only requests from that IP range can perform cryptographic operations. If a developer tries to access the HSM from their laptop (dynamic IP), the request is blocked—even if they have proper RBAC permissions.

Regional Availability and Limitations

The preview is available in six regions:

• East US (primary)
• West US
• West US 2
• West Central US
• UK South
• West Europe

If you need this feature in other regions, you'll need to wait for general availability or use alternative approaches like private endpoints combined with network security groups.

Comparison with Azure Key Vault Standard

It's worth noting that Azure Key Vault (standard/premium) has supported IP firewalls for some time, but the Managed HSM version has additional considerations:

• Managed HSM provides FIPS 140-2 Level 3 validated HSMs
• Standard Key Vault uses shared infrastructure without dedicated HSMs
• Both support IP firewalls now, but Managed HSM's firewall applies to high-value cryptographic operations
• The 10 CIDR limit is the same across both services

Alternative Approaches for Access Control

If IP firewalls don't meet your needs, consider these alternatives:

Private Endpoints

Create a private endpoint for your Managed HSM in a virtual network. This ensures traffic never traverses the public internet. You can then use network security groups (NSGs) to control access at the subnet level.

Service Endpoints

For Azure services, you can use service endpoints to keep traffic on the Microsoft backbone. However, this doesn't provide the same level of IP-based restriction as the firewall.

RBAC + Managed Identities

For Azure-hosted workloads, using managed identities with least-privilege RBAC assignments is often more secure than IP-based controls, as it eliminates credential management.

Security Considerations

When implementing IP firewalls, consider these factors:

• IP Spoofing: IP-based controls can be bypassed if an attacker controls network infrastructure. Combine with other controls.
• Static IP Management: Ensure your IP ranges are stable. Changing IPs means updating firewall rules.
• Emergency Access: Maintain a break-glass approach for emergency access that bypasses the firewall.
• Monitoring: Enable Azure Monitor and Log Analytics to track blocked requests.

Getting Started

To try this feature:

1. Ensure you have an Azure Managed HSM in one of the supported regions
2. Navigate to the HSM resource in Azure portal
3. Under "Network Security," find the IP Firewall settings
4. Add your CIDR ranges and enable the feature
5. Test access from both allowed and blocked IPs to verify behavior

For detailed configuration steps and best practices, see the IP Network Firewall product documentation.

What This Means for Enterprise Security

This feature fills a significant gap in Azure's HSM security model. Many enterprises operate hybrid environments where on-premises systems need to access cloud HSMs. Without IP restrictions, these connections rely solely on RBAC and network-level security groups, which may not provide sufficient defense-in-depth.

The IP firewall adds another layer to the security model, following the principle of least privilege. Even if credentials are compromised, an attacker would also need to be in the trusted IP range to perform cryptographic operations.

However, organizations should view this as one component of a comprehensive security strategy, not a standalone solution. Effective implementation requires combining IP firewalls with:

• Strong RBAC policies
• Private endpoints where possible
• Comprehensive logging and monitoring
• Regular security audits

As the feature moves from public preview to general availability, expect enhancements like IPv6 support, increased CIDR limits, and integration with Azure Firewall and Azure Sentinel for more sophisticated threat detection.