Notifications
Clear all
Topic starter
15/08/2026 6:09 pm
TL;DR: Only about 10% of the CIS Microsoft 365 benchmark was covered by Microsoft Graph alone, so meaningful Microsoft 365 auditing had to combine Graph with controlled PowerShell sessions, according to Prowler. The practical lesson is that security visibility often depends on the least elegant integration path, especially when identity, authentication state, and command safety all matter.
NHIMG editorial — based on content published by Prowler: Unlocking M365 Continuous Audit and Beyond by Running PowerShell from Python like a pro
By the numbers:
- Microsoft Graph only allowed Prowler to cover around 10% of the CIS Microsoft 365 requirements.
- 70% of Prowler's checks relied on PowerShell., ied on PowerShell.
Questions worth separating out
Q: What breaks when Microsoft 365 audit automation depends on a single API surface?
A: Coverage breaks first.
Q: Why do stateful admin sessions create extra risk in security automation?
A: They turn authentication into a living runtime dependency.
Q: How do you know if audit automation is actually complete?
A: Check whether every control maps to a verified data source, not just whether the integration works.
Practitioner guidance
- Validate audit coverage against the actual control set Map each Microsoft 365 or similar benchmark control to the data source that proves it.
- Treat persistent automation sessions as privileged identities Assign ownership, rotation rules, timeout policies, and break-glass handling to every long-lived automation process that preserves authentication state across commands.
- Harden shell-backed integrations against malformed input Use strict sanitization, command allow-listing, and output delimiters whenever Python or another orchestrator sends instructions to PowerShell or any other shell.
What's in the full article
Prowler's full post covers the engineering detail this analysis intentionally leaves at a higher level:
- Step-by-step breakdown of the PowerShell session wrapper used to preserve authentication across multiple M365 queries
- Command parsing, stdout and stderr handling, and marker-based response delimiting for long-lived subprocesses
- The specific sanitization and timeout protections added after internal break testing exposed denial-of-service risk
- Why the hybrid Graph plus PowerShell approach was necessary to reach automated CIS coverage in Microsoft 365
👉 Read Prowler's analysis of PowerShell-based Microsoft 365 audit coverage →
PowerShell from Python for M365 audit coverage: what changes?
Explore further
15/08/2026 6:17 pm
Coverage gaps are governance gaps, not just integration gaps. If Microsoft Graph exposes only a fraction of the CIS benchmark, the problem is not tooling preference but incomplete control evidence. Security teams routinely assume an API is authoritative because it is official, yet governance fails when the audit source cannot see the full configuration state. The lesson for practitioners is to validate evidence coverage before relying on any single access path.
A question worth separating out:
Q: Who is accountable when privileged automation can be abused through command input?
A: The owning platform and security teams share accountability, because the control failure sits at the boundary between application design, identity governance, and operational oversight. Frameworks such as NIST SP 800-53 and NIST Cybersecurity Framework 2.0 both expect clear access control, monitoring, and resilience over privileged automation paths.
👉 Read our full editorial: PowerShell from Python extends Microsoft 365 audit coverage
