Since late August 2026, Windows devices running Microsoft Defender Antivirus have been popping up a "Turn on virus protection" or "Microsoft Defender Antivirus is turned off" warning — even on machines where Defender never stopped running. Microsoft confirmed it on August 28, 2026 as a genuine bug, not a false report from a compromised or misconfigured device. As of today, it is still listed as Confirmed with no fix shipped.
This is a different bug from the "memory integrity shows as off" issue covered elsewhere on this site — that one is about the Windows Settings toggle for Virtualization-Based Security's Memory Integrity (Core Isolation) feature. This post is specifically about Microsoft Defender Antivirus — the real-time malware scanning engine — falsely reporting itself as disabled through Windows Security notifications. Different feature, different bug, same underlying lesson: don't trust a status message without checking the source of truth behind it.
Watch on YouTube · Subscribe at @EndpointWeekly
Microsoft confirmed on August 28, 2026 that recent Microsoft Defender Antivirus updates can trigger a false "Microsoft Defender Antivirus is turned off" notification, even though real-time protection, cloud-delivered protection, and Defender's own service are all still running normally. The notification bypasses Windows notification settings and Do Not Disturb, and Microsoft has not yet shipped a fix — the release-health status is still Confirmed, unresolved, as of this post. Do not act on the notification alone: verify the real state with Get-MpComputerStatus, the Windows Security app's own detail view, and — at fleet scale — the Intune or Microsoft Defender for Endpoint portal, before you escalate a "device is unprotected" incident or trigger a compliance remediation. This post gives you the exact commands, a read-only PowerShell audit script, and the Event Viewer entries that tell real from false.
The problem: a "turned off" warning that Microsoft says is wrong
Here is exactly what users are seeing. A notification appears — sometimes at sign-in, sometimes randomly while the device is in use — that reads along the lines of "Turn on virus protection" or "Microsoft Defender Antivirus is turned off." Clicking it opens the Windows Security home tab, where everything usually looks fine: no red banner, no "Off" state on the Virus & threat protection tile. The notification simply reappears later, on its own schedule.
Microsoft's own Windows release health page confirms this is real and lists it as an open issue. Quoted verbatim from the Windows 11, version 25H2 known issues page (the identical entry also appears on the 24H2 page):
The affected-platforms list on that page is unusually wide. It is not scoped to one Windows version — it spans every Windows release still receiving Defender updates:
Server: Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012
In plain terms: if a device has Microsoft Defender Antivirus installed and pulls the latest Defender updates, it can hit this bug, regardless of which Windows version it runs. That is a signal in itself — a bug tied to the Defender Antivirus update channel (signatures/platform), not to any one Windows build's code.
Why it happens: notification versus actual protection state
To understand this bug, you need to know that "Defender is off" can be reported from more than one place, and those places do not always agree with each other or with reality.
Windows Security (the app with the shield icon in your taskbar) is a front end. It does not run the antivirus engine itself — it reads status from underlying components and displays a summary. The two components that matter here are:
- The Microsoft Defender Antivirus service itself (Windows service name
WinDefend), which owns real-time protection, scanning, and signature state. This is whatGet-MpComputerStatusqueries directly. - The notification/health-reporting layer inside the Defender Antivirus platform, which periodically raises a toast when it believes protection is off. Event ID 1151 ("Endpoint Protection client health report") is exactly this: an hourly self-report of real-time protection (RTP) state, on-access (OA) state, behavior monitoring (BM) state, and signature freshness, generated by the Defender platform itself.
Microsoft has not published the specific internal defect — no root-cause writeup, no engine build number, no code path. What it has confirmed is the observable behavior: the health-reporting/notification layer is producing an incorrect "off" signal while the actual protection component (the service, real-time protection, cloud-delivered protection, and tamper protection) all continue reporting themselves as enabled. That is a reporting defect, not a protection defect — but be honest with yourself about the limits of that statement: it is Microsoft's characterization, not something this post independently verified inside the Defender binary.
The August 2026 wave of press coverage (Windows Latest, Forbes, cybersecuritynews.com, and others) lines up with Microsoft's own account: devices showing the false alert had real-time protection, cloud-delivered protection, and tamper protection all still reading On when checked directly. That consistency across independent reports — plus Microsoft's own "Confirmed" status — is why this post treats the underlying antivirus engine as unaffected, while treating the notification itself as broken.
Understanding what Windows Security is actually built on
If you want the full underlying model: Microsoft Defender Antivirus exposes its state through a WMI class, MSFT_MpComputerStatus, in the Root\Microsoft\Windows\Defender namespace. Get-MpComputerStatus is simply a PowerShell wrapper around that WMI class. It is a direct read from the antivirus engine's own service — not from the notification layer, and not from Windows Security's rendering logic. That distinction is exactly why it is the right tool to cut through this bug: it asks the engine, not the messenger.
How to verify: the commands and portals that tell the truth
Whenever you see this notification — or a helpdesk ticket that quotes it — verify before you act. Here is the full chain, from a single device up to fleet scale.
Step 1 — Ask the engine directly with PowerShell
Open PowerShell as Administrator and run this. It queries MSFT_MpComputerStatus directly, the same source Windows Security itself is supposed to be summarizing.
Here is what a genuinely healthy device reports (real capture pattern, values illustrative — signature dates and versions will differ on your device):
Every one of those property names is documented on Microsoft's own MSFT_MpComputerStatus class reference and the Get-MpComputerStatus cmdlet reference. RealTimeProtectionEnabled is the exact property this bug's notification is wrong about — Microsoft's own doc defines it plainly as: "Specifies whether real-time protection is enabled." If this reads True, the notification is false, full stop.
AMRunningMode is worth watching even outside this bug. A value of Normal means full Defender protection. Passive Mode means Defender is scanning and reporting but not actively remediating — normal when a third-party antivirus is the primary engine, or when the device is Microsoft Defender for Endpoint onboarded with a non-Microsoft AV as primary. EDR Block Mode means Defender AV itself is passive but is still available to block malicious artifacts detected by Defender for Endpoint. Neither of those two non-Normal states is what this bug is about, but they are a common source of a genuinely confusing "is my AV really protecting me" question, so check this property whenever you check the others.
Step 2 — Confirm the underlying service is actually running
Cross-check with the Windows service itself. This does not depend on the Defender health-reporting layer at all — it asks the Service Control Manager directly.
STATE: 4 RUNNING is what you want to see. Unlike some Windows background services that are trigger-started and legitimately show as stopped between runs, WinDefend is a continuously running protection service — if it genuinely shows STOPPED here, that is worth investigating on its own, independent of this notification bug.
Step 3 — Check the Windows Security app's own detail view, not just the home tile
The home tab of Windows Security is the least detailed view. Go one level deeper.
- Open Windows Security (search the Start menu for "Security," or click the shield icon in the taskbar).
- Select Virus & threat protection.
- Under Virus & threat protection settings, select Manage settings.
- Confirm the toggles for Real-time protection, Cloud-delivered protection, and Tamper Protection all read On.
If all three read On here and Get-MpComputerStatus also reports them enabled, you are looking at exactly the bug Microsoft confirmed: a false notification with a healthy underlying state. If any of them genuinely read Off, that is a real problem unrelated to this specific bug, and you should treat it as one.
Step 4 — Check the Windows Defender Operational event log
The event log gives you a timestamped, tamper-evident history — useful when you need to show a real change (or the absence of one) rather than a point-in-time snapshot.
The row that matters most is the one that is missing: no Event ID 5001 (MALWAREPROTECTION_RTP_DISABLED — "Real-time protection is disabled"). If real-time protection had genuinely been turned off, this event would be logged at the moment it happened. Its absence, combined with a healthy 1150/1151 pair every hour, is strong evidence the notification is the false one described in Microsoft's advisory — not the protection state.
Defender Antivirus Event ID catalog
This is the full set of Event IDs in the Windows Defender/Operational log that speak directly to protection being enabled, disabled, or blocked from changing — the complete reference for this specific "on vs. off" question, not just the one event tied to this bug:
| Event ID | Level | Meaning |
|---|---|---|
| 1150 | Information | Antimalware client is running in a healthy state — reported roughly hourly while everything is normal |
| 1151 | Information | Full client health report: real-time protection (RTP), on-access (OA), and behavior monitoring (BM) state, plus signature age — the richest single event for confirming true status over time |
| 3002 | Warning | A real-time protection feature (On Access, IE/Outlook attachment scanning, Behavior Monitoring, or Network Inspection) hit an error and failed — a genuine problem worth investigating, unlike this bug |
| 3007 | Information | Real-time protection recovered automatically after the 3002 failure above — Microsoft recommends a full scan afterward |
| 5000 | Information | Real-time protection was enabled |
| 5001 | Information | Real-time protection was disabled — this is the event you should search for and NOT find if the false notification is what you're dealing with |
| 5004 | Information | A specific real-time protection feature's configuration changed (On Access, IE/Outlook scanning, Behavior Monitoring, or Network Inspection) |
| 5007 | Information | The overall antimalware platform configuration changed — worth reviewing if unexpected, since Microsoft notes it can indicate tampering |
| 5009 / 5010 | Information | Antispyware scanning enabled (5009) or disabled (5010) |
| 5011 / 5012 | Information | Antivirus scanning enabled (5011) or disabled (5012) |
| 5013 | Information | Tamper Protection blocked an attempted change to a Defender setting, and names which setting was blocked — if you see this, something (or someone) tried to weaken Defender and was stopped |
Get-MpComputerStatus's tamper protection state (surfaced in the Windows Security app's Manage settings page; the underlying property is not exposed by every PowerShell module version, so treat the Windows Security app view as authoritative if the cmdlet output on your build doesn't show it) before trusting the absence of 5013 events as proof nothing was tampered with.
Registry keys behind Defender's on/off state
These are the Group Policy-managed registry values that actually flip real-time protection and antispyware scanning off at the policy layer. They are useful to know for two reasons: to confirm nothing in your own environment is setting them, and to understand why Tamper Protection exists — it specifically blocks direct edits to keys like these outside of the Windows Security app or an approved management channel.
| Value name (type) | Healthy value | If wrong |
|---|---|---|
DisableAntiSpyware (REG_DWORD) | Absent, or 0 | 1 = antispyware/antivirus protection disabled by policy |
Real-Time Protection\DisableRealtimeMonitoring (REG_DWORD) | Absent, or 0 | 1 = real-time protection disabled by policy — this is the actual policy-layer equivalent of what this bug's notification falsely claims |
Real-Time Protection\DisableBehaviorMonitoring / DisableOnAccessProtection (REG_DWORD) | Absent, or 0 | 1 = the specific sub-feature (behavior monitoring or on-access scanning) is disabled by policy |
HKLM\SOFTWARE\Policies\Microsoft\Windows Defender — the Group Policy-managed branch, separate from the non-policy runtime keys under HKLM\SOFTWARE\Microsoft\Windows Defender. With Tamper Protection enabled (the default on modern Windows), Microsoft's own documentation confirms direct edits to these values are blocked regardless of who or what makes them, including a local administrator using regedit.exe. If you find one of these set to a disabling value on a Tamper Protection-enabled device, that by itself is unusual and worth investigating as a potential tampering attempt, not a routine config drift.
Registry Editor view — a multi-row look at a real-time protection policy branch
An absent value is the healthy state for every one of these — Defender treats "key not present" the same as "explicitly 0" (not disabled). If you see any of them present and set to 1, that is a genuine policy-level disable, and no amount of dismissing the false notification will make it go away — you have found a real configuration issue instead of this bug.
The fix: what to actually do about it, one device or a whole fleet
There is no code fix you can apply yet — Microsoft has not released one. What you can do is stop the notification from causing wasted incident-response time, and make sure you would still catch a real "off" event if one happened.
On a single device: verify, document, and stand down
- Run the four verification steps above (
Get-MpComputerStatus,sc query WinDefend, the Windows Security detail view, and the Operational event log) and confirm all report healthy. - If everything reports healthy, treat the notification as the confirmed Microsoft bug. Do not reinstall Defender, do not re-run onboarding, and do not open a security incident for this device based on the notification alone — those actions do not address a bug in the reporting layer.
- Document the check (screenshot or command output) against the timestamp of the notification, in case the same user reports it again later. This spares your helpdesk from re-diagnosing the identical false alarm every time it recurs.
- Keep the device's Defender updates current anyway — Microsoft's stated plan is to ship the fix through a future Microsoft Defender Antivirus update, not a Windows quality update, so continuing normal signature/platform updates is how the fix will eventually arrive.
At fleet scale: don't let this desensitize you to a real "off" device
The real risk of a widely reported false alarm is not the alarm itself — it's the habit it creates. If your team learns to reflexively dismiss "Defender is off" tickets, a genuinely unprotected device can hide in the noise. Two places give you a fleet-wide, independent-of-the-notification view:
Microsoft Intune — Antivirus status report
- Sign in to the Microsoft Intune admin center.
- Go to Endpoint security > Antivirus.
- Select the Windows devices tab to see real-time protection status, signature age, and detection counts per managed device, sourced from the device's own reported health — not from a notification.
- Filter or sort by Real-time protection state to spot any device that is genuinely reporting disabled, independent of what any toast on that device is showing its user.
DEVICE-B2 above is the one that deserves a real incident — its portal-reported state, not just an on-device toast, says protection is off. That distinction is exactly why the portal view matters more than ever while this bug is unresolved.
Microsoft Defender for Endpoint — device health and antivirus health report
If your tenant has Microsoft Defender for Endpoint, its Antivirus health report and the per-device health page pull directly from the same sensor data as Get-MpComputerStatus, aggregated centrally. Go to Reports > Microsoft Defender Antivirus health in the Microsoft Defender portal to see fleet-wide real-time protection, signature currency, and engine version compliance without depending on any single device's notification state.
The companion script: verifying true Defender status from the command line
The script for this post, Get-DefenderTrueStatusReport.ps1, runs every check from the "How to verify" section above in one pass: Get-MpComputerStatus's protection properties, the WinDefend service state, and a scan of the last 24 hours of the Windows Defender Operational log for Event ID 5001 (real-time protection disabled) or 5013 (Tamper Protection blocked a change). It is entirely read-only — it never calls Set-MpPreference or any other state-changing cmdlet, and it does not attempt to dismiss, suppress, or interact with the notification itself (Windows does not expose a supported API for that from a script, and this post is not going to guess at an unsupported one).
Run it locally first and confirm the output against what Get-MpComputerStatus and Event Viewer show you directly, before relying on it operationally.
Run with -CsvPath to log one row per run, so a helpdesk team can build a simple audit trail of "checked, confirmed healthy" against every ticket this notification generates.
Proof it worked: reading the script's output correctly
"Proof it worked" here means proof your verification was thorough enough to trust, not proof of a fix — there isn't one yet. Three things to look for in a healthy result:
- All three independent sources agree.
Get-MpComputerStatus(the engine),sc query WinDefend(the service), and the Operational event log (the history) all need to say "healthy" together. Any one of them disagreeing is worth chasing down before you close the ticket. - No 5001 event in the recent log. This is the single most direct piece of evidence that real-time protection was never actually switched off — Microsoft's own event catalog defines 5001 as firing specifically when real-time protection is disabled, not on a timer or a health-check cadence.
- No 5013 event either. This rules out the specific scenario where something did try to weaken Defender and Tamper Protection stopped it — a different, real problem that happens to produce a similar-sounding "something is wrong with my antivirus" feeling for the end user.
If your script (or your manual checks) come back any other way — a real False on RealTimeProtectionEnabled, a stopped WinDefend service, or a genuine 5001/5013 event in the log — stop treating it as this bug. You have found a real Defender health issue, and it deserves the normal incident response your team already has for that, not a shrug because "everyone's seeing the false alert this month."
Download Get-DefenderTrueStatusReport.ps1 from Imran76Awan/Windows-Patching-Scripts — no sign-in required. It is read-only: it never calls Set-MpPreference or any other state-changing cmdlet, and never touches the notification itself. Validate it in your own environment before relying on its output.
References
- Microsoft Learn — Windows 11, version 25H2 known issues (the confirmed advisory, "Incorrect notifications that 'Microsoft Defender Antivirus is turned off'")
- Microsoft Learn — Windows 11, version 24H2 known issues (identical advisory entry)
- Microsoft Learn — Get-MpComputerStatus cmdlet reference
- Microsoft Learn — MSFT_MpComputerStatus class reference (property definitions)
- Microsoft Learn — Microsoft Defender Antivirus event IDs and error codes (full catalog, including 1150/1151/5000-5013)
- Microsoft Learn — Configure Microsoft Defender Antivirus notifications (Group Policy path for suppressing notifications)
- Microsoft Learn — Policy CSP: Defender (AllowRealtimeMonitoring and related MDM nodes)
- Microsoft Learn — Microsoft Defender for Endpoint release notes (Defender Antivirus platform/engine release history)
- Microsoft Learn — Windows message center