I've spent the past year building automated Microsoft 365 posture assessments, and the biggest challenge has been identifying security settings that cannot be read programmatically. These are the gaps I've found:
- Entra Password Protection: the custom banned-password list and on-premises agent status are portal-only.
- Defender for Cloud Apps: alerts are readable, but policy configuration and Cloud Discovery settings are not. A licensed tenant with no policies can look identical through the API to one that is fully configured.
- Entra diagnostic settings: there is no Graph API read path for whether sign-in and audit logs are being exported to Log Analytics or storage. This is especially awkward for PCI DSS 10.1, SOC 2 CC7.2, and ISO 27001 A.8.15 evidence.
- Defender for Office 365 Tenant Allow/Block List: it is not available app-only through the documented endpoint.
- Information barriers: reading policies requires OrganizationManagement, which is write-capable. There does not appear to be a genuinely read-only option.
I also ran into an Exchange app-only authentication issue. The documentation points to Exchange.ManageAsAppV2, but granting and consenting to that permission produced tokens containing the role while every call to `POST https://outlook.office365.com/adminapi/beta/{tenantId}/InvokeCommand` returned an empty 403. The Exchange Online PowerShell module failed the same way.
The working endpoint authorizes with the older Exchange.ManageAsApp permission. The app role also has to be assigned to the service principal in each tenant using Graph appRoleAssignments or PowerShell; admin consent for the app registration alone is not enough. The relevant role ID is `dc50a0fb-09a3-484d-be87-e023b12c6440`.
Has anyone found a reliable way to verify Entra diagnostic-setting exports, particularly for compliance evidence?
1 Answer
For diagnostic settings, I’d stop trying to read the configuration switch and verify that data is actually reaching the destination. For a Log Analytics workspace, query recent `AuditLogs` and `SigninLogs`, for example:
`AuditLogs | where TimeGenerated > ago(6h) | summarize count()`
`SigninLogs | where TimeGenerated > ago(6h) | summarize count()`
Recent rows demonstrate that the export is functioning, which is often more useful to an auditor than simply proving that a setting is enabled. Schedule the query and alert when there are zero rows for the expected period. That catches broken exports, insufficient retention, stale workspace IDs, and similar failures.
Use the same pattern for other destinations: check for recent blobs in a storage container or recent ingestion into Event Hubs. Graph audit endpoints can show that Entra logs exist, but they do not prove that the configured export path is working. The limitation is that sink testing proves data flow rather than the exact configuration, so document the check and its expected sources clearly.
That’s a much better approach. Verifying the destination instead of only checking the setting also catches the practical failures that a configuration flag would miss.