On 3 May 2026, security teams and Windows users began reporting Microsoft Defender detections for Trojan:Win32/Cerdigent.A!dha involving trusted DigiCert root certificates. Public reporting indicates that the affected certificates were DigiCert Assured ID Root CA and DigiCert Trusted Root G4, both legitimate root certificates widely used in trust chains. PiunikaWeb reported that the issue appeared after Microsoft Defender security intelligence update 1.449.424.0, and that later updates such as 1.449.430.0 or 1.449.431.0 appeared to stop triggering the detection.
Microsoft’s own security intelligence changelog confirms that version 1.449.424.0, released on 3 May 2026, included an updated severe detection for Trojan:Win32/Cerdigent.A!dha. The Microsoft Update Catalog also shows multiple Defender intelligence updates published on 3 May 2026, including KB2461484 version 1.449.431.0 and later versions.
From an enterprise perspective, the main risk was not necessarily malware execution. The bigger operational problem was alert noise, automatic quarantine/remediation, potential certificate trust disruption, and SOC escalation pressure. DigiCert states that its root certificates are widely trusted and used to issue TLS certificates across many sectors, including education, finance, and government. DigiCert also recommends including these roots in applications and hardware that support X.509 certificate functionality.
What Happened?
The incident appears to have been a signature or detection logic false positive in Microsoft Defender Antivirus / Microsoft Defender for Endpoint.
According to public reports, Defender began flagging legitimate DigiCert root certificate entries as Trojan:Win32/Cerdigent.A!dha. The detection was classified as severe, creating high-priority alerts across affected environments. The two certificate thumbprints most often associated with the event were:
0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43DDFB16CD4931C973A2037D3FC83A4D7D775D05E4The first thumbprint is publicly associated with DigiCert Assured ID Root CA in vendor documentation, while public reporting and community discussion associated the second with DigiCert Trusted Root G4.
The likely sequence was:
- Microsoft Defender received a security intelligence update.
-
The updated detection logic for
Trojan:Win32/Cerdigent.A!dhamatched legitimate DigiCert root certificate artifacts. - Defender generated severe malware detections and, in some cases, quarantined or removed the certificate artifacts.
- Later intelligence updates appeared to stop the false detection and systems reportedly began restoring or re-adding the certificates.
This is important because root certificates are not ordinary files. They are part of the trust fabric used by operating systems, browsers, security tools, VPN clients, update services, and enterprise applications. If a trusted root is removed or blocked, downstream TLS validation, code-signing validation, or application trust checks may be affected.
Why This Matters for CISOs
This event is not just a technical curiosity. It shows three structural issues that every CISO should care about.
First, security tools can become a source of operational risk. Modern endpoint protection platforms are highly automated. When a detection is classified as severe, automated investigation and remediation can quarantine files, remove registry keys, stop processes, or trigger escalation workflows. Microsoft’s own documentation notes that remediation actions can include quarantine, registry-key removal, process termination, service stoppage, driver disablement, and scheduled-task removal.
Second, root certificate trust is critical infrastructure. DigiCert root certificates are widely trusted and automatically recognized by common browsers, mobile devices, mail clients, and other systems. A false positive against a root certificate can therefore create confusion far beyond the endpoint security team.
Third, SOC teams need fast false-positive validation procedures. Microsoft’s Defender documentation explicitly recognizes that false positives can occur in endpoint protection tools and recommends reviewing, classifying, suppressing, creating indicators, and submitting samples or detections for analysis where appropriate.
For a CISO, the key question is not only “Was this malware?” The better question is:
Can our organization rapidly distinguish a real compromise from a vendor false positive without creating unnecessary business disruption?
Defender XDR Hunting Query: How to Check What Happened
The following KQL query can be used in Microsoft Defender XDR Advanced Hunting to look for registry key creation events involving the two certificate thumbprints after the beginning of the incident window.
Microsoft documents that the DeviceRegistryEvents table contains information about creation and modification of registry entries, including fields such as Timestamp, DeviceName, ActionType, and RegistryKey.
DeviceRegistryEvents
| where RegistryKey contains “0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43”
or RegistryKey contains “DDFB16CD4931C973A2037D3FC83A4D7D775D05E4”
| where ActionType == “RegistryKeyCreated”
| where Timestamp > datetime(2026-05-03T04:00:00)
| project Timestamp, DeviceName, ActionType, InitiatingProcessFileName
| order by Timestamp desc
What This Query Shows
This query checks whether registry keys containing the two relevant certificate thumbprints were created after 3 May 2026 04:00 UTC. In the context of this incident, such events may indicate that the certificates were re-added or restored into the Windows certificate trust store after Defender remediation or after a follow-up update.
A similar query was also shared publicly in the cybersecurity community as a way to verify whether Microsoft or Windows background processes were restoring the affected certificates.
Certificate Restoration Verification
Use the following query to verify whether the affected certificates have been restored automatically.
let startTime = datetime(2026-05-03T00:00:00Z);
let thumbprints = dynamic([ “0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43”, “DDFB16CD4931C973A2037D3FC83A4D7D775D05E4”]);DeviceRegistryEvents
| where Timestamp >= startTime
| where RegistryKey has @”\Microsoft\SystemCertificates\”
| where RegistryKey has_any (thumbprints)
| extend Thumbprint = case( RegistryKey has “0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43”, “0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43”, RegistryKey has “DDFB16CD4931C973A2037D3FC83A4D7D775D05E4”, “DDFB16CD4931C973A2037D3FC83A4D7D775D05E4”, “unknown”)
| summarize
LastDelete = maxif(Timestamp, ActionType in (“RegistryKeyDeleted”,”RegistryValueDeleted”)),
LastAdd = maxif(Timestamp, ActionType == “RegistryKeyCreated”),
LastAction = arg_max(Timestamp, ActionType, InitiatingProcessFileName, InitiatingProcessParentFileName, InitiatingProcessAccountName, RegistryKey) by DeviceName, Thumbprint
| extend Status = case( isnotempty(LastAdd) and (isempty(LastDelete) or LastAdd > LastDelete), “Present/re-added (within window)”, isnotempty(LastDelete) and (isempty(LastAdd) or LastDelete > LastAdd), “Likely missing (deleted after last add)”, “No signal in window”)
| project DeviceName, Thumbprint, Status, LastDelete, LastAdd, ActionType, InitiatingProcessFileName, InitiatingProcessParentFileName, InitiatingProcessAccountName, RegistryKey
| order by Status desc, DeviceName asc
How to Interpret the Results
If you see events where the initiating process is a Microsoft or Windows component, and the timestamps align with the Defender intelligence update correction, this supports the hypothesis that the affected certificate entries were restored rather than maliciously created.
If you see unusual initiating processes, unexpected scripting engines, remote management tools, or non-standard executables creating certificate-related registry keys, the event deserves deeper investigation. A false positive can coexist with unrelated suspicious activity, so the SOC should not simply close all alerts without validation.
Recommended CISO / SOC Response
1. Confirm Defender Intelligence Version
Check whether affected endpoints received Defender security intelligence version 1.449.424.0 and whether they subsequently updated to 1.449.431.0 or later. Microsoft’s Update Catalog shows later updates on 3 May 2026, including version 1.449.431.0 and newer versions.
2. Validate the Certificate Thumbprints
Confirm whether the detections map to known DigiCert root certificates and not to unknown files, suspicious executables, or unsigned payloads. Focus on the object type, certificate name, certificate thumbprint, detection path, and remediation action.
3. Use Advanced Hunting
Run the KQL query above across all endpoints. Export the results and group them by device, timestamp, and initiating process. This gives the SOC a clean view of whether the environment experienced certificate removal and restoration activity.
4. Review Quarantine and Remediation Actions
Check whether Defender quarantined or removed the certificate artifacts. If certificates were removed and not automatically restored, validate whether they need to be restored through trusted OS mechanisms, enterprise certificate management, or vendor guidance.
5. Avoid Permanent Exclusions Unless Necessary
Temporary exclusions may reduce noise during an active false positive, but they should be time-bound and risk-reviewed. Microsoft warns that exclusions lower the level of protection because excluded entities are not remediated even if detected.
6. Classify and Suppress Carefully
Once validated, classify the incident as a false positive and suppress duplicate alert noise where appropriate. Microsoft recommends classifying false-positive alerts and using suppression rules to reduce queue noise so analysts can focus on higher-priority cases.
7. Document the Incident
For governance and audit purposes, document:
Incident date: 3 May 2026Detection: Trojan:Win32/Cerdigent.A!dhaSuspected cause: Defender security intelligence false positiveAffected certificates:- DigiCert Assured ID Root CA- DigiCert Trusted Root G4Relevant thumbprints:- 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43- DDFB16CD4931C973A2037D3FC83A4D7D775D05E4Validation method: Defender XDR Advanced Hunting / DeviceRegistryEventsResolution: Defender intelligence updated; certificate restoration verifiedBusiness impact: To be completed by organizationLessons Learned
This event is a powerful reminder that cybersecurity operations require both automation and judgment. Automated endpoint protection is essential, but blind trust in detections can create unnecessary panic and operational disruption.
For CISOs, the real maturity test is not whether a false positive occurs. False positives are inevitable. The maturity test is whether the organization can:
- detect the scope quickly,
- validate the technical evidence,
- distinguish a vendor-side detection error from a real compromise,
- restore trust without weakening security controls,
- communicate clearly to IT, SOC, management, and business stakeholders.
The DigiCert / Defender incident shows why advanced hunting, certificate inventory, change tracking, and clear SOC playbooks are no longer optional. They are core elements of operational cyber resilience.
Final CISO Takeaway
A trusted root certificate being flagged as malware is not just an antivirus issue. It is a trust-chain incident, a SOC-noise incident, and a governance incident.
The best response is disciplined: verify the Defender intelligence version, validate the certificate thumbprints, hunt for registry restoration events, review quarantine actions, avoid unnecessary permanent exclusions, and document the case as a false positive only after evidence supports that conclusion.
Security teams should treat this as a useful exercise in one of the most important operational principles in cybersecurity:
Not every severe alert is a severe incident — but every severe alert deserves a structured investigation.