How should security teams secure Microsoft Azure workloads in a shared responsibility model?

Why This Matters for Security Teams

Azure’s shared responsibility model is often misunderstood as a platform promise that extends to customer workloads. It does not. Microsoft secures the cloud infrastructure, while the customer remains accountable for identity, configuration, secrets, data protection, and workload behavior. That distinction matters because the most common failures are not Azure service failures, but exposed keys, permissive roles, and unmanaged access paths. NHI Management Group’s research on machine identity shows how often organisations still struggle with visibility and rotation, which is exactly where Azure environments drift into risk.

For teams building or operating Azure services, the practical issue is that a secure default for the platform is not the same as a secure default for a workload. A storage account, a managed identity, a Key Vault policy, or a CI/CD pipeline can all be technically functional while still being overexposed. The right mental model is to treat Azure as a controlled substrate and every workload as its own identity-and-policy problem, reinforced by guidance such as the NIST SP 800-53 Rev 5 Security and Privacy Controls and NHIMG’s Ultimate Guide to NHIs — Standards. In practice, many security teams encounter compromise only after an Azure secret, token, or overly broad role assignment has already been abused.

How It Works in Practice

Security teams should separate platform controls from workload controls. Microsoft is responsible for the underlying cloud, but customers must continuously govern who and what can act inside the tenant. That means hardening Entra ID, using conditional access and MFA for humans, and using managed identities or workload identity federation for services wherever possible. For machine access, static secrets are the weak point: current guidance suggests replacing them with short-lived credentials, scoped tokens, and automated rotation rather than leaving long-lived connection strings in code or pipelines.

A practical Azure control stack usually includes:

• Least privilege RBAC with narrow assignments at the smallest usable scope
• Key Vault for secret storage, with access policies reviewed and monitored
• Policy-as-code for subscriptions, resource groups, and deployment pipelines
• Private networking and explicit exposure review for public endpoints
• Logging and alerting for role changes, secret access, and identity anomalies

This is where workload identity matters. The SPIFFE workload identity specification is useful because it frames identity as cryptographic proof of what a workload is, not just a reusable credential. That model aligns closely with NHIMG’s Guide to SPIFFE and SPIRE, especially for teams trying to remove long-lived shared secrets from Azure-hosted services. It also fits the reality of Azure incidents like the Microsoft Azure Key Breach, where exposed secrets became the path of compromise rather than an infrastructure flaw. These controls tend to break down in legacy environments with embedded secrets, broad administrator sprawl, and manual deployment processes because access drift outpaces review cycles.

Common Variations and Edge Cases

Tighter cloud governance often increases delivery friction, so organisations must balance release speed against the risk of standing privilege and misconfiguration. That tradeoff is especially visible in shared Azure subscriptions, cross-team landing zones, and hybrid estates where on-prem and cloud identity controls do not line up cleanly.

Best practice is evolving, but several edge cases are clear. Azure PaaS services can reduce patching burden, yet they do not remove the need to secure identities, network paths, and data access. Managed identities help, but they still require careful scoping and monitoring. In multi-tenant SaaS or partner integration scenarios, teams should treat third-party OAuth apps, consent grants, and service principals as first-class attack surfaces. For regulated workloads, map Azure controls to formal baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls and verify whether compensating controls are needed for secrets, certificates, and break-glass access. NHIMG’s research on the State of Non-Human Identity Security is especially relevant here because visibility gaps and over-privileged identities remain common failure modes. The main exception is highly ephemeral test and dev environments, where strict automation can safely replace manual approvals if teardown and rotation are enforced consistently.

Related resources from NHI Mgmt Group

• How should security teams govern access to Azure AI workloads?
• How should security teams replace shared secrets for workloads that span multiple clouds?
• What do teams get wrong about shared responsibility in cloud security?
• How should security teams secure AI workloads beyond AI-SPM?