Topic starter
25/10/2026 11:02 am
TL;DR: Two legitimate DigiCert root certificates were flagged by Microsoft Defender as Trojan:Win32/Cerdigent.A!dha, according to Censys. Certificate triage needs validation-path and revocation checks before a trust anchor is treated as a threat.
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: 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.
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.
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.
Glossary terms: Certificate Trust Context, Root Certificate, Validation Path, Certificate Transparency
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
Certificate trust context is now a SOC requirement, not a niche PKI concern. When endpoint tools flag certificates, the real question is whether the object changes a trust decision, not whether it looks suspicious in isolation. That creates a governance gap between PKI ownership and SOC triage, because the analysts who see the alert may not own the trust data needed to validate it. Practitioners should treat certificate intelligence as part of detection engineering, not as an afterthought.
A few things that frame the scale:
- 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.
A question worth separating out:
Q: How can SOC teams reduce false positives from certificate-related alerts?
A: Build a PKI-aware triage path that checks root-store status, revocation, CT data, and endpoint placement before escalation. False positives fall when analysts can quickly separate ordinary trust infrastructure from objects that actually modify trust in suspicious ways. That reduces wasted incident effort and preserves focus for true compromise signals.
👉 Read our full editorial: Why certificate trust context matters when Defender flags root certs
This post was modified 7 days ago by NHI Mgmt Group