Microsoft Defender
Microsoft Defender for Endpoint connects device, user, vulnerability, and software data into Navigator: the richest single connector for security-relevant data among the Microsoft connectors.
At a glance
| Data provided | Devices, Users, Vulnerabilities, Software |
|---|---|
| Authentication | OAuth2 client credentials (Azure app registration) |
| Where to configure | Connectors → Add a Connector → Microsoft Defender |
Required permissions
Create (or reuse) an Azure app registration, then grant it these Application permissions (not delegated) with admin consent, on the WindowsDefenderATP API specifically (not Microsoft Graph):
| Permission | Why it’s needed |
|---|---|
Machine.Read.All | Read device (machine) records |
User.Read.All | Read per-machine logged-on users |
Vulnerability.Read.All | Read per-machine vulnerability findings |
Software.Read.All | Read per-machine installed software |
Setup
- In the Azure Portal, go to Entra ID → App registrations and create a new app registration (or reuse an existing one).
- Under API permissions → Add a permission, choose APIs my organization uses and search for WindowsDefenderATP (not Microsoft Graph). Add the four Application permissions listed above, then click Grant admin consent.
- Under Certificates & secrets, create a new client secret and copy its value immediately. It’s only shown once.
- Note your Tenant ID, the app registration’s Client ID, and the client secret you just created.
- In Navigator, go to Connectors → Add a Connector → Microsoft Defender.
- Enter the Tenant ID, Client ID, and Client Secret.
- Optionally, choose which onboarding statuses to import (Onboarded, Can be onboarded, Unsupported, Insufficient info); all four are included by default. Limiting this also limits which machines’ users, vulnerabilities, and software are imported, since those are all fetched per-machine.
- Save. Navigator validates the credentials and enqueues a first sync immediately.
Vendor documentation
Microsoft’s own instructions: Create an app to access Microsoft Defender for Endpoint without a user. This is also where Microsoft documents the legacy-resource quirk mentioned above (some Defender APIs still require a token issued for api.securitycenter.microsoft.com specifically).
What data this connector provides
- Devices: including native internal/external IP address separation (one of the few connectors that distinguishes these directly rather than needing to infer it) and, for devices with the Defender sensor installed, the time the sensor last reported, used for its last activity time. Devices Defender only discovered on the network (printers, switches, unmanaged PCs) have no activity time from Defender.
- Users: per-machine logged-on users.
- Vulnerabilities: per-machine findings via Defender’s own vulnerability management data.
- Software: per-machine installed software inventory.
Every Defender-covered device is treated as having agent-based EDR coverage.
Known limitations
- Defender’s user and software data are fetched per-machine (there’s no single “all users” or “all software” endpoint), so a first sync on a large fleet takes longer than connectors with a bulk export, and is subject to Microsoft’s own API rate limits (100 requests/minute, 1,500/hour) on very large environments.
Related connectors
Defender, Entra ID, Intune, and Azure are independent connectors that can each use their own Azure app registration, or share one. See the Connectors overview.