Microsoft Defender Mistakenly Flags DigiCert Root Certificates as Malware

Related

Canada Arrests Three for Operating SMS Blaster Device in Toronto

What happened Canadian authorities have arrested three men for operating...

Alleged Silk Typhoon Hacker Extradited to US for Cyberespionage

What happened A Chinese national accused of conducting cyberespionage operations...

Pentagon Grapples With Securing AI as It Moves Toward Autonomous Warfare

What happened Senior US military leaders are publicly wrestling with...

Share

What happened

A faulty Microsoft Defender antimalware signature update released around April 30, 2026, caused widespread false positive alerts by incorrectly flagging two legitimate DigiCert root certificates as high-severity malware. The detection, labeled Trojan:Win32/Cerdigent.A!dha, identified registry entries belonging to DigiCert Assured ID Root CA and DigiCert Trusted Root G4 as threats and automatically quarantined them from the Windows trust store as part of Defender’s standard remediation workflow.

The quarantine of these root certificates created significant downstream risk. Without them in place, systems could fail to validate SSL/TLS connections and break code-signing verification for legitimate software, potentially cascading into service disruptions, browser certificate warnings, and application failures across enterprise networks. Organizations relying on DigiCert-signed software or HTTPS endpoints backed by these roots were particularly exposed.

Microsoft acknowledged the issue and rolled out corrective definition updates, with version .430 cited as a key fix that began restoring the quarantined certificates on affected machines. The restoration appeared to deploy automatically across managed endpoints. Administrators in environments with restricted update policies were advised to manually verify certificate presence using certutil -store AuthRoot | findstr -i “digicert” and to check Advanced Hunting logs in Microsoft Defender for Endpoint to confirm restoration. No actual compromise of the certificates occurred. Certificate hashes confirmed by administrators matched officially published DigiCert values.

Who is affected

Enterprise environments running Microsoft Defender with automatic remediation enabled and automatic updates applied around April 30 are directly affected. Organizations with restricted update policies that did not receive the corrective definition update automatically face an ongoing risk of SSL/TLS validation failures and code-signing disruptions until the certificates are manually restored.

Why CISOs should care

This incident illustrates the operational risk inherent in automated threat remediation acting on foundational infrastructure components. The same mechanism that protects against certificate store tampering, a documented malware technique, can cause significant service disruption when triggered incorrectly. A single faulty signature update targeting the Windows root certificate trust store has the potential to cascade into broad SSL/TLS failures across an entire enterprise environment within the time it takes for automatic remediation to run.

For security leaders who have fully automated Defender remediation without compensating monitoring controls, this incident is a useful prompt to assess what circuit breakers exist between a signature update and irreversible remediation actions on critical system components.

3 practical actions

  1. Verify DigiCert root certificate restoration on all affected endpoints: Run certutil -store AuthRoot | findstr -i “digicert” on systems that received Defender updates around April 30 to confirm both DigiCert Assured ID Root CA and DigiCert Trusted Root G4 are present. Use the Advanced Hunting query published by Florian Roth to identify devices where the RegistryKeyCreated action confirms restoration has occurred.
  2. Review Defender remediation policies for detections targeting the Windows certificate trust store: Automatic quarantine of registry entries under HKLM\SOFTWARE\Microsoft\SystemCertificates is a high-impact action that warrants additional validation before execution. Assess whether your Defender configuration includes any review step or alert escalation for detections in this path before remediation runs automatically.
  3. Establish monitoring for SSL/TLS validation failures as an early warning indicator of certificate store disruption: The operational impact of this incident would have been detectable through application errors, browser certificate warnings, and code-signing failures before administrators identified the root cause. Monitoring for these signals as a category, separate from security alerting, provides earlier warning when certificate infrastructure is disrupted whether by a faulty update or an actual attack.
e1057c44fd23a2339dd83fc7bd88822e97b8b3544e012414c207939b16e0441d?s=150&d=mp&r=g
+ posts