Microsoft Defender briefly turned a trust problem into an enterprise outage after a bad detection update flagged two legitimate DigiCert root certificates as malware. The result was not a new threat on Windows machines, but a false alarm severe enough to quarantine certificates that many systems rely on every day.
The issue began after a Defender signature update on April 30 introduced the detection name Trojan:Win32/Cerdigent.A!dha. Instead of targeting malicious software, the logic matched on an incorrect cryptographic hash and hit trusted root certificates already present in the Windows trust store.
Trusted certificates were caught in the crossfire
The two certificates affected were DigiCert Assured ID Root CA, with thumbprint 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43, and DigiCert Trusted Root G4, with thumbprint DDFB16CD4931C973A2037D3FC83A4D7D775D05E4. Both are widely used for SSL/TLS validation, code-signing, and API calls across enterprise and consumer Windows systems.
Once Defender quarantined them, validation chains broke. Administrators then faced service issues that were difficult to trace, and some even reinstalled operating systems after seeing the Trojan alert appear in their security consoles.
Why the detection appeared in the first place
The false positive was tied to a real security incident involving DigiCert earlier in April. Attackers used a malicious ZIP file disguised as a customer screenshot to compromise two support team endpoints, and one machine was exposed after a misconfigured EDR deployment failed to stop the intrusion early.
After gaining access, the attackers reached DigiCert’s internal support portal and obtained initialization codes for a limited number of EV code-signing certificates. DigiCert later identified and revoked 60 certificates within 24 hours, including some linked to the Zhong Stealer malware campaign.
Microsoft then expanded Defender detection to protect customers from malware signed with compromised certificates. However, the detection logic cast too wide a net and ended up quarantining legitimate DigiCert root CAs instead of only the abused certificates.
Microsoft and DigiCert pushed remediation
Microsoft told BleepingComputer that it had classified the alert as a false positive and updated the detection logic. The fix arrived through Security Intelligence update 1.449.430.0, which also restored the affected certificates automatically on systems that received it.
For environments with restricted update policies, administrators may need to verify restoration manually using the command certutil -store AuthRoot | findstr -i "digicert". Microsoft also said that updating Defender through Settings, then Windows Security, Virus and Threat Protection, and Protection Updates, should help complete the recovery process.
DigiCert said on its official blog that any certificate mistakenly removed by Defender will recover automatically once the update is applied. The company also stated that there was no broader compromise of customer certificates, accounts, or systems.
Some alerts still lingered after the fix
Even after the correction was released, some users continued to see Trojan:Win32/Cerdigent.A!dha alerts on definition version 1.449.446.0. That suggested the recovery had not fully propagated across every Defender definition channel.
Microsoft recommended installing the latest Security Intelligence version, running Windows Update, and restarting the device if needed. In some cases, that extra step was enough to complete the restoration of certificates that had been quarantined earlier.
The incident adds to a crowded period of Microsoft update problems in April and May, when administrators also dealt with KB5083769 boot loops on HP and Dell machines, forced upgrade pushes to Windows 11 25H2, and updates that broke third-party backup tools from Acronis and Macrium. For enterprise IT teams, the lesson is straightforward: an aggressive security update can become an operational outage when it touches core trust infrastructure.
Source: www.notebookcheck.net