Defender for Endpoint - RBAC group filter not working on export APIs

Question

Defender for Endpoint - RBAC group filter not working on export APIs

Berlin Russel 0

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

Givary-MSFT 35,911 Reputation points Microsoft Employee Moderator

2026-09-10T09:49:41.6533333+00:00
@Berlin Russel

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.

1 answer

Your answer

Answer 1

Hello @Berlin Russel

Certificate authentication itself isn't the issue here. A certificate and a client secret are simply different credentials for obtaining an app-only token through the client credentials flow. They don't change how Defender authorizes the application.

For these Vulnerability Management export APIs, Microsoft documents:

Application: Vulnerability.Read.All

Delegated: Vulnerability.Read

The application permission is tenant-wide. The documentation doesn't provide a supported method to restrict Vulnerability.Read.All to a particular Defender device/RBAC group.

This is also an important distinction with Defender device-group RBAC. Microsoft documents device-group enforcement specifically for user-context access, while Unified RBAC role assignments are made to users or Entra security groups. There is currently no documented configuration for assigning a certificate-authenticated service principal to a Defender for Endpoint device group for these export APIs.

So creating five certificate-authenticated app registrations wouldn't solve the problem either. If each application has Vulnerability.Read.All, each can still retrieve tenant-wide vulnerability data.

For app-only ingestion today, the supported approach is therefore to use the export/delta API and filter by RbacGroupId / RbacGroupName after retrieval. The export API itself doesn't support those properties as server-side filters.

If strict server-side separation per business unit is required, I would recommend opening a Microsoft support/feature request, because device-group-scoped app-only access isn't currently documented as a supported capability for these Vulnerability Management export APIs.

If this answer helps, please mark it as Answered.