Cerdigent was a false positive. Check what Defender actually removed.

If Defender fired a high-severity alert for Trojan:Win32/Cerdigent.A!dha this morning, this specific alert isn’t evidence of infection on those machines. What you do need to check is whether Defender’s auto-remediation deleted trusted root certificates from your certificate store. That part has real consequences.

What happened

On April 30, Microsoft shipped Defender antimalware definition update 1.449.424.0. It introduced a new detection called Cerdigent, targeting malware signed by fraudulently issued DigiCert code-signing certificates. The signature was faulty.

Florian Roth flagged a push timestamp of roughly 04:00 UTC on May 3, when most environments started seeing the alert volume hit incident queues. Instead of flagging malicious binaries, Defender matched on two legitimate DigiCert root CA certificate entries stored in the Windows registry:

• DigiCert Trusted Root G4, thumbprint DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
• DigiCert AuthRoot (also called DigiCert Assured ID Root CA in some sources), thumbprint 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43

These registry keys live under HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\ and HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\, and they are present on standard Windows installations. By May 3, Neowin reported incident queues flooded worldwide with high-severity trojan alerts on Windows 10, Windows 11, and Windows Server endpoints. No patch, no attack, no misconfiguration. Just a bad signature update applied universally.

Microsoft pushed a corrected definition, with the fix landing in 1.449.430.0 and 1.449.431.0 (PiunikaWeb confirmed both versions resolve the issue). Verify your endpoints are on one of those versions or later before doing anything else.

Why the DigiCert breach is a separate problem

The DigiCert breach that prompted this signature is real.

A threat actor compromised a DigiCert support analyst’s machine in April, obtained initialization codes used in the certificate issuance process, and generated fraudulently issued code-signing certificates. DigiCert investigated and revoked 60 certificates in total: 27 directly tied to the threat actor, and 33 revoked precautionarily. The last revocation was on April 17. Some of those certificates were used to sign Zhong Stealer, an infostealer malware family.

Florian Roth flagged the roughly 10-day gap between the last revocation and the Defender signature push. The signature misfired and matched the root CAs instead of the malicious binaries.

The existence of a real DigiCert incident doesn’t mean your Cerdigent alert reflects a real infection. The detection flagged root certificate registry entries, not behavior. If Zhong Stealer had actually run on a machine, you’d be looking at different telemetry entirely.

What actually matters: the certificate removal

Here’s where the false positive becomes an actual operational problem.

When Defender detects something it classifies as a threat, MsMpEng.exe (running as NT AUTHORITY\SYSTEM) takes remediation action. For registry-based detections, that means deleting the flagged registry keys. On any machine where Defender ran auto-remediation before the corrected signature shipped, those DigiCert root CA entries may now be gone from the certificate store.

DigiCert root certificates are trust anchors for a substantial portion of TLS on the web. Remove them, and Windows can no longer validate certificate chains that trace back to those roots. The failure won’t be immediate on most machines because Windows caches resolved chains, but you’ll see it surface over days as:

• Browser warnings on sites with DigiCert-anchored certificates
• Application errors connecting to external services with DigiCert TLS
• Windows Update or Intune connectivity issues if DigiCert-chained certificates are in the path
• Code signing validation failures for software signed against those roots

If your software deployment pipeline, MDM solution, or monitoring stack uses certificates chained to DigiCert Trusted Root G4 or DigiCert AuthRoot, this is worth checking actively, not waiting for help desk tickets.

What to do

Start with definition version. Every endpoint should be running Defender antimalware definitions 1.449.430.0 or 1.449.431.0 or later. Check this in Defender XDR, your Intune device compliance reports, or locally via PowerShell. Anything still sitting on 1.449.424.0 through 1.449.429.x needs a forced definition update before you do anything else.

From there, identify machines where remediation already ran. If you have Defender for Endpoint with Advanced Hunting, query RegistryKeyDeleted events initiated by MsMpEng.exe against the two thumbprints, looking back from roughly 04:00 UTC on May 3. The community has published a working KQL triage query in the GitHub repo LeDevK/Cerdigent, which saves you writing it from scratch. Without XDR telemetry, fall back to the quarantine history in Defender locally or through your management console.

Once you have the affected list, restore the removed certificates. The standard recovery path is certutil -syncWithWU, which syncs the Windows Certificate Trust List from Microsoft’s servers and repopulates missing trusted root entries. It works on domain-joined machines with internet access. If your environment is air-gapped or routes Windows Update through WSUS, you’ll need to export the certificates from a healthy machine and import them via Group Policy or a deployment script. If Defender quarantined the items rather than deleting them outright, you can restore directly from the Defender quarantine, since the quarantined items are the legitimate root certificates.

Finally, if you can’t push the corrected definitions across the fleet immediately, add alert suppression rules in Defender XDR for the two thumbprints to keep the false positive from generating new incidents while the rollout completes. The LeDevK repo has guidance on this as well.

The window

This one is time-sensitive only in the sense that certificate removal damage compounds quietly. The alert itself is already fixed once you’re on 1.449.430.0 or 1.449.431.0. But if machines in your environment had auto-remediation run, you want to identify and fix them before the certificate cache misses start surfacing as user-facing outages.

Focus on the certificate store first. That’s the problem that’s sitting on your machines right now.