Why scoring Microsoft 365 without Azure measures half the posture — and the wrong half

The question almost no one asks when buying a "Microsoft 365 audit"

The typical Microsoft 365 audit brochure — from the local MSP, the regional integrator, or the compliance SaaS vendor — promises to review Entra ID, Exchange Online, SharePoint, OneDrive, Teams, Defender for Office 365, and ship a PDF with prioritised findings. That is legitimate work. It is also incomplete work, and the question almost no one asks is: _what about Azure?_

The honest answer from most vendors is "not in scope." The correct answer for the customer is that the exclusion is not a technical decision; it is a commercial decision dressed as scope. And the difference matters because the security posture of a company operating both Microsoft 365 and Azure cannot be measured by looking at one of the two planes alone.

This article explains why.

The two control planes: Graph and ARM

Microsoft exposes its enterprise cloud through two distinct control planes:

Microsoft Graph is the control plane for the SaaS applications: Entra ID (identities, MFA, Conditional Access), Exchange Online (mailboxes, transport rules, antiphish), SharePoint and OneDrive (sites, external sharing), Teams (channels, messaging policies), Defender for Office 365 (Safe Links, Safe Attachments, ATP), Intune (MDM), Purview (DLP, sensitivity labels). The canonical endpoint is `graph.microsoft.com`. It is documented at learn.microsoft.com/graph.

Azure Resource Manager is the control plane for the infrastructure: subscriptions, resource groups, virtual machines, virtual networks (VNets), Network Security Groups, storage accounts, Key Vaults, managed databases, Azure Functions, Container Apps, Azure RBAC role assignments, Azure Policy, Defender for Cloud. The canonical endpoint is `management.azure.com`. It is documented at learn.microsoft.com/azure/azure-resource-manager.

Both planes share the same identity — Entra ID is the root directory of both — but their configuration surfaces are distinct, their tokens are distinct (audiences `https://graph.microsoft.com` vs `https://management.azure.com`), and their compliance benchmarks are explicitly distinct.

That last part matters: the authors of the compliance frameworks already separated the two planes. CIS publishes a Microsoft 365 Foundations Benchmark (v4.0.0, November 2024) and, separately, a Microsoft Azure Foundations Benchmark (v3.0.0, December 2024). Microsoft publishes the Microsoft Cloud Security Benchmark (MCSB v1) which maps controls to NIST SP 800-53 Rev. 5 and explicitly separates Azure from Microsoft 365. CISA, through its SCuBA project, publishes Microsoft 365 baselines (AAD, EXO, SharePoint, Teams, Defender, Power Platform) and does not touch Azure Resource Manager — because ARM has its own family of baselines, handed off to CIS Azure Foundations and MCSB.

If the formal frameworks separate the two planes for a reason, a vendor that audits only one and ships a consolidated score is collapsing two categories the standard authors kept distinct. That is a methodology defect, not a scope choice.

Why the Azure plane matters for an SMB that "only uses Microsoft 365"

The counterintuitive argument from the local integrator: "the customer only uses Microsoft 365, they have no workloads in Azure, why audit Azure?"

The argument fails for three simultaneous reasons:

1. The SMB has an Azure subscription whether they know it or not

Every Microsoft 365 tenant carries at least one Azure subscription — the one backing Azure AD (now Entra ID), the one signing certificates, the one hosting unified audit logs, the one registering app registrations. For customers who bought Microsoft 365 through a CSP partner, there is a "Pay-As-You-Go" or "Azure plan" subscription in the tenant that the partner administers and that the customer rarely inspects.

That subscription has a Global Administrator who is the same Global Administrator as Microsoft 365. It has Azure RBAC role assignments that can be escalated to tenant Owner. It has activity logs an attacker can disable if they hold the privileges. And it has a set of Microsoft defaults that — like any set of defaults — are optimised for time-to-first-deploy, not for hardened posture.

If the SMB has a Microsoft 365 tenant, it has an Azure Resource Manager plane. The question is whether it is audited.

2. Identity crosses both planes without notice

The Microsoft Digital Defense Report 2024 (published October 2024) documents identity as the primary attack vector against organisations operating in Microsoft's cloud, with sustained volume of hundreds of password-spray attempts per second at global scale and a growing share of adversary-in-the-middle (AiTM) phishing that captures valid tokens rather than credentials.

When an attacker obtains a valid Entra ID identity token — through AiTM phishing, through illicit consent to an OAuth app, through a compromised device with active SSO — that token can be used to call Microsoft Graph and to call Azure Resource Manager. The control on what the attacker can do with that token does not depend on which plane is audited: it depends on how conditional access is configured, what privileges the associated principal holds, what Azure RBAC role assignments it inherited, and whether mailboxes, Key Vaults, and storage accounts have access policy rules that constrain the exploitation.

Auditing only Microsoft Graph means counting doors on one wall and declaring the house secure without looking at the other side of the building.

3. Mexican regulation obligates "maintaining" — not auditing partially

LFPDPPP Art. 18 obligates the data controller to "establish and maintain administrative, technical, and physical security measures that protect personal data against damage, loss, alteration, destruction, or unauthorised use, access, or processing." The verb "maintain" does not admit the reading "maintain only the plane the vendor decided to quote on."

CNBV — for financial institutions — requires under the Circular Única de Bancos a Security Master Plan and periodic privilege reviews, with evidence. If the Azure subscription hosts the backup of the unified audit logs and that subscription is not reviewed, the master plan is not a periodic review; it is a partial review.

NMX-I-27001 (the Mexican standard mirrored from ISO/IEC 27001:2022) lists in its Annex A controls for "Information security for use of cloud services" (A.5.23) without restricting scope to SaaS. The ISMS must cover IaaS, PaaS, and SaaS that the data controller uses — and a Microsoft 365 tenant with its adjacent Azure subscription uses all three.

The split: 155 Microsoft Graph rules + 46 Azure Resource Manager controls

simiriki publishes its detection library in `lib/deepScan.ts` as a public TypeScript array (part of the repository the platform security audit documents at `/security-posture`). The current count at the close of Q2 2026 is 201 detection rules (most return an automated pass/fail verdict; the rest are flagged needs-review when the tenant data is insufficient to decide), distributed by plane as follows:

• 155 Microsoft Graph evaluators — run against `graph.microsoft.com` with delegated read permissions. Cover the domains IAM (identity and access, Entra ID), EML (Exchange Online), EXO (Exchange tenant settings), DLP (Purview Data Loss Prevention), DEV (app registrations and consent), MDM (Intune / device compliance), AUD (unified audit, log retention), APP (application access and workload identities), OPS (tenant operations), TMS (Teams and messaging), RSK (Risky users and sign-ins), PUR (Purview policies), PWR (Power Platform DLP).
• 46 Azure Resource Manager evaluators — run against `management.azure.com` with Reader permission at the subscription. Cover the domains AZR (subscription posture), SEN (Sentinel and Defender for Cloud), NET (networking, NSG, Private Endpoints), CMP (compute, virtual machines, disk encryption), DBS (managed databases, encryption at rest), GOV (governance, Azure Policy, role assignments).

The count is verifiable: `grep -c "id: " packages/scan-core/src/registry.ts` returns 201. It is not a marketing number.

The 155/46 split — roughly 77% Graph / 23% ARM — does not reflect the relative importance of each plane. It reflects that the Microsoft Graph technical surface is broader (seven productivity applications, MDM, compliance suite) while ARM is a single infrastructure plane with fewer but deeper critical configurations. A misconfigured ARM rule — for example a Storage Account with `allowBlobPublicAccess=true` that hosts CFDI backups — carries a larger financial and regulatory impact than many Graph rules.

The six ARM domains, concretely

To stop the split from being abstract, the six Azure Resource Manager domains that simiriki audits correspond to controls that appear explicitly in CIS Microsoft Azure Foundations Benchmark v3.0.0 and Microsoft Cloud Security Benchmark v1:

AZR (Azure subscription posture) — CIS control 1.x: Microsoft Entra global administrator account not used as subscription admin, subscriptions with assigned management group, elevated-privilege Service Principals rotated.

SEN (Sentinel + Defender for Cloud) — CIS control 2.x: Microsoft Defender for Cloud enabled on every subscription, auto-provisioning of Log Analytics agent, Defender for Servers / Storage / Key Vault / SQL plans active according to inventory.

NET (Networking) — CIS control 6.x: NSGs with restricted inbound rules, no resource with `:22` or `:3389` open to the internet, Private Endpoints on Storage Accounts and Key Vaults, DDoS Standard Protection where applicable.

CMP (Compute) — CIS control 7.x: VM disk encryption enabled, OS patched, Just-In-Time VM Access configured, security extensions (`MDE.Windows`, `MDE.Linux`) present.

DBS (Databases) — CIS control 4.x: Transparent Data Encryption on Azure SQL, Auditing enabled, Advanced Threat Protection active, firewall rules with no `0.0.0.0`.

GOV (Governance) — CIS control 5.x: Azure Policy assignments for the minimum baseline, Role Assignments reviewed, custom roles audited, Privileged Identity Management (PIM) active.

Each of the six domains has an explicit mapping in simiriki to CIS Azure Foundations, MCSB, and — where applicable — Article 18 of LFPDPPP and the sections of CNBV Chapter X (Operational Risks) and Chapter XX (Third-Party Service Contracting). The mapping is in code, not on a separate spreadsheet.

The asymmetry of risk in a real breach

An illustrative use case, built from the pattern documented in the Microsoft Digital Defense Report 2024 and in the annual incident response reports of Microsoft's Detection and Response Team (DART):

An attacker sends an AiTM phishing email to a user with Application Administrator privileges in Entra ID. The email leads the user to a proxy that captures the valid session token after MFA authentication. The attacker uses the token to call Microsoft Graph and create a new client secret on an app registration with elevated application permissions — a pattern documented in CISA Alert AA23-074A. Up to this point, a Graph-only audit would detect the pattern.

The attacker uses the same identity token to escalate to the Azure plane: requests a token for `https://management.azure.com`, discovers the app's principal holds a Contributor Role Assignment on the production subscription (because someone wanted to simplify a Function App deployment two years ago), and exfiltrates the contents of a Storage Account that hosts backups of tables with CURPs and RFCs.

An audit that covered only Microsoft Graph will report: "anomalous client secret creation detected, severity high." The customer will read the report, rotate the secret, and close the ticket. A week later they may discover that the exfiltrated Storage Account sat in a subscription that was never audited and the breach requires a separate legal assessment.

The split is not a technical preference. It is the difference between closing an identity finding and correctly assessing the actual scope of a breach.

How to evaluate a vendor on this axis

If your current Microsoft 365 audit vendor — local MSP, regional integrator, or compliance SaaS — promises a complete posture, the questions that validate or invalidate that promise are specific:

1. Which Microsoft endpoint is called during the scan, besides `graph.microsoft.com`? If the answer does not include `management.azure.com`, the scope is Graph-only.

2. What permissions does the audit app request in the tenant? Permissions exclusively from Microsoft Graph (`Directory.Read.All`, `Policy.Read.All`, etc.) without an Azure RBAC role assignment (`Reader` at subscription or management group level) confirm that the ARM plane is not evaluated.

3. What is the rule count evaluated, and what is the per-plane split? A vendor that cannot answer for the composition of its library is selling methodological opacity.

4. Is the result mapped to CIS Microsoft Azure Foundations Benchmark, not just to CIS Microsoft 365 Foundations? The two benchmarks are separate documents with separate IDs. Asking for the mapping is trivial; delivering it requires having done it.

5. What about the CSP partner subscription? If the tenant bought Microsoft 365 through a Cloud Solution Provider, the subscription backing Entra ID is under partner administration. A serious audit documents what can and cannot be seen from the customer's position.

The five questions are neutral — any competent vendor answers them without friction. The answers, not the promises, determine whether the audit covers the complete posture or the comfortable half.

What simiriki does, so the comparison is symmetric

So this article is not an abstract argument: simiriki's library covers both planes with 201 rules. The free scan evaluates the 155 rules on the Microsoft Graph plane (the `graph.microsoft.com` token audience) under read-only consent during the PKCE flow; the 46 rules on the Azure Resource Manager plane (the `management.azure.com` audience) run when you connect the tenant with admin consent and the Reader role over the subscription. The three-page Posture Brief separates findings by plane and maps them to CIS Microsoft 365 Foundations, CIS Azure Foundations, MCSB, and NIST CSF v2.0 with stable identifiers.

The code that does it is public and verifiable in the repository:

• `apps/api/src/graph/graph-client.service.ts` — rate-limited client for Microsoft Graph
• `apps/api/src/connectors/azure-resource-manager.connector.ts` + `lib/armToken.ts` — token acquisition and connector for Azure Resource Manager
• `packages/scan-core/src/registry.ts` — canonical library of the 201 detection rules (lib/deepScan.ts re-exports it for compatibility)

Neither the scope nor the mappings are marketing material. They are auditable artefacts.

Next step

If you want to see the difference in your own tenant — what shows up in Graph, what shows up in ARM, and what is left uncovered when scope shrinks to one plane — the free scan starts with Graph; ARM requires separate admin consent and Reader access. The preview typically appears in minutes. The complete report is delivered on a best-effort basis, with a non-guaranteed estimated target of up to 1 hour. No credit card, no local installation.

Scan your Microsoft 365 + Azure free →

---

Sources cited in this article:

• Microsoft Digital Defense Report 2024 (October 2024) — identity as primary vector, AiTM phishing patterns
• CIS Microsoft 365 Foundations Benchmark v4.0.0 (November 2024) — Microsoft 365 controls
• CIS Microsoft Azure Foundations Benchmark v3.0.0 (December 2024) — AZR/NET/CMP/DBS/GOV controls
• Microsoft Cloud Security Benchmark (MCSB) v1 — mapping to NIST SP 800-53 Rev. 5
• NIST SP 800-53 Rev. 5 (September 2020, 2023 patch release) — federal security controls
• CISA SCuBA Secure Configuration Baselines — explicitly Microsoft 365-only scope
• CISA Alert AA23-074A — app registration and client-secret abuse pattern
• Chamber of Deputies · LFPDPPP Art. 18 — security measures
• CNBV · Circular Única de Bancos, Chapters X and XX (last amendment 2024)
• NMX-I-27001 / ISO/IEC 27001:2022, Annex A.5.23 — Information security for use of cloud services
• Microsoft Learn · Azure Resource Manager — learn.microsoft.com/azure/azure-resource-manager
• Microsoft Learn · Microsoft Graph — learn.microsoft.com/graph

Full source index: simiriki.com/sources