Fixes get provenPatch verification
Microsoft Intune
Reads which updates are actually installed on your managed devices, so a finding closes on evidence that the patch landed rather than on somebody saying it did.
What the connector does
- Managed device inventory and update state, read-only
- CVE-to-KB mapping, so a vulnerability can be checked against an installed update
- Device identity reconciled with the platform's own assets
- Nothing is deployed, assigned or remotely triggered from here
Credential required
An Entra ID application with DeviceManagementManagedDevices.Read.All. No write permission is requested or used.
What this connector is for
The last step of the remediation loop is proof. For a host vulnerability, the proof is that the update which fixes it is installed — and Intune already knows. Reading that removes an entire category of false closure: the ticket marked done, the patch that never deployed, the finding that reappears next month as if it were new.
What is read
Managed devices and their update state. Nothing else, and nothing at all is written: this connector does not create deployments, assign policies or trigger sync on a device. That restriction is structural rather than a setting — the client it uses has no method that writes, and a test asserts it.
What happens next
An update is matched to the CVEs it addresses. A finding whose CVE is covered by an update the device reports as installed becomes a verified close, with the patch identifier recorded against it. A finding whose patch is missing stays open regardless of what any ticket says, which is the whole reason to look.
What you have to grant
An Entra ID app registration with a single read scope. The permission list is short on purpose: an integration that reads device inventory and an integration that can push software to every laptop in the company are not the same risk, and this is the first one.