Topic starter
25/10/2026 11:02 am
TL;DR: Microsoft Defender flagged two legitimate DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha, showing how trust anchors can be mistaken for malware when analysts lack certificate context, revocation status, and validation-path visibility, according to Censys research. The case shows why detection needs authoritative trust intelligence before incident conclusions are drawn.
Editorial analysis by NHI Mgmt Group, based on content published by Censys: “Microsoft: DigiCert Root Certificates Are Malware? Censys in SOC Triage”.
Key questions
Q: What should security teams do when an endpoint alert points to a certificate instead of malware?
A: Treat it as a trust investigation first.
Q: Why do legitimate certificates sometimes trigger malware detections?
A: Because security tools may detect the context around a certificate rather than executable behaviour.
Q: What is the difference between certificate trust context and certificate provenance?
A: Certificate provenance is where the certificate came from and who issued it.
Practitioner guidance
- Validate certificate provenance before quarantine Check whether the flagged object is a root certificate, what trust stores recognise it, and whether revocation or CT history supports the alert before taking containment action.
- Correlate Defender alerts with external certificate data Use certificate transparency, validation-chain observations, and root-store status to decide whether the alert reflects trust infrastructure or a real malicious artefact.
- Separate trust-anchor handling from malware response Create an endpoint runbook that routes certificate detections to PKI-aware analysts instead of applying the same workflow used for executables or scripts.
Bottom line: The core issue is not that a certificate ran as malware, but that endpoint controls can misread trust infrastructure when context is thin.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →