What is a one sentence summary of your feature request?
Add a new state report showing all application/service principal OAuth permission grants — including consent type and a high-risk scope flag — so customers can detect and audit risky third-party application access before it’s exploited.
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
The problem: Netwrix Auditor’s Entra ID connector currently has no visibility into application consent or OAuth permission grants at all — this is a completely uncovered area, not a partial gap. Customers cannot see which applications hold which Microsoft Graph permissions, who consented to them (a user or an admin), or whether any of those grants involve high-privilege scopes (e.g. Directory.ReadWrite.All, Mail.Read, Files.ReadWrite.All).
This matters because application-level permission abuse is one of the most persistent and hardest-to-detect attack paths in Entra ID: once an application is granted access, it acts independently of any signed-in user — no further password prompts, no MFA challenges, nothing for the user to notice. A newly documented OAuth phishing technique (“ConsentFix”/“AuthCodeFix”, March 2026) specifically abuses pre-consented first-party applications to bypass passwords, MFA, and in some cases Conditional Access entirely — making this a live, currently-exploited risk rather than a theoretical one.
Why this is the right solution: OAuth grants and app role assignments are queryable as current state via Graph API, so this fits the same state-collection pattern already used elsewhere in the connector — no event-log pipeline is required for v1. The report would surface:
- Application / service principal name
- Granted scope or app role
- Consent type: admin consent vs. user consent
- Grantor (who consented)
- A risk flag matched against a static watchlist of high-privilege Graph scopes (no dynamic risk-scoring engine needed initially)
This maps to NIST 800-53 (AC-3(7), CA-7 continuous monitoring, SA-9/SR-3 supply chain), ISO 27001 (A.5.20 supplier relationships, A.8.2 privileged access), and SOC 2 (CC6.1, CC6.7). It’s also already established as baseline expected functionality in this market — a niche Entra ID/M365 reporting competitor ships a comparable “OAuth Permission Granted Applications” report as part of a 120+ report library, and Netwrix’s own published threat research names illicit consent grants as a primary Entra ID persistence technique.
How do you currently solve the challenges you have by not having this feature?
Customers have no way to review application consent state through Netwrix Auditor today. They either rely on the Microsoft Entra admin center’s enterprise applications view (manual, point-in-time, no historical comparison) or build custom Graph API/PowerShell scripts to export the data separately, with no integration into their existing Netwrix-based audit evidence or alerting. In practice, this means risky or over-privileged application grants frequently go unnoticed until an incident or an external audit specifically asks for this evidence.