Microsoft recorded the issue as confirmed on August 28, 2026. The company says it is working on a resolution to be delivered in a future Microsoft Defender Antivirus update. At the latest available check on August 31, Microsoft had not identified the update that introduced the problem, a Defender version containing the correction, or a release date.
What Microsoft has confirmed
The known issue concerns notifications that say “Microsoft Defender Antivirus is turned off.” In the affected scenario, the warning can appear after the latest Defender updates despite the antivirus operating normally and all relevant settings reporting that it is active.
The behavior is not limited to a single pop-up at the moment an update is applied. Microsoft says notifications can appear at Windows startup and intermittently afterward. More unusually, they may continue even after notification settings have been disabled. That persistence means users may reasonably conclude that Windows Security is reporting an ongoing security condition rather than a stale or cosmetic warning.
Microsoft’s wording is important: it identifies an incorrect-notification condition, not a confirmed shutdown of the antivirus service. The advisory does not tell people to dismiss Defender warnings wholesale. It establishes that this particular message can be inaccurate under the described circumstances, and that endpoint protection must be checked before deciding what the warning means.
That nuance should guide both consumer troubleshooting and enterprise response. A security notification is an interface signal, not in itself definitive proof of the state of every protection component. Conversely, a documented false signal does not prove that a particular machine is protected.
Windows and Windows Server scope
Microsoft’s release-health entry says the condition can be observed in any version of Windows or Windows Server when Microsoft Defender Antivirus has the latest Defender updates. That broad description defines the potential condition; it should not be read as a finding that every device, build, or configuration will display the misleading message.
The record separately enumerates affected platforms. Its client list includes Windows 11 versions 26H1, 25H2, 24H2, and 23H2; Windows 10 versions 22H2 and 21H2; and Windows 10 Enterprise LTSC 2019 and 2016. The server list includes Windows Server 2025, 2022, 2019, 2016, and Windows Server 2012 R2 and 2012.
The platform list is useful for prioritizing testing and support communications, while Microsoft’s broader statement means administrators should not use an operating system’s absence from that enumeration alone to rule out the condition. Equally, the advisory does not provide incidence rates or identify a role, build, management method, or Defender configuration that is especially likely to produce the bad notification.
For administrators, that breadth means it would be unwise to assume that a clean result on one ring of endpoints rules out the condition elsewhere. At the same time, the lack of a known originating update and a version-based remediation makes broad rollback or blanket change decisions difficult to justify from the available information alone.
Do not confuse it with a real Defender-off state
The key counterpoint is straightforward: Defender being shown as disabled can be entirely legitimate. Microsoft documents that when a current non-Microsoft antivirus or antimalware product is installed, Defender capabilities can be disabled or placed in passive mode. The Windows Security app can indicate Defender is disabled in that configuration.
This is why an alert matching the language of the known issue should not automatically be labeled a false positive. A PC that has a third-party security product installed may be behaving as designed. A device may also require investigation for reasons unrelated to the false-notification defect. The confirmed issue only says that some notifications may be incorrect after the relevant Defender updates; it does not override the normal relationship between Defender and another antivirus product.
For a home PC, start with context. Has another antivirus package been installed, renewed, removed, or partially uninstalled? Does Windows Security indicate that a different provider is handling antivirus protection? If so, the correct question is whether that provider is current and operating, not whether Defender must be active simultaneously.
For managed environments, the same principle applies at scale. Inventory the intended security product and configuration for the endpoint before opening an incident solely because the notification says Defender is off. Devices designed to use a non-Microsoft antivirus product should not be measured against the same expected Defender state as devices intended to run Defender in normal active protection mode.
Verify protection state on the affected device
Because the visible warning may be wrong, Microsoft’s documented status tooling provides a more useful endpoint-specific check. The PowerShell cmdlet Get-MpComputerStatus retrieves the status of installed antimalware software. Its reported properties include AMRunningMode, AMServiceEnabled, AntivirusEnabled, and RealTimeProtectionEnabled.
On a device expected to use Defender as its active antivirus, values such as a normal running mode and enabled antivirus service, antivirus protection, and real-time protection are materially more relevant than an isolated toast notification. They support the conclusion that the reported “turned off” message matches Microsoft’s known false-notification condition.
That interpretation remains conditional. Get-MpComputerStatus output must be assessed against the endpoint’s intended antivirus configuration. In particular, a current third-party antivirus product can legitimately leave Defender in passive or disabled mode, so results that would be concerning on a Defender-managed machine may be expected on a machine protected by another approved product.
The opposite is also true: results that do not show the expected protection state should not be waved away because the advisory exists. They warrant investigation under the organization’s ordinary endpoint-security process. The cmdlet’s fields are useful evidence, but their expected values depend on the machine’s intended security design, including whether another current antivirus product is installed.
This approach avoids two bad shortcuts:
- Ignoring the warning without checking anything. A genuine protection problem can still occur and needs a response.
- Escalating every warning as a confirmed outage. In the confirmed defect scenario, Defender remains active and the notification itself is inaccurate.
Administrators can turn that distinction into a practical triage rule: classify the notification only after checking the device’s intended antivirus provider and the actual protection status. Record the notification separately from the validated endpoint state. Doing so prevents a display issue from becoming misleading evidence in security or compliance workflows.
Why repeated false alarms are still disruptive
Microsoft’s public advisory does not report exploitation, alert suppression, or increased compromise attributable to this defect. Repeatedly unreliable security messages could create operational concerns, but those outcomes must not be presented as demonstrated consequences of this incident.
Still, the operational impact is concrete even without evidence of exploitation. Users may spend time trying to re-enable a product that is already active. Help desks may receive duplicate tickets. Administrators may see a mismatch between user-facing alerts and device-level verification. If notifications recur after notification settings are changed, the issue can also weaken confidence in the controls that are meant to manage alerts.
The appropriate response is not to normalize failure messages. It is to make the verification path clear and consistent. A user who sees the message should know whether to check Windows Security, confirm the installed antivirus provider, or contact IT. Support personnel should have a defined way to confirm Defender’s state on a device expected to run it. Security teams should preserve the difference between a user-interface notification and evidence that an endpoint has lost protection.
This is especially important on servers. A noisy warning on a server console can prompt an urgent reaction, but the published advisory covers a notification defect, not a documented service outage. Server teams should validate the status of the relevant security components before changing protection settings or making broad configuration changes. The available information also does not establish whether enterprise telemetry or compliance reporting is affected, so organizations should not assume that every security-management signal shares the defect.
What not to do while waiting for a fix
Microsoft’s current public position is limited: a future Defender Antivirus update is planned. There is no identified originating update, affected Defender version, fixed version, or delivery date in the published record. That leaves little basis for confidently naming an update to uninstall, blocking a particular package, or declaring a workaround beyond verifying actual protection state.
Avoid disabling Defender, real-time protection, or another working antivirus product merely to make the warning disappear. Such steps could transform a false notification into a real security gap. Likewise, avoid disabling all notification mechanisms as a general solution. Microsoft says the misleading notices can persist even with notification settings disabled, and suppressing alerts broadly can make genuine future issues harder to notice.
For organizations, a measured interim plan is more defensible:
- Identify endpoints that report the specific Defender-off notification.
- Check whether the device is intended to use Defender or a current third-party antivirus product.
- Validate the relevant antimalware status on devices expected to use Defender.
- Treat a notification as a known false positive only when the local protection state supports that conclusion.
- Keep normal processes for genuine disabled-protection findings intact.
- Monitor for the future Defender Antivirus update Microsoft has said will resolve the issue.
This process does not require assuming that all alerts are harmless or that all machines have identical antivirus configurations. It gives IT teams a way to reduce unnecessary escalation while preserving a path for detecting real protection failures.
The larger lesson: security signals need corroboration
The incident is a reminder that endpoint security depends on more than whether a warning appears on screen. Notifications are valuable because they draw attention quickly, but they are only one layer of evidence. The strongest operational response pairs the alert with the device’s actual antivirus configuration and status.
For Windows users, that means resisting both panic and complacency. The message may be a confirmed false notification if Defender is active, but it may also reflect an expected switch to another antivirus provider or an issue that needs support. For IT administrators, it means documenting a verification workflow now, rather than teaching users to ignore a security message whose meaning depends on the endpoint.
Until Microsoft publishes the corrective Defender update, the safest posture is precise: acknowledge the confirmed bug, validate the protection state of the individual system, and continue treating verified disabled antivirus protection as a real security concern.