> ## Content Index
> Fetch the complete content index at: https://www.thecybersignal.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Microsoft Defender Quarantined DigiCert Roots Worldwide: The Fix
- URL: https://www.thecybersignal.com/defender-quarantined-digicert-roots-worldwide-heres-the-fix/
- Published: 2026-05-04T14:22:00.000Z
- Updated: 2026-08-11T02:05:48.000Z
- Description: A Microsoft Defender signature quarantined two trusted DigiCert root certificates worldwide, breaking TLS validation on Windows. The fix is one signature update — but the real lesson is what happens when your endpoint tool holds a kill switch over your trust store.
- Author: Nicholas Robert
- Tags: Vulnerabilities, Microsoft Ecosystem, Malware, Vulnerability Management

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](https://www.thecybersignal.com/vulnerability-management-the-complete-guide/) 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](https://www.bleepingcomputer.com/news/security/microsoft-defender-wrongly-flags-digicert-certs-as-trojan-win32-cerdigentadha/?ref=thecybersignal.com) that this was a false positive, and DigiCert says flatly that its [certificates were never compromised](https://www.digicert.com/blog/microsoft-defender-incorrectly-flagged-digicert-root-certificates-as-malware?ref=thecybersignal.com).

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.

| ● WHEN THE SCANNER IS THE OUTAGEOne over-broad detection rule cascaded from a single antivirus definition into broken TLS trust worldwide. |
| ------------------------------------------------------------------------------------------------------------------------------------------ |
| FALSE POSITIVEA \~Apr 30 Defender signature flags two trusted DigiCert roots as Trojan:Win32/Cerdigent.A!dha.                              |
| ↓                                                                                                                                          |
| AUTOMATED QUARANTINEDefender's standard remediation removes the root registry entries from the Windows trust store.                        |
| ↓                                                                                                                                          |
| TRUST CHAIN BREAKSAny certificate chaining to those roots can no longer be validated on the affected machine.                              |
| ↓                                                                                                                                          |
| APPS & SITES FAILBrowsers throw certificate warnings, signed apps fail to launch, updates error — and some admins reimage clean machines.  |
| Source: BleepingComputer; DigiCert; Microsoft Q&A administrator reports.                                                                   |

## 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](https://bugzilla.mozilla.org/show%5Fbug.cgi?id=2033170&ref=thecybersignal.com), 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](https://www.helpnetsecurity.com/2026/05/04/digicert-breach-code-signing-certificates-malware/?ref=thecybersignal.com), 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](https://www.thecybersignal.com/what-is-social-engineering-the-psychology-behind-cyber-attacks/), 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](https://www.thecybersignal.com/cisa-orders-feds-patch-bluehammer-defender-zero-day-by-may-7-or-explain-why-not/). 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](https://www.bleepingcomputer.com/news/security/microsoft-defender-wrongly-flags-digicert-certs-as-trojan-win32-cerdigentadha/?ref=thecybersignal.com)
- [DigiCert — Microsoft Defender incorrectly flagged DigiCert root certificates as malware](https://www.digicert.com/blog/microsoft-defender-incorrectly-flagged-digicert-root-certificates-as-malware?ref=thecybersignal.com)
- [Mozilla Bugzilla #2033170 — DigiCert incident report](https://bugzilla.mozilla.org/show%5Fbug.cgi?id=2033170&ref=thecybersignal.com)
- [Help Net Security — DigiCert breached via malicious screensaver file](https://www.helpnetsecurity.com/2026/05/04/digicert-breach-code-signing-certificates-malware/?ref=thecybersignal.com)
- [Cyber Security News — Defender mistakenly flags DigiCert root certificates as malware](https://cybersecuritynews.com/defender-flags-digicert-root-certificates/?ref=thecybersignal.com)