The Antivirus Turned Off Notification Can Appear While Defender Is Still Running

A notification stating that "Microsoft Defender Antivirus is turned off" is, on most machines showing it right now, wrong. Microsoft opened a known issue for exactly this behavior on 2026-08-28 at 15:34 PT and it remains at status Confirmed as of this writing. The company's own description says the message can appear "even though the antivirus is functioning correctly and all settings show it as active."

The correct response is not to reinstall anything, not to run a repair, and not to install a second antivirus product alongside Defender. The correct response is to spend four minutes confirming the real protection state from sources that report the engine rather than paint a message, and then leave the machine alone.

Three checks do that. They are ordered so that the cheapest and most decisive one runs first, and so that each later check only matters if the earlier one came back clean.

The Three Checks, In Order

Each step below answers a different question. Step 1 asks whether the antimalware service considers itself on. Step 2 asks whether anything ever switched it off. Step 3 asks whether the guardrail that would have prevented a silent shutdown was in place. A machine that clears all three is displaying a cosmetic defect, and the useful action is to stop.

Check 1 — Ask the Antimalware Service Directly

Open Windows PowerShell and run a single cmdlet:

1. Run Get-MpComputerStatus with no parameters.
2. Read the values for AMServiceEnabled, AntivirusEnabled, AntispywareEnabled, and RealTimeProtectionEnabled.
3. Read AMRunningMode, which reports the operating mode of the antimalware service.
4. Note AMEngineVersion and AMProductVersion before closing the window, because those two values identify which Defender build the machine is on.

Microsoft's reference page for this cmdlet describes it in one line: "Gets the status of antimalware software on the computer." That is the whole point of running it. The cmdlet does not read a notification cache or a tile color. It returns the state the antimalware service itself reports.

On a machine affected by this issue, every one of those boolean properties comes back True and AMRunningMode comes back Normal, while the notification continues to insist the opposite. That combination is the signature of the defect. There is nothing subtle about reading it; the values are printed as plain text in the console.

If instead RealTimeProtectionEnabled or AntivirusEnabled returns False, the notification is accurate and the rest of this article does not apply. Skip ahead to the section on a genuine shutdown.

One practical note on scope. The documented example output for this cmdlet includes thirty-three properties, among them BehaviorMonitorEnabled, IoavProtectionEnabled, OnAccessProtectionEnabled, and AntivirusSignatureVersion. Reading the four listed above is sufficient for this decision. The others matter for a deeper audit, not for separating a false message from a real gap.

Check 2 — Look for the Event a Real Shutdown Would Have Written

Defender writes a dedicated event whenever real-time protection actually stops. If protection genuinely went down, that record exists. If it does not exist, protection did not go down.

The log lives at Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational in Event Viewer. Filter it to the window of time around the moment the notification appeared, and look for two event IDs in particular.

• Event ID 5001, symbolic name MALWAREPROTECTION_RTP_DISABLED. Its message text reads "Real-time protection is disabled." This is the record of real-time scanning being switched off.
• Event ID 5010, symbolic name MALWAREPROTECTION_ANTISPYWARE_DISABLED. Its message text reads "Scanning for malware and other potentially unwanted software is disabled."

Neither event present in that window means nothing turned protection off, which means the notification is describing a state the machine was never in. That is the second and strongest confirmation available without vendor tooling.

If either event is present, the log gives a way to find the cause. Event ID 5007, symbolic name MALWAREPROTECTION_CONFIG_CHANGED, carries the message "The antimalware platform configuration changed." Its documented description is blunt about what to do with it: "Microsoft Defender Antivirus configuration changed. If this event is unexpected, you should review the settings as the event might be the result of malware." The 5007 entry records an old value and a new value, so pairing it with the 5001 timestamp usually identifies what changed and when.

A related entry worth recognizing is Event ID 5004, MALWAREPROTECTION_RTP_FEATURE_CONFIGURED, whose message is "The real-time protection configuration changed." That one records a feature-level configuration change rather than a full disable, and it names the specific feature involved. It is not by itself evidence that protection stopped.

Reading vendor event logs to separate a cosmetic symptom from a functional one is the same technique that resolves several other post-update reports on Windows. The same approach applies to games that freeze or close without warning after Windows 11 KB5121003, where the driver named in the logs is what decides whether the fault is the game or the system.

Check 3 — Confirm the Guardrail Was in Place

Tamper protection is the control that keeps Defender settings from being switched off behind the user's back. Microsoft's support documentation describes it as a feature that helps prevent malicious apps from changing important Microsoft Defender Antivirus settings, naming real-time protection and cloud-delivered protection specifically.

Its state is reachable at Windows Security app > Virus & threat protection > Manage settings > Tamper protection. If that setting reads On, then a silent disable of real-time protection was not available to ordinary software in the first place, which corroborates what the first two checks found.

The enterprise documentation enumerates what stays fixed while tamper protection is on, and the list includes the two items most relevant here: "Real-time protection remains turned on." and "Notifications are visible in the Windows Security app on Windows devices." That second line is worth dwelling on. Tamper protection guarantees that notifications keep being shown. It makes no guarantee that a shown notification is correct. Message delivery and message accuracy are different properties, and only the first one is in scope.

There is one trap in this area that produces false confidence in both directions. The same documentation warns that "changes made to tamper-protected settings might appear to succeed but are actually blocked by tamper protection." A toggle that visually moves is therefore not evidence that the underlying setting moved. Anything toggled during troubleshooting should be re-verified with Get-MpComputerStatus rather than trusted on the strength of how the interface looked afterward.

If tamper protection reads Off, turn it on and then repeat Check 1. A machine without that guardrail has a much wider range of explanations for a genuinely disabled scanner, and the conclusion in this article should not be applied until the guardrail is restored and the service state re-read.

Why the Message and the Service Disagree

The single most useful field on Microsoft's own entry for this issue is the one most people skip: Originating update: N/A. Every other current entry on that dashboard names a KB number. This one names none, and that absence is informative rather than incidental.

Microsoft's Defender release page lists the Defender Antivirus build separately from any Windows KB number. The current Defender release is identified by platform 4.18.26080.3 and engine 1.1.26080.3, with security intelligence at 1.159.11.0. Microsoft's description ties the symptom to that track directly, stating the notifications may appear after installing the latest updates for Microsoft Defender Antivirus.

Two consequences follow, and both are practical. First, there is no cumulative update to uninstall, so the familiar remediation of rolling back last month's patch has no target here. That distinguishes this case from issues such as USB audio devices left at Code 10 by KB5124008, where a specific package is named and the rollback question is at least coherent. Second, Microsoft says the resolution will come in a future Microsoft Defender Antivirus update, so the signal to watch for is a Defender version change rather than a new KB entry.

The scope is deliberately broad in the vendor text: "This issue can be observed in any version of Windows or Windows Server with Microsoft Defender Antivirus running with the latest Defender updates." The published affected list runs to eight client releases, from Windows 11 version 26H1 down to Windows 10 Enterprise LTSC 2016, plus six server releases from Windows Server 2025 back to Windows Server 2012. An issue that spans that much of the estate is almost never a per-machine misconfiguration.

The behavior of the notification itself is also documented, which helps distinguish it from an ordinary alert. It reportedly recurs on a schedule rather than once: "These notifications can appear when Windows starts and intermittently afterward." And the usual escape hatch does not work, because "They persist even if notification settings are turned off." A message that ignores the setting meant to silence it is a strong hint that the message path, not the protection path, is what is broken.

When the Notification Is Accurate

The checks above exist precisely so that a real failure is not dismissed as a known cosmetic bug. If Check 1 returned False for RealTimeProtectionEnabled or AntivirusEnabled, or Check 2 surfaced event 5001 or 5010, the machine is genuinely unprotected and the sequence changes.

1. Confirm no third-party antivirus was installed recently. Read AMRunningMode, which the documented example output shows as Normal on a standard configuration.
2. Read the Event ID 5007 entry nearest the 5001 timestamp and compare its recorded old value against its new value to identify what configuration changed.
3. Check whether tamper protection was Off at the time. A disable that succeeded implies either the guardrail was down or the change came through a management channel.
4. Re-enable protection, then re-run Get-MpComputerStatus and confirm the properties flipped to True rather than trusting the interface.
5. If the setting refuses to stay on across a reboot, escalate to vendor support with the 5001, 5007, and 5010 entries exported, since those timestamps are what an engineer will ask for first.

The 5007 description is explicit that an unexpected configuration change deserves scrutiny rather than a shrug, so treat an unexplained entry as a security question and not merely a settings question.

What Not to Do While the Fix Is Pending

• Do not install a second real-time antivirus. Two real-time scanners on one machine cause the overlap problems this blog covers regularly, and the first product was never actually off.
• Do not uninstall a cumulative update. The originating update field is N/A. Removing a patch trades a cosmetic message for a real security regression.
• Do not reset or reinstall Windows. The affected-platform list spans fourteen releases, which rules out local corruption as the explanation.
• Do not toggle Defender settings repeatedly. Tamper protection may block the change while the interface suggests it succeeded, leaving an inaccurate mental model of the machine's state.
• Do not silence the message by turning off notifications. Microsoft's own text records that the message persists regardless, and a blanket notification change would suppress genuine alerts later.

Reading a Windows Security message literally, without checking what it actually asserts, is a recurring source of unnecessary work. The same discipline applies to the device security area, where several Secure Boot status messages share nearly identical opening wording while requiring completely different responses. In both cases the fix begins with establishing what the message is actually claiming.

When This Doesn't Apply

This analysis is narrow on purpose, and several nearby situations fall outside it.

• A third-party antivirus is installed and registered. The sources behind this article document only Defender's own reported state, so a Defender-off message on such a machine falls outside what they establish. Read AMRunningMode before concluding anything.
• Check 1 returns any False value. That machine has a real gap, and none of the reassurance here transfers to it.
• Event 5001 or 5010 appears in the Operational log. A logged disable event is a factual record. It outranks any claim that the notification is spurious.
• The device is managed by an organization. Policy, Intune configuration, or Configuration Manager can legitimately disable components, and the local read may not reflect the managed intent. Route it through the internal help desk rather than changing settings locally.
• The message text differs from the documented wording. The known issue covers a specific claim about Microsoft Defender Antivirus being turned off. A different alert, such as one about expired signatures or a failed scan, is a separate matter with its own remediation.
• Defender is not the product in question. Notifications from a different security suite are governed by that vendor's release notes, not by the Windows release health dashboard.
• The reader is looking at a status tile rather than a notification. The documented symptom is a notification appearing while settings continue to show protection as active. A settings page that itself reports protection as off is a different observation.

Tracking the Fix to Closure

The issue remains at status Confirmed with no resolution date published. Microsoft states that a resolution is planned for a future Microsoft Defender Antivirus update, with more information to follow when it is available. There is no workaround offered, and none should be improvised, because the underlying protection is not impaired.

For anyone tracking this on more than one machine, the monitoring points are straightforward:

1. Watch the Windows release health known issues page for the release the fleet runs, and check whether the status moves from Confirmed to Mitigated or Resolved.
2. Watch the Defender release page for a platform version higher than 4.18.26080.3 or an engine version higher than 1.1.26080.3.
3. Re-run Get-MpComputerStatus after a platform bump and record AMProductVersion so the before-and-after is documented.

Primary sources for everything above: the Windows 11 version 25H2 known issues page and the matching Windows 11 version 26H1 known issues page, which both carry this entry; the Get-MpComputerStatus cmdlet reference; the Defender Antivirus event ID reference for 5001, 5004, 5007, and 5010; the tamper protection overview and the Windows Security tamper protection article; and the Microsoft Defender for Endpoint releases page for current platform and engine versions.

The short version stands: a notification is a claim, and Get-MpComputerStatus is a measurement. On this defect the measurement wins, and the correct action after confirming it is to close the console and change nothing.