A faulty Microsoft Defender signature update released around April 30, 2026, triggered widespread false positive alerts across Windows enterprise environments, incorrectly classifying two of the internet’s most trusted DigiCert root certificates as high-severity malware.
The incident, tracked under the detection name Trojan:Win32/Cerdigent.A!dha exposed critical infrastructure systems to accidental SSL/TLS failures and code-signing failures before Microsoft issued corrective signature updates.
On May 3, 2026, IT administrators and security teams worldwide woke up to a storm of high-severity malware alerts generated by Microsoft Defender.
The source was not an active threat actor; it was Microsoft’s own security intelligence update, version 1.449.424.0, which contained a defective detection signature that incorrectly categorized two widely deployed DigiCert root certificate registry entries as malicious.
Microsoft Defender Flags DigiCert Certs
The two certificates falsely flagged were:
- DigiCert Assured ID Root CA – Thumbprint:
0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 - DigiCert Trusted Root G4 – Thumbprint:
DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
These certificates reside under the Windows registry path HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates, which is the core Windows trust store for managing trusted certificate authorities.
Upon detection, Defender’s automated remediation engine quarantined the certificate entries effectively pulling them from the Windows root trust store without administrator intervention.
The downstream consequences of this false positive were immediately severe. With the DigiCert root certificates removed from the Windows trust store, affected systems faced the risk of failing to validate SSL/TLS connections for HTTPS websites and breaking code-signing verification for digitally signed software.
Organizations relying on DigiCert-issued certificates covering millions of websites and enterprise applications were especially exposed to potential service disruptions, browser trust warnings, and application launch failures.
Security professionals noted that this class of false positive is uniquely dangerous because it targets foundational PKI infrastructure rather than a standalone application. A false positive at the root certificate level breaks the entire chain of trust affecting every website, service, or software package that chains back to those roots.
Enterprise environments running Microsoft Defender for Endpoint (MDE) in automatic remediation mode were particularly at risk, as quarantine actions executed silently across managed endpoints.
The affected registry entries triggering the alert were:
HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
Cross-verification of the certificate thumbprints confirmed the hashes matched DigiCert’s officially published root CA values, ruling out any actual certificate compromise.
Cybersecurity researcher Florian Roth (@cyb3rops) was among the first to publicly identify and broadcast the issue on May 2–3, 2026. Roth shared a Microsoft Defender Advanced Hunting (KQL) query to help administrators check whether affected DigiCert certificates had been restored post-quarantine on their managed devices.
Recommended a rapid command-line verification method for individual systems:
textcertutil -store AuthRoot | findstr -i "digicert"This command allows administrators to instantly confirm whether DigiCert’s root CAs remain present in the local certificate trust store. The security community rapidly mobilized around Roth’s detection queries, with enterprise admins sharing results and confirming the widespread false positives across Reddit’s r/sysadmin and r/cybersecurity communities.
Remediation
Microsoft acknowledged the issue and moved swiftly to issue corrective security intelligence updates. The critical fix arrived in Security Intelligence version 1.449.430.0, which reversed the erroneous signature and began automatically restoring the quarantined DigiCert certificates on affected systems.
The rollout appeared to occur silently across managed endpoints connected to Microsoft’s update infrastructure, suggesting a deliberate silent remediation push alongside the corrected signature.
For environments with restricted or delayed update policies common in air-gapped networks, government systems, or organizations with strict change management controls, manual remediation was required. Administrators in these environments were advised to:
- Manually verify certificate presence using
certutil -store AuthRoot - Review Advanced Hunting logs in Microsoft Defender for Endpoint for any certificate-related quarantine events
- Restore quarantined items from Defender’s Protection History if the update has not yet propagated
- Update to Security Intelligence version 1.449.430.0 or later immediately
Microsoft Q&A forums confirmed the false positive was tied to the definitions version 1.449.424.0, and that Defender’s detection engine (MsMpEng.exe) triggered the quarantine action against the registry-based certificate store entries.
This incident exposes a critical tension in modern endpoint security: automated threat remediation, while powerful, carries catastrophic risk when signature quality control fails at the infrastructure level.
Certificate-store tampering is a documented malware technique that threat actors routinely use to manipulate root certificates to perform TLS interception, bypass security tooling, or enable man-in-the-middle attacks. Defender’s detection logic for this attack vector is legitimate and necessary.
However, triggering auto-quarantine against certificates that are cryptographically verifiable as authentic DigiCert roots without secondary validation checks represents a significant gap in the signature release pipeline.
The incident reinforces the industry’s need for staged signature rollouts, enhanced pre-release testing against known-good PKI assets, and administrator-controlled quarantine policies for detections that target Windows core infrastructure components.
The Cerdigent false positive joins a growing list of high-profile Defender misfires that have disrupted enterprise operations, serving as a renewed call for Microsoft to implement more robust safeguards before pushing signature changes that affect foundational system components, such as the root certificate trust store.
FAQ
Q1: What is Trojan:Win32/Cerdigent.A!dha?
It is a Microsoft Defender detection name that, in this case, incorrectly flagged legitimate DigiCert root CA certificate registry entries as malware.
Q2: Which certificates were affected by this false positive?
DigiCert Assured ID Root CA (thumbprint: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43) and DigiCert Trusted Root G4 (thumbprint: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4Were the two certificates falsely quarantined?
Q3: How do I check if my system was affected?
Run certutil -store AuthRoot | findstr -i "digicert" in Command Prompt; if the DigiCert roots are missing, update Defender to Security Intelligence version 1.449.430.0 or later and restore quarantined items.
Q4: Has Microsoft fixed the Cerdigent false positive issue?
Yes, Microsoft released Security Intelligence version 1.449.430.0, which corrects the faulty signature and automatically restores the quarantined DigiCert certificates on most managed systems.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
