⚠ Situation Summary

Millions of Windows users worldwide received alarming Microsoft Defender alerts about Trojan:Win32/Cerdigent.A!dha beginning May 3, 2026. The detections are false positives caused by a faulty Defender signature update — your computer is almost certainly not infected. A fix has already been released.

What Is Trojan:Win32/Cerdigent.A!dha?

Starting on the morning of May 3, 2026, Windows users around the world began waking up to urgent security warnings from Microsoft Defender. The alert named a high-severity Trojan: Trojan:Win32/Cerdigent.A!dha. The wave of near-simultaneous reports across continents immediately raised a crucial question: was this a genuine mass infection, or something else entirely?

Security researchers quickly determined it was the latter. The Cerdigent detection is real — it was introduced by Microsoft to flag malicious certificates linked to a DigiCert breach — but its signature was written too broadly. Instead of targeting only the compromised certificates it was designed to catch, it swept up two widely-trusted, entirely legitimate DigiCert root CA certificates used by countless websites, software, and enterprise services worldwide.

“Even a clean Windows 11 install with no third-party software triggers the alert — because the problem is in Defender’s signature, not in user files.”
Confirmed by independent testing and multiple security researchers

Adding to the confusion, Defender did not simply warn users — it acted. On many affected systems, it automatically quarantined and deleted the flagged certificate registry entries, quietly removing trusted root certificates from the Windows certificate store without user confirmation.

The Background: A DigiCert Breach Sets the Stage

The story begins weeks earlier. According to a detailed incident report published in Mozilla’s Bugzilla tracking system, a threat actor gained limited access to DigiCert’s internal support systems after compromising a support analyst’s machine. Using this access, the attacker obtained initialization codes for a limited number of code-signing certificates — enough to generate certificates that appeared legitimate and were accepted by operating systems as trusted.

DigiCert investigated the breach between April 14–17, 2026, and identified 60 certificates that were potentially compromised. Of these, 27 were explicitly linked to the threat actor — 11 identified through community-reported malware samples, and 16 discovered during DigiCert’s own internal investigation. The remaining 33 were revoked as a precautionary measure. Several of the confirmed malicious certificates had been used to sign the Zhong stealer malware.

Microsoft responded by creating a new Defender signature, Trojan:Win32/Cerdigent.A!dha, to detect and block these compromised certificates. The intent was sound. The execution, however, went wrong.

What the Flawed Signature Actually Did

The Cerdigent signature was deployed in Defender Security Intelligence update 1.449.424.0 on April 30, 2026. Rather than matching only the certificate thumbprints associated with the DigiCert breach, it also matched the cryptographic thumbprints of two legitimate, long-established DigiCert root CA certificates that are part of the standard Windows trusted root store:

Certificate Name Thumbprint Status
DigiCert Assured ID Root CA 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 Incorrectly flagged & removed
DigiCert Trusted Root G4 DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 Incorrectly flagged & removed

These certificates reside in the Windows registry under HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates, the system’s trusted root certificate store. When Defender flagged them, it deleted the corresponding registry keys as part of its standard remediation — effectively telling Windows to stop trusting those certificate authorities.

The real-world consequences of having these certificates removed can include broken HTTPS connections, failures in Windows Update, TLS errors in enterprise applications, and software refusing to launch because its signing chain can no longer be verified.

A Timeline of Events

April 14–17, 2026
DigiCert investigates a breach of its internal support systems. The attacker obtained initialization codes for code-signing certificates, which were used to sign the Zhong stealer malware. DigiCert revokes 60 affected certificates.
April 30, 2026
Microsoft releases Defender Security Intelligence update 1.449.424.0, introducing the Trojan:Win32/Cerdigent.A!dha detection to target malicious DigiCert-signed certificates. The signature inadvertently also matches two legitimate root CA certificates.
May 3, 2026 — Morning
Alerts begin appearing en masse worldwide as scheduled Defender scans run. Forums, Reddit, and Microsoft’s Q&A community fill with reports. Many users panic, some begin reinstalling Windows — which does not fix the problem since the issue is in the signature, not the OS.
May 3, 2026 — Afternoon
Security researchers including Florian Roth confirm the false positive nature of the alert and identify the specific DigiCert certificate thumbprints involved. Reporting by BleepingComputer and others informs the wider public.
May 3, 2026 — Evening
Microsoft releases a fix in Security Intelligence update 1.449.430.0. The corrected signature stops flagging the legitimate certificates. The update also automatically restores previously quarantined/deleted certificates on affected systems.

Microsoft’s Response

After initially providing only automated community responses, Microsoft confirmed the nature of the false positive in an official statement:

“Following reports of compromised certificates, Microsoft Defender immediately added detections for malware in our Defender Antivirus Software to help keep customers protected.”
Microsoft — Official Statement

Microsoft moved swiftly once the scope of the problem became clear. The corrected signature update began rolling out automatically across managed endpoints, with the fix also designed to restore any DigiCert root certificates that had been removed by the erroneous earlier update. Reports from administrators confirmed that certificate restoration was occurring automatically.

The current latest Defender definition version is ✓ 1.449.431.0, which includes the fix and certificate restoration.

✓ Resolved — Action Required

The fix is available now. Simply update your Microsoft Defender definitions to version 1.449.430.0 or later. The update will both stop the false positive alerts and automatically restore any DigiCert root certificates that were removed.

How to Fix It: Step-by-Step

Update Defender Definitions (Recommended — Fastest)

  1. Open Windows Security from the Start Menu or system tray.
  2. Go to Virus & threat protection.
  3. Under “Virus & threat protection updates,” click Check for updates.
  4. Allow the update to install. Defender will update to version 1.449.430.0 or later.
  5. Run a quick scan. The Cerdigent alert should no longer appear.

Verify Your Certificates Were Restored (Optional)

  1. Open Command Prompt as Administrator.
  2. Run: certutil -store AuthRoot | findstr -i "digicert"
  3. Confirm that DigiCert entries appear in the output. If they do not, wait for the automatic restoration or re-run Windows Update.

If the alert persists after updating, reboot your machine and run the definition update check again. Automatic restoration of certificates may take a short time to propagate across all affected systems.

What Not to Do

  • Do not reinstall Windows. Testing confirms a fresh Windows 11 install with no third-party software triggers the same alert when running the affected signature version. Reinstalling solves nothing and wastes time.
  • Do not manually delete the flagged files. The “infected” objects are legitimate root certificate registry entries. Deleting them intentionally will break HTTPS and other certificate-dependent functionality on your system.
  • Do not modify your root certificate store manually. Incorrect changes to HKLM\SOFTWARE\Microsoft\SystemCertificates can cause irreversible system failures. Let Defender’s update handle the restoration.
  • Do not disable Defender long-term. Temporarily pausing real-time protection may stop the alert noise while waiting for the update, but disable it for the shortest time possible and re-enable it immediately after updating.
  • Do not pay for “removal tools.” Some websites are exploiting this incident to sell unnecessary antimalware software. The legitimate fix is free via Windows Update.

The Broader Lesson

The Cerdigent incident is a reminder of how closely interconnected modern software trust infrastructure really is. A single signature update — one that was genuinely motivated by a real threat — rippled outward to affect hundreds of millions of Windows systems worldwide. The speed with which Microsoft identified and patched the issue is commendable, but the episode underscores the need for rigorous quality controls around signature releases, particularly for detections that touch foundational OS components like the root certificate trust store.

For enterprises, the incident also highlights the importance of monitoring certificate store integrity as part of endpoint health checks. Cybersecurity researcher Florian Roth suggested the following quick diagnostic query for administrators managing fleets of Windows machines:

KQL Query for Defender XDR / Enterprise

  1. In Defender XDR, run: DeviceRegistryEvents | where ActionType == "RegistryKeyCreated" | where Timestamp > datetime(2026-05-03T04:00:00) | project Timestamp, DeviceName, ActionType, InitiatingProcessFileName | order by Timestamp desc
  2. This helps verify that certificate entries are being restored across your fleet.

The Windows certificate trust chain underpins a vast swath of the internet’s security model. When that chain is disturbed — even accidentally — the effects are immediate and global. As the world’s most widely deployed desktop operating system, Windows carries a responsibility commensurate with its reach. This incident, ultimately resolved within hours, is a case study in both the fragility and the resilience of modern security infrastructure.