TL;DR
- False Positive: A Microsoft Defender signature update on April 30, 2026 misclassified two legitimate DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha.
- Quarantine Impact: Defender quarantined the DigiCert Assured ID Root CA and Trusted Root G4 entries, breaking SSL/TLS validation on affected endpoints.
- Corrective Update: Microsoft fixed the detection in Security Intelligence version 1.449.430.0 and restored removed certificates with version 1.449.431.0.
- Residual Exposure: Endpoints whose update policies blocked the corrective definition will keep failing SSL/TLS validation until administrators deploy 1.449.430.0 or later.
Microsoft on April 30 released a Defender signature update that misclassified two legitimate DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha, quarantining the certificates from the Windows trust store and breaking SSL/TLS validation on affected endpoints before Microsoft shipped a fix.
Both DigiCert Assured ID Root CA and DigiCert Trusted Root G4 were caught by the faulty antimalware signature update, in some cases removing their entries from Windows. Microsoft fixed the false positive in Security Intelligence update version 1.449.430.0, with version 1.449.431.0 also restoring the removed certificates on affected systems.
Anyone else seeing Microsoft #Defender flagging #DigiCert root certificate registry keys as malware?
We’ve seen reports that Defender signature update from April 30 added a detection called:
Trojan:Win32/Cerdigent.A!dha
In some environments, Defender apparently detected…
— Florian Roth ⚡️ (@cyb3rops) May 3, 2026
Inside the False Positive
Microsoft added the Trojan:Win32/Cerdigent.A!dha detections to a Defender signature update on April 30, 2026, following reports of compromised certificates from a recent DigiCert breach. Within hours those detections began matching the registry entries for two legitimate DigiCert root certificates instead of only the revoked code-signing certificates Microsoft intended to block.
A faulty Microsoft Defender antimalware signature pushed the misclassification to endpoints worldwide, labeling registry entries for DigiCert Assured ID Root CA and DigiCert Trusted Root G4 as high-severity threats. Microsoft said the false positives were tied to the new compromised-certificate detections it had added in response to the DigiCert breach. Both flagged roots are widely used anchors of trust on Windows, used to validate SSL/TLS sessions, signed installers, and a broad swath of code-signing chains across enterprise software.
In a statement, Microsoft told BleepingComputer it had added the malware detections to its Defender Antivirus Software following reports of compromised certificates as a customer-protection step, then determined later that day that false-positive alerts had fired by mistake and adjusted the alert logic to suppress them.
Impact on Windows Systems
Microsoft Defender automatically quarantined the flagged DigiCert root certificate registry entries from the Windows trust store as part of its standard remediation workflow. Thumbprints 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 and DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 identified DigiCert Assured ID Root CA and DigiCert Trusted Root G4 respectively, and administrators who compared those values against DigiCert’s published hashes verified they remained legitimate.
Quarantined DigiCert registry entries reside under HKLM\SOFTWARE\Microsoft\SystemCertificates in the Windows certificate trust store, so removing them broke the chain of trust Windows uses to validate SSL/TLS connections and signed code. Some Windows users, mistaking a misfired Defender detection for a real compromise, grew concerned their devices were infected and reinstalled the operating system in response to the alerts. Administrators wanting to confirm the state of the roots without diving into the registry can run certutil -store AuthRoot | findstr -i "digicert" on systems that received Defender updates around April 30 to verify whether the DigiCert entries remain present.
Fix and Recovery
Microsoft acknowledged the issue and rolled out corrective definition updates, with version 1.449.430.0 cited as the key fix that began restoring the quarantined certificates on affected machines. The corrective definition update appeared to deploy automatically across managed endpoints, restoring the quarantined certificates without administrator action, while Windows users can also force a Defender update manually via Windows Security, Virus and threat protection, Protection updates, Check for Updates.
Microsoft also issued explicit remediation instructions for administrators handling residual alerts in customer environments.
“Microsoft Defender suppressed and cleaned up the alerts for customer environments. Customers should update to Security Intelligence version 1.449.430.0 or later, but do not need to take additional action for these alerts. We have notified affected organizations and recommend administrators look for more details in the service health dashboard (SHD) within the M365 admin center.”
Microsoft spokesperson, statement (via BleepingComputer)
A Recurring Defender False-Positive Pattern
No actual compromise of the DigiCert certificates occurred, and certificate hashes verified by administrators matched officially published DigiCert values. The Defender-flagged roots are root certificates in the Windows trust store and do not match the revoked DigiCert code-signing certificates linked to a separate Zhong Stealer incident, in which DigiCert revoked 60 code-signing certificates including 27 tied to that campaign. Conflating those two layers, root trust anchors and revoked end-entity signing certificates, was what produced the misfired Defender detection in the first place.
Defender’s signature pipeline failed to constrain the new compromised-certificate detection to the revoked end-entity thumbprints, so a rule meant to block 27 Zhong Stealer signing certificates instead matched the registry entries of two unrelated root CAs that share the DigiCert issuer namespace: a scope-control failure inside Microsoft’s own signature build, not a DigiCert compromise.
Microsoft Defender has misfired on legitimate software before: the antivirus engine previously flagged Microsoft’s own Office software as a virus in 2022, after which Microsoft committed to tighter false-positive controls, a commitment the Cerdigent misfire shows has not held for the certificate-detection path. Organizations whose restricted update policies blocked the corrective definition still face exposure: until administrators push 1.449.430.0 or later to those endpoints or manually restore the DigiCert roots, those systems will continue to fail SSL/TLS validation and reject signed code.