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.
Editorial analysis by NHI Mgmt Group, based on content published by Prowler: “Unlocking M365 Continuous Audit and Beyond by Running PowerShell from Python like a pro (Yes, it’s actually possible)”.
Key questions
Q: What breaks when Microsoft 365 auditing depends on Graph alone?
A: Graph-only collection breaks coverage when important Microsoft 365 settings are exposed only through PowerShell or portal-backed administrative paths.
Q: Why do persistent PowerShell sessions matter for Microsoft 365 checks?
A: Persistent sessions matter because many Microsoft 365 modules expect one authenticated context to survive across multiple commands.
Q: What are the main failure modes when embedding PowerShell in Python automation?
A: The main failure modes are command injection, orphaned or long-running processes, and broken response handling between stdout and stderr.
Practitioner guidance
- Define the Microsoft 365 control surface Map each CIS-relevant Microsoft 365 requirement to Graph, PowerShell, or another administrative plane before implementing checks.
- Use persistent sessions for multi-step checks Keep one authenticated PowerShell session alive for the duration of a service collection run so authentication state is preserved across queries.
- Enforce strict command validation Sanitise every input, reject characters that can alter shell parsing, and validate all parameters before they reach the PowerShell process.
Bottom line: Microsoft 365 audit tooling can look modern and still miss large parts of the control surface if it relies on Graph alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
15/08/2026 6:17 pm
Hybrid audit paths are now a control-design issue, not an implementation quirk. If Microsoft 365 governance evidence exists partly in Graph and partly in PowerShell, then tooling strategy must follow the control surface rather than the developer’s preferred interface. The real decision is whether the organisation wants partial visibility with simple integration or complete coverage with tighter execution governance. Practitioners should design for the full control map, not the easiest API.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: When should teams choose a hybrid API and shell approach for SaaS audits?
A: Teams should choose a hybrid approach when the supported API covers only part of the required benchmark and the remaining controls live in a governed administrative shell. The decision is justified when completeness matters more than architectural purity, provided the shell path is tightly constrained and continuously tested for abuse.
👉 Read our full editorial: PowerShell from Python extends Microsoft 365 audit coverage