Notifications
Clear all
Topic starter
06/09/2026 9:34 am
TL;DR: Microsoft Defender briefly removed legitimate DigiCert root certificates after a signature update misclassified them as malicious, while Airlock Digital ties the timing to a separate DigiCert certificate abuse incident that shows how trust can break at the issuance and activation layer. The lesson is that certificate trust is only as strong as the local execution policy that sits behind it.
NHIMG editorial — based on content published by Airlock Digital: Microsoft Defender Signature Update Flagged as Malicious
By the numbers:
- A total of 60 certificates were affected, spanning multiple regions and industries.
- The search returned 39 samples, 10 of which are shown below.
- Microsoft later acknowledged the issue in DZ1299600 and resolved it in signature version 1.449.430.
Questions worth separating out
Q: What breaks when organisations trust signed code too broadly?
A: Broad trust in signed code breaks the distinction between authenticity and authorisation.
Q: Why do certificate activation workflows need stronger governance?
A: Because activation workflows can be the real credential path, even when private keys are not stolen.
Q: How can security teams reduce the impact of compromised code-signing certificates?
A: Use default-deny application control, scope publisher trust narrowly, and maintain explicit block rules for known compromised thumbprints.
Practitioner guidance
- Tighten publisher trust scope Review every allow rule that trusts software by publisher and remove broad exceptions that would let a misused certificate inherit execution rights.
- Separate signature validation from approval Require explicit local policy approval for sensitive applications so a valid certificate alone cannot authorise execution.
- Treat certificate activation as privileged Apply stronger checks, separation of duties, and audit logging to certificate activation codes and order fulfilment workflows.
What's in the full article
Airlock Digital's full blog post covers the operational detail this post intentionally leaves for the source:
- The certificate thumbprint checks and affected publisher lists used to identify trust exposure in application control policies
- The walkthrough of how to create and deploy explicit block rules for compromised certificates
- The validation steps for confirming that publisher-based allow rules are not over-granting execution rights
- The video demonstration that shows how to apply the policy changes in practice
👉 Read Airlock Digital's analysis of the Microsoft Defender and DigiCert certificate trust issue →
Certificate trust failures: are your controls keeping up?
Explore further
06/09/2026 9:34 am
Certificate trust is not the same as execution trust. Organisations often collapse these two decisions into one, but the article shows why that is dangerous. A certificate can still be cryptographically valid while being operationally unfit for local approval. For practitioners, the implication is that application control must remain the final policy boundary, not the certificate authority or the endpoint reputation layer.
A question worth separating out:
Q: What is the difference between certificate validation and execution authorisation?
A: Certificate validation checks whether a signature chains to a trusted root and appears authentic. Execution authorisation decides whether that signed binary should be allowed to run in your environment. Validation is a technical trust signal, but authorisation is a local governance decision.
👉 Read our full editorial: Certificate trust failures expose why default-deny still matters
