Notifications
Clear all
Topic starter
24/06/2026 7:15 pm
TL;DR: Microsoft Defender incorrectly flagged certain DigiCert root certificates as malware, and DigiCert also noted a separate April 2026 misissuance event involving a limited number of code-signing certificates that were revoked, according to DigiCert. Security teams need stronger certificate verification, revocation, and endpoint-detection hygiene because trust failures now arise as much from control-plane mistakes as from compromise.
NHIMG editorial — based on content published by DigiCert: Microsoft and code-signing certificates: What to know
Questions worth separating out
Q: What breaks when endpoint security wrongly flags a valid certificate?
A: False positives can trigger quarantines, blocks, or deletion workflows that interrupt signed software, even when the certificate itself is valid.
Q: Why do code-signing certificates need stricter lifecycle controls than ordinary certificates?
A: Code-signing certificates establish trust in software artifacts, so a single misissuance can affect distribution, execution, and reputation at scale.
Q: How do teams know whether certificate governance is actually working?
A: Look for three signals: clean issuance records, consistent revocation propagation, and matching status across PKI, endpoint security, and operations.
Practitioner guidance
- Separate validation from detection triage Create an explicit process to confirm whether a certificate is actually revoked, misissued, or merely misclassified before making endpoint-wide changes.
- Tighten code-signing approval gates Require stronger issuance checks, dual approval, and clear audit trails for code-signing certificates so a small misissuance cannot become a software trust event.
- Align PKI and endpoint status views Maintain a shared workflow between PKI operations, endpoint protection, and service desk teams so certificate status changes propagate consistently across the estate.
What's in the full analysis
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- The exact statement on how Microsoft Defender's false positive was corrected and how updated signatures change the response path.
- The April 2026 misissuance and revocation sequence for impacted code-signing certificates, including customer notification handling.
- The vendor's own account of which certificates were affected and what systems or customer data were not impacted.
- Support guidance for organisations that are still seeing certificate-related issues after updating Defender.
👉 Read DigiCert's analysis of Microsoft Defender false positives and code-signing certificates →
Microsoft Defender and code-signing certificates: what teams should know?
Explore further
25/06/2026 4:28 am
Certificate trust is not a single control, it is a chain of assumptions. This event shows that organisations often treat certificate authority status, endpoint detection, and revocation as if they were interchangeable. They are not. A false positive in one layer can create an outage even when the cryptographic certificate remains valid, which means certificate governance must be evaluated as a system, not a point product decision.
A few things that frame the scale:
- 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Only 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.
A question worth separating out:
Q: Who is accountable when a certificate is misissued or falsely quarantined?
A: Accountability usually spans certificate operations, security engineering, and endpoint administration because each owns a different control layer. The practical test is whether one team can prove certificate status quickly and another can enforce the right response without creating unnecessary downtime.
👉 Read our full editorial: Microsoft Defender false positives and code-signing certificate trust
