Intune Vulnerability Remediation Agent: Applied Is Not Fixed
Your dashboard says Applied. Your devices may still be exposed. In the Intune Vulnerability Remediation Agent, Applied is only an administrator’s attestation—the agent does not remediate anything.
AI can prioritize risk and guide the response, but endpoint teams still own deployment, validation, and measurable risk reduction. The label is not the outcome.
The Problem
Defender Vulnerability Management can surface more CVEs than an endpoint team can address at once. The agent analyzes that data, prioritizes suggestions, summarizes impact, lists exposed devices, and provides step-by-step Intune guidance.
That accelerates triage. It does not prove that a package deployed, a setting applied, a CVE disappeared, or the exposure score improved.
The Nugget
Apply five guardrails to an Intune Vulnerability Remediation Agent pilot:
| Guardrail | Evidence required |
|---|---|
| Scope | Agent identity covers the intended Defender device groups |
| Prioritization | Severity, exploitability, exposure, business criticality, and compensating controls reviewed |
| Execution | Named remediation owner and an approved Intune deployment path |
| Verification | Device status, app or OS version, Defender exposure, and failure population checked |
| Record | Suggestion, decision, deployment, exception, and post-change evidence retained |
Only mark a suggestion Applied after the remediation evidence exists. Treat the status as a control record, not a workflow shortcut.
Why This Matters
Current Microsoft Learn documentation describes a limited public preview for selected customers. The agent requires Intune Plan 1, Microsoft Security Copilot capacity, and Defender Vulnerability Management. It supports Windows clients and Intune apps in the public cloud, not Windows Server or government clouds.
Scope deserves extra attention. The assigned identity must have access to the relevant Defender device groups. The preview does not support Intune scope tags, and Microsoft warns that suggestion data can be visible to admins who can access the agent even when it falls outside their assigned Intune roles or scope.
Logging is also limited. Security Copilot logs capture management and permission failures, but not discovered vulnerabilities or the moment a remediation is marked Applied. Build your own evidence chain in the change or vulnerability-management system.
The agent runs manually, cannot be stopped after starting, and its authorization can expire after 90 days without a run. Those are operational dependencies, not footnotes.
What Admins Should Do
- Confirm preview access, licensing, plugins, roles, and Defender device-group scope.
- Select one known application or Windows CVE for the pilot.
- Compare the agent priority with Defender exposure and business context.
- Deploy remediation through a test ring, then a staged production ring.
- Verify version, installation, device failures, and remaining exposure.
- Mark Applied only after evidence is attached to the remediation record.
Keep security and endpoint ownership explicit. Defender can identify risk; Intune can deliver change; one named owner must confirm the result across both systems.
Verification Path
Before and after remediation, export the affected device set and capture the software or OS version. Reconcile that with Intune deployment status and Defender vulnerability data. Investigate every device that remains exposed or fails to report.
Pro Tip
Track the delta, not the label. The useful KPI is the reduction in exposed, business-relevant devices after remediation – not the number of suggestions marked Applied.