Certificate trust failures expose why default-deny still matters

At a glance

What this is: A Microsoft Defender signature update falsely flagged legitimate DigiCert root certificates, and the broader context is a separate certificate abuse incident that shows how trust in signing workflows can be undermined upstream.

Why it matters: For IAM and security teams, the issue is not only certificate validity but where trust is granted, because publisher trust, activation codes, and allow rules can all become control points that shape execution risk.

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.

👉 Read Airlock Digital's analysis of the Microsoft Defender and DigiCert certificate trust issue

Context

Certificate trust is a governance problem as much as a technical one. Systems may validate a signature, but organisations still have to decide whether that signature should translate into execution, especially when publisher trust, certificate stores, and application control policies interact.

This article sits at the intersection of application control and identity security because certificates are credentials, and code-signing workflows depend on issuance, activation, and trust decisions that resemble lifecycle governance. That makes the subject relevant to NHI practitioners as well as endpoint and platform security teams.

The starting position here is typical of enterprises that trust signed software too broadly: a valid signature is often treated as sufficient proof of safety, even when the surrounding workflow has been compromised.

Key questions

Q: What breaks when organisations trust signed code too broadly?

A: Broad trust in signed code breaks the distinction between authenticity and authorisation. A binary can be correctly signed and still be unsafe for a given environment if the certificate was misused, the publisher was compromised, or the signing workflow was abused. Teams need local execution policy to remain the final decision point.

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. If an attacker can manipulate approvals, order fulfilment, or activation codes, they can obtain legitimate-looking certificates without breaking the cryptography. That makes the workflow itself a high-value identity control.

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. These controls stop a valid signature from automatically becoming execution permission and reduce the blast radius when a certificate is misused.

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.

Technical breakdown

How certificate trust decisions propagate into execution control

Code-signing trust is layered. A certificate authority issues a certificate, the operating system validates the chain to a trusted root, and application control policies decide whether that signed binary can execute. The key failure is that these layers are often treated as equivalent, when they are not. A valid signature can prove origin, but it does not guarantee that the publisher is safe in a given environment. If policy is built around broad publisher trust, a compromised certificate can still open the door even when the binary is genuinely signed.

Practical implication: separate signature validation from execution authorisation and require explicit local policy approval for sensitive application classes.

Why activation-code abuse is a workflow compromise, not a key theft problem

The DigiCert incident described here matters because the attacker did not need the customer’s private key material. Instead, the abuse path ran through approved orders and activation codes, which were enough to complete certificate retrieval and use. That changes the defence model. When the issuance workflow is the attack surface, controls around account verification, approval, and order activation become as important as the cryptographic strength of the certificate itself. In identity terms, the workflow became the credential.

Practical implication: treat certificate activation and order fulfilment as privileged identity workflows that require stronger approval, separation of duties, and auditability.

Why default-deny reduces trust amplification

Default-deny works because it prevents trust from being inherited automatically from external authorities. A signed file is still subject to a local allow decision, which means the organisation retains the final say over execution. This is especially important when root stores, reputation services, and publisher trust can all be influenced by events outside the enterprise. In effect, default-deny narrows the blast radius of certificate misuse by forcing each application class to earn approval inside the environment rather than outside it.

Practical implication: use default-deny for high-risk execution paths and reserve publisher trust for narrowly defined, reviewed software sets.

Threat narrative

Attacker objective: The attacker’s objective was to obtain legitimate-looking code-signing capability so malicious binaries would pass trust checks and execute more easily.

1. Entry occurred through social engineering of support staff and a malicious ZIP-delivered .scr file that gave the attacker a foothold in the certificate workflow environment.
2. Credential and workflow abuse followed when the threat actor accessed internal systems and the portal, then obtained activation codes tied to already-approved EV certificate orders.
3. Impact came from the ability to produce validly signed malware that could appear trustworthy to application control and reputation-based defences.

NHI Mgmt Group analysis

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.

Activation-code compromise is a lifecycle failure, not just an issuance problem. The governance gap is the assumption that once a certificate order is approved, the surrounding workflow is safe. That assumption fails when an attacker can hijack activation or fulfilment steps without touching private keys. NHI-style lifecycle thinking applies here: creation, activation, and use are distinct control points, and each must be governed explicitly.

Publisher trust creates a broad blast radius when trust is inherited automatically. If allow rules are based on publishers rather than explicit local approval, any abused certificate tied to that publisher can inherit execution rights. That turns certificate misuse into a policy problem rather than a single compromised artefact. Practitioners should treat publisher trust as a scoped exception, not a default operating model.

Root store decisions and endpoint policy now form part of the identity perimeter. The post shows how operating systems, security tools, and enterprise policies all make trust decisions before local governance does. That makes certificate governance adjacent to IAM and NHI oversight because certificates are credentials with lifecycle, issuance authority, and revocation pressure. The practical conclusion is to govern trust boundaries as identity boundaries.

Blast-radius control is the decisive control variable when signed malware can look legitimate. If defenders cannot guarantee the integrity of upstream certificate workflows, they must reduce what a valid signature can accomplish inside the environment. That means constraining execution paths, scoping trusted publishers tightly, and maintaining clear revocation and blocklisting processes.

What this signals

Certificate governance is converging with machine identity governance. The same lifecycle weaknesses that affect service accounts and workload identities also affect signing certificates, because both depend on controlled issuance, activation, and revocation. Teams that still separate endpoint trust from identity governance will miss how quickly trust expands when certificates are treated as static artefacts rather than managed credentials.

The operational signal for practitioners is clear: default-deny and scoped trust will matter more as supply-chain abuse keeps pushing defenders to rely on signed artefacts. That makes certificate lifecycle visibility and policy review part of the identity perimeter, not an adjacent hygiene task.

For practitioners

• 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.
• Block known compromised thumbprints Create explicit block rules for affected certificate thumbprints so binaries signed with those certificates are denied even when publisher trust exists.

Key takeaways

• The article shows that certificate misuse is as much a workflow problem as a cryptographic problem.
• The evidence points to a control gap where trust can be inherited too broadly from signing and publisher status.
• Practitioners should narrow execution trust, harden activation workflows, and treat certificates as governed identities.

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.
• Publisher trust: Publisher trust is a policy model that allows software to run because it was signed by a trusted publisher. It reduces review overhead, but it can widen risk if the publisher or certificate lifecycle is compromised, because trust is inherited rather than newly decided for each binary.
• Default-deny application control: Default-deny application control is an execution model where software is blocked unless it is explicitly approved. It is designed to keep the final trust decision inside the organisation, limiting exposure when signatures, certificates, or external trust services make incorrect decisions.
• Certificate activation workflow: The certificate activation workflow is the operational process that turns an approved certificate order into usable signing capability. It is a high-value control point because abuse at activation can produce valid-looking certificates without stealing private keys, making workflow governance critical.

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

👉 The full Airlock Digital post covers certificate checks, allowlisting implications, and block rule validation steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a practical foundation for governing credentials across their identity programmes.