Microsoft does not penetration test your tenant. It secures the data centres, hosts and platform underneath Microsoft 365 and Azure. Your sign-in rules, admin roles, sharing settings, storage permissions and app integrations are yours, and they are what a cloud penetration test in Australia should be aimed at. If nobody has tested that configuration, nobody has tested the part of the cloud an attacker is most likely to use.
Many of the businesses we talk to assume the opposite, so this post sets out who tests what, what a cloud test should cover, how it differs from a configuration review, and what a useful report looks like. If you already know you need one, our penetration testing team scopes Microsoft 365, Azure and API testing for businesses across Australia.
Who tests what: Microsoft's platform versus your tenant
Microsoft publishes a shared responsibility model that spells out the split. For every cloud deployment type, the customer owns its data and identities. For software as a service such as Microsoft 365, the customer is also responsible for configurations and settings, users and identities, and access management, which Microsoft lists as role-based access control, multifactor authentication and conditional access policies. Microsoft is responsible for the physical data centres, network and hosts, and, in SaaS and PaaS, the operating systems and platform services.
In plain terms, Microsoft runs the building and the locks are yours. A penetration test of your cloud tests your locks.
Microsoft's own Security Testing Rules of Engagement draw the same line from the other side. They allow testing inside your own tenant, or assets you are explicitly authorised to test, and they apply equally to you and to a consultancy acting for you. They prohibit denial-of-service testing, touching other customers' tenants or data, and phishing Microsoft staff. They also say Microsoft may interrupt an attack in progress, whether or not it is part of a valid test.
What a cloud penetration test covers in Microsoft 365 and Azure
A cloud test starts from an attacker's realistic position, usually a stolen password or a phished user, and works out how far that gets them. In a Microsoft 365 and Azure environment, the work concentrates on five areas.
Identity and sign-in
Can a stolen password still log in? Testers look for legacy authentication left open, MFA methods that can be downgraded to SMS or a push prompt, accounts excluded from MFA, and guest accounts nobody reviews.
Conditional Access
Conditional Access policies decide who can sign in, from where and on what device. Microsoft's rules of engagement list evaluating Conditional Access policies as an encouraged test activity. Across the reports we review for clients, Conditional Access gaps are the high-severity finding we see most: policies that exclude a group of users, break-glass accounts nobody monitors, and rules that never applied to the apps that matter.
Admin roles and privilege paths
Who holds Global Administrator, and who can grant it to themselves? Testers trace paths from an ordinary account to admin rights through group ownership, app permissions and Azure role assignments. Our access management work starts with the same list.
Storage and sharing
SharePoint and OneDrive sharing links, Teams guest access, Azure storage accounts and their access keys. The question is what a compromised user, or an anonymous outsider, can read.
Detection
A test should also tell you whether anyone noticed. Microsoft encourages customers to test their tenant's monitoring and detection, and a good tester will record which actions triggered an alert and which did not.
API and SaaS integrations: the part most scopes miss
Most scopes stop at the Microsoft tenant. The data often leaves through the side door: a third-party app with consent to read every mailbox, a line-of-business system syncing through an API, an automation account with a stored secret.
The OWASP API Security Top 10 lists broken object level authorisation first: an API that hands back another customer's record when someone changes an ID in the request. It also lists unsafe consumption of APIs, where developers trust data from third-party services more than user input. Neither shows up in a tenant settings review.
If your business has a customer portal, an integration between Microsoft 365 and another platform, or apps that users approved with one click, ask for them in scope by name. A cloud test that ignores them answers half the question.
How a cloud pen test differs from a configuration review or vulnerability scan
| Vulnerability scan | Cloud configuration review | Cloud penetration test | |
|---|---|---|---|
| What it does | Automated check for known weaknesses | Compares tenant settings to a baseline | A tester tries to use weaknesses to reach data or admin rights |
| What it tells you | What might be wrong | What is set differently from guidance | What an attacker could actually do, step by step |
| Covers integrations and APIs | Rarely | Partly | Yes, when scoped |
| Tests detection | No | No | Yes |
A configuration review is cheaper and a sensible first step. It tells you a setting is wrong. A penetration test tells you whether that wrong setting, combined with two others, gets someone into the finance mailbox. We cover the general difference in penetration testing vs vulnerability scanning.
How it maps to ASD Essentials for cloud
The ASD published Essentials for cloud on 15 October 2026 for organisations that run on SaaS and PaaS. It marks each action with where responsibility usually sits: the customer, the provider, or "supplied", meaning the provider supplies the capability and you have to switch it on, configure and monitor it. The ASD's position is that a supplied capability left at an insecure default is not yet effective.
That supplied category is where a cloud penetration test earns its money. Conditional Access, audit logging and consent controls all ship with Microsoft 365. A test shows whether yours actually work. The chapter also treats integrations and APIs as boundary services and puts identity and boundary services in the first priority phase, which matches where we point testers first.
ASD's assessment guidance rates evidence that shows a control working in the live environment above evidence that only shows it exists. A test result is that kind of evidence. Our post on ASD Essentials for cloud explains the chapter itself.
Scoping and rules of engagement: what you must approve first
Before anyone touches your tenant, you should sign off on:
- The tenant, subscriptions, apps and APIs in scope, and anything excluded, with the reason.
- The starting position: a test account with normal user rights, a phished-user scenario, or both.
- Test windows and an emergency contact on each side.
- Whether testers may change settings, create objects or send email, and how they clean up.
- Third-party SaaS in scope, and written permission from those vendors where their terms require it.
Microsoft's rules of engagement add one practical point. If a tester stumbles into data they have no right to access, they must stop, notify Microsoft and delete it. Your rules of engagement should say the same.
What a good cloud pen test report contains, and what to fix first
A useful report has an executive summary a director can read in five minutes, then each attack path written as a story: where the tester started, each step, and what they reached. Every finding needs evidence, a severity based on what was actually exploitable in your tenant, and a specific fix, plus a list of which actions your monitoring caught and which it missed. A retest should confirm the fixes.
Fix in this order: anything that lets a stolen password become admin rights, then sign-in gaps such as legacy authentication and weak MFA, then third-party app consents and integrations, then sharing and storage exposure. That order follows the attacker's route.
What you should do now
List what you actually run in the cloud. Your Microsoft 365 tenant, Azure subscriptions, third-party apps with consent to your data, and any APIs or portals customers use. That list is your draft scope.
Ask your IT provider for the admin list and the Conditional Access exclusions. If they cannot produce both within a week, you have found your first finding before any testing starts.
Book a scoping call before you request a price. A cloud test quoted off a form is usually a configuration scan. Talk to our penetration testing team on 1300 EPIC IT and we will scope your tenant, integrations and APIs properly.
Frequently asked questions
Does Microsoft penetration test my Microsoft 365 tenant?
No. Microsoft secures the platform: data centres, hosts, networks and, for SaaS, the underlying software. Under its shared responsibility model, your configuration, identities and access controls are your responsibility, so testing them is too.
Do I need Microsoft's permission for cloud penetration testing in Australia?
Microsoft's Security Testing Rules of Engagement allow you, or a consultancy acting for you, to test your own tenant and the assets you are explicitly authorised to test. The rules prohibit denial-of-service testing, testing other customers' tenants and phishing Microsoft staff. Any cloud penetration testing provider in Australia should follow them and write them into your rules of engagement.
What does a cloud penetration test cover?
In Microsoft 365 and Azure, a cloud penetration test covers sign-in and MFA, Conditional Access, admin roles and privilege paths, storage and sharing, and whether your monitoring detects the activity. A good scope also names third-party apps, integrations and APIs that can reach your data.
Is a cloud configuration review the same as a cloud penetration test?
No. A configuration review compares your settings to a baseline and lists differences. A cloud penetration test has a tester try to use those weaknesses to reach data or admin rights, and shows the full attack path and whether anyone noticed.
How does cloud penetration testing relate to ASD Essentials for cloud?
ASD Essentials for cloud expects capabilities your provider supplies, such as Conditional Access and logging, to be configured and effective, not just available. A cloud penetration test shows whether they work in your live environment, which is the kind of evidence the ASD rates most highly.
