The first time an analyst clicks Request remediation and then watches nothing happen, they file a support ticket. Nothing happened because nothing was supposed to happen. Submitting the request does not trigger remediation and does not apply any change to any device, and Microsoft’s own instructions tell the person who filed it to go and tell the IT administrator themselves. Read as a product defect this is embarrassing. Read as what it actually is, a formalised handoff across the boundary between the organisation that finds problems and the organisation that is allowed to change machines, it is the most honest thing in the console. Where you draw that boundary is the design decision. The button is just where it becomes visible.
Two streams, and knowing which number you are moving
Recommendations arrive in two kinds and they are not interchangeable. Software update recommendations say a version is vulnerable and a newer one is not, and acting on them moves the exposure score. Configuration change recommendations say a setting is wrong, and acting on them moves Microsoft Secure Score for Devices. Because those two scores are calculated independently and run in opposite directions, a remediation programme that only ever ships patches will watch one number improve while the other sits still, and a team that reports whichever number moved that month is not measuring anything. Decide up front which stream your programme is actually funded to work, and report that one honestly rather than picking the flattering figure each quarter.
The ordering of that queue changed materially in June 2026. Prioritization now weights exploit prediction alongside severity, so a medium-severity vulnerability with a live exploit outranks a critical one nobody has ever weaponised. It factors in whether the asset faces the internet, and it factors in whether you have told the platform the asset is critical, which is a genuinely new dependency because it means the quality of your prioritization is now partly a function of work you did somewhere else entirely. An estate that has never classified a critical asset is getting an ordering computed from defaults. That is worth knowing before anyone concludes the tool has bad judgement.
Expectations about timing need setting at the same moment, because this is where trust is usually lost. A software change on a device typically takes about two hours to appear in the portal, and configuration changes take anywhere from four to twenty-four. Software inventory refreshes every three to four hours and there is no way to force a synchronisation. The exposure score is slower still: it recalculates daily, with up to twenty-four hours before a remediation shows up in it, and Microsoft says explicitly that movement is not guaranteed to be monotonic, because newly published vulnerabilities offset the work you just did. A team that patches on Tuesday and expects a lower score on Tuesday afternoon will conclude the product is broken. It is not. It is slow on purpose, and a programme built on daily score-watching is a programme built on noise.
The handoff, and what it refuses to do for you
What the request actually creates is a tracked activity: a record with a priority, a due date, notes, a progress bar and an export, sitting on a remediation page that both organisations can see. That is a work order. It is not an instruction, and the platform is careful never to pretend otherwise. There is no approval that reaches back and changes a device. There is no deployment attached. The endpoint team receives something they must choose to accept, and then they do the actual work through whatever mechanism they already use, because the task itself deploys nothing.
The absence people find hardest to accept is the notification. Filing a request does not tell anyone. Microsoft’s documented step is that you notify your administrator and have them go and look, which in a mature organisation means the request is a record of a conversation rather than a substitute for one. I have seen two failure modes from teams who did not internalise this. The first is a security team that files two hundred requests, reports a remediation programme in flight, and is genuinely surprised six weeks later that the queue is untouched. The second is subtler and worse: an endpoint team that treats the queue as the authoritative work list, checks it periodically, and therefore silently deprioritises everything the security team raised by email instead. Both are governance failures wearing a product costume.
The request is a record of a conversation, not a substitute for one. Nothing in the product will have that conversation for you.
There is a hard limit worth designing around. A single request reaches at most ten thousand devices, and where a vulnerability affects more, the resulting task covers ten thousand of them. For most estates this never bites. For the ones where it does, it bites precisely on the recommendations that matter most, because the vulnerability sitting on every machine you own is the one that exceeds the cap. Split those by device group deliberately rather than letting the platform truncate for you, and you also get a queue that maps onto the teams who will actually do the work.
The completion signal is the part I trust and the part I tell clients to build their reporting on. An activity can be completed by a named person, which means somebody asserted it was done, or by system confirmation, which means the platform re-assessed and found every exposed device remediated. Those are not the same claim and should never be aggregated into one completion percentage. Human completion is a statement of intent. System confirmation is evidence. Completed activities are retained for a hundred and eighty days, which is your audit window and also, in practice, the reason to export anything you will need to defend beyond two quarters.
Exceptions, which is where governance actually lives
Every real programme accepts risk, and the interesting question is whether it does so on the record. Exceptions exist at two levels here. A recommendation exception suppresses a recommendation, either globally or for chosen device groups, and the recommendation’s state changes to full or partial exception accordingly. A vulnerability-level exception, which reached general availability in December 2025, does the same for an individual common vulnerability and exposure identifier, and it added a false-positive justification that the recommendation level does not have. Both require an explicit permission to file, which is the right shape: accepting risk should be a privilege somebody holds deliberately.
The justification set is where the design intent shows. You can claim a third-party control, an alternate mitigation, a planned remediation with a grace period, or a plain risk acceptance, and at the vulnerability level you can additionally say there is no patch or that the finding is a false positive. What separates these is what they do to the score, and this is the detail I most often find stated wrongly. For recommendation exceptions, the justifications that assert a compensating control, third-party control and alternate mitigation, are the ones documented to reduce the score impact. A plain risk acceptance does not, and that asymmetry is deliberate and correct: you have not made the estate safer by agreeing to live with the danger, and a scoring model that let you pretend otherwise would be worthless. At the vulnerability level the behaviour is different again, and the current documentation says the justification does not affect the impact score at all. Do not carry the recommendation-level rule across to vulnerability-level exceptions.
Two mechanics keep the register honest. Durations are mandatory and cannot be extended, so an exception that runs out has to be filed again with a fresh justification by somebody who still holds the permission. That is an expiry that forces a re-decision rather than a renewal nobody reads, and it is the single best governance property in this product. There is no documented maximum duration, so the discipline has to come from your own standard rather than a ceiling the platform enforces. And exceptions are managed only in the portal, with no public application programming interface to create them, which means the register cannot be automated into existence and cannot be quietly bulk-loaded. For once, a missing interface is doing useful work.
The cases where there is nothing to hand off
Not every finding has a fix, and the product is unusually straight about that. A zero-day carries its own tag across the console and, where the vulnerability has not yet been assigned an identifier, an internal temporary name. Its recommendation is attention required rather than update, and attention required is a state with no due date and nothing deployable, because there is nothing to deploy. Workarounds appear where the vendor has published them. When a fix ships the recommendation converts to an update, gains a label marking it as a security update for a zero-day, and the tag disappears from every page. That lifecycle is worth explaining to anyone who reports on this queue, because a growing count of attention-required items is not a growing backlog of unfixed work. It is a count of things the industry has not fixed yet, and treating it as team performance will make your team miserable for no reason.
The premium tier offers one stopgap for exactly this situation, and it is worth understanding as a mitigation rather than a remediation. Blocking a vulnerable application generates file indicators against the vulnerable versions’ executables so the estate refuses to run them, which buys time when there is no patch or no maintenance window. It is Windows only, best effort, and executable-scoped, so an application’s separate updater keeps running. It cannot touch Microsoft’s own applications, operating-system-level recommendations, or store applications. Warning rather than blocking lets a user push through temporarily. Enforcement can take up to three hours in either direction, so it is not an incident-response control. And the dependency named in the anchor article decides whether you can use it at all: indicator enforcement needs Defender Antivirus in active mode, which means the tenant that runs a third-party engine and keeps Defender passive has bought a capability it cannot fire. That is the active-versus-passive decision reaching forward to constrain a product two pillars away, which is how architecture usually works and why the endpoint block came first.
Where to put the seam
All of this reduces to one design question. The platform assumes two organisations and gives you a formal interface between them, so you have to decide what sits on each side. My position is that the security organisation owns finding, prioritising, and accepting risk, and the endpoint organisation owns changing machines, and that the seam belongs exactly there and nowhere else. The failure I see most often is a security team given rights to deploy, which sounds efficient and destroys the review that made the process trustworthy. The second most common is a security team with no exception permission at all, which sounds cautious and simply moves risk acceptance into a spreadsheet where nothing expires. Give one side the finding and the acceptance, give the other side the change, and make the queue the contract between them.
That contract has a concrete implementation, because the request can carry a ticket into Intune where the endpoint team already works, and the whole loop can be made to close and prove itself. That wiring, the toggle it depends on that defaults to off, the accept and complete verbs on the far side, the exception you file when the answer is no, and the end-to-end test that proves a finding travelled all the way to a fixed machine and back, is the build sheet.
Defender XDR
‹ Previous: [D 6] Vulnerability and Exposure Management: Three Instruments, One Estate
Next: [D 6.1.1] Build Sheet: The Remediation Loop from Defender to Intune ›
