Microsoft Defender false positives and code-signing certificate trust

At a glance

What this is: This is a certificate trust update explaining that Microsoft Defender produced false positives against certain DigiCert root certificates, alongside a separate limited code-signing certificate misissuance that was revoked.

Why it matters: It matters because IAM, PKI, and endpoint teams need to distinguish detection errors from real certificate compromise and keep revocation, restoration, and trust validation processes tightly controlled.

Context

This article is about certificate trust, not malware compromise. Microsoft Defender falsely classified certain DigiCert root certificates as malicious, which means the immediate problem sits in detection logic and trust validation rather than in a breached certificate estate.

The separate April 2026 misissuance of a limited number of code-signing certificates shows why certificate governance has to cover issuance, revocation, and endpoint response together. For identity teams, the practical issue is how trust decisions are made when security tools and certificate authorities disagree.

Key questions

Q: What should teams do when a security tool flags a legitimate certificate as malware?

A: Teams should verify the certificate chain, revocation status, and the security tool's signature state before treating the event as compromise. False positives create operational noise, but the response should stay grounded in trust evidence. If the certificate was restored after a detection update, the priority is validation, not broad emergency rotation.

Q: Why do certificate false positives create operational risk even when nothing is compromised?

A: They consume incident-response time, can disrupt software signing and distribution, and may cause teams to distrust valid trust anchors. When the problem is a detection error, the real risk is misdirected remediation that weakens normal operations. That is why endpoint validation and certificate governance need a shared decision process.

Q: How should security teams handle code-signing certificate revocation after misissuance?

A: They should treat revocation as a lifecycle control with notification, endpoint cleanup, and confirmation that impacted certificates are no longer trusted. The goal is to restore assurance without overextending the response to certificates or systems that were never affected. This is a governance task as much as a technical one.

Q: What is the difference between certificate compromise and certificate misissuance?

A: Compromise means an attacker has obtained and is abusing a valid credential or certificate. Misissuance means the certificate was created incorrectly in the first place. The operational response differs: compromise focuses on containment and abuse, while misissuance focuses on revocation, customer notification, and validating which assets were actually impacted.

Technical breakdown

Why certificate false positives break trust decisions

A false positive occurs when an endpoint security engine labels a legitimate certificate or file as malicious, even though the certificate chain is intact. In this case, the trust problem was introduced by Microsoft Defender's detection logic, not by compromise of DigiCert certificates. That distinction matters because certificate-based trust depends on reliable validation of the issuing chain, revocation status, and endpoint enforcement. If the security stack cannot distinguish legitimate trust anchors from malware, operations teams can end up remediating the wrong layer.

Practical implication: Validate certificate trust failures against the issuing chain and revocation status before treating them as compromise.

Code-signing certificate misissuance and revocation lifecycle

Code-signing certificates prove that signed software came from a trusted source, but that assurance collapses if issuance is wrong or if revocation does not happen quickly. DigiCert's separate April 2026 event involved a limited number of misissued certificates that were revoked, which shows the lifecycle has to cover issuance quality, detection, customer notification, and cleanup. The operational question is not only whether a certificate exists, but whether it was issued correctly and can still be trusted at the point of use.

Practical implication: Track code-signing certificate issuance and revocation as a single lifecycle control, not as separate administrative tasks.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate trust now depends on two control planes at once: the CA lifecycle and the endpoint detection stack. When Microsoft Defender mislabels a root certificate, the issue is not only a false alert, it is a trust collision between validation and detection. Practitioners should treat certificate trust as an end-to-end governance problem, not a single control.

Misissuance and false positives are different failures, but they break the same operational assumption: that a trusted certificate can be identified unambiguously at the point of use. The April 2026 revocation event and the Defender false positive both show that issuance, revocation, and endpoint enforcement must be coordinated. The practical conclusion is that certificate trust cannot be managed as a static inventory problem.

Code-signing certificates sit at the boundary of software integrity and identity assurance: when they are misissued, revoked, or incorrectly flagged, downstream teams inherit uncertainty about what should run and what should be blocked. This is where certificate lifecycle management and endpoint policy tuning intersect. Practitioners need a governance model that ties trust decisions to verified lifecycle state, not to alert volume.

Trust restoration is part of certificate operations, not an afterthought: once an incorrect removal or revocation occurs, the environment needs a clear restoration path that preserves integrity without leaving legitimate software stranded. That means lifecycle evidence, notification discipline, and endpoint synchronization all matter. The key takeaway is that trust recovery deserves the same rigour as initial issuance.

Named concept: certificate trust collision: this article shows how a legitimate certificate can be treated as suspicious when detection logic and CA lifecycle controls diverge. That collision creates operational friction for security teams, because neither endpoint telemetry nor certificate metadata can be accepted blindly. Practitioners should design for cross-checking, not assumptions.

From our research library:

• 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.

What this signals

Certificate trust collision: security teams should expect more cases where endpoint detection, certificate lifecycle, and operational trust checks disagree. The right response is to reconcile evidence across those layers before changing trust posture.

Microsoft Defender false positives are a reminder that certificate governance does not end at issuance. Teams need a clean path to confirm revocation, restore legitimate certificates, and avoid treating every alert as evidence of compromise.

For practitioners

• Verify Defender signature state Confirm Microsoft Defender is fully up to date across endpoints so incorrectly removed certificates are restored through the updated detection logic.
• Cross-check certificate trust status Validate certificate chain, revocation status, and issuing authority before escalating a certificate-related alert as compromise.
• Track revocation as an operational event Treat revocation as a coordinated workflow that includes notification, endpoint cleanup, and confirmation that affected code-signing certificates are no longer in circulation.
• Separate misissuance from compromise response Build an internal decision path that distinguishes certificate misissuance from theft or abuse so teams do not over-rotate unrelated credentials or software trust settings.

Key takeaways

• The article separates a Defender false positive from a separate certificate misissuance event, and that distinction matters for response and governance.
• The main evidence is operational, not numerical: Microsoft says the detection error was fixed, and DigiCert says the misissued certificates were revoked.
• Practitioners should validate certificate trust against lifecycle state and endpoint signatures before escalating or broadening remediation.

Key terms

• Code Signing Certificate: A code signing certificate is a digital credential used to prove that software came from a trusted publisher and has not been altered. In identity terms, it is a non-human identity that authorizes release activity, and its value depends on lifecycle control, key custody, and revocation discipline.
• Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.
• False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
• Trust anchor: A trust anchor is the root authority that signs federation metadata and establishes the policies other participants inherit. In practice, it controls who can join, what cryptographic rules apply, and how trust is delegated across an ecosystem. The security posture of the whole federation depends heavily on this layer.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.