Microsoft confirmed the false alerts on August 28 and listed the originating update as N/A, leaving administrators nothing to roll back and no way to suppress them.
On Friday, August 28, 2026, at 3:34 p.m. PT, Microsoft opened a known issue on the Windows release health dashboard confirming that Windows is telling people their antivirus is switched off when it is not. The entry was updated at 4:02 p.m. PT the same day and its status is “Confirmed.” That confirmation is the development; the underlying behavior has been reported by users in the Release Preview channel since June, according to BleepingComputer, which covered the acknowledgment on Monday, August 31, 2026.
Two details make this more than a cosmetic annoyance. The dashboard lists the originating update as “N/A” — there is no KB to identify, defer, or uninstall. And Microsoft’s own description says the notifications “persist even if notification settings are turned off,” which means the false alert cannot be suppressed by the mechanism that suppresses alerts.
What happened
The release health entry is titled: Incorrect notifications that “Microsoft Defender Antivirus is turned off.” Microsoft’s description reads, in full: “After installing the latest updates for Microsoft Defender Antivirus, notifications might appear stating that ‘Microsoft Defender Antivirus is turned off,’ even though the antivirus is functioning correctly and all settings show it as active. These notifications can appear when Windows starts and intermittently afterward. They persist even if notification settings are turned off.”
On scope, Microsoft is unusually broad: “This issue can be observed in any version of Windows or Windows Server with Microsoft Defender Antivirus running with the latest Defender updates.” The platform list bears that out. Client: Windows 11 versions 26H1, 25H2, 24H2, and 23H2; Windows 10 versions 22H2 and 21H2, plus Enterprise LTSC 2019 and Enterprise LTSC 2016. Server: Windows Server 2025, 2022, 2019, 2016, 2012 R2, and 2012. That is effectively every supported Windows installation running Defender.
Under next steps, Microsoft says: “We are working to release a resolution in a future Microsoft Defender Antivirus update and will provide more information when it is available.” No workaround is offered, no target date is given, and no specific Defender platform or security intelligence build is named as the one that introduced the defect.
That last omission is the operationally significant one. Release health entries normally carry an originating update — a KB number that tells administrators which cumulative update introduced a regression, and therefore which one to hold back or remove. This entry lists “N/A” and points instead at “the latest updates for Microsoft Defender Antivirus,” which is a different channel entirely: the Defender platform and security intelligence updates that flow continuously, automatically, several times a day in the case of definitions, and that most organizations neither pin nor roll back by design, because pinning them is itself a security risk.
So the defect sits in the fastest-moving, least-controlled update stream in the Windows estate, and Microsoft has not said which build in that stream carries it. An administrator who wants to determine whether a given machine is affected has nothing to compare against.
Why it matters
A status indicator on a security control is part of the control. The value of a notification reading “Microsoft Defender Antivirus is turned off” comes entirely from the fact that it is rare and it is true. It appears when protection has actually stopped — because a policy misfired, because a third-party product took over and then failed, or because something on the machine disabled it deliberately. Disabling Defender is a standard early step in a hands-on-keyboard intrusion, and it is one of the more reliable tamper signals a Windows shop has.
Microsoft has now told every Windows user and every help desk in the world that this specific message is noise. That instruction is correct today and it is corrosive over any longer period. The people who see the toast are being trained, at scale and with the vendor’s endorsement, to dismiss the one notification whose entire purpose is to be undismissable. Whatever the fix date turns out to be, the habit outlasts it.
The suppression detail sharpens it further. Because the notifications ignore the notification settings, an administrator cannot make them go away by policy. The available responses are to leave a false security warning firing at every boot on the entire fleet, or to work around it somewhere further out — in the ticketing queue, in a monitoring rule, in a written instruction to staff. Every one of those workarounds degrades the real signal along with the false one. A SOC that tunes out Defender-disabled telemetry to stop the flood has removed a detection; a service desk that adds “ignore antivirus warnings” to its scripted response has removed a reporting path. Neither of those comes back automatically when Microsoft ships the fix.
The “N/A” originating update is a smaller thing that says something about the reporting model. Release health exists so that administrators can reason about cause and rollback. When the cause is in the Defender update channel, that reasoning is not available: there is no equivalent of holding back a cumulative update, and Microsoft did not name a build. The entry confirms the symptom and withholds everything that would let an organization scope it. Confirmed and unactionable is an unusual combination for a dashboard whose purpose is action.
This is a familiar shape. Severity Daily reported on August 29 that CISA’s own assessment of the two exploited PaperCut vulnerabilities still recorded exploitation as “none” a day after the vendor said customers were under attack. The pattern is the same in both directions: the authoritative status display and the actual state of the world come apart, and the people relying on the display have no way to tell from the display itself. In the PaperCut case the record was too quiet. Here it is too loud. The failure mode is identical — a signal that no longer carries information.
What to do
Stop treating the toast as the source of truth and query the service directly. On any machine in question, run Get-MpComputerStatus and read AMServiceEnabled, AntivirusEnabled, and RealTimeProtectionEnabled. That is the authoritative state, and it is what Microsoft is saying will show protection as active while the notification claims otherwise. Push the same check through your management tooling so you can answer the question fleet-wide rather than one desktop at a time.
Correlate against the event log rather than the notification. The Microsoft-Windows-Windows Defender/Operational log records real-time protection being disabled as event ID 5001, and configuration changes as event 5007. A genuine disablement leaves a trail there; a false notification does not. If your endpoint telemetry already ingests that log, the discriminator you need is in place today.
Do not disable your Defender-tamper detections to stop the noise. If the alert volume is unmanageable, gate on the event log or on Get-MpComputerStatus output rather than turning the rule off, and write down that you did it so it gets reversed when Microsoft ships the fix. Rules disabled during an incident of convenience are rarely re-enabled on schedule.
Brief the service desk with the verification command, not with “ignore it.” The distinction costs one line in a script and preserves the reporting path for the machine where the warning is real. Expect ticket volume from the whole estate, including servers, and expect it at boot.
Track the release health entry rather than waiting for a KB. There is no update to uninstall and no build to avoid, so the only signal that this is resolved will be Microsoft updating the item. Its status today is “Confirmed” with no resolution date.
Sourcing note
Checked: the Windows release health status page for Windows 11 version 25H2, read directly, for the issue title, the verbatim description and next steps, the “Confirmed” status, the “N/A” originating update, the opened and last-updated timestamps of August 28, 2026 at 3:34 p.m. PT and 4:02 p.m. PT, and the full client and server platform list. BleepingComputer’s August 31, 2026 report is the source for the statement that users reported the behavior in the Release Preview channel starting in June; Microsoft’s entry does not mention pre-release reporting and Severity Daily could not confirm it against a Microsoft source.
Not reached: any Microsoft statement naming the Defender platform or security intelligence build that introduced the defect. No such build is identified on the release health entry, and none was found in the Defender release notes referenced from it. The remediation guidance above uses standard Defender status and event-log checks rather than anything Microsoft has published for this issue, because Microsoft has published no workaround.
Unresolved: which Defender update causes the false notification, whether machines can be assessed as affected or unaffected before the notification appears, and when the fix ships. Microsoft has committed only to “a future Microsoft Defender Antivirus update.”