Microsoft
One tenant connection: the machines you manage but have not measured, pushing the agent, and the directory behind them.
On this page
One connection to your Microsoft tenant, consented once, and three of its products become readable: Intune, Entra ID and Defender. Microsoft 365 Copilot has a connection of its own: seats against use, and every licensed person's prompts scanned with your DLP policy and kept only as counts.
For most organisations this is the fastest thing to look at first, because one of its numbers is available before a single machine is enrolled: how many machines you manage that endlayer cannot see.
The credential is your app registration, not ours
You create the application in your directory, consent to it, and paste the tenant id, client id and a client secret into the console. App-only; nothing is delegated and no user signs in.
The alternative — one multi-tenant application owned by the vendor — is a nicer first five minutes and does not work for this product: a self-hosted deployment cannot share an application secret it does not have, and every customer's connector would depend on one registration in one directory that could then never be rotated.
The secret is sealed before storage and the console shows four characters, alongside its expiry so a connector about to lapse is visible before it lapses.
What it gives you
| The inventory gap | Your Intune records, reconciled against what has actually enrolled. Managed machines that never reported become a number somebody can act on — filterable by OS, compliance, ownership, and with Defender's last reported threat state per machine |
| Rollout from the console | Pick Entra device groups and push the agent. No script to transcribe, no secret to copy, and the install result is read back per device — so a rollout that half-worked says which half |
| Fleet lifecycle | Update fleet re-runs the rollout pinned to a newer version and upgrades below-version machines in place. Uninstall and reinstall push a maintenance script at chosen groups, or at one machine |
| The directory | A bounded mirror of people, so a device resolves to a department rather than a hostname — and leaver alerts: a disabled account whose machine is still reporting |
| What your tenant already consented to | Every application holding delegated OAuth access, classified and ranked by what its permissions could reach. "Which AI products can already read our mail and our files", asked of the tenant instead of the laptop |
Each capability is separately consented
Nine permissions, each probed against the token itself. A tenant that grants three gets exactly what those three unlock and is told what to grant for the rest. Grant none of the directory set and you keep a fully working Intune connector with no Entra views lit.
A missing figure renders as not available — never as zero, which would be a claim about your estate rather than about a permission. And a control panel appears only once the permissions behind it are confirmed present, rather than appearing to work and failing on submit.
Its limits, stated
- Reaches Windows client machines and Macs. Windows Server, Linux, containers and CI runners go through the ordinary rollout, which is also the route for Jamf, Kandji, Mosyle, Workspace ONE and SCCM. A mixed estate normally uses both.
- There is no Jamf API connection, and none is planned. Jamf already does device selection well.
- Disconnecting cleans up in your tenant — it unassigns and deletes the scripts endlayer created and revokes the secrets they carried. Enrolled machines keep reporting, because each holds a credential of its own.
Fuller treatment in the full documentation.