Microsoft Defender Quarantined DigiCert Roots Worldwide: The Fix

The version everyone repeated in Slack was blunt: Microsoft Defender broke HTTPS. The version worth keeping is stranger. At the end of April 2026, an antivirus product doing exactly what it is designed to do — spot a malicious certificate and remove it — reached into the Windows trust store and quarantined two of the most widely trusted root certificates on the internet. Nothing was hacked. The security tool was the outage.

A Microsoft Defender Antivirus signature update pushed around April 30 began flagging two legitimate DigiCert roots — DigiCert Assured ID Root CA and DigiCert Trusted Root G4 — as Trojan:Win32/Cerdigent.A!dha. Defender's normal remediation workflow then did what it always does with high-severity malware: it quarantined the offending registry entries, pulling those roots out of the trust store on affected machines. Microsoft has since confirmed to BleepingComputer that this was a false positive, and DigiCert says flatly that its certificates were never compromised.

If you just need the fix, it is short and it is below. But the reason this happened — and why it was not a random bug — is the part that should change how you think about your own stack.

The Fix, First

For most environments the auto-update path already handled this. Signature version 1.449.430.0 both suppressed the bad detection and triggered restoration of the removed certificates through Defender's own remediation channel; later builds (1.449.431.0 at time of reporting) shipped on top. The affected definitions were roughly 1.449.424.0 through 1.449.425.0. If you manage endpoints with gated updates, air-gapped segments, or OT networks where signatures are staged, verify manually:

• Get to signature 1.449.430.0 or later. On each endpoint: Windows Security → Virus & threat protection → Protection updates → Check for updates. Delayed-update policies will not have pulled this automatically.
• Confirm the roots are back. Run certutil -store AuthRoot | findstr -i "digicert" — both DigiCert Assured ID Root CA and DigiCert Trusted Root G4 should be listed. This is the check researcher Florian Roth published when he flagged the issue.
• Hunt for stragglers. In Defender for Endpoint, use Roth's Advanced Hunting query for RegistryKeyCreated events under the AuthRoot certificates path after the fix timestamp to find machines where restoration did not complete.
• Do not reimage. The fix is in the signature update. Several administrator reports document machines wiped in a panic before anyone realized the alert was false — restoring from backup buys you nothing here.
• Watch the M365 Service Health Dashboard. Microsoft says affected organizations were notified there; check it for follow-up rather than acting on the raw alert.

The Breach That Wrote the Rule

Detection logic does not invent certificate names out of nowhere. Microsoft added Cerdigent because DigiCert had a real incident, and the rule was written fast under that pressure. Per DigiCert's report on Mozilla Bugzilla #2033170, on April 2 a threat actor contacted DigiCert support through a customer chat channel and sent a ZIP disguised as a screenshot. Inside was a .scr file — the Windows screensaver executable format that has been a malware carrier for decades. CrowdStrike blocked four attempts; a fifth, on April 3, compromised one support analyst's endpoint, and a sixth on April 4 hit a second analyst whose malfunctioning CrowdStrike install meant the intrusion went undetected until April 14.

What the attacker did with that access is the uncomfortable part. A legitimate support-portal feature — the ability for an analyst to view a customer account from the customer's own perspective — exposed initialization codes for approved-but-undelivered EV code-signing certificate orders. An initialization code plus an approved order is enough to collect the finished certificate. DigiCert ultimately revoked 60 code-signing certificates, 27 of them tied to the Zhong Stealer malware family and the rest revoked precautionarily. Notably, DigiCert observed that certificates from other certificate authorities have also signed Zhong Stealer — this is a campaign with a procurement pipeline, not a one-CA event. The initial access was classic social engineering, aimed at the softest human surface DigiCert exposes.

Roots Are Not the Certs That Got Abused

Here is the clarification that got lost in the panic: the certificates Defender quarantined are DigiCert root certificates in the Windows trust store. The certificates that were actually misused in the breach are code-signing certificates, and DigiCert already revoked those. They are not the same objects. Defender's rule reached past the compromised code-signing certs and swept in unrelated, still-valid roots — precisely the overreach you get when detection content ships at incident speed against a trust-store target. It is worth noting this landed the same week CISA ordered federal agencies to patch a separate Defender zero-day. Two unrelated technical problems — but a rough stretch for a product many organizations run as their only detection layer.

My Read

The modern endpoint depends on two stacks that almost never get considered together: the certificate-trust hierarchy that decides what software and which websites are legitimate, and the endpoint-security agent that decides what gets deleted. This incident is what happens when the second one is given write access to the first. An EDR that can quarantine a root certificate has, by design, the power to revoke trust for the entire machine — and it will exercise that power automatically, at global scale, on the strength of a definition file written in the last few hours of an active breach response.

That is the fragility worth internalizing. The failure here was not incompetence; Microsoft was right to add detections for abused DigiCert certificates, and the rule got fixed within a day. The problem is structural. As detection cycles compress to keep pace with fast-moving CA and supply-chain incidents, the odds of an over-broad rule hitting something load-bearing go up, not down. When your security tool holds a kill switch over your trust store, its false positives are not nuisance alerts — they are outages. Plan for the tool itself to be the incident, because periodically it will be.

What To Do Now

• Treat trust-store detections as high-blast-radius changes. Where your tooling allows, gate or stage signature updates that can quarantine certificate-store objects rather than letting them auto-remediate on production endpoints.
• Keep a fast rollback path for signature updates. You need to be able to pin or revert a definition version quickly — the fix cycle here was hours, but the blast radius was immediate.
• Do not run one detection layer blind. A single product with automated quarantine authority is a single point of failure; keep an independent way to verify an alert before you act on it.
• Audit your code-signing hygiene. If you buy EV code-signing certificates, reconcile recent issuances against orders you actually placed, and hunt for binaries signed by recently revoked certs across any CA — not just DigiCert.
• Write false-positive response into the runbook. “Verify before you reimage” should be a documented step; the costliest damage in this event was self-inflicted by admins who wiped clean machines.

Open Questions

Two things remain unresolved. First, the exact size of the blast radius: Microsoft notified affected organizations privately through the Service Health Dashboard rather than publishing a count, so how many endpoints actually lost their roots is not public. Second, the Zhong Stealer campaign is not closed — DigiCert's revocations shut one supply of valid certificates, but with other CAs already implicated and no evidence the operators have stopped sourcing new ones, the code-signing abuse this all started from is very likely still running.

Primary Documents

• BleepingComputer — Microsoft Defender wrongly flags DigiCert certs as Trojan:Win32/Cerdigent.A!dha
• DigiCert — Microsoft Defender incorrectly flagged DigiCert root certificates as malware
• Mozilla Bugzilla #2033170 — DigiCert incident report
• Help Net Security — DigiCert breached via malicious screensaver file
• Cyber Security News — Defender mistakenly flags DigiCert root certificates as malware