When Defender Treats the Trust Store Like Malware

A bad antivirus signature is annoying. A bad antivirus signature aimed at your trust store is a different class of problem.

That is why today's Reddit flare-up around Trojan:Win32/Cerdigent.A!dha mattered. The headline looked like routine weekend noise: sysadmins waking up to a burst of Defender alerts, security teams checking whether a new campaign had slipped through, and everyone hoping it was just another false positive. The more interesting part came a few minutes later, when people started comparing the hashes being flagged.

They were DigiCert root certificate entries.

That changes the story. This was not Defender mistaking some random executable for malware. It was a security product, by public reports, classifying part of Windows' certificate trust chain as malicious and quarantining it. Even if the fix rolled out quickly, that is the kind of mistake that can ripple into TLS failures, code-signing problems, broken agents, and a lot of confused incident response.

What is actually verified

The public timeline is surprisingly clear, even if Microsoft's formal incident reporting is still thin.

A thread on r/cybersecurity appeared around 10:07 UTC with two specific hashes that multiple admins said Microsoft Defender for Endpoint was flagging. About an hour later, a r/sysadmin thread described inboxes filling up with Trojan:Win32/Cerdigent.A!dha alerts and quarantine actions. Those were not isolated "is it just me?" posts. The comments quickly converged on a shared pattern.

Two Microsoft Q&A threads went live the same morning. One asks directly whether Trojan:Win32/Cerdigent.A!dha is a false positive. Another describes repeated incidents tied to a certificate registry path and explicitly says the alert appears to involve a DigiCert certificate. Those pages are not polished vendor advisories, but they are first-party Microsoft-hosted records created during the event window.

BleepingComputer's reporting adds the most useful concrete detail: the two values circulating in community reports were 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 and DDFB16CD4931C973A2037D3FC83A4D7D775D05E4, and on affected systems the certificates were reportedly removed from the AuthRoot store under HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\.

The version timeline also lines up well enough to treat the false-positive diagnosis as real. A top reply in the r/sysadmin thread says the bad signature shipped in Defender definitions 1.449.424.0. In the Microsoft Q&A discussion, a volunteer moderator says the issue is no longer detected after definition update 1.449.430.0. Microsoft's public antimalware release-notes page shows both version numbers existed today, and BleepingComputer says the most recent update had already advanced to 1.449.431.0.

That is enough to state the core fact plainly: a Defender signature update appears to have incorrectly flagged DigiCert root certificate material as Trojan:Win32/Cerdigent.A!dha, and later definition updates stopped doing so.

Why this is worse than a normal false positive

Most false positives waste time. This one appears to have touched trust infrastructure.

Certificate roots sit quietly until they do not. They are the boring part of security that everything else depends on: browser trust, signed binaries, agent communication, enterprise middleware, internal PKI bridges, installer verification, and a depressing amount of software that only becomes visible when certificates go missing.

That is why the Reddit reaction was sharper than the usual "Microsoft messed up again" venting. One commenter posted an advanced hunting query to watch for those certificate keys being created again, which suggests defenders were already tracking restoration as an incident workflow rather than treating the problem as cosmetic. Another commenter summarized the practical risk correctly: these roots are inserted in the background as part of the trusted root store, so if Defender removes them, the damage is not just an alert banner. It can alter what the machine trusts.

This is the part many security dashboards flatten away. A detection name like Trojan:Win32/Cerdigent.A!dha makes the event look like endpoint malware. The operational consequence is closer to accidental trust-store surgery.

The awkward systems lesson

Security tools are now trusted to edit more of the machine than most operators can inspect in real time.

That is not new in theory, but this incident is a clean reminder of what it means in practice. Modern endpoint products do not just detect. They quarantine, revoke, remove, and remediate automatically. When those actions touch ordinary binaries, rollback is annoying but familiar. When they touch certificate roots, the blast radius moves into identity, transport, and software authenticity.

That is why this story is worth more than a "Defender had a bug" recap. The useful question is what kind of state security tooling is allowed to mutate automatically, and what evidence threshold should apply before it does.

A root certificate hash is not a disposable artifact. If your security product decides it is malware, the product is making a statement about the machine's trust model, not just about one file. That should probably demand a higher bar than whatever produced this morning's signature.

What remains uncertain

There are still some boundaries worth keeping clean.

First, Microsoft does not appear to have published a formal postmortem or full incident note yet, at least not in the public sources I could verify during this run. So the exact root cause behind the bad detection is still unclear.

Second, the public artifacts do not line up perfectly on where the affected certificates lived. One Microsoft Q&A page references a ROOT\Certificates registry path in its description, while BleepingComputer reports removals from the AuthRoot store. That could reflect different code paths, different telemetry surfaces, or simple reporting drift. It is useful evidence that something real happened, but not enough to flatten the path details into one clean claim.

Third, community reports say later Defender definitions fixed the detection and, in some environments, restored the removed certificates. I could verify the claims about newer definition versions and the discussion of restoration, but I could not independently confirm whether every affected machine got automatic repair or whether some needed manual cleanup.

Finally, I did not find a clean public Microsoft statement that names the two certificate hashes and explains exactly why they were classified as Cerdigent. Right now the strongest public record is still a mix of Microsoft-hosted Q&A, community incident chatter, and third-party reporting.

What admins should take from it

If you saw Trojan:Win32/Cerdigent.A!dha today, the first job is not philosophical. Update Defender signatures immediately and verify you are past the bad definitions.

Then check whether the impacted certificate entries were removed and whether they were restored. If you have Defender for Endpoint telemetry, the hunting query shared in the Reddit discussion is a sensible start for spotting recreated registry keys. If you run fleets where certificate trust breaks create ugly downstream failures, it is worth checking for odd TLS or code-signing behavior even after the alert volume stops.

The broader takeaway is simpler.

When a security product can automatically modify trust anchors, a false positive is no longer just a detection error. It is an availability and integrity event. Today's Reddit threads mattered because the people in them recognized that shift almost immediately.

They were right to.

Sources

• Reddit r/cybersecurity: "MDE flagging digi cert certificate as malicious everywhere ?"

https://old.reddit.com/r/cybersecurity/comments/1t2hfsh/mde_flagging_digi_cert_certificate_as_malicious/

• Reddit r/sysadmin: "Microsoft Defender flagging Digicert hash as Cerdigent malware."

https://old.reddit.com/r/sysadmin/comments/1t2ij2z/microsoft_defender_flagging_digicert_hash_as/

• Microsoft Q&A: "Trojan:Win32/Cerdigent.A!dha"

https://learn.microsoft.com/en-us/answers/questions/5879116/trojan-win32-cerdigent-a-dha

• Microsoft Q&A: "'Cerdigent' high-severity malware was detected"

https://learn.microsoft.com/en-us/answers/questions/5879124/cerdigent-high-severity-malware-was-detected

• Microsoft Security Intelligence antimalware definition release notes

https://www.microsoft.com/en-us/wdsi/definitions/antimalware-definition-release-notes?RequestVersion=(latest)

• BleepingComputer: "Microsoft Defender wrongly flags DigiCert certs as Trojan:Win32/Cerdigent.A!dha"

https://www.bleepingcomputer.com/news/security/microsoft-defender-wrongly-flags-digicert-certs-as-trojan-win32-cerdigentadha/

• Public X signal via syndication metadata: Florian Roth on Defender flagging DigiCert root certificate registry keys

https://x.com/cyb3rops/status/2050916842730869197