Azure Cloud HSM: Secure, Compliant & Ready for Enterprise Migration
Azure Cloud HSM is Microsoft’s single-tenant, FIPS 140-3 Level 3 validated hardware security module service, designed for organizations that need full administrative control over cryptographic keys in the cloud. It’s ideal for migration scenarios, especially when moving on-premises HSM workloads to Azure with minimal application changes. Onboarding & Availability No Registration or Allowlist Needed: Azure Cloud HSM is accessible to all customers no special onboarding or monetary policy required. Regional Availability: Private Preview: UK West Public Preview (March 2025): East US, West US, West Europe, North Europe, UK West General Availability (June 2025): All public, US Gov, and AGC regions where Azure Managed HSM is available Choosing the Right Azure HSM Solution Azure offers several key management options: Azure Key Vault (Standard/Premium) Azure Managed HSM Azure Payment HSM Azure Cloud HSM Cloud HSM is best for: Migrating existing on-premises HSM workloads to Azure Applications running in Azure VMs or Web Apps that require direct HSM integration Shrink-wrapped software in IaaS models supporting HSM key stores Common Use Cases: ADCS (Active Directory Certificate Services) SSL/TLS offload for Nginx and Apache Document and code signing Java apps needing JCE provider SQL Server TDE (IaaS) via EKM Oracle TDE Deployment Best Practices 1. Resource Group Strategy Deploy the Cloud HSM resource in a dedicated resource group (e.g., CHSM-SERVER-RG). Deploy client resources (VM, VNET, Private DNS Zone, Private Endpoint) in a separate group (e.g., CHSM-CLIENT-RG) 2. Domain Name Reuse Policy Each Cloud HSM requires a unique domain name, constructed from the resource name and a deterministic hash. Four reuse types: Tenant, Subscription, ResourceGroup, and NoReuse choose based on your naming and recovery needs. 3. Step-by-Step Deployment Provision Cloud HSM: Use Azure Portal, PowerShell, or CLI. Provisioning takes ~10 minutes. Register Resource Provider: (Register-AzResourceProvider -ProviderNamespace Microsoft.HardwareSecurityModules) Create VNET & Private DNS Zone: Set up networking in the client resource group. Create Private Endpoint: Connect the HSM to your VNET for secure, private access. Deploy Admin VM: Use a supported OS (Windows Server, Ubuntu, RHEL, CBL Mariner) and download the Azure Cloud HSM SDK from GitHub. Initialize and Configure Edit azcloudhsm_resource.cfg: Set the hostname to the private link FQDN for hsm1 (found in the Private Endpoint DNS config). Initialize Cluster: Use the management utility (azcloudhsm_mgmt_util) to connect to server 0 and complete initialization. Partition Owner Key Management: Generate the PO key securely (preferably offline). Store PO.key on encrypted USB in a physical safe. Sign the partition cert and upload it to the HSM. Promote Roles: Promote Precrypto Officer (PRECO) to Crypto Officer (CO) and set strong password Security, Compliance, and Operations Single-Tenant Isolation: Only your organization has admin access to your HSM cluster. No Microsoft Access: Microsoft cannot access your keys or credentials. FIPS 140-3 Level 3 Compliance: All hardware and firmware are validated and maintained by Microsoft and the HSM vendor. Tamper Protection: Physical and logical tamper events trigger key zeroization. No Free Tier: Billing starts upon provisioning and includes all three HSM nodes in the cluster. No Key Sharing with Azure Services: Cloud HSM is not integrated with other Azure services for key usage. Operational Tips Credential Management: Store PO.key offline; use environment variables or Azure Key Vault for operational credentials. Rotate credentials regularly and document all procedures. Backup & Recovery: Backups are automatic and encrypted; always confirm backup/restore after initialization. Support: All support is through Microsoft open a support request for any issues. Azure Cloud HSM vs. Azure Managed HSM Feature / Aspect Azure Cloud HSM Azure Managed HSM Deployment Model Single-tenant, dedicated HSM cluster (Marvell LiquidSecurity hardware) Multi-tenant, fully managed HSM service FIPS Certification FIPS 140-3 Level 3 FIPS 140-2 Level 3 Administrative Control Full admin control (Partition Owner, Crypto Officer, Crypto User roles) Azure manages HSM lifecycle; customers manage keys and RBAC Key Management Customer-managed keys and partitions; direct HSM access Azure-managed HSM; customer-managed keys via Azure APIs Integration PKCS#11, OpenSSL, JCE, KSP/CNG, direct SDK access Azure REST APIs, Azure CLI, PowerShell, Key Vault SDKs Use Cases Migration from on-prem HSMs, legacy apps, custom PKI, direct cryptographic ops Cloud-native apps, SaaS, PaaS, Azure-integrated workloads Network Access Private VNET only; not accessible by other Azure services Accessible by Azure services (e.g., Storage, SQL, Disk Encryption) Key Usage by Azure Services Not supported (no integration with Azure services) Supported (can be used for disk, storage, SQL encryption, etc.) BYOK/Key Import Supported (with key wrap methods) Supported (with Azure Key Vault import tools) Key Export Supported (if enabled at key creation) Supported (with exportable keys) Billing Hourly fee per cluster (3 HSMs per cluster); always-on Consumption-based (per operation, per key, per hour) Availability High availability via 3-node cluster; automatic failover and backup Geo-redundant, managed by Azure Firmware Management Microsoft manages firmware; customer cannot update Fully managed by Azure Compliance Meets strictest compliance (FIPS 140-3 Level 3, single-tenant isolation) Meets broad compliance (FIPS 140-2 Level 3, multi-tenant isolation) Best For Enterprises migrating on-prem HSM workloads, custom/legacy integration needs Cloud-native workloads, Azure service integration, simplified management When to Choose Each? Azure Cloud HSM is ideal if you: Need full administrative control and single-tenant isolation. Are migrating existing on-premises HSM workloads to Azure. Require direct HSM access for legacy or custom applications. Need to meet the highest compliance standards (FIPS 140-3 Level 3). Azure Managed HSM is best if you: Want a fully managed, cloud-native HSM experience. Need seamless integration with Azure services (Storage, SQL, Disk Encryption, etc.). Prefer simplified key management with Azure RBAC and APIs. Are building new applications or SaaS/PaaS solutions in Azure. Scenario Recommended Solution Migrating on-prem HSM to Azure Azure Cloud HSM Cloud-native app needing Azure service keys Azure Managed HSM Custom PKI or direct cryptographic operations Azure Cloud HSM SaaS/PaaS with Azure integration Azure Managed HSM Highest compliance, single-tenant isolation Azure Cloud HSM Simplified management, multi-tenant Azure Managed HSM Azure Cloud HSM is the go-to solution for organizations migrating HSM-backed workloads to Azure, offering robust security, compliance, and operational flexibility. By following best practices for onboarding, deployment, and credential management, you can ensure a smooth and secure transition to the cloud.Enterprise Strategy for Secure Agentic AI: From Compliance to Implementation
Imagine an AI system that doesn’t just answer questions but takes action querying your databases, updating records, triggering workflows, even processing refunds without human intervention. That’s Agentic AI and it’s here. But with great power comes great responsibility. This autonomy introduces new attack surfaces and regulatory obligations. The Model Context Protocol (MCP) Server the gateway between your AI agent and critical systems becomes your Tier-0 control point. If it fails, the blast radius is enormous. This is the story of how enterprises can secure Agentic AI, stay compliant and implement Zero Trust architectures using Azure AI Foundry. Think of it as a roadmap a journey with three milestones - Milestone 1: Securing the Foundation Our journey starts with understanding the paradigm shift. Traditional AI with RAG (Retrieval-Augmented Generation) is like a librarian: It retrieves pre-indexed data. It summarizes information. It never changes the books or places orders. Security here is simple: protect the index, validate queries, prevent data leaks. But Agentic AI? It’s a staffer with system access. It can: Execute tools and business logic autonomously. Chain operations: read → analyze → write → notify. Modify data and trigger workflows. Bottom line: RAG is a “smart librarian.” Agentic AI is a “staffer with system access.” Treat the security model accordingly. And that means new risks: unauthorized access, privilege escalation, financial impact, data corruption. So what’s the defense? Ten critical security controls your first line of protection: Here’s what a production‑grade, Zero Trust MCP gateway needs. Its intentionally simplified in the demo (e.g., no auth) to highlight where you must harden in production. (https://github.com/davisanc/ai-foundry-mcp-gateway) Authentication Demo: None Prod: Microsoft Entra ID, JWT validation, Managed Identity, automatic credential rotation Authorization & RBAC Demo: None Prod: Tool‑level RBAC via Entra; least privilege; explicit allow‑lists per agent/capability Input Validation Demo: Basic (ext whitelist, 10MB, filename sanitize) Prod: JSON Schema validation, injection guards (SQL/command), business‑rule checks Rate Limiting Demo: None Prod: Multi‑tier (per‑agent, per‑tool, global), adaptive throttling, backoff Audit Logging Demo: Console → App Service logs Prod: Structured logs w/ correlation IDs, compliance metadata, PII redaction Session Management Demo: In‑memory UUID sessions Prod: Encrypted distributed storage (Redis/Cosmos DB), tenant isolation, expirations File Upload Security Demo: Ext whitelist, size limits, memory‑only Prod: 7‑layer defense (validate, MIME, malware scanning via Defender for Storage), encryption at rest, signed URLs Network Security Demo: Public App Service + HTTPS Prod: Private Endpoints, VNet integration, NSGs, Azure Firewall no public exposure Secrets Management Demo: App Service env vars (not in code) Prod: Azure Key Vault + Managed Identity, rotation, access audit Observability & Threat Detection (5‑Layer Stack) Layer 1: Application Insights (requests, dependencies, custom security events) Layer 2: Azure AI Content Safety (harmful content, jailbreaks) Layer 3: Microsoft Defender for AI (prompt injection incl. ASCII smuggling, credential theft, anomalous tool usage) Layer 4: Microsoft Purview for AI (PII/PHI classification, DLP on outputs, lineage, policy) Layer 5: Microsoft Sentinel (SIEM correlation, custom rules, automated response) Note: Azure AI Content Safety is built into Azure AI Foundry for real‑time filtering on both prompts and completions. Picture this as an airport security model: multiple checkpoints, each catching what the previous missed. That’s defense-in-depth. Zero Trust in Practice ~ A Day in the Life of a Prompt Every agent request passes through 8 sequential checkpoints, mapped to MITRE ATLAS tactics/mitigations (e.g., AML.M0011 Input Validation, AML.M0004 Output Filtering, AML.M0015 Adversarial Input Detection). The design goal is defense‑in‑depth: multiple independent controls, different detection signals, and layered failure modes. Checkpoints 1‑7: Enforcement (deny/contain before business systems) Checkpoint 8: Monitoring (detect/respond, hunt, learn, harden) AML.M0009 – Control Access to ML Models AML.M0011 – Validate ML Model Inputs AML.M0000 – Limit ML Model Availability AML.M0014 – ML Artifact Logging AML.M0004 – Output Filtering AML.M0015 – Adversarial Input Detection If one control slips, the others still stand. Resilience is the product of layers. Milestone 2: Navigating Compliance Next stop: regulatory readiness. The EU AI Act is the world’s first comprehensive AI law. If your AI system operates in or impacts the EU market, compliance isn’t optional, it’s mandatory. Agentic AI often falls under high-risk classification. That means: Risk management systems. Technical documentation. Logging and traceability. Transparency and human oversight. Fail to comply? Fines up to €30M or 6% of global turnover. Azure helps you meet these obligations: Entra ID for identity and RBAC. Purview for data classification and DLP. Defender for AI for prompt injection detection. Content Safety for harmful content filtering. Sentinel for SIEM correlation and incident response. And this isn’t just about today. Future regulations are coming US AI Executive Orders, UK AI Roadmap, ISO/IEC 42001 standards. The trend is clear: transparency, explainability, and continuous monitoring will be universal. Milestone 3: Implementation Deep-Dive Now, the hands-on part. How do you build this strategy into reality? Step 1: Entra ID Authentication Register your MCP app in Entra ID. Configure OAuth2 and JWT validation. Enable Managed Identity for downstream resources. Step 2: Apply the 10 Controls RBAC: Tool-level access checks. Validation: JSON schema + injection prevention. Rate Limiting: Express middleware or Azure API Management. Audit Logging: Structured logs with correlation IDs. Session Mgmt: Redis with encryption. File Security: MIME checks + Defender for Storage. Network: Private Endpoints + VNet. Secrets: Azure Key Vault. Observability: App Insights + Defender for AI + Purview + Sentinel. Step 3: Secure CI/CD Pipelines Embed compliance checks in Azure DevOps: Pre-build: Secret scanning. Build: RBAC & validation tests. Deploy: Managed Identity for service connections. Post-deploy: Compliance scans via Azure Policy. Step 4: Build the 5-Layer Observability Stack App Insights → Telemetry. Content Safety → Harmful content detection. Defender for AI → Prompt injection monitoring. Purview → PII/PHI classification and lineage. Sentinel → SIEM correlation and automated response. The Destination: A Secure, Compliant Future By now, you’ve seen the full roadmap: Secure the foundation with Zero Trust and layered controls. Navigate compliance with EU AI Act and prepare for global regulations. Implement the strategy using Azure-native tools and CI/CD best practices. Because in the world of Agentic AI, security isn’t optional, compliance isn’t negotiable, and observability is your lifeline. Resources https://learn.microsoft.com/en-us/azure/ai-foundry/what-is-azure-ai-foundry https://learn.microsoft.com/en-us/azure/defender-for-cloud/ai-threat-protection https://learn.microsoft.com/en-us/purview/ai-microsoft-purview https://atlas.mitre.org/ https://digital-strategy.ec.europa.eu/en/policies/european-approach-artificial-intelligence https://techcommunity.microsoft.com/blog/microsoft-security-blog/microsoft-sentinel-mcp-server---generally-available-with-exciting-new-capabiliti/4470125
Global Administrator MFA recovery not possible
Since Microsoft automatically enforced MFA on administrator role in Azure you can end up in the situation where it is no longer possible to recover your tenant. If your only account on that tenant is with Global Administrator role and you accidentally loose your MFA, the only way is to call Microsoft support. Support on the phone is automated where any question regarding Azure is redirected to visit Azure portal. If your only user cannot login then Azure portal is not accessible.Anomalies with Conditional Access Policy "Terms of Use" Failures
Hello Microsoft Community, I'm reaching out with a bit of a puzzle regarding our "Terms of Use" Conditional Access policy, and I'm eager to tap into the collective wisdom here for some insights. In our Entra ID User Sign-In logs, we've identified intermittent "failure" entries associated with the "Terms of Use" Conditional Access policy. Interestingly, even for users who had previously accepted the "Terms of Use". There appears to be no discernible impact, and they continue their tasks without interruption. This observation became apparent during the troubleshooting of unrelated Surface Hub and Edge Sync issues at some client sites. What adds to the complexity of the situation is that for the same users, both before and after these "failure" entries, the Conditional Access policy is marked as "success". Hence, it doesn't seem to be a straightforward case of the policy erroneously detecting non-acceptance of the "Terms of Use". The mystery lies in understanding why these intermittent "failure" entries occur for users who have already accepted the terms, especially when the policy consistently reports "success" for the same users. Furthermore, the Insights for the "Terms of Use" Conditional Access policy show around 1.48k successes and 1.43k failures in the last 90 days, yet there's no discernible impact on user functionality. Observations: "Failure" entries in Sign-In logs don't seem to disrupt users' day-to-day activities. The ratio of successes to failures is balanced, yet users experience no noticeable problems. The issue complicates troubleshooting efforts but doesn't significantly affect the user experience. I'm turning to the community for guidance on interpreting and resolving this discrepancy between "failure" entries in the Conditional Access policy logs and the seemingly unaffected user experience. Any insights into why these failures occur without user impact would be greatly appreciated. For additional context, I've attached screenshots of a user's Sign-In log entry and the insight chart from the Conditional Access policy. Sign-In log of a user (failure): Sign-In log of same user (success): Current Conditional Access insights: Thank you in advance for your time and assistance. I look forward to any guidance or solutions you can provide. Best regards, Leon TüpkerCloud Kerberos - Failed to read secrets from the domain
Hi all, Apologies if this is the wrong place to post this! I am looking at understanding Cloud Kerberos and the uses behind it, primarily for WHfB for now. Following the guide on the Microsoft page, I get an error when running on the DC https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module?WT.mc_id=EM-MVP-5004668 Set-AzureADKerberosServer : Failed to read secrets from the domain DOMAIN.LOCAL. The lab environment has 2 DCs at different sites but replicate between each other without issue. The process creates an entry in AD but when I run the command below (GA details is an address, just changed for the forum post) Get-AzureADKerberosServer -Domain $domain -UserPrincipalName "GA details" -DomainCredential $domainCred I get the output below... Id : 16451 UserAccount : CN=krbtgt_AzureAD,CN=Users,DC=DOMAIN,DC=LOCAL ComputerAccount : CN=AzureADKerberos,OU=Domain Controllers,DC=DOMAIN,DC=LOCAL DisplayName : krbtgt_16451 DomainDnsName : DOMAIN.LOCAL KeyVersion : 1598799 KeyUpdatedOn : 27/07/2024 06:41:15 KeyUpdatedFrom : PDC.DOMAIN.LOCAL CloudDisplayName : CloudDomainDnsName : CloudId : CloudKeyVersion : CloudKeyUpdatedOn : CloudTrustDisplay : Can you advise why the secrets aren't being found and the cloud information not populated? This is a lab enviroment so if needed, we can get a bit rough with it. Any help would be welcomed. Kind regards Tom
New Blog | Monitoring traffic flows in Azure Firewall using Virtual Network Flow Logs
By Gustavo Modena Azure Firewall is a managed service designed to protect your Azure Virtual Network resources, providing advanced threat protection and advanced logs and metrics that are essential tools for monitoring and managing your network security. By leveraging both logs and metrics, you can ensure the overall health and efficiency of your firewall, maintain an audit trail of configuration changes, and comply with security and auditing requirements. In this blog post we will show you a different approach to enhance the monitoring experience of Azure Firewall by using Virtual Network Flow Logs and Traffic Analytics. This combination provides a comprehensive view of traffic flows within your network, offering deeper insights for analysis and investigation, helping to identify traffic deviation that may indicate a security issue and identify applications that are consuming Azure Firewall the most. What are Virtual Network Flow Logs and Traffic Analytics? Both Virtual Network Flow logs and Traffic Analytics are features of Azure Network Watcher that collects information about network traffic and enriches raw flow logs to provide insights into network traffic patterns, including source and destination IP addresses ports protocols and the volume of traffic. To learn more about both features, check out the product documentation. Read the full post here: Monitoring traffic flows in Azure Firewall using Virtual Network Flow Logs
Whenever login into the office applications different OTP needs to be applied Outlook and teams
When signing into Office applications, a different OTP is required for both Outlook and Teams. To address this issue, there is any resolution this issue supports or a supporting document as proof to confirm that this is a standard procedure.
