Microsoft Defender false positives and code-signing certificate trust

At a glance

What this is: This is a DigiCert explanation of a Microsoft Defender false-positive event and a separate code-signing certificate misissuance issue.

Why it matters: It matters because certificate trust depends on both issuance integrity and endpoint detection logic, so IAM, PKI, and security operations teams must coordinate more tightly.

👉 Read DigiCert's analysis of Microsoft Defender false positives and code-signing certificates

Context

Code-signing certificate trust depends on two separate control planes: issuance and detection. When an endpoint tool misclassifies a trusted root certificate as malware, operational disruption can look like compromise even when no certificate or certificate authority breach has occurred.

For identity and trust programmes, the key issue is not just certificate validity. It is whether revocation, endpoint protection, and certificate lifecycle governance are aligned closely enough to prevent false positives from becoming business outages, and to contain a genuine misissuance event quickly.

Key questions

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. The failure is in the detection layer, not necessarily in PKI. Teams need a confirmation path that distinguishes certificate compromise from security-tool misclassification before they take estate-wide action.

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. Because they influence runtime trust, issuance validation, revocation traceability, and recovery procedures need tighter governance than routine TLS certificates.

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. If a valid certificate is blocked or a revoked certificate remains trusted somewhere, governance is fragmented and the control model is failing.

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.

Technical breakdown

Why certificate trust can fail without certificate compromise

Certificate ecosystems assume that trust anchors remain stable and that security tooling interprets them correctly. A false positive in endpoint detection breaks that assumption by treating a valid root as malicious, which can trigger automated quarantine, deletion, or operational blocks. In certificate management, this is a detection-layer failure, not an issuance-layer failure, but the operational effect can be similar to revocation or compromise. The important distinction is that trust in the certificate itself may remain intact while the surrounding security stack is misbehaving.

Practical implication: teams should separate certificate validity checks from endpoint alert triage so a detection error does not become an unnecessary trust incident.

What code-signing certificate misissuance means for lifecycle control

Misissuance is a lifecycle failure in certificate governance. It means a certificate was created or approved outside the intended control boundary, even if only for a small set of customers and even if it was later revoked. Code-signing certificates are especially sensitive because they are used to establish software trust at runtime, and any issuance error can ripple into software delivery, endpoint reputation, and incident response workflows. Revocation is necessary, but it is not the same thing as preventing bad issuance in the first place.

Practical implication: certificate issuance workflows need tighter approval, validation, and revocation traceability than general-purpose operational certificates.

Why endpoint protection and PKI governance must be managed together

Endpoint security products often make trust decisions faster than humans can review them, but PKI governance still defines the authoritative status of the certificate. When those two systems diverge, teams can end up with certificates that are valid in PKI but blocked in the estate, or certificates that were revoked but remain operationally trusted in places that missed the update. That gap is a governance problem as much as a technical one, because the organisation has no single, reliable view of certificate status across tooling layers.

Practical implication: establish a shared certificate status workflow across PKI, endpoint security, and operations before the next false positive or revocation event.

Threat narrative

Attacker objective: The objective was not an attacker goal but a security-control failure that disrupted trust decisions and could have blocked legitimate signed software.

1. Entry began when Microsoft Defender's intelligence update incorrectly classified trusted DigiCert root certificates as malware, creating a detection-layer trust disruption rather than a compromise.
2. Escalation occurred when automated endpoint responses could have removed or blocked certificate material before the signature update corrected the false positive.
3. Impact was operational, not exfiltrative, because certificate trust and software execution could be interrupted even though DigiCert said there was no compromise of certificates or systems.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Code-signing certificates expose the highest-cost failure mode in lifecycle governance. When a signing certificate is misissued, the problem is not just bad inventory. It is that software trust can be compromised before anyone notices, and revocation only limits blast radius after the fact. This is why certificate lifecycle control belongs in the same governance conversation as software supply chain integrity.

Endpoint security and PKI governance now share the same trust budget. If Defender or another endpoint control can override a certificate decision incorrectly, operational trust no longer sits solely with the CA or with the security operations team. The implication is that certificate risk has become cross-functional identity infrastructure risk, and practitioners need a single view of certificate status, enforcement, and recovery.

Trust breakdowns in certificate ecosystems are increasingly procedural, not cryptographic. The cryptography may be sound while the surrounding operational process fails through misissuance, false positives, or slow coordination between revocation and endpoint update cycles. That pattern matters because it shifts the control question from key strength to lifecycle discipline and assurance of the enforcement layer.

Misclassification events like this sharpen the case for certificate governance as a runtime identity problem. Certificates do not only exist at issuance time. They must remain interpretable by every downstream control that consumes them, including EDR, code integrity, and software signing pipelines. Practitioners should treat trust visibility as a continuous operational requirement, not a one-time issuance attribute.

From our research:

• 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.
• The certificate governance lesson here is to treat trust enforcement as a lifecycle problem, and use the NHI Lifecycle Management Guide to pressure-test revocation, rotation, and offboarding discipline.

What this signals

Trust misclassification is now a programme-level risk, not an isolated tool error. When endpoint controls can misread trusted artifacts, identity and security teams need shared exception handling and evidence trails. The practical signal is that certificate status, detection status, and recovery status must be reconciled inside the same operational workflow, not left to separate teams.

Certificate governance is increasingly a runtime control problem. A certificate can be cryptographically valid and still operationally unusable if downstream tooling misclassifies it. That means security programmes should track how quickly they can prove authenticity, clear false positives, and restore service across the estate.

The deeper lesson is that lifecycle governance has to cover both issuance and enforcement. If certificate trust is only checked at minting time, the organisation will miss the moments when endpoint security, revocation, or software distribution actually change what is trusted.

For practitioners

• 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. This avoids turning a Defender false positive into a self-inflicted outage.
• 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.
• Test revocation and restore paths Validate how quickly revoked or quarantined certificates are restored after a signature update, and confirm which systems depend on manual intervention versus automatic recovery.

Key takeaways

• This event shows that certificate trust can fail at the detection layer even when the certificate itself is not compromised.
• Misissuance and false positives are different failure modes, but both expose weaknesses in certificate lifecycle governance and enforcement.
• Teams need a shared PKI, endpoint, and operations workflow so trust decisions are consistent across the estate.

Key terms

• Code-signing Certificate: A code-signing certificate is a digital certificate used to sign software so recipients can verify who published it and whether it has been altered. In practice, it is a high-trust identity artifact because it influences execution and reputation decisions across endpoints, distribution systems, and software supply chains.
• Certificate Misissuance: Certificate misissuance happens when a certificate is approved, created, or delivered outside the intended policy or validation process. It is a governance failure, not a cryptographic one, because the resulting certificate may still be valid while representing an identity or trust relationship that should never have been granted.
• False Positive: A false positive is a security detection that incorrectly labels benign activity or an asset as malicious. In certificate operations, false positives can disrupt trust even when the certificate is valid, which makes detection accuracy part of identity and trust governance, not just alert management.
• Certificate Revocation: Certificate revocation is the formal process of marking a certificate as no longer trustworthy before its natural expiry. It is a lifecycle control that limits exposure after compromise or misissuance, but it only works when revocation status is distributed and enforced consistently across the environment.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management 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 operational governance, it is worth exploring.

This post draws on content published by DigiCert: Microsoft and code-signing certificates: What to know. Read the original.