Skip to content

ISO 27001, SOC 2, the DPDP Act and manual VAPT. Book a Free Scoping Call

Microsoft 365

Microsoft 365 Configuration Review vs Penetration Testing

A Microsoft 365 configuration review reads your tenant's settings and compares them with a published baseline, such as the CIS Microsoft 365 Foundations Benchmark. A penetration test of Microsoft 365 and Entra ID starts from an attacker's position and tries to prove what a weak setting lets someone reach. The review needs read-only access and returns a list of deviations; the test needs written authorisation, test accounts and agreed limits, and returns attack paths with evidence. Microsoft's Penetration Testing Rules of Engagement let a tenant owner and its authorised agents test inside their own tenant, and prohibit testing anything they do not own.

Contact SecureRoot

About this guide

Written by SecureRoot Risk Advisory LLP.

The difference

Two different pieces of work

Both look at the same tenant. They answer different questions, need different access and produce different reports, so it helps to decide which one you are buying before anyone quotes.

  1. 01

    Configuration review: are the settings right?

    A reviewer reads the tenant's configuration and checks each setting against a baseline. Typical areas are Entra ID (conditional access, multi-factor authentication, administrative role assignments, application consent and guest access), Exchange Online mail flow and forwarding, SharePoint and OneDrive sharing, Teams external access, and audit logging. The CIS Microsoft 365 Foundations Benchmark is the common reference; CISA's Secure Cloud Business Applications (SCuBA) project publishes secure configuration baselines for Microsoft 365 and a no-cost tool, ScubaGear, that checks a tenant against them. A review changes nothing and exploits nothing.

  2. 02

    Penetration test: what can an attacker do with them?

    A tester works from an attacker's position, usually starting with a low-privilege test account that stands in for a compromised user, and tries to prove impact: escalating through role assignments or application permissions, getting around conditional access, or reaching mailboxes, sites and files the account should not see. A test answers which of the deviations actually matter, which a list of settings cannot do on its own.

Configuration review and penetration test compared
AspectConfiguration reviewPenetration test
The question it answersAre the settings right?What can an attacker do with them?
Starting pointThe tenant's configuration, checked setting by setting against a baseline such as the CIS Microsoft 365 Foundations Benchmark or CISA's SCuBA baselinesAn attacker's position, usually a low-privilege test account standing in for a compromised user
What it does to the tenantChanges nothing and exploits nothingTries to prove impact inside agreed written limits: escalating privileges, getting around conditional access, reaching data the account should not see
Access it needsA read-only role created for the engagement, time-bound and removed at the endWritten authorisation from the tenant owner naming the tenant, fresh test accounts, and a written list of what is allowed and off limits
What it deliversA result for each baseline control (met, not met or not assessed) with evidence, and deviations ranked by risk with the setting to changeThe attack paths that worked, with evidence, ranked by impact; the paths tried and blocked; remediation; observations on what monitoring saw
When to start with itThe tenant has never been checked against a baselineThe baseline is already clean

Which comes first depends on where you are. If the tenant has never been checked against a baseline, start with the review: paying a tester to prove that legacy authentication is still enabled teaches you little. If the baseline is already clean, a test is the sharper spend, because it looks for the paths a checklist does not describe.

Microsoft's rules

What Microsoft's Rules of Engagement say

Microsoft publishes one set of rules for security testing of its online services, the Microsoft Security Testing Rules of Engagement on the Microsoft Security Response Center (MSRC) site. A test plan for a Microsoft 365 tenant should be checked against the current text, because it is the boundary of what anyone may do. In summary, as published when this guide was checked:

  • Who they cover: the rules apply equally to the owner of a resource and its duly authorised agents, which the page says includes third-party security consultancies.
  • Where testing may happen: within your own tenant, or assets for which you have explicit authorisation. The page describes no separate approval form or advance notice to Microsoft for testing your own tenant.
  • Encouraged: creating test accounts or trial tenants, evaluating conditional access or Intune mobile application management (MAM) policies, and testing your tenant's security monitoring and detection, for example with EICAR test files.
  • Prohibited: accessing or testing other customers' or Microsoft's data or systems without explicit permission; using credentials or secrets that are not yours, including ones leaked publicly; denial-of-service testing and automated testing that generates excessive traffic; and phishing or social engineering of Microsoft employees, or using Microsoft services to phish or socially engineer others.
  • Also prohibited: post-compromise actions such as enumerating internal networks, dumping secrets, lateral movement or pivoting, and any action that uses a discovered vulnerability beyond an initial proof of concept.
  • If you reach data you have no rights to: stop immediately, notify MSRC, delete the data and do not share it. Vulnerabilities in Microsoft's own services are reported to MSRC under coordinated vulnerability disclosure.
  • Microsoft says it may interrupt attacks in progress, and that breaking the rules can lead to account suspension or legal action.

Two practical consequences follow. First, the tenant owner, not the tester, is the one who authorises the work, so the authorisation should be in writing and name the tenant. Second, the rules do not draw a separate line for post-exploitation activity inside your own tenant, so the actions the tester may take after a first foothold, and any phishing simulation, should be agreed in writing against the current text before testing starts.

From you

What each needs from the client

Neither needs credentials, keys or personal data at the scoping stage. Access is created later, inside your own tenant, after the scope is agreed.

  1. 01

    For a configuration review

    A read-only role created in your tenant for the engagement and removed at the end of it. Microsoft's built-in Global Reader role is described as able to read everything a Global Administrator can, but not update anything; Microsoft marks it as privileged, so time-bind it. Also: the licence plans in use (some settings exist only on higher plans), the workloads in scope, whether identities are synchronised from on-premises Active Directory, which baseline you want to be measured against, and a technical contact.

  2. 02

    For a penetration test

    Written authorisation from the tenant owner naming the tenant. Test accounts created fresh for the work, never a real employee's login. A written list of what is allowed and what is off limits: credential guessing and its rate, phishing or not, changes to configuration, break-glass accounts, executive mailboxes. Testing windows, an escalation contact on each side, and a decision on whether your security operations team or managed detection provider is told in advance or left to detect the activity.

What comes back

What each delivers

  1. 01

    Configuration review

    A result for each baseline control: met, not met or not assessed, with the evidence behind it and the reason where a control could not be checked, for example because the licence does not include the feature. Deviations ranked by risk, with the setting to change. Expect a long list; the value is in the ranking.

  2. 02

    Penetration test

    The attack paths that worked, each with the starting point, the steps, the evidence and what was reached, ranked by impact, plus the paths that were tried and blocked. Remediation for each, and observations on what your monitoring did or did not see. Ask in advance whether a retest of the fixes is included.

Either report is a point-in-time view. Microsoft 365 settings change often, through administrators and through Microsoft's own feature releases, so a clean result last year says little about today.

Scope boundaries

What this does not cover

  • Neither piece of work tests Microsoft's own infrastructure or other customers' tenants. Microsoft's rules prohibit that, and vulnerabilities in Microsoft's services go to MSRC.
  • Meeting a benchmark is not the same as being compliant with a law or framework, and neither a review nor a test guarantees that a tenant cannot be compromised.
  • On-premises Active Directory is a separate estate. SecureRoot's Active Directory audit covers on-premises Active Directory and its domain controllers; Entra ID is outside that audit's standard scope.
  • Licensing, configuration changes and the decision to accept a risk remain with the tenant owner.

Questions

Common questions

  • Do we need Microsoft's permission to test our own Microsoft 365 tenant?

    Microsoft's published Rules of Engagement do not describe an approval form for testing your own tenant. They allow testing within your own tenant or assets for which you have explicit authorisation, apply to the owner and its authorised agents alike, and list prohibited activities such as denial of service and using credentials that are not yours. Check the current text before testing, because it is the boundary.

  • Is a configuration review enough for a customer security questionnaire?

    It depends on the question. If the customer asks whether your tenant follows a recognised baseline, a review against the CIS Microsoft 365 Foundations Benchmark or the CISA SCuBA baselines answers it. If they ask for a penetration test, a review is not one, and it is better to say so than to relabel it.

  • Does the tester need a Global Administrator account?

    Not for a review: a read-only role such as Global Reader, created for the engagement and removed afterwards, is the usual route. A penetration test normally starts from a low-privilege test account, because the point is to see how far an ordinary user can get.

Primary Sources

Where the Figures on This Page Come From

Figures and requirements above are taken from the sources below, linked to the primary text wherever one exists rather than to a summary of it.

Related

Services and help that go with this

Talk through your tenant

If you are deciding between a review and a test, tell SecureRoot what triggered the question and what the report is for. We will say plainly what we can and cannot help with.

Contact SecureRoot