Skip to content

Connect Microsoft Defender

Ledger reads device/machine inventory and health status from Microsoft Defender for Endpoint — and, since Defender for Business shares the same API surface, from Microsoft Defender for Business too — to check which devices actually have EDR coverage. It is a read-only endpoint auditor — it reads the machine list (stored fields include health status, risk score, exposure level, device value and tags), never reads alerts, incidents, vulnerabilities, or any other Defender data, and never writes to Defender. Auth is a certificate credential (never a client secret), and each customer tenant gets its own admin-consented grant.

Defender is a dependent source: the machine records it returns carry no hardware serial, hardware UUID, or manufacturer/model — it joins to a device Ledger already knows about mainly through the device's Entra device ID (and, where Defender returns them, its hostname and network adapter addresses). For the clearest picture, connect Microsoft Intune (or Entra) first; Defender then tells you which of those devices Defender actually protects.

What you're consenting to

Ledger's Graph app registration requests one additional application permission, admin-consent-only, on the same app registration Intune already uses:

Permission Resource
Machine.Read.All WindowsDefenderATP (not Microsoft Graph — it appears in the "Add permission" list only once you start typing the name)

This is a second, Defender-specific consent, separate from Intune's Graph consent — even if you have already connected Intune, connecting Defender asks your tenant's admin to approve this permission too. Machine.Read.All is broader than the calls Ledger actually makes: Ledger only ever calls the list-machines endpoint, never a per-device call, never Machine.ReadWrite.All, and never a write.

1. Enter your tenant ID in Ledger

From Connections → Add connection → Microsoft Defender, enter your Tenant ID — the GUID for your Azure AD / Entra tenant, never the literal value common. Ledger rejects anything that doesn't parse as a GUID.

Saving the connection returns an admin-consent URL of this shape:

https://login.microsoftonline.com/{your-tenant-id}/v2.0/adminconsent
  ?client_id={ledger-app-id}
  &scope=https://api.securitycenter.microsoft.com/.default
  &redirect_uri={ledger-redirect-uri}
  &state={one-time-token}

Note the scope — it names api.securitycenter.microsoft.com, not graph.microsoft.com. This is correct: Defender's token audience is a different resource than Intune's, even though both go through the same Microsoft sign-in flow. Open the URL as your tenant's Global Administrator (or another role that can grant admin consent for application permissions) — a non-admin account cannot approve this request.

Microsoft shows the permission listed above. Approve it, and Microsoft redirects back to Ledger.

Ledger does not trust the tenant value on that redirect on its own — Microsoft's own documentation warns that parameter can be forged. Instead, Ledger acquires a token for the tenant ID you entered in step 1 and reads the tenant claim back out of that token, so the confirmation can never be spoofed by a malicious redirect.

4. Confirm the connection is healthy

Back in Ledger, the connection should show healthy. If it shows failed, the error message (with any secret scrubbed) explains why — common causes are consent not yet propagated (retry after a minute or two) or a tenant ID that doesn't match the account that approved consent. If the connection fails with an audience error, contact support — it is not something to fix on your end.

If Ledger later needs an additional permission, or your organization revokes consent, the connection moves to a revoked/needs re-consent state. Use the connection's Reconsent action to generate a fresh, single-use consent URL — the same walkthrough above, without contacting support or exchanging emails by hand.