Microsoft secures the physical data centres and the platform. Everything you build and configure on top, including who can access what, is your responsibility. This is the shared responsibility model, and it's where most cloud breaches happen: not through exotic exploits, but through identities with too much access and resources left open by mistake.

An Azure penetration test looks at your environment the way an attacker would. Starting from a leaked credential, a compromised laptop or a public-facing app, how far could they get?

Can you test Azure without asking Microsoft?

Yes. Microsoft doesn't require you to request approval before testing your own Azure resources, but testing must follow the Microsoft Cloud Penetration Testing Rules of Engagement. Those rules forbid things like denial-of-service testing, attacking other customers' tenants or Microsoft's own infrastructure, and phishing Microsoft staff. Every engagement we run is scoped to resources you own and authorise in writing.

What we test

1. Identity: Microsoft Entra ID

Identity is the new perimeter. Entra ID (formerly Azure Active Directory) controls access to Azure, Microsoft 365 and often your own apps, so it gets the most attention:

  • Accounts without multi-factor authentication, and gaps in Conditional Access policies
  • Too many Global Administrators and other highly privileged roles, and standing access where just-in-time access (PIM) should be used
  • App registrations and service principals with powerful API permissions, long-lived secrets or forgotten owners
  • Guest accounts with more access than they need
  • Paths from an ordinary user to administrator through group ownership, role assignments or app permissions

2. Azure permissions (RBAC)

We map who holds Owner, Contributor and User Access Administrator roles, and at what scope. A Contributor role at subscription level, granted for convenience, often gives far more power than intended, such as running commands on every virtual machine or reading secrets.

3. Storage and data

  • Storage accounts and blob containers allowing anonymous public access
  • Shared Access Signature (SAS) tokens with broad permissions or far-off expiry dates, sometimes found in code or documentation
  • Key Vaults with weak access policies or no network restrictions
  • Databases (Azure SQL, Cosmos DB) reachable from the internet with permissive firewall rules

4. Compute and workloads

  • Managed identities attached to virtual machines, App Services or Functions: if the workload is compromised, the identity's permissions go with it
  • Secrets in App Service settings, Function configuration, VM extensions or deployment scripts
  • Virtual machines with management ports (RDP, SSH) open to the internet
  • AKS (Kubernetes) clusters with public API servers or over-privileged workloads

5. Network exposure

We enumerate everything reachable from the internet, then review network security groups, private endpoints and firewall rules to confirm sensitive services are actually private.

6. Logging and detection

We check whether Entra ID sign-in and audit logs, Azure Activity logs and Microsoft Defender for Cloud alerts would show our activity. A test that goes unnoticed is a finding in itself.

The misconfigurations we see most

  1. Service principals with secrets that never expire and permissions nobody remembers granting
  2. Broad Contributor or Owner assignments at subscription level
  3. Public blob containers holding backups, exports or logs
  4. Accounts outside MFA because of a Conditional Access exclusion added "temporarily"
  5. Secrets stored in app configuration instead of Key Vault, or Key Vault open to all networks

Quick self-check: list every identity with Owner or Contributor on your production subscription, including service principals and managed identities. Can you explain why each one needs it?

How an Azure engagement works

We agree the scope (tenants, subscriptions and starting points: a standard user account, an assumed-breach workload or an external-only view) and get written authorisation. We combine a configuration review with hands-on testing of attack paths, and report each finding with evidence, the business impact and the exact fix, whether that's an Azure Policy, an RBAC change or a Conditional Access rule. Then we retest.

We also review Infrastructure-as-Code before deployment. See our guide to IaC and application security testing.

Running production workloads on Azure? Request a quote for cloud penetration testing.