Azure Penetration Testing Rules: What You Can and Cannot Test
You do not need Microsoft’s permission to run Azure penetration testing against your own tenant. Notification was dropped back in 2017, and the Microsoft Cloud Penetration Testing Rules of Engagement now set the boundaries instead. You may test resources, applications and identities you own or control. You may not test the platform underneath them, and denial of service testing stays firmly off the table.
What the Microsoft rules of engagement allow
The rules of engagement permit testing against resources in subscriptions you own or control, without prior notice to Microsoft. That covers fuzzing your own web application, port scanning your own virtual machines, testing Entra ID configuration, and attacking identities you have created for the exercise. Prohibited activity is specific: denial of service and stress testing, anything that touches another customer’s data, phishing aimed at Microsoft employees, and testing beyond your own subscription boundary. Shared platform services need care. On Azure App Service you are testing your own application, not the worker infrastructure beneath it, and scale testing belongs in Azure Load Testing rather than in a pen test.
The Azure findings that come up most often
Most Azure findings come from identity, not from the network layer. The NCSC’s cloud security guidance builds its principles around identity and authentication for good reason: in a well built tenant there is little exposed at the network edge, so the route in runs through credentials and role assignments. Typical reported issues include Conditional Access policies with a legacy authentication exclusion that nobody removed, storage accounts reachable with a shared access signature that never expires, Key Vault access policies granting secret retrieval far too widely, and managed identities holding Contributor at subscription scope when they need read access to one resource group. Device code phishing deserves a mention too, because it defeats plenty of tenants that believe multi-factor authentication has them covered.
“Nine times out of ten the fastest route to Global Administrator in a client tenant starts with a service principal that somebody granted Contributor during a migration and never cleaned up. Export your role assignments at subscription scope and read them before you book the work. You will get far more value from the consultant days you pay for.”
William Fieldhouse, Director, Aardwolf Security Ltd
How Azure testing differs from a network test
Azure cloud penetration testingexamines configuration and identity relationships, while a traditional network test examines exposed services and patch levels. The distinction shows up in what the tester needs from you. A network test needs an IP range. Cloud work needs a low privileged user account in the tenant, usually a Reader role assignment at management group or subscription scope, and sometimes a second account with no privileges at all so the tester can prove what an ordinary employee can reach. Findings then follow the control plane: who can assign roles, and which automation accounts are holding credentials in plain text. Expect a mix of manual review through the Azure Resource Manager API and hands-on attack paths built from what the review turns up.
Scoping the work and choosing a provider
You should scope Azure work by the number of subscriptions, the size of the identity tenant and the count of workloads that actually process data. A single subscription with two app services and a SQL database is a short engagement. A tenant with forty subscriptions and several hundred service principals is not, and any provider quoting that in two days has not read the brief. Ask who holds Azure experience rather than general infrastructure skills, and check the consultant doing the work is the one named in the proposal. CREST accreditation gives you a baseline for process and vetting, which matters when the tester is holding credentials into your production estate. Our guide to choosing the best penetration testing company sets out the questions worth asking before you sign.
Frequently asked questions about Azure penetration testing
Two questions come up on nearly every Azure scoping call.
Do you have to notify Microsoft before testing?
No. Microsoft removed the pre-approval requirement in June 2017. You are still bound by the Cloud Penetration Testing Rules of Engagement, so read them and keep a copy with your scoping document.
How often should an Azure environment be tested?
Once a year suits most organisations, with an extra assessment after any significant change: a migration, a merger, a new production workload or a shift in your Conditional Access design. Drift between tests is better caught by monitoring than by waiting twelve months.
