Microsoft Defender Engine Not Updating: How to Force the Update When WSUS, Intune, or Auto-Update Fails
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
After every CISA deadline that specifies a minimum Defender engine version, the same problem surfaces across thousands of organizations: the engine version on endpoints does not match what WSUS, Intune, or the vendor dashboard shows as deployed. The update appeared to go out. The endpoints did not update.
Defender engine updates fail silently. There is no prominent dashboard alert, no failed deployment badge in most environments, and no end-user notification. The endpoint keeps running its old engine. You do not know until you run a query.
This guide covers the five distinct failure modes and the exact commands to diagnose and fix each one.
Step 0: Check Your Current Engine Version
Before troubleshooting, verify what version is actually installed on affected endpoints.
On a single endpoint (PowerShell):
Get-MpComputerStatus | Select-Object AMEngineVersion, AMServiceVersion, AMProductVersion, AntivirusEnabled, RealTimeProtectionEnabled
The fields to check:
AMEngineVersion: the antivirus engine (this is what CISA deadlines reference)AMServiceVersion: the Defender service versionAMProductVersion: the platform version
At scale with Intune (MDE Advanced Hunting):
DeviceTvmSoftwareInventory
| where SoftwareName == "windows_defender"
| summarize count() by SoftwareVersion
| order by count_ desc
At scale with Defender for Endpoint portal: Navigate to Reports > Microsoft Defender Antivirus > then filter by AMEngineVersion. Any endpoint below the target version appears in the non-compliant count.
Once you know which endpoints are behind, identify the failure reason before attempting remediation.
Failure Reason 1: WSUS Is Not Approving Defender Updates
By default, Microsoft Defender antivirus updates flow through Windows Update. In enterprise environments using WSUS, the Defender engine update must be approved in WSUS before endpoints will pull it. Many WSUS configurations auto-approve definition updates but not engine updates, because they fall under a different update classification.
Diagnosis: Open WSUS console, navigate to Updates, and filter by Classification: "Definition Updates" and "Security Updates." Search for the target engine version. If it appears as Not Approved, WSUS is the blocker.
Fix: Approve the Defender engine update in WSUS for the target computer groups. Endpoints poll WSUS on their configured detection cycle (default: every 22 hours). To force immediate detection:
wuauclt /detectnow
wuauclt /updatenow
Or on newer Windows versions:
(New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()
Long-term fix: Configure WSUS to auto-approve all updates in the "Definition Updates" and "Microsoft Defender Antivirus" classifications for your endpoint groups. Engine updates fall into these categories and require the same approval as signature updates.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Failure Reason 2: Tamper Protection Is Blocking Manual Updates
Tamper Protection prevents unauthorized changes to Defender settings and update sources. When enabled and configured incorrectly, it can block administrator-initiated manual updates that do not come through the approved management channel.
Diagnosis: Attempt a manual update and check the Windows Event log:
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" | Where-Object {$_.Id -eq 5007 -or $_.Id -eq 1013} | Select-Object -First 20 TimeCreated, Message
Event ID 5007 indicates a settings change that was blocked. Event ID 1013 indicates an update that failed.
Fix: Tamper Protection must be managed through the same channel that enforces it. If Tamper Protection is managed through Intune (most enterprise environments), the engine update must also be deployed through Intune. Running Update-MpSignature or triggering Windows Update locally will not override Tamper Protection.
If you need to temporarily disable Tamper Protection to apply an emergency update, do so through the Intune policy console. Disabling it via registry or local Group Policy will be overridden by the cloud policy within minutes.
Failure Reason 3: Delivery Optimization or BranchCache Is Stalling Distribution
Delivery Optimization (DO) and BranchCache are designed to reduce bandwidth by distributing updates peer-to-peer across the local network. In some configurations, this causes a subset of endpoints to wait for a peer that never delivers the update, while the management console shows deployment as complete because the update reached the DO cache.
Diagnosis: Check Delivery Optimization status on a stuck endpoint:
Get-DeliveryOptimizationStatus | Select-Object FileId, TotalBytesDownloaded, BytesFromPeers, BytesFromCdn, Status
If BytesFromCdn is 0 and BytesFromPeers is also 0 for the Defender update, the endpoint is waiting and getting nothing from either source.
Fix (immediate): Force a direct CDN download by temporarily setting the DO download mode to Bypass:
Set-DeliveryOptimizationStatus -ForceRefresh
Or configure a Group Policy or Intune profile to set Download Mode to 0 (HTTP only, no peering) for Defender updates specifically.
Fix (permanent): Review your DO group assignment. Endpoints that span multiple subnets without a configured DO group ID will default to internet peering with random peers, which is unreliable. Set DOGroupId via Group Policy to a consistent GUID per site.
Failure Reason 4: Group Policy Is Overriding the Update Source
A common misconfiguration: a legacy Group Policy Object sets the Defender update source to a file share, internal update server, or WSUS path that no longer exists or does not contain the target engine version. The endpoint polls that source, finds nothing new, reports success to management (because the GPO is applied), and never pulls the actual update.
Diagnosis: Check the configured update source:
Get-MpPreference | Select-Object SignatureDefinitionUpdateFileSharesSources, SignatureDisableUpdateOnStartupWithoutEngine, SignatureFallbackOrder
Also check Group Policy RSoP:
gpresult /h gpresult.html
Open gpresult.html and search for "Windows Defender" or "Defender Antivirus" policy settings. Any policy configuring SignatureUpdateFallbackOrder or SignatureDefinitionUpdateFileSharesSources that references an unavailable source will block engine updates.
Fix: Either update the GPO to point to a valid source, remove the conflicting GPO, or add MicrosoftUpdateServer and MMPC to the fallback order so endpoints can reach Microsoft's update servers when the primary source is unavailable:
SignatureFallbackOrder: InternalDefinitionUpdateServer | MicrosoftUpdateServer | MMPC
Failure Reason 5: Manual Force Update via Intune Live Response
When the above automated paths fail and you need the engine updated immediately on specific endpoints, Intune Live Response gives you direct command execution without requiring physical access.
Step 1: In the Intune portal, navigate to Devices > Windows > select the device > "..." menu > New Remote Assistance Session (or use Endpoint Security > Initiate Live Response if your license includes MDE P2).
Step 2: From the live response session, force an immediate engine update:
cd "C:\Program Files\Windows Defender"
.\MpCmdRun.exe -SignatureUpdate -MMPC
The -MMPC flag forces the update directly from Microsoft's Malware Protection Center, bypassing all local WSUS, GPO, and peer distribution configurations.
Step 3: Verify the result:
Get-MpComputerStatus | Select-Object AMEngineVersion
At scale without live response: If live response is not available, deploy a one-time Intune remediation script containing the MpCmdRun command above. Target it at the device group containing stuck endpoints. The script runs in SYSTEM context and bypasses the user session entirely.
The bottom line
Defender engine updates fail for five distinct reasons, each requiring a different fix. WSUS approval gaps are the most common in enterprise environments. Tamper Protection conflicts are the most frustrating because they silently reject manual interventions. Start by verifying the engine version on affected endpoints, then trace the failure through event logs, GPO RSoP, and delivery optimization status before attempting any remediation. For emergency patching against an active CISA deadline, the MpCmdRun -SignatureUpdate -MMPC command executed via Intune Live Response bypasses every local configuration blocker and completes in under 5 minutes per endpoint.
Frequently asked questions
What is the difference between AMEngineVersion and AMProductVersion?
AMEngineVersion is the version of the Defender antivirus scanning engine (mpengine.dll), which processes files during scans and real-time protection. This is the version number referenced in CISA CVE remediation requirements. AMProductVersion is the version of the Defender platform component (MsMpEng.exe), which is the host process. Both require separate updates through different delivery mechanisms. CISA deadlines for CVE-2026-41091 specified both AMEngineVersion 1.1.26040.8 and AMProductVersion 4.18.26040.7.
Why does Intune show the engine update as deployed but the endpoint still shows an old version?
Intune marks a deployment as successful when the update package reaches the device and the install command executes without an error code. It does not always verify the resulting installed version. The most common cause of this discrepancy is Tamper Protection rejecting the update silently after Intune marks it delivered, or the device being in a state where the update installs but the engine service has not restarted yet. Verify actual version with Get-MpComputerStatus on a sample of endpoints rather than relying solely on the Intune deployment status.
Can I push the Defender engine update without rebooting endpoints?
Yes. Microsoft Defender engine updates do not require a reboot. The engine is updated in place and the new version takes effect for new scan processes immediately. Existing scan processes may continue using the old engine until they complete. Real-time protection switches to the new engine version as soon as the update applies.
How do I verify Defender engine versions across 5,000 endpoints at once?
Use MDE Advanced Hunting with a KQL query against DeviceTvmSoftwareInventory filtered for windows_defender, or query the DeviceInfo table for ClientVersion. For WSUS environments, the WSUS console Reports section provides per-computer update status. For Intune-managed environments, Endpoint Security > Antivirus > Windows 10 and later antivirus shows per-device engine version with filtering by version range.
Why does Microsoft Defender show different version numbers for engine, platform, and signatures?
Microsoft Defender for Windows has three independently versioned components: the antimalware engine (AMEngineVersion) which performs the actual malware detection work; the platform/product (AMProductVersion) which is the overall Defender application and updates through Windows Update; and the security intelligence (AntivirusSignatureVersion/AntispywareSignatureVersion) which is the malware definition database that updates multiple times daily. All three must be current for complete protection. Signature updates are the most time-sensitive (daily); engine and platform updates ship monthly via Windows Update or MDE monthly channel. An endpoint with current signatures but an outdated engine may have reduced detection capability for evasion techniques that the newer engine version specifically addresses.
How do you build a reliable automated compliance check that confirms Defender engine versions meet a minimum version requirement across a large endpoint fleet?
A production-grade Defender engine version compliance check requires three components working together. First, a query layer that pulls current AMEngineVersion per device from a source that reflects ground truth -- MDE Advanced Hunting via the DeviceTvmSoftwareInventory table is more reliable than Intune compliance reporting because it reads from the agent's actual reported state rather than the last policy sync. Second, a threshold definition stored outside the query so you can update the minimum required version without modifying code -- a configuration file, an Azure Key Vault secret, or a simple text file in a private repository works. Third, an alerting path with enough context for the responder to act without additional investigation: the alert should include the device name, current AMEngineVersion, required version, primary user, Intune enrollment status, and last check-in time. Run the check on a 4-hour schedule during business hours and daily overnight. For Intune-managed fleets, supplement the query with a Device Compliance policy that marks endpoints below the minimum engine version as non-compliant, which integrates into Conditional Access and can block those endpoints from accessing corporate resources until the engine updates.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.