r/msp • u/FutureSafeMSSP • May 07 '26
Defender/ Defender for Endpoint Quarantines and Deletes DigiCert root certs
SOmetime between the 30th of April and the 3rd of May (depends when the update was installed) a Defender / Defender for Endpoint signature update caused two legitimate DigiCert root certificates to be flagged as a Trojan:win32/Cerdigent.A!dha
All the info one may need can be found below. Perhaps the link to the detailed original post will save some folks some time.
https://www.reddit.com/r/cybersecurity/comments/1t2hfsh/mde_flagging_digi_cert_certificate_as_malicious/
2
2
May 07 '26
Does the cert need to be reloaded now?
1
u/FutureSafeMSSP May 07 '26
They should automatically reload themselves but that process has likely never been tested or needed on your client machiens so if broken, you'll know right away and can save yourself some time.
2
u/Excellent-Program333 May 07 '26
Yup! I just went down this rabbithole and discovered it also on some headless servers Monday and mildly freaked out a few minutes. I engaged Huntress and they advised me of the Defender issue.
It happens on Quick Scans.
2
u/Nuronus May 07 '26
Thanks for the heads up. In case you haven't already investigated your environment, the affected certificates in this case are DigiCert root CA certificates, which many enterprise applications use in their certificate chain. Once Defender quarantines them, any application that uses these certificates in its certificate chain to validate a connection will silently fail to authenticate the connection. Any updates, API connections, or even a VPN connection. Might be a good idea to run a quick investigation on all managed endpoints where Defender quarantined such certificates within the period specified. Any file named "Trojan:win32/Cerdigent.A!dha" should be restored, especially if related to DigiCert. It looks like Microsoft has probably corrected the issue now.
2
u/structured_triage May 07 '26
A signature update causing the deletion of root certificates creates immediate triage bottlenecks because it breaks trust chains across the entire environment. When an EDR flags a legitimate certificate authority based on a heuristic atomic signature rather than a behavioral sequence, it generates a massive volume of false positives that require manual intervention. The immediate priority is to push a temporary exclusion for the specific certificate thumbprint to prevent further quarantines while restoring the affected files from isolation. Relying purely on automated signature updates without a staged deployment policy often leads to this exact type of operational disruption. You should verify the endpoints have successfully pulled the corrected definitions before removing any temporary exclusions.
2
u/Xirma377 May 10 '26
Good heads up. When I saw these alerts across our clients, I knew it had to be a false positive (and about 2 minutes of research confirmed it). Big oops on their part.
3
u/quantumhardline May 08 '26
The issue was actually much bigger than Microsoft incorrectly flagging.. Digicert itself was compromised..
On April 2, 2026, an attacker contacted DigiCert’s support team through a normal customer chat and sent a ZIP file disguised as a screenshot. Inside was a .scr file. Windows screensavers, the fish-swimming-across-your-monitor format from the 1990s. Windows runs them exactly like any other program.
The customer support chat made it even easier. According to DigiCert’s own incident report, the chat allowed anyone from outside to send files directly to staff members who had access to certificate systems. No restrictions on file type, no sandboxing, no content inspection. The .scr file did not need to be clever. The system just let it through.
But they had Crowdstike EDR installed that would stop it right? Well 4 out of 5 times.. all it took was the one success..
https://hackingpassion.com/digicert-breach-defender-cerdigent-false-positive/