Discover
Defender identifies vulnerable software, weaknesses, missing configuration, affected devices, threat context, and security recommendations.
Defender Vulnerability Management • exposure triage • IT ownership • validation evidence
Defender for Endpoint Vulnerability Remediation Workflow Guide
A vulnerability remediation workflow turns Defender exposure data into owned, scheduled, tested, and verifiably completed change. This guide connects Microsoft Defender Vulnerability Management recommendations to business-aware prioritization, Intune security tasks, application and infrastructure owners, change windows, exception governance, and closure evidence.
Risk-based prioritizationDefender-to-Intune handoffPatch and configuration executionValidation and exceptions
Operating objective
Make every exposure finding an accountable business decision
Defender Vulnerability Management continuously discovers software, weaknesses, exposed devices, security recommendations, and remediation opportunities. That visibility is valuable, but it is not the same as remediation. A recommendation can remain open because ownership is unclear, the affected application is unmanaged, the change window is months away, a vendor has no fix, a deployment failed on part of the fleet, or the organization accepted risk without creating a governed exception.
The workflow must therefore bridge two operating worlds. Security explains exploitation risk, affected assets, campaigns, and potential exposure reduction. IT and application teams explain deployment tooling, compatibility, business windows, rollback, and asset lifecycle. Change management authorizes the work, service owners accept disruption or residual risk, and security verifies that the exposure actually changed after implementation.
Control statement: Every material recommendation or CVE must have a scope, risk rationale, accountable owner, action type, target date, deployment method, test ring, change/rollback record, validation evidence, residual-risk decision, and recurring review until closure.
Workflow architecture
Separate finding, request, execution, and verification
Prioritize
Security adds exploit activity, asset criticality, exposure path, business impact, fix maturity, and operational urgency.
Assign
Create a remediation activity, optional Intune security task, change record, responsible team, due date, and acceptance criteria.
Execute
Patch, upgrade, uninstall, reconfigure, isolate, block, or apply a temporary mitigation through the appropriate management tool.
Validate
Confirm endpoint state, telemetry refresh, recommendation impact, failed-device ownership, exception scope, and evidence retention.
Critical distinction: Microsoft states that submitting a Defender remediation request creates a remediation activity; it does not automatically apply changes. If the Intune connection is enabled and the task option is selected, Intune receives a security task that an administrator still needs to accept or reject and act on.
Prioritization model
Rank work by attack likelihood and business consequence
Do not sort exclusively by CVSS, exposed-device count, or exposure-score impact. A medium-severity weakness on an internet-facing identity server with active exploitation can outrank a high-severity issue on an isolated test workstation. Conversely, a recommendation that affects thousands of endpoints may produce large score impact but require application testing, bandwidth planning, and multiple maintenance waves.
Immediate / criticalSignals: active exploitation or campaign linkage, zero-day, internet-facing or privileged asset, broad credential or remote-code impact, no meaningful compensating control.Action: incident-style ownership, rapid mitigation or block, emergency change, explicit executive/service-owner awareness, daily validation.
Accelerated / highSignals: reliable exploit, high-value device group, common vulnerable version, material security recommendation impact, available and tested fix.Action: short due date, pilot ring, formal rollout, failure queue, scheduled verification, temporary mitigation if deployment cannot finish quickly.
Planned / governedSignals: lower exploitability, limited scope, strong compensating controls, complex change, vendor dependency, or low-confidence applicability.Action: normal change cadence, documented owner, time-bound exception if appropriate, vendor tracking, periodic re-prioritization.
| Decision factor | Evidence to capture | Why it changes priority | Common mistake |
|---|---|---|---|
| Threat and exploit activity | Exploit availability, active campaign or zero-day tags, incident correlation, vendor/CISA guidance | Raises near-term likelihood beyond a static severity score | Treating every CVE with the same CVSS as equally urgent |
| Asset and identity value | Device group, role, data handled, privileged access, business service, external reachability | Changes blast radius and business consequence | Prioritizing endpoints without knowing what they support |
| Exposure breadth | Unique devices, versions, locations, stale/offline assets, unmanaged installations | Determines execution scale and probability of partial failure | Using raw event or record counts instead of unique assets |
| Fix and mitigation quality | Vendor patch, configuration change, uninstall, workaround, block capability, rollback | Determines how quickly risk can be reduced safely | Assuming an available patch is deployment-ready |
| Operational constraint | Change freeze, application testing, bandwidth, maintenance window, clinical/industrial uptime | Changes feasible due date and requires interim controls | Setting deadlines without an executable deployment plan |
| Confidence and applicability | Software evidence, vulnerable version, package source, false-positive signals, device sample | Avoids disrupting systems for a finding that does not apply | Creating broad exceptions before validating the evidence |
Ownership and service design
Use clear handoffs without handing off accountability
Security / exposure management
Confirm the finding, enrich threat context, define priority and acceptable residual risk, create the remediation request, monitor activity, and validate the resulting exposure change.
Endpoint / Intune operations
Accept or reject the security task, choose the supported deployment mechanism, test packages and policies, execute rings, manage failures, and return implementation evidence.
Application or platform owner
Validate compatibility, business windows, vendor guidance, dependencies, rollback, and service impact. Own upgrades or replacements that endpoint tooling cannot perform safely.
Service and change owner
Authorize timing and disruption, approve exceptions or residual risk at the correct level, ensure communications and support readiness, and prevent overdue items from becoming invisible.
Handoff rule: A rejected Intune security task does not eliminate the vulnerability. The rejecting administrator must document why the task cannot be executed as requested, identify a capable owner or alternative tool, and return the item to triage with a revised plan or risk decision.
Implementation runbook
Move from recommendation to verified closure in twelve steps
Normalize the finding
Capture the recommendation and related CVEs, affected product and versions, remediation guidance, exposed devices, device groups, threat context, discovery time, and data freshness. Sample devices to confirm applicability.
Map assets to business services
Enrich device records with owner, criticality, location, internet exposure, privileged function, application dependencies, maintenance constraints, and replacement status. Put unknown ownership into its own remediation queue.
Prioritize and set the clock
Use threat likelihood, business consequence, affected scope, fix maturity, and compensating controls. Assign a priority and achievable due date; define escalation points before the item becomes overdue.
Select the remediation action
Choose software update, operating-system update, uninstall, configuration correction, application block, other mitigation, or attention required. For a zero-day without a fix, create an attention item and track workarounds and vendor updates.
Create the activity and task
Submit the Defender remediation request with priority, due date where applicable, notes, scope, and action. If the Defender–Intune connection is enabled and supported, create the Intune security task. Link the activity to the change or service ticket.
Accept, clarify, or reroute
The implementing team reviews the request, validates the device list and tool, then accepts or rejects it with evidence. Unmanaged applications, non-Intune devices, or unsupported actions must be assigned to another owner rather than abandoned.
Design pilot rings and rollback
Build lab, champion, representative, and broad rings. Define success signals, failure thresholds, rollback package or policy, communication, maintenance window, and emergency owner.
Execute the smallest safe wave
Deploy the update, configuration, uninstall, or mitigation to the first ring. Preserve logs and package/policy versions. Keep unrelated endpoint changes out of the same window so failures remain attributable.
Validate functionality and security
Confirm installation or effective configuration, device health, service workflows, reboot state, telemetry, and absence of material regression. Retest the vulnerable condition or recommendation where a safe method exists.
Expand and manage failures
Promote to the next ring only after the gate passes. Separate transient failures, stale/offline devices, unsupported systems, incompatible applications, and permanently unmanaged assets into owned queues.
Reconcile Defender evidence
Allow for telemetry and score recalculation, then compare exposed devices, recommendation state, software versions, and residual CVEs. Investigate devices that remain exposed rather than closing from deployment-console success alone.
Close, except, or continue
Mark complete only when acceptance criteria are met. Create a time-bound recommendation or CVE exception for approved residual scope, or keep the activity open with revised owner, milestone, and mitigation.
Defender and Intune handoff
Build a task that an implementation team can actually execute
Microsoft's remediation request asks what should be remediated, whether to open an Intune ticket, priority, due date, and notes. If the action is “attention required,” there is no specific device action to track and therefore no due date or progress bar in the same way. Use that option for conditions such as a zero-day without an available fix, but create an internal milestone for mitigation review so “attention” does not become an indefinite holding state.
The Defender-to-Intune integration requires the Intune connection to be enabled in Defender endpoint advanced features. Intune administrators can accept or reject security tasks and, after executing the work, mark the task complete so status synchronizes back. A request can cover no more than 10,000 devices in the Intune handoff; larger exposure scopes need segmentation and separate control of the residual population.
Retention boundary: Microsoft states that completed remediation activities are retained on the Remediation page for 180 days before removal. Export or preserve the evidence required for audit, incident lessons, compliance, or long-term metrics outside that temporary activity view.
Execution patterns
Match the remediation type to the system that owns the change
| Remediation type | Typical implementation | Validation | Rollback or residual path |
|---|---|---|---|
| Application update | Intune app supersedence, enterprise patch platform, vendor updater, package deployment | Installed version, process/file evidence, app launch, business workflow, Defender refresh | Previous package, uninstall, application-owner exception, compensating block |
| Operating-system update | Windows Update for Business, Autopatch, Configuration Manager, server maintenance | KB/build, reboot status, update compliance, service tests, residual device scope | Known Issue Rollback/uninstall where supported, defer ring, isolate high-risk failures |
| Configuration correction | Intune endpoint security policy, settings catalog, GPO, Defender policy, script | Effective setting on device, conflict state, functional/security test, recommendation update | Policy version rollback, narrower scope, documented platform exception |
| Software uninstall or replacement | Managed uninstall, script, service-owner project, procurement/lifecycle work | Absence of vulnerable version, replacement availability, workflow continuity, inventory refresh | Reinstall approved version, alternate application, risk acceptance during migration |
| Temporary vulnerable-app block | Supported Defender Vulnerability Management mitigation or application-control mechanism | Known vulnerable versions blocked on applicable endpoints, business impact, indicator capacity | Unblock after patch; use another control when application/OS/platform is unsupported |
| Attention required | Vendor monitoring, workaround, isolation, feature disablement, incident watch | Mitigation evidence, owner check-in, vendor status, threat review | Convert to an actionable update when a fix appears or create a governed exception |
Blocking boundary: Microsoft describes vulnerable-application blocking as a best-attempt mitigation that depends on Defender Antivirus and is not supported for every recommendation, operating system, platform, Microsoft application, or Store app. Treat it as temporary risk reduction—not proof that the vulnerability has been removed.
Status model
Use states that expose stalled work instead of hiding it
Finding captured; applicability, owner, scope, and priority not yet confirmed.
Remediation activity created; implementing team has not accepted or clarified the request.
Owner, action, rings, change window, due date, rollback, and acceptance criteria are approved.
Change is moving through rings; failures and exceptions are actively managed.
Implementation reports success; Defender and sampled endpoint evidence are being reconciled.
Acceptance criteria met; residual devices have separate owners; evidence and lessons are preserved.
Approved residual risk has defined type, scope, justification, duration, controls, and review owner.
Milestone or due date missed; service owner has an explicit decision and interim risk treatment.
Validation and closure
Close on reduced exposure—not on a green deployment job
Three proof layers for closure
Use all three layers. A console can report success while endpoints remain stale, excluded, offline, incompatible, or vulnerable through a different package.
1. Implementation proof
Package or policy version, targeted scope, deployment results, reboot state, failures, rollback readiness, and functional tests.
2. Endpoint proof
Sampled software/version or effective configuration, device health, process/file evidence, application workflow, and telemetry timestamps.
3. Exposure proof
Recommendation/CVE state, residual exposed devices, device-group impact, exception effects, trend comparison, and owner for every remaining asset.
Exposure score is a directional prioritization and trend metric, not a closure artifact by itself. Microsoft notes that it recalculates daily and that changes can take up to 24 hours after remediation. Record the measurement window, avoid claiming immediate causality from a single score change, and use the underlying recommendation and device evidence to explain the outcome.
Success gate
Intended device percentage remediated, no critical workflow regression, telemetry current, recommendation impact reduced, and failed devices in an owned queue.
Partial gate
Broad change succeeded but offline, incompatible, unmanaged, or exception devices remain. Keep a child activity or residual work item rather than hiding them in a note.
Rollback gate
Business or technical failure exceeds threshold. Roll back the affected ring, preserve evidence, apply interim mitigation, and revise the package or policy.
Exception governance
Use the smallest defensible exception for the shortest defensible time
Microsoft supports recommendation exceptions and CVE exceptions. A recommendation exception excludes the broader security recommendation and can affect all underlying CVEs, while a CVE exception addresses a specific vulnerability. Both require appropriate permissions and should be scoped globally only when the risk decision truly applies to the entire organization. Device-group exceptions are safer for constrained business cases.
Microsoft states that exceptions are effective only for their specified duration and scope. Durations cannot be extended; if risk must remain accepted after expiry, create a new exception with refreshed justification and approval. Future device groups are not automatically included in an existing device-group exception, which is useful for containment but requires administrators to review organizational changes.
Reporting consequence: Exceptions change what appears active and can change exposed-device and impact views. Report both gross exposure and exposure after exceptions so leadership can see risk that was accepted rather than mistakenly concluding that it was technically removed.
Top risks and common misconfigurations
Failures that make remediation look better than it is
A request is treated as a fix
Submitting a Defender activity or Intune task does not patch devices. Work stays exposed while status appears administratively active.
Score impact replaces risk context
Teams chase the largest potential score change and miss actively exploited weaknesses on high-value or internet-facing assets.
Unknown owners disappear
Devices without business or technical owners fall outside every team's queue. Unknown ownership must itself be an escalated remediation category.
One task covers over 10,000 devices
The Intune handoff reaches only the documented limit, while the residual population is omitted from progress and closure assumptions.
Deployment success closes the item
Portal or package success is accepted without endpoint sampling, Defender refresh, or reconciliation of remaining exposed devices.
Rejected tasks have no return path
Intune rejects an unsupported or unmanaged application request and security assumes another team owns it; no alternative owner is assigned.
Global exceptions hide broad risk
A recommendation is excluded organization-wide for a problem limited to one device group or one CVE.
Temporary mitigation becomes permanent
An application block or workaround reduces urgency, but no one schedules the patch, replacement, or mitigation removal.
Offline devices vanish from closure
Stale, retired, traveling, or intermittently connected devices are excluded from the denominator without disposal or recovery evidence.
Evidence expires with the portal item
Completed activities age out after 180 days, leaving no durable record for audit, metrics, or recurring-failure analysis.
Metrics and review cadence
Measure flow, residual risk, and verification quality
| Cadence | Review | Evidence | Decision |
|---|---|---|---|
| Daily | New critical/actively exploited findings, zero-days, internet-facing scope, overdue emergency work | Recommendation/CVE export, threat context, incident links, owner queue | Mitigate, create emergency change, assign executive/service owner, or escalate. |
| Weekly | Pending/rejected tasks, ring progress, failure queues, stale devices, upcoming due dates | Remediation activity and Intune task status, deployment reports, change tickets | Clarify, reroute, repair package, expand ring, or revise target date. |
| Monthly | Exposure trend, gross vs after-exception exposure, age, ownership, validation sampling | Exposure score context, recommendation state, exception register, residual devices | Reprioritize portfolio and resolve systemic bottlenecks. |
| Quarterly | Exception expiry, compensating controls, tool coverage, evidence retention, SLAs | Exception exports, control tests, owner approvals, archival package | Cancel, renew with new approval, narrow scope, or launch replacement work. |
| After material change | Application upgrade, policy migration, device-group change, vendor advisory, exploit update | Before/after inventory, device samples, threat review, test result | Reopen, accelerate, or close based on refreshed evidence. |
Time to ownership
Median time from first material finding to accountable security, IT, application, and service owner.
Time to risk reduction
Median time to verified mitigation or remediation by priority—not time to task creation.
Residual exposure
Unique exposed devices remaining after deployment, including offline, failed, unmanaged, and excepted scope.
Closure quality
Percentage of completed activities with implementation, endpoint, and exposure proof plus durable evidence.
Troubleshooting
Diagnose stalled or inconsistent remediation with evidence
Security task does not appear in Intune
Verify the service-to-service Defender/Intune integration, the Defender Intune connection, device onboarding and management path, supported remediation type, permissions, and synchronization time. Confirm the request actually selected the Intune task option.
Task complete but devices remain exposed
Check actual versions or effective configuration, reboots, supersedence, multiple software packages, stale telemetry, offline devices, partial scope, and failed deployments. Allow the documented reporting window, then reopen residual devices with owners.
No security recommendation for a CVE
A supported security update might not exist for the affected software/version, or the package might be unsupported. Use weakness/CVE evidence, vendor guidance, mitigation, lifecycle replacement, support request, or a time-bound CVE exception.
Recommendation conflicts with business workflow
Validate the applicability on sampled devices, reproduce the impact, involve the application owner, test alternate configuration or version, and use a device-group exception only after compensating controls and expiry are approved.
Exposure score moves unexpectedly
Review model or inventory changes, new devices, new recommendations, exceptions, telemetry freshness, and the daily recalculation window. Explain the underlying recommendation changes rather than treating score movement as self-explanatory.
Remediation has no capable tool
Route to application packaging, server management, RMM, software vendor, cloud platform, procurement, or service replacement. Keep Defender as the risk and verification record even when Intune is not the execution tool.
This guide is for implementation planning and initial validation. It does not replace a professional vulnerability assessment, penetration test, cybersecurity audit, application compatibility test, incident investigation, compliance assessment, or legal/compliance review.
Related architecture and authoritative resources
Connect remediation to endpoint, patch, and risk operations
IT Perfection guides and services
Microsoft Defender for Endpoint Configuration Guide — onboarding, sensor, policy, and operations foundation Defender Device Grouping and RBAC — scope recommendations and permissions by device group Attack Surface Reduction Pilot Guide — deploy preventative behavior controls through rings Microsoft Defender XDR Operations Guide — route active threat evidence into incident response Third-Party Application Patch Management — package, deploy, validate, and report non-Microsoft updates Infrastructure Vulnerability Remediation Roadmap — coordinate broader servers, network, cloud, and lifecycle work Free Endpoint Security Assessment — review the surrounding endpoint control baseline Endpoint Security Support — managed deployment, monitoring, and remediation assistance About Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experienceCurrent Microsoft guidance
Remediate vulnerabilities — requests, activities, Intune tasks, status, and retention Use Intune security tasks — accept, execute, complete, and synchronize work Security recommendations — exposed devices, impact, remediation, and inaccuracy reporting Vulnerabilities in the organization — CVE details, updates, and related recommendations Vulnerability Management exceptions — types, justifications, and scope Create and manage exceptions — duration, device groups, impact, and cancellation Exposure score guidance — prioritization and recalculation timing Block vulnerable applications — temporary supported mitigation boundariesFrequently asked questions
Defender vulnerability remediation workflow FAQ
What does a Defender vulnerability remediation request actually do?
Submitting a remediation request creates a trackable remediation activity in Defender Vulnerability Management. When the Intune connection is enabled and the option is selected, it can also create an Intune security task. Microsoft states that the request itself does not patch, uninstall, or reconfigure devices; IT administrators still approve or reject the task and execute the change.
How should vulnerability remediation be prioritized?
Combine exploit activity and threat intelligence with exposed-device count, internet reachability, asset criticality, business impact, fix availability, compensating controls, operational window, and confidence in the evidence. Exposure-score impact is useful, but it should not replace asset and threat context.
When is a remediation activity complete?
Complete the activity only after the change is deployed to the intended scope, sampled devices show the expected software or configuration state, Defender telemetry updates, the recommendation or CVE exposure decreases as expected, failed devices have owners, and rollback or residual risk is documented.
What is the difference between a recommendation exception and a CVE exception?
A recommendation exception excludes the security recommendation and its underlying scope from the remediation view, while a CVE exception targets a specific CVE. Microsoft supports duration, justification, and device-group scope; exceptions should be time-bound, approved, and paired with compensating controls.
Can Intune security tasks remediate every vulnerability?
No. Intune tasks can coordinate supported application or configuration work, but some software is unmanaged, some fixes require another deployment tool, and some issues have no available patch. Use the task as the accountability record, then route execution through the tool and owner capable of making the change.
Why might exposure score not change immediately after remediation?
Microsoft indicates that exposure score recalculates daily and recommends allowing up to 24 hours after remediation for the score change to appear. Validate endpoint state and recommendation data first; do not reopen or duplicate work solely because the score has not updated immediately.
Practical exposure reduction
Need a remediation process that closes the loop?
IT Perfection helps Orange County and Southern California organizations connect Defender exposure data to accountable owners, Intune and patch operations, safe deployment rings, exception governance, validation evidence, and executive reporting.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
