Microsoft Defender is incorrectly flagging valid DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha, causing widespread false alarms and, in some instances, deleting these certificates from Windows systems.
Cybersecurity specialist Florian Roth notes that the problem began after Microsoft included these detections in a Defender signature update released on April 30th.
System administrators around the globe started noticing that DigiCert root certificate entries were being marked as malicious software and, on impacted machines, were being removed from the Windows certificate trust store.
A Reddit thread discussing the false positives identified the following certificates as being affected:
- 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43
- DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
On affected machines, these certificates were deleted from the AuthRoot store located at this Registry path:
HKLMSOFTWAREMicrosoftSystemCertificatesAuthRootCertificatesThese false alarms have sparked anxiety among Windows users, with some believing their computers were compromised and choosing to reinstall their operating systems as a precaution.

Source: Reddit
Microsoft has apparently resolved the detection issue in Security Intelligence update version 1.449.430.0, with the latest update now being 1.449.431.0.
Additional Reddit posts suggest that the fix also reinstates certificates that were previously removed from affected systems.
The updated Microsoft Defender definitions will install automatically, though Windows users can manually trigger an update by navigating to Windows Security > Virus and threat protection > Protection updates and selecting Check for Updates.
Potential connection to a recent DigiCert security breach
The false positives emerged shortly after DigiCert disclosed a security breach that allowed attackers to acquire legitimate code-signing certificates, which were then used to sign malicious software.
“A malware attack targeted a member of our customer support team. Once detected, the attack vector was immediately contained,” DigiCert stated in its incident report.
“Our follow-up investigation revealed that the attacker managed to obtain initialization codes for a small number of code signing certificates, some of which were subsequently used to sign malware.”
“The affected certificates were revoked within 24 hours of being discovered, with the revocation date backdated to their original issuance date. As a preventive step, pending orders within the relevant timeframe were cancelled. Further details will be shared in our comprehensive incident report.”
DigiCert’s report indicates that in early April, attackers targeted the company’s support personnel by submitting support tickets containing a malicious ZIP file disguised as a screenshot.
After several unsuccessful attempts, one support analyst’s computer was eventually compromised, followed by a second machine that remained undetected for a period due to a gap in endpoint protection monitoring.
With access to the compromised support environment, the attacker exploited a feature in DigiCert’s internal support portal that permitted support staff to access customer accounts from the customer’s viewpoint.
Although the scope was limited, this access revealed “initialization codes” for previously approved but not yet delivered EV code-signing certificate orders.
“Having both an initialization code and an approved order is enough to obtain the corresponding certificate (see Contributing Factors discussion below),” DigiCert explained.
“Because the attacker could gather both pieces of information for a specific set of approved orders, they were able to acquire EV Code Signing certificates across multiple customer accounts and certificate authorities.”
DigiCert confirmed it revoked 60 code-signing certificates, 27 of which were associated with a “Zhong Stealer” malware campaign.
“11 were identified through certificate problem reports submitted to DigiCert by community members who linked the certificates to malware, and 16 were discovered during our internal investigation,” DigiCert stated.
Zhong Stealer malware operation
This matches earlier findings from security researchers who had observed newly issued DigiCert EV certificates being used in malware operations and had reported them to DigiCert.
Researchers including Squiblydoo, MalwareHunterTeam, and g0njxa reported that certificates issued to reputable companies such as Lenovo, Kingston, Shuttle Inc, and Palit Microsystems were being used to sign malicious software.
“What connects Lenovo, Kingston, Shuttle Inc, and Palit Microsystems?” Squiblydoo posted on X.
“EV Certificates belonging to these companies were issued and exploited by a Chinese criminal group, #GoldenEyeDog (#APT-Q-27)!”
The malware in this operation is called “Zhong Stealer,” though analysis suggests it functions more like a remote access trojan (RAT) than a traditional information stealer.
The researcher outlined the malware’s distribution chain as follows:
- Phishing emails delivering a fake image or screenshot
- An initial executable that shows a decoy image
- Downloading a second-stage payload from cloud storage services like AWS
- Deployment of signed binaries and loaders, including components associated with legitimate vendors
After DigiCert published its incident report, the researchers noted that the report clarified how the certificates used in these malware campaigns had been obtained.
While Microsoft has not officially confirmed that the Defender detections are linked to the DigiCert breach, the timing and the focus on DigiCert-related certificates point to a possible connection.
It is important to note, however, that the certificates flagged by Microsoft Defender are root certificates in the Windows trust store and are not the same as the revoked DigiCert code-signing certificates that were used to sign malware.
BleepingComputer reached out to Microsoft with questions about the incident, including whether it was related to DigiCert’s security breach.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.
At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what’s exploitable, proves controls hold, and closes the remediation loop.
Claim Your Spot



