On September 2, 2026, Microsoft shipped Edge 152.0.4191.62 to patch CVE-2026-85046 - a vulnerability Google's Chromium team had already confirmed was being actively exploited. Two days later, on September 4, Edge 152.0.4191.66 landed as a further Chromium security refresh. Two security builds, 48 hours apart, for the same major version.
That pace isn't a one-off. Edge just moved to a two-week release cycle for major versions, and security-only point releases can land on top of that schedule at any time. The interesting question for an admin isn't "what does CVE-2026-85046 do" - it's "can I actually prove every managed device installed 152.0.4191.66, or am I just assuming Edge's own updater did its job?"
Watch on YouTube · Subscribe at @EndpointWeekly
Microsoft Edge updates itself using its own background service (EdgeUpdate), completely separate from Windows Update and separate from how Intune deploys Win32 apps. That independence is exactly why "Edge should be current" is not the same claim as "Edge is current" - the service can be silently disabled, a leftover test policy can be pinning devices to an old build, or an update can finish downloading but never take effect because nobody relaunched the browser. This post shows the real registry values and PowerShell to check a single device, how to configure Intune (Settings Catalog, ADMX-backed) and Group Policy to keep every device current and force a relaunch when an update is waiting, and where to look in Intune to check the whole fleet at once.
The problem: "Edge should have updated" isn't proof
Picture the request: security or compliance asks you to confirm every managed Windows device is running Edge 152.0.4191.66 or later, because that build closes an actively-exploited vulnerability. Your first instinct is to open Intune and look. That instinct is the trap.
Edge is not deployed and versioned like a normal Win32 app in Intune. It ships with Windows and updates itself in the background using its own updater, on its own schedule, largely invisible to whatever's watching Windows Update compliance. Intune's own app inventory data about Edge is a snapshot from the last time each device checked in - not a live read of what's actually installed right now.
Three specific things quietly cause a device to lag behind the version Microsoft actually shipped:
| Cause | What you'll see | How you'd catch it |
|---|---|---|
| EdgeUpdate service or scheduled tasks disabled/blocked | Device stays on whatever version it had when the service stopped running, indefinitely | Service state and scheduled task last-run time |
A leftover TargetVersionPrefix or wrong TargetChannel policy from a pilot or lab build | Device is pinned to an old version or the wrong channel and never moves, even with the service healthy | Registry values under the EdgeUpdate policy key |
| Update downloaded successfully, but the browser was never relaunched | The file on disk is new, but the running process is still the old version until relaunch | Comparing the installed version to the running process version |
Why it happens: Edge updates itself, on its own schedule, independent of Windows
Edge's updater is built on the same underlying technology Chrome uses (an open-source project called Omaha). When Edge installs, it also installs a small background service called EdgeUpdate and two scheduled tasks. That service periodically calls out to Microsoft's update servers, checks whether a newer build exists for whatever channel the device is targeting, and if so, downloads and installs it in the background - without needing Windows Update, without needing an Intune Win32 app assignment, and without needing the user to do anything.
That background, self-contained design is genuinely good for security - it means most devices patch themselves within a day or two of release with zero admin effort. It's also exactly why you can't just eyeball it. Three things can each independently break the chain silently:
First, the EdgeUpdate service itself has to be running. If a security tool, a group policy, or a well-meaning technician disabled it - sometimes to "reduce background processes" - the device simply stops checking for updates and nobody gets an error.
Second, Edge's updater honors policy settings that pin it to a specific version or channel. These are genuinely useful for testing a new release before a wide rollout - but if that pilot policy is never removed afterward, the device is now permanently stuck on whatever version was pinned, silently, forever.
Third, downloading a new version and running it are two different events. The updater can successfully download 152.0.4191.66 in the background, but the browser process actually in memory keeps running the old code until the user closes and reopens Edge - which, for someone who keeps forty tabs open for three weeks, might be a while.
How to verify: one device, then the whole fleet
Start with a single device. Two numbers need to agree: the version Edge Update has actually installed on disk, and the version of the browser process the user is currently running.
Here's how to read that. InstalledOnDisk comes from the pv registry value under Edge Update's own client key - this is the version the updater believes it has fully installed. CurrentlyRunning reads the actual file version of msedge.exe that a running browser process is using. In the example above, the updater has already installed 152.0.4191.66, but the browser itself hasn't been relaunched since - it's still running .62. That device isn't broken. It's just waiting on a relaunch, and it will keep showing up as "vulnerable" to anyone checking only the running process until that happens.
edge://version into the address bar. It shows the running version at the top, and if an update has been downloaded and is waiting for a relaunch, Edge also shows a Relaunch button directly on that same page.Next, check whether policy is pinning the device to something other than the latest Stable build:
If TargetChannel or TargetVersionPrefix exist and don't match what you intend for that device, that's your answer - the device isn't behind because of a broken updater, it's behind because a policy is telling it to stay behind. Also worth a quick look: confirm the updater itself is actually alive.
Stopped is normal, not a fault - do not "fix" this. edgeupdate is a trigger-started service: it starts, runs its check, and stops again within seconds, so catching it mid-Running is the exception, not the rule. Several admins have reported the exact same thing to Microsoft, mistaking it for a crash. The signal that actually matters is StartType - it should be Automatic (sometimes shown as an automatic/delayed-start variant), never Disabled. edgeupdatem is a separate, lower-privilege helper that only runs briefly during an install. The MicrosoftEdgeUpdateTaskMachineUA scheduled task - the one that actually performs the update check - should show Ready, meaning it's enabled and waiting for its next scheduled run rather than disabled.For the whole fleet at once, without touching a single device individually, use Intune's own inventory of what's installed.
Go to Apps › Monitor › Discovered apps in the Intune admin center, search for Microsoft Edge, and it breaks device counts down by exact version. Export it (both an aggregate and a raw, per-device CSV are offered) to get the actual device names behind each version bucket.
The fix: policy that keeps Edge current and forces the relaunch
Two separate policy areas matter here, and they live under two different ADMX files, which is worth knowing before you go looking for them: Microsoft Edge Update policies (channel and version control) and Microsoft Edge browser policies (the relaunch behavior). Both are fully supported as built-in, ADMX-backed settings in Intune's Settings Catalog - no custom OMA-URI profile needed.
| Setting | Registry value (under its policy key) | Recommended value |
|---|---|---|
| Update policy override default | UpdateDefault | 1 - Always allow updates |
| Target channel override | TargetChannel{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} | stable for production, extended for slower-cadence fleets - never leave a pilot's beta/dev value in place |
| Target version override | TargetVersionPrefix{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} | Not configured, unless you have a genuine, time-boxed reason to pin a version |
| Relaunch notification | RelaunchNotification (separate key, see below) | 2 - Required |
| Relaunch notification period | RelaunchNotificationPeriod (same key) | 86400000 (24 hours, in milliseconds) |
The first three live under HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate (Group Policy path Administrative Templates › Microsoft Edge Update › Applications › Microsoft Edge, ADMX file msedgeupdate.admx). The relaunch settings live under a different key, HKLM\SOFTWARE\Policies\Microsoft\Edge (Group Policy path Administrative Templates › Microsoft Edge, ADMX file msedge.admx) - it's easy to assume they're all in one place since they all say "Edge," but the updater and the browser itself are configured through two separate policy sets.
Deploy through Intune (Settings Catalog)
- Sign in to the Intune admin center.
- Go to Devices › Configuration › Create › New policy.
- Choose platform Windows 10 and later, profile type Settings catalog.
- Search for and add Update policy override default, Target channel override, and Target version override from the Microsoft Edge Update > Applications category. Set the first to Always allow updates, set the channel to Stable (or Extended Stable if that's your fleet's policy), and leave the version override not configured unless you have an active, time-boxed reason to pin one.
- In the same profile (or a second one), search the Microsoft Edge category for Notify a user that a browser relaunch is recommended or required and Set the time period for update notifications. Set the first to Required and the second to a value your users can tolerate - 24 hours is a reasonable default.
- Assign both profiles to your target device group, review, and create.
Deploy through Group Policy
- Open gpmc.msc, edit the target GPO.
- Navigate to Computer Configuration › Administrative Templates › Microsoft Edge Update › Applications › Microsoft Edge.
- Configure Update policy override default (Always allow updates), Target channel override (Stable or Extended Stable), and confirm Target version override is Not Configured.
- Navigate to Computer Configuration › Administrative Templates › Microsoft Edge (a separate node from the one above).
- Configure Notify a user that a browser relaunch is recommended or required to Required, and Set the time period for update notifications to your chosen value in milliseconds.
- Run
gpupdate /forceon a test device to confirm the policy applies before rolling out broadly.
Proof it worked
Re-run the same two-number check from earlier, on the same device, a day or two after the policy applies and at least one relaunch has happened.
This is what good looks like: both numbers match, and they match the latest Stable build. Back in Intune's Discovered apps report, the device count on the current version should climb over the following day or two as check-ins roll in, and the stragglers list should shrink to genuinely offline devices rather than devices silently stuck behind a stale policy.
-CompliantVersion parameter and a -ExportCsv switch for scheduling it as an Intune platform script across a fleet.Here's what it actually looks like run against a real, currently-non-compliant device - this is a genuine captured run, not a mocked-up example:
Read that the same way as the manual check earlier: InstalledVersion and RunningVersion agree with each other (no pending relaunch), and EdgeUpdateServiceStartType confirms the service is configured correctly (Automatic, not Disabled) - the Stopped status next to it is the normal trigger-started idle state covered above, not a finding. The only real problem the Reasons field surfaces is the version itself: this device genuinely has not received 152.0.4191.66 yet. Triggering an on-demand check (the remediation step below) is the direct next move; if the version still has not moved after that, the device's network path to Microsoft's update servers is the next thing to check.
Script for this post is in Windows-Patching-Scripts. Download and run it directly - no sign-in required. It is read-only and makes no changes to the device; validate it in your own environment before scheduling it fleet-wide.
At fleet scale: stop checking laptops one at a time
Everything so far works on a single device. That is fine for spot-checking one machine, but it does not scale to a few hundred or a few thousand endpoints - and it should not be the process security or compliance actually relies on. The two scripts above (Detect-EdgeUpdateCompliance.ps1 and Remediate-EdgeUpdateCompliance.ps1) turn the exact same checks into an Intune Proactive Remediation that runs on a schedule across every assigned device, with no one opening a single PowerShell window.
Disabled and then triggers an on-demand update check - it deliberately does not force the service to a "Running" state, since Stopped is its normal idle state between checks. It does not touch TargetChannel or TargetVersionPrefix, because those are set by your Intune/GPO policy from "The fix" section above, and a script silently rewriting them would just get overwritten again on the next policy refresh. If a device is still non-compliant purely because of a policy value, that is a signal for an admin to review the assignment, not something to script around.- Sign in to the Intune admin center.
- Go to Devices › Scripts and remediations › Proactive remediations.
- Select Create and name it, e.g. "Edge Update Compliance - Detect and Remediate".
- On the Settings page, paste
Detect-EdgeUpdateCompliance.ps1into Detection script file, and update the$CompliantVersiondefault inside it to match the current required build before you upload it - Intune has no built-in value to read this from automatically. - Paste
Remediate-EdgeUpdateCompliance.ps1into Remediation script file. - Set Run this script using the logged-on credentials to No (the script needs to manage a machine-level service) and Enforce script signature check based on your environment's requirements.
- Select Next, then assign to your target device group under Scope tags › Assignments.
- Set the schedule (e.g. Daily, every 1 day) and select Next › Create.
Once this has run at least once, Devices › Scripts and remediations › Proactive remediations › [your policy name] › Device status shows every assigned device's detection result and, where it fired, the remediation outcome. That view is the closest thing Intune has to a live answer for "are we all on 152.0.4191.66" - closer than Discovered Apps, since it reflects the last scheduled run rather than the last general check-in, and it shows the exact reason a device failed, not just the version.
To turn that per-device Intune view into something you can actually scan at a glance, export the Detect/Remediate results (or run Get-EdgeUpdateComplianceReport.ps1 -ExportCsv across the fleet through your RMM or a scheduled task, combining the per-device CSVs into one file) and load it into the Edge Compliance Ledger - a small dashboard built specifically around this script's own CSV output. It is a single static page with no backend, so it also works if you download it from the script repo below and open it straight from disk - useful if your fleet's compliance data shouldn't touch a public web page at all.
The Edge Compliance Ledger loaded with example data - the same shape a real fleet export produces.
Why this is worth having instead of eyeballing a spreadsheet or a portal screen device by device:
- It's one place, not three. Discovered Apps gives you version counts but not why a device is behind. Proactive Remediation's device status gives you the reason but lives inside Intune's own UI, not something you can filter or hand to someone else as a snapshot. This puts both in one screen.
- The summary strip answers the question before you read a single row. "94% compliant, six devices to chase" is visible in the first second - closer to what a manager or auditor actually asked for than a raw device list.
- Every non-compliant row explains itself. The Reasons column is the same text the script generates - a disabled service, a policy pinning an old build, a relaunch pending - so whoever picks up the finding knows what to check before they touch the device.
- Nothing leaves the browser. The CSV is parsed client-side; no device data is ever uploaded anywhere, which matters given the file has real device names in it.
- It costs nothing to stand up. No Power BI licence, no reporting pipeline to build - the script's own
-ExportCsvoutput is the only input it needs.
References
- Microsoft Edge Security Updates - Microsoft Learn - the release notes confirming 152.0.4191.62 (Sept 2, CVE-2026-85046) and 152.0.4191.66 (Sept 4).
- Faster updates, enterprise-friendly schedule: the new Microsoft Edge release cycle - Microsoft Edge Blog - the announcement of the two-week Stable cadence starting with Edge 152, and the Extended Stable schedule.
- Microsoft Edge Update Policy Documentation - Microsoft Learn - every EdgeUpdate policy, including
TargetChannel,TargetVersionPrefix, andUpdateDefault, with their exact registry paths. - RelaunchNotification policy - Microsoft Learn - the browser-side policy (separate ADMX from EdgeUpdate) that forces a relaunch once an update is waiting.
- Deploy Microsoft Edge policy using settings catalog in Microsoft Intune - confirms these are built-in, ADMX-backed Settings Catalog categories, no custom OMA-URI required.
- Discovered apps in Microsoft Intune - how the fleet-wide version report works and its export options.