By the end of this you have a working handoff: the Defender side able to raise a tracked remediation request that lands as a security task in Intune, an endpoint administrator able to accept it and close it back, a documented exception register for the findings you decide not to fix, and a round-trip test that proves a real vulnerability travelled from a recommendation to a patched machine and returned as system-confirmed rather than somebody ticking a box. It also tells you the three places in this loop where no programmatic surface exists, because knowing that up front is what stops you designing an automation that cannot be built.
Before step 1. You need Intune Plan 1 and core Defender Vulnerability Management, which arrives with Defender for Endpoint Plan 2 or with the standalone vulnerability management licence. Nothing here needs the premium add-on except the optional application-blocking step at the end, which is marked. The Intune connector for Defender for Endpoint must already be live from the compliance gate build. On the Defender side you need a role carrying Remediation handling (manage) to raise requests and Exception handling (manage) to file exceptions, both of which sit in the Posture management group under Security posture in unified role-based access control. On the Intune side, the administrator who accepts tasks needs the Organization read permission to see the aggregated task pane. Devices must be Entra joined for the ticket option to apply.
Step 1: Turn on the connection that makes the ticket option exist
The Intune connector you built earlier carries the tenant relationship, but it is not what puts a ticket option on the remediation form. That comes from a separate advanced feature in the Defender portal named Microsoft Intune connection, which lives on the Advanced features page under Endpoints in the portal settings, and which is off by default. Turn it on and save the preference. Until you do, the option to open a ticket in Intune simply does not appear on the request form, and the usual diagnosis, that somebody lacks a permission, is wrong.
| Setting | Value | Why |
|---|---|---|
| Microsoft Intune connection (Defender portal, Advanced features) | On | The gate for the entire loop. Off by default, and with it off the ticket checkbox is absent rather than greyed out, which is why this fails silently. |
| Allow or block file (Defender portal, Advanced features) | On, only if you intend to block vulnerable applications | Application blocking works by writing file indicators. Without this feature the indicators are created and never enforced. |
There is no supported way to do this programmatically. No Microsoft Graph resource and no PowerShell cmdlet reads or sets any Defender advanced feature toggle, so this step is portal-only in every tenant you will ever build, and it belongs in your tenant build documentation rather than in a script somebody expects to be idempotent.
Step 2: Establish the baseline you are about to change
Capture the current state before you file anything, because the whole point of the test at the end is a before and after. The export assessment interfaces give you this in a form you can diff. Note the base address is the Defender service endpoint, and note that the software inventory export uses a different permission from the vulnerability exports, which is the single most common cause of an unexpected 403 in this family.
# Baseline: every device-to-CVE finding in the tenant.
# Permission: Vulnerability.Read.All (application) or Vulnerability.Read (delegated)
GET https://api.security.microsoft.com/api/machines/SoftwareVulnerabilitiesByMachine
# Baseline: installed software per device.
# Permission: Software.Read.All <-- NOT Vulnerability.Read.All. A 403 here is almost
# always this, not a broken app registration.
GET https://api.security.microsoft.com/api/machines/SoftwareInventoryByMachine
# The CVE you are about to work, with its exception state.
# status returns exactly one of: RemediationRequired, NoActionRequired,
# UnderException, PartialException
GET https://api.security.microsoft.com/api/vulnerabilities?$filter=id+eq+'CVE-0000-00000'Expected result is a JSON collection you can store and compare against later. The failure mode to watch for is a quietly truncated result set: the vulnerability interface caps at eight thousand records per call and the per-machine exports default to fifty thousand rows with a two hundred thousand ceiling, so a large estate that does not page is working from a partial baseline while everything looks successful. If you would rather diff daily than in full, the change-oriented variant takes a mandatory start time and will not look back more than fourteen days, returning each finding tagged as new, fixed or updated.
Step 3: Raise the request, and decide the three fields that matter
Open a security recommendation and choose its remediation options. The button carries two different labels across Microsoft's own current documentation, Request remediation on one page and Remediation options on another, so recognise the flyout by what it contains rather than by its caption. Inside it you pick a remediation type, set a due date, set a priority, tick the Intune ticket option, and write notes. Three of those are decisions rather than data entry.
| Setting | Value | Why |
|---|---|---|
| Remediation type | Software update, software uninstall, or attention required | Attention required is the honest choice when no fix exists. It produces a tracked item with no due date and no progress bar, which is correct: there is nothing to deploy and a due date would be theatre. |
| Open a ticket in Intune | Ticked | Creates the security task. The label still says AAD joined devices rather than Entra, which is naming lag and not a different scope. |
| Remediation due date | Your standard for the severity band, not the default | This date is the only service-level commitment in the record, and it is what a later audit reads. Set it from your policy. |
| Priority | High, Medium or Low | Read by the receiving team to order their queue. It is not read by the platform and changes nothing about enforcement. |
| Notes | Your naming convention, below | The only free-text field in the record and therefore the only place the request can be reconciled against your change system. |
Naming convention. The notes field is the sole place you control the vocabulary, so impose one and use it without exception: VULN-YYYYMM-nnn | owning-team | change-reference, for example VULN-202607-014 | EUC-Desktop | CHG0041882. Every remediation activity and every exception you file carries this, which means an export can be joined to your change record system, and an auditor asking who approved a piece of accepted risk gets an answer in one query rather than an archaeology project. Without a convention the notes field fills with sentences and the register becomes unqueryable within a quarter.
Two limits shape how you scope a request. A single request reaches at most ten thousand devices, and where a vulnerability affects more, the task covers ten thousand of them. Split by device group deliberately before that happens, because a truncation you chose maps onto the teams doing the work and a truncation the platform chose does not. And where a recommendation has no fix Intune can implement, no ticket is offered at all, which is documented behaviour rather than a fault. There is no published matrix of which recommendation types are routable, so treat the absence of the ticket option as the answer and route those through your normal change process instead.
Step 4: Worked example, including the part you do not fix
A third-party document reader is flagged with a vulnerability that carries a verified public exploit. It sits on fourteen hundred devices. Eleven hundred are ordinary corporate laptops. Three hundred sit in a manufacturing group under a change freeze that runs another six weeks. Splitting this into two decisions is the entire skill, and here is the mapping.
| Population | What you file | Exact values |
|---|---|---|
| 1,100 corporate laptops | Remediation request with Intune ticket | Type software update; priority High; due date at your exploited-vulnerability standard; notes VULN-202607-014 | EUC-Desktop | CHG0041882 |
| 300 frozen manufacturing devices | Partial exception scoped to that device group | Justification Planned remediation (grace); duration set to end shortly after the freeze lifts; notes VULN-202607-014 | OT-Ops | freeze CHG0041665 |
Two things about that second row are deliberate. Planned remediation is the accurate justification because you are not claiming a compensating control and you are not accepting the risk permanently; you are saying there is a date. And because exception durations cannot be extended, the expiry forces somebody to make the decision again in six weeks rather than letting a freeze quietly become a permanent posture. Do not reach for risk accepted here just because it is fewer keystrokes. Choosing the justification that matches what is actually true is what makes the register worth having.
Step 5: File the exception, and know what it does to the score
Exceptions are filed in the Defender portal and nowhere else. There is no public interface to create, amend or cancel one, at either the recommendation level or the individual vulnerability level, so an exception register cannot be bulk-loaded and cannot be automated into existence. Scope decides the label: choosing every device group produces a full exception, choosing some produces a partial one, and a global exception also covers device groups created later, which a per-group exception does not.
| Justification | Use it when | Effect on the score |
|---|---|---|
| Third party control | Another product genuinely mitigates this finding | Documented to reduce the score impact at recommendation level |
| Alternate mitigation | You have applied a compensating control yourself | Documented to reduce the score impact at recommendation level |
| Planned remediation (grace) | A fix is scheduled and dated | Not among the justifications documented to reduce impact |
| Risk accepted | You are choosing to live with it | Does not reduce impact, deliberately. Agreeing to the danger does not remove it. |
| CVE with no patch (vulnerability level only) | The vendor has shipped nothing | At vulnerability level the justification does not affect the impact score |
| False positive (vulnerability level only) | The finding is wrong | At vulnerability level the justification does not affect the impact score |
Do not carry the recommendation-level rule across to vulnerability-level exceptions. At the recommendation level the justification you pick changes what happens to the score; at the vulnerability level, current documentation says it does not affect the impact score at all. Allow up to an hour for exposed-asset counts and scores to reflect a new exception. You can confirm one landed without waiting for the portal, because the exception state is readable even though the exception itself is not writable.
# Confirm an exception took effect. Expect status to move from
# RemediationRequired to UnderException (full) or PartialException (scoped).
# Permission: Vulnerability.Read.All
GET https://api.security.microsoft.com/api/vulnerabilities?$filter=id+eq+'CVE-0000-00000'
# The remediation activity register. status is exactly Active or Completed.
# Permission: RemediationTasks.Read.All
GET https://api.security.microsoft.com/api/remediationTasks
# Which devices a given activity covers, for reconciliation against your CMDB.
GET https://api.security.microsoft.com/api/remediationTasks/{id}/machineReferencesThe failure mode here is expecting to write. These interfaces are read-only. There is no supported call that creates a remediation activity, and none that creates or cancels an exception, so any runbook that assumes it can raise these from a pipeline needs redesigning around a human in the portal.
Step 6: Work the task on the Intune side
The task arrives under Security tasks in Endpoint security, showing the requestor, the notes, the affected applications and the device count. It also now surfaces in the aggregated Admin tasks pane under Tenant administration, alongside privilege-management elevation requests and multi-admin approvals, which is the better place to operate from if your endpoint team works a single queue. Accept or reject it, with notes that travel back to the security team, then remediate through whatever mechanism you normally use, because the task deploys nothing by itself. When the work is done, choose Complete Task, which updates the status in both consoles.
| Setting | Value | Why |
|---|---|---|
| Remediation type on the task | Application or Configuration | Application tasks against managed apps carry actionable detail; against unmanaged apps Intune can only give text instructions, which is your signal that the app needs bringing under management first. |
| Accept or Reject | Decided by the endpoint team, with notes | This is the authority boundary made concrete. Rejecting with a reason is a legitimate outcome and should not be treated as a failure. |
| Complete Task | Only after the change is actually deployed | Completing on receipt rather than on completion is how the register stops meaning anything. |
The aggregated pane carries its own status vocabulary, active, pending, completed, rejected, expired and needs approval, and expired tasks are removed after thirty days. If you want to read the queue programmatically, a beta Graph surface exists for these task objects, exposing security configuration and application vulnerability task types with a status enumeration of unknown, pending, active, completed and rejected. Treat it as a reporting read and nothing more: it is a partner integration surface, it is beta rather than generally available, and the intended producer of these objects is Defender itself.
# Read the security-task queue. Beta only; no v1.0 equivalent exists.
# Permission: DeviceManagementApps.Read.All. Requires an active Intune licence.
GET https://graph.microsoft.com/beta/deviceAppManagement/deviceAppManagementTasksStep 7: Optional, and premium only, block while you wait
If you hold the premium add-on and the finding has no fix or no window, the same flyout offers a mitigation rather than a remediation. Blocking generates file indicators on the vulnerable executables so the estate refuses to run them; warning does the same but lets a user push past temporarily. Enforcement takes up to three hours in either direction, so this is a containment measure and never an incident response. It is Windows only, it will not touch Microsoft's own applications or store applications or operating-system recommendations, and it blocks the named executable rather than the product, so an application's separate updater keeps running. Watch your indicator headroom: the tenant ceiling is fifteen thousand file indicators, and while blocks created since December 2024 generate fewer of them, a broad blocking policy is still capable of consuming capacity you wanted for threat intelligence.
The prerequisite that decides whether this works at all is Defender Antivirus running in active mode with cloud-delivered protection on. Passive mode cannot enforce a file indicator and neither can detection and response in block mode. A tenant that runs a third-party engine primary has bought this capability and cannot fire it.
Step 8: Prove the loop end to end
One round trip, on one pilot device, with timings you can hold people to. Pick a device carrying a genuinely outdated third-party application that you control and can update on demand. Then run this sequence and record each observation rather than assuming it.
Confirm the finding exists for that device in the baseline export from step 2. Raise a remediation request scoped to a device group containing only that device, with the Intune ticket ticked and notes carrying your convention. Confirm the task appears under Security tasks in Intune, accept it, and confirm the acceptance is visible back on the Defender side. Update the application on the device by your normal mechanism. Now wait properly: software changes take about two hours to reflect, and software inventory refreshes every three to four hours with no way to force it. Re-run the inventory and vulnerability exports and confirm the finding is gone for that device. Then confirm the remediation activity closed with a completed-by value of system confirmation rather than a person's address, which is the only completion signal in this product backed by evidence rather than assertion. Finally, and separately, check the exposure score no earlier than the next day, because it recalculates daily with up to twenty-four hours of lag and its movement is explicitly not guaranteed to be monotonic. A score that did not fall does not mean the test failed.
If you want the same evidence as a query rather than an export, hunt it. The vulnerability management tables are the durable surface here, and the one caveat worth knowing is that they are not ingested into Sentinel: the schema is visible there for validation but queries return no rows, so run this in the Defender portal.
// Before and after evidence for one device and one CVE.
// Run in Defender advanced hunting. Returns rows before remediation, none after.
DeviceTvmSoftwareVulnerabilities
| where DeviceName =~ "pilot-lt-014"
| where CveId == "CVE-0000-00000"
| project DeviceName, SoftwareName, SoftwareVersion, CveId, VulnerabilitySeverityLevel
// If you drive this from a pipeline, call it through Graph, not the legacy
// endpoint: the old advancedqueries/run and advancedhunting/run interfaces
// stop returning data on 1 February 2027.
// Permission: ThreatHunting.Read.All
POST https://graph.microsoft.com/v1.0/security/runHuntingQueryThe three walls, stated plainly
A build sheet earns trust by naming what it cannot do. There is no supported interface for the advanced feature toggle in step 1, so tenant build automation stops at the portal. There is no interface to create a remediation activity, so the request in step 3 is always a human action. And there is no interface at all for exceptions, in either direction, so the register in step 5 is portal-only by design. Everything programmatic in this loop is a read. If you were planning to automate risk acceptance, the platform has already decided against it, and on reflection I think it is right.
That closes the remediation half of this pillar. What it does not answer is which of these findings matters most, because a queue ordered by severity still treats every machine as equivalent. The product that arranges your weaknesses the way an attacker would use them is next, at Security Exposure Management.
Defender XDR
‹ Previous: [D 6.1] Recommendations to Remediation: Who Owns the Fix
Next: [D 6.2] Security Exposure Management: The Attacker’s Map of Your Tenant ›
