Intune Vulnerability Remediation Agent: What It Really Does

My garage has a problem. Somewhere in there is a box of Christmas lights, three partial cans of the same beige paint, a car seat my kids outgrew more years ago than I want to admit, and at least one thing that is actively leaking. Every item in that garage matters to somebody. None of it is labeled. So every Saturday I open the door, look at it for about nine seconds, and close it again.

That is roughly what happens when you open a vulnerability report for the first time. Four thousand findings, every one of them scored and sorted, and not a single one telling you where to start.

Microsoft’s Vulnerability Remediation Agent in Intune is aimed at exactly that problem. It reads your Microsoft Defender Vulnerability Management data, ranks what it finds, then hands back remediation steps written in Intune’s vocabulary instead of generic security advice. Let’s stand it up, get the permissions right, and see what it actually gives you.

What it is, and what it is not

The Vulnerability Remediation Agent is a Security Copilot agent that lives inside the Intune admin center. It is not a new scanner. It does not discover anything Defender Vulnerability Management did not already know about.

What it adds is triage and translation. It collects CVE data from Defender, prioritizes based on CVSS scores, exposure impact, and device count, then writes step-by-step remediation guidance tailored to Intune.

Notice what is missing from that list. No EPSS, no exploit prediction, no threat intelligence feed. Three inputs, and that is it. Plenty of coverage out there implies more sophistication than Microsoft actually claims, so calibrate accordingly.

Microsoft is refreshingly blunt about the ceiling here. The setup screen says the quiet part out loud: this agent is in preview and currently does not take action on your devices. It suggests. You deploy.

One more thing before we go further. This is still in public preview as of this writing. It hit limited preview in mid 2025 and opened to all customers in the June 2026 service release. There is no GA date yet, so expect field names and portal placement to shift.

What you need first

Three licenses:

• Microsoft Intune Plan 1
• Microsoft Security Copilot with sufficient security compute units, or SCUs
• Microsoft Defender Vulnerability Management, delivered through Microsoft Defender for Endpoint P2 or the standalone offering

Two Security Copilot plugins have to be enabled, specifically Microsoft Intune and Microsoft Defender. If you already use Copilot in Intune, that plugin is on already.

The account you sign in with needs Intune Read Only Operator, or a custom role carrying Security Tasks, Mobile apps, Device configurations, and Organization read. In Security Copilot you need Copilot owner. That covers setting the agent up and viewing results.

The agent itself runs as a separate identity with a separate set of permissions. That part gets its own section below, because it is where most people get stuck.

A quick word about SCUs

Good news on this front. Security Copilot is now included with Microsoft 365 E5 and E7. You get 400 SCUs per month for every 1,000 paid user licenses, up to a ceiling of 10,000 per month, and the math scales below 1,000 licenses too. A 400 seat tenant gets 160 SCUs a month. A 4,000 seat tenant gets 1,600.

That allocation explicitly covers agentic scenarios across Entra, Intune, Purview, Defender, and the standalone Security Copilot portal, so this agent draws from the same pool. Two catches worth writing down. The allocation resets monthly and does not roll over, so unused capacity evaporates. Usage past your allocation gets throttled eventually, with pay as you go available at six dollars per SCU.

What nobody publishes is how many SCUs a single run of this agent actually burns. Microsoft says only that a run might fail due to insufficient SCUs. Budget for some trial and error before you know what it costs you.

Step 1: Set up the agent

In the Intune admin center, go to Agents, then Vulnerability Remediation Agent. It also shows up under Endpoint security if that is where your muscle memory takes you. Both paths land on the same agent.

Select Set up agent. The pane that opens is more useful than most setup wizards, because it tells you five things up front: how the agent gets triggered, which permissions it will need, which plugins it uses, which roles can see it, and which Security Copilot workspace it will run in.

Two details on that pane deserve a callout.

First, the workspace. The agent runs in whatever preferred workspace you selected for Security Copilot. If that is wrong, or if your account is not a member of it, you get a “you are not part of the workspace needed to access this agent” error later, and it looks nothing like a permissions problem.

Second, the warning box. Microsoft tells you plainly that the agent creates a new agentic user, and that it will not complete a run until you assign permissions to that user yourself. The wizard does not do it for you. Read that line twice, because it is the whole reason the next section exists. Select Set up agent to finish. You get a notification when the identity is provisioned.

Step 2: Assign permissions to the agentic user

This is where the setup actually lives. The agent runs under a Microsoft Entra agentic identity, which is a welcome change from the original model where it borrowed a human admin account. The tradeoff is that a brand new identity starts with exactly zero access to anything.

The Settings tab spells out the three permissions in plain English, which is nicer than decoding RBAC role names:

• Read vulnerability data from Defender
• Read mobile apps in Intune
• Read device configurations in Intune

Those three map one to one against what the readiness check tests, so keep them in mind. Here is how you actually grant them.

Find the agentic user

On the Settings tab under Permissions, select Manage agentic user. If that link gives you trouble, copy the agent identity ID with the Copy ID button, then go to the Entra admin center, Entra ID, Agents, Agent identities, and paste it into the search box.

Put it in a security group

Create a security group, something like SG-Intune-VRA-Agent, and add the agentic user as a member. Do not skip this. Intune assigns RBAC roles to groups, never to individual users, so the agentic user has to sit inside a group before Intune can grant it anything.

Assign the Intune role

Go to Tenant administration, Roles, All roles, then Read Only Operator. You can also build a custom role with just Mobile apps read and Device configurations read if you want to stay least privilege. Open Assignments and select Assign.

Add your group under Admin Groups, then add it again under Scope Groups. That second step is where people lose an afternoon. If Scope Groups is empty or points somewhere else, the agent authenticates fine and still sees zero devices, so the readiness check keeps failing with no obvious explanation.

Assign the Defender access

This one branches depending on which permission model your tenant runs. Check in the Defender portal under System, Permissions, Roles. If you see an Activate workloads banner or a Workload settings button, some workloads are still on the legacy model.

If Unified RBAC is active for Defender for Endpoint, assign the Microsoft Entra ID Security Reader role to the agentic user. That grants read access to Defender Vulnerability Management data and enforces device group scoping automatically. This is the easy path, and it matches what the setup pane hints at when it says access can come from a custom role or a Security Reader role.

If you are still on granular Defender for Endpoint RBAC, create a custom role with View data for Defender Vulnerability Management, then scope it to include every device group you care about. The agent cannot report on devices outside its assigned scope, so a narrow scope quietly produces a short list.

Worth noting that the Vulnerability Remediation Agent documentation only covers the granular path. The sibling Change Review Agent doc spells out both, and the Unified RBAC option is the one most tenants should reach for.

Step 3: Run the readiness check

Back on the Settings tab, select Run readiness check. It starts at Not run, spins for a few minutes, then reports per endpoint.

Until this passes, the Run button stays greyed out. That is by design.

All three failed is the normal state immediately after setup, before you have delegated anything. Nothing is broken. The check is telling you the agentic user currently has no access to any of the three data sources, and the three rows map exactly to the three permissions listed below them.

If you just assigned permissions and everything still shows Failed, wait. Intune RBAC assignments take several minutes to take effect after the agentic user joins the group, and the readiness check itself takes a few minutes to run. Re-running it immediately is the most common false alarm here. Go get coffee, then try again. I have been down that road before.

If Defender clears but the two Intune rows stay red, go back and check Scope Groups specifically. That is almost always it.

Scheduling, or not

By default the agent only runs when you start it manually. After setup, you can optionally schedule automatic runs from the Triggers page on the Settings tab.

Fair warning that the documentation lags the product a little here. One section of the Learn article says scheduling unlocks alongside the Run button, while the operational considerations section on the same page still says an admin must manually start it. The portal is the source of truth, and the portal has a Triggers page.

Either way, once a run begins you cannot stop or pause it. Just go with it.

Reading the Suggestions tab

The agent gives you three tabs. Overview shows status tiles, your top suggestions, and an Activity section tracking run history. Suggestions hold the full list. Settings is where identity, permissions, and triggers live.

Columns are Suggested next steps, Remediation type, which tells you whether the fix targets an app or the operating system, then Impact, Exposed devices, Status, and Last applied. That Impact value deserves a second look, since it is not a Copilot invention. It comes straight from the Defender exposure score, and the number you see is the projected reduction if you apply the fix. If you have already tuned exposure scoring on the Defender side, that work pays off here. Conversely, if your Defender data is a mess, this column will faithfully reflect the mess.

Status has exactly two values, Not applied and Applied. That is the whole lifecycle. Agent runs carry their own separate states of Run in progress and Complete over in the Activity section, so do not confuse the two.

Why you might only see app updates

My first successful run came back with six suggestions, and every single one was an App update. Nothing at the OS level, nothing about configuration. If that happens to you, here is what is going on.

Defender splits device findings into two separate workflows, and as of the unified Recommendations page, they are literally separate views. Vulnerabilities covers software CVEs that need patches and drives your exposure score. Misconfigurations covers hardening gaps and drives Microsoft Secure Score for Devices.

This agent reads the vulnerabilities side only. Your Impact column proves it, since those values are exposure score reductions.

Finally, and this tripped me up, configuration guidance is not a Remediation type at all. It lives one level down, inside each suggestion. More on that next.

To sanity check any of this, open the Defender portal, go to Exposure management, Recommendations, the Devices tab, and switch to the Vulnerabilities view. Whatever sits there is the agent’s entire input.

Turning a suggestion into an actual fix

Open a suggestion and you get vulnerability details, suggested actions, exposed devices, and a Configurations section.

Mark it applied, and know what that means

Once the fix is out and devices have checked in, select Mark as applied. If the same suggestion resurfaces on a later run, the button becomes Mark update as applied.

Now the important part. Marking a suggestion applied does not touch a single device. Microsoft’s wording is that it does not trigger any device changes by the agent. It writes a timestamp and flips a status field. That is all it does.

I am not knocking the feature. A self attestation plus a timestamp gives you a baseline to compare future runs against, which is useful for tracking whether exposure is actually dropping. Just do not walk away thinking you clicked a button that fixed something.

So does it actually fix anything?

No, and I want to be direct about that, because the word “agent” is doing a lot of heavy lifting across the industry right now.

This one reads, ranks, and writes instructions. Every deployment is still yours to build, scope, and assign. Microsoft says as much on the setup screen.

What else to watch for

A handful of limitations worth knowing before you pitch this to anyone:

• Public cloud only. Government clouds are not supported.
• Windows clients only. CVE counts and the exposed device list exclude Windows Server editions entirely. If you have a server estate, those machines are invisible here.
• Scope tags are not supported in public preview.
• Agent data ignores your RBAC scope. Microsoft states that admins accessing the Intune admin center can see agent-reported data even when it falls outside their assigned Intune roles or scope. Worth knowing if you have carefully tiered your helpdesk.
• Audit logging is thin. Security Copilot logs capture agent management actions and permission failures, though not discovered vulnerabilities or when remediations were applied.
• Removing the agent deletes every suggestion, including ones marked Applied. That stings more once you learn that remove and re-add is also the documented fix for authorization failures. Export anything you care about first. Trust me on this one.

Wrapping Up

The Vulnerability Remediation Agent will not clean out your garage.

What it does is walk in with a flashlight, point at the thing that is leaking, tell you roughly how many other boxes are getting wet, and hand you the part number for the fix. You still go get the wrench. You still decide whether Saturday morning is the right time. The difference is that you are no longer standing in the doorway for nine seconds wondering where to start.

For a preview feature, that is a fair trade. The setup is fiddly, and almost all of the friction sits in that one step where you delegate permissions across three portals. Budget an hour for it, expect the first readiness check to fail, and do not panic when it does.