Microsoft Security | Microsoft Defender | Microsoft Defender for Cloud
A cloud-native solution that protects workloads across hybrid and multi-cloud environments with threat detection and security recommendations
Defender for Endpoint - RBAC group filter not working on export APIs
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(304, 28.999999999999996%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBR%3C/text%3E%3C/svg%3E)
Berlin Russel
0
Reputation points
Hi team,
We're ingesting vulnerability/asset data from Defender for Endpoint for a single tenant segmented into multiple RBAC device groups (one group per business unit).
We're attempting to filter by RBAC group ID/name, but the assessment export APIs (SoftwareVulnerabilitiesByMachine, SoftwareVulnerabilityChangesByMachine) don't honor RbacGroupId/RbacGroupName as a filter parameter - it's silently ignored. As a result, we're pulling the full tenant snapshot (all assets and vulnerabilities across all business units) for every single ingest, which is multiplying our call volume and pushing us into rate limits.
We found this Microsoft Q&A thread confirming the same behavior: https://learn.microsoft.com/en-us/answers/questions/5834828/rbacname-filter-not-working-for-export-software-vu. Microsoft's response there points to scoping the calling credentials themselves (via Unified RBAC role assignment on the app/service principal) so the API returns only that device group's data, rather than filtering client side.
We'd like to go this route, but with one specific question: our clients require certificate-based authentication for app-only access (they're pushing back on client secrets due to rotation overhead). Does Unified RBAC device-group scoping actually apply to app-only tokens authenticated via certificate, or does group enforcement only apply to delegated/user-context tokens? If it does apply to app-only/cert auth, could you point us to the exact configuration steps to scope a certificate-authenticated app registration to a specific device group?
We're currently doing full-tenant pulls with client-side filtering, which works but is heavy at our scale, and the file-based export doesn't return enough data for our use case - so this credential-scoping path is our preferred fix if it's supported.
Happy to share request/response samples if useful, or hop on a call if that's easier to work through.
Thanks,
Berlin
Microsoft Security | Microsoft Defender | Microsoft Defender for Cloud
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 17%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGM%3C/text%3E%3C/svg%3E)
Givary-MSFT 35,911 Reputation points Microsoft Employee Moderator2026-09-10T09:49:41.6533333+00:00 Certificate-based authentication is supported for Microsoft Defender for Endpoint app-only API access, but it doesn’t change the authorization scope of the application.
A certificate and a client secret are two credential types for the same OAuth 2.0 client-credentials flow. A certificate replaces the client_secret with a signed client_assertion ; the resulting token is still an app-only token containing application roles such as Vulnerability.Read.All .
Microsoft Defender Unified RBAC role assignments are documented for individual users and Microsoft Entra groups. Defender for Endpoint device-group access is also assigned to Microsoft Entra user groups. The documented Unified RBAC and device-group interfaces don’t support assigning an app registration or service principal to a device group.
Consequently, there is no supported procedure to scope a certificate-authenticated app-only token to one Defender device group. An app granted Vulnerability.Read.All should be treated as having tenant-wide vulnerability-data access.
RbacGroupName and RbacGroupId in the vulnerability export results are response properties. They aren’t documented filter parameters for SoftwareVulnerabilitiesByMachine or SoftwareVulnerabilityChangesByMachine , so sending them as filters can be ignored.
The recommended unattended-ingestion design is:
- Call the full export once per tenant for initial synchronization.
- Use the delta export once per tenant for subsequent ingestion.
- Persist the delta checkpoint.
- Partition the returned records downstream by RbacGroupId or RbacGroupName .
- Provide each business unit access only to its partitioned data.
This is significantly more efficient than executing the same tenant-wide export separately for every business unit. If source-enforced isolation is mandatory, the current app-only export API and Unified RBAC model don’t provide that granularity; a central broker, separate tenants, or a product enhancement would be required.
Sign in to comment
Sign in to answer