EV code signing rules and software trust governance

At a glance

What this is: This is a DigiCert analysis of Microsoft’s EV code signing requirements and how stronger publisher verification changes software trust.

Why it matters: It matters because code signing is an identity control for software publishers, so security teams need to align certificate governance, trust decisions, and release pipelines.

By the numbers:

• 1.2% of all mobile applications are legitimate applications that have been repackaged to deliver ads and collect user information.

👉 Read DigiCert's analysis of Microsoft’s EV code signing requirements

Context

Software signing is a trust control that binds code to a verified publisher identity. In this case, Microsoft’s EV code signing requirement raised the assurance bar for new UEFI submissions and for existing publishers migrating to the new standard.

For IAM and security teams, the practical issue is not the certificate itself but the governance model behind it. Stronger identity vetting changes how organisations should think about publisher authenticity, reputation services, and the trust placed in released software.

The same pattern matters beyond driver submission. When software supply chains are under pressure from repackaging and malware, code signing becomes part of identity governance for developers, release pipelines, and platform trust.

Key questions

Q: How should organisations govern code signing certificates for software releases?

A: Treat code signing certificates as privileged identity assets. Define ownership, approval, renewal, and revocation workflows, and ensure certificate policy is enforced before software reaches distribution paths. The goal is to keep publisher identity, release governance, and trust decisions aligned so a signed package is also a verified one.

Q: Why does EV code signing matter more than basic signing for software trust?

A: EV code signing matters because it adds stronger identity verification before trust is granted. That raises the assurance level behind the certificate and gives reputation systems a firmer basis for accepting software from a new or low-history publisher.

Q: What do security teams get wrong about signed software?

A: Many teams treat signing as proof of safety when it is really proof of origin and, depending on the certificate type, proof of stronger identity assurance. A signed file can still be malicious if the publisher identity is compromised or the release process is weak.

Q: Who should be accountable when software trust controls fail?

A: Accountability should sit with the teams that own publisher identity, certificate issuance, and software release governance together. If those functions are separated, trust breaks down because no single group can see the full lifecycle from identity proofing to distribution.

Technical breakdown

How EV code signing changes publisher trust

Extended Validation code signing adds a stronger identity proofing step before a certificate is issued. That matters because the certificate is not only a cryptographic object, it is also a statement about who the publisher is and whether that identity was verified to a higher standard. In Microsoft’s model, that stronger assurance improves initial reputation with SmartScreen and helps distinguish original software from repackaged or impersonated code. The mechanism is less about encryption and more about binding software distribution to a trusted publisher identity.

Practical implication: treat code signing policy as an identity assurance control, not a release checkbox.

Why SmartScreen reputation depends on signing assurance

Reputation systems need a starting point, and EV-signed code can establish that baseline even when a file or publisher has no prior history. That reduces the friction for legitimate software while making impersonation harder for attackers who rely on unsigned or weakly trusted packages. The trust gain comes from the combination of identity verification and distribution reputation, not from the certificate format alone. For organisations, this means software trust decisions should be tied to publisher assurance, not just to whether a binary is signed.

Practical implication: validate that your trust policy distinguishes basic signing from verified publisher identity.

What this means for UEFI submissions and release governance

UEFI code submission requirements create a governance gate in the software lifecycle. Developers must prove identity before code can enter a high-trust platform path, and existing submitters face migration pressure when standards change. That turns signing into a lifecycle control with onboarding, migration, and ongoing compliance dimensions. The real lesson is that software trust is managed over time, through publisher identity review, certificate issuance discipline, and release-path enforcement.

Practical implication: map certificate issuance and renewal into the same lifecycle controls you use for other privileged identities.

Threat narrative

Attacker objective: The attacker wants to borrow trust from legitimate software distribution to deliver malicious code at scale.

1. Entry occurs when attackers repackaged legitimate applications and distributed them as if they were trusted software.
2. Credential or trust abuse happens when users or platforms accept the packaged code without strong publisher identity proof.
3. Impact follows when malware, spyware, adware, or Trojans execute under the reputation of a seemingly legitimate application.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

EV code signing is an identity governance control for software publishers, not a packaging detail. Microsoft’s requirement shows that code trust depends on stronger publisher verification, not merely on the presence of a valid certificate. That shifts the control conversation from binary signing to identity assurance, certificate issuance, and trust policy. Practitioners should treat software publishing as an identity lifecycle problem with governance attached.

Reputation systems expose the difference between being signed and being trusted. SmartScreen can use EV-signed code to establish reputation even before a file has history, which makes the publisher identity the real control point. That is a meaningful distinction for security teams evaluating software trust. The implication is that certificate policy and publisher verification must be managed together, not separately.

Code signing is a privileged identity pattern because it grants distribution trust at scale. Once a publisher identity is accepted, every signed artifact can inherit that trust path into user endpoints and app stores. That makes certificate governance similar to privileged access governance: issuance, validation, and revocation all matter. Security teams should manage signing credentials as high-value identities, not routine developer assets.

Microsoft’s UEFI requirement illustrates how trust standards can force lifecycle discipline into the release pipeline. Existing submitters had to migrate by a deadline, which turned policy into an operational control rather than a paper standard. That is the part many organisations miss: trust requirements only matter when they are embedded into onboarding and migration workflows. The practitioner takeaway is to align release governance with identity proofing from the start.

Repackaged software is a reminder that supply-chain trust failures are identity failures first. If a malicious package can borrow the look of legitimate software, the gap is not only technical tampering but weak publisher authentication. That makes code signing, platform reputation, and identity verification part of the same defensive surface. Practitioners should review software trust as a cross-functional identity control, not a standalone developer task.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to NHI Mgmt Group research.
• For lifecycle controls that reduce trust drift across machine identities, see NHI Lifecycle Management Guide.

What this signals

Code signing policy is converging with identity governance, which means release teams will increasingly need the same discipline they already apply to privileged credentials and service accounts. The pressure point is not the certificate format itself but whether publisher identity can be verified, owned, and retired with the same rigor as other high-value identities.

When secrets leak into code and CI/CD paths, trust controls around software distribution become harder to defend in practice. That is why certificate governance, repository hygiene, and release approvals need to be managed together, not as separate assurance layers.

For practitioners

• Map code signing certificates to publisher lifecycle ownership Assign clear ownership for issuance, renewal, migration, and revocation so signing credentials are governed like other privileged identities. Include release engineering, security, and compliance in the approval path.
• Separate basic signing from high-assurance publisher trust Update trust policies so the organisation can distinguish a signed binary from one backed by verified identity proofing and stronger reputation treatment.
• Embed code trust checks into release governance Require code signing validation, certificate status review, and publisher identity checks before software enters UEFI, app store, or endpoint distribution paths.
• Review trust decisions for repackaged software risk Assess whether your current controls would still accept repackaged legitimate applications and whether reputation services are being used as a proxy for identity assurance.

Key takeaways

• EV code signing raises software trust by strengthening publisher identity verification, not by changing cryptography alone.
• Repackaged software shows why signed code still needs lifecycle governance, because trust can be borrowed even when identity controls are weak.
• Security teams should manage signing certificates as privileged identities and embed trust checks into release and distribution workflows.

Key terms

• Extended Validation Code Signing Certificate: A higher-assurance code signing certificate that requires stronger identity verification before issuance. It binds software to a verified publisher and is often used to strengthen trust decisions in operating systems, reputation services, and distribution platforms.
• Software publisher identity: The verified identity of the person or organisation responsible for releasing software. In trust governance, this identity matters because signed code can inherit reputation and distribution access, so publisher verification becomes a control point rather than a formality.
• Code signing governance: The set of lifecycle controls that manage issuance, use, renewal, and revocation of signing credentials. It is an identity control for software release, ensuring that trusted code is tied to a known publisher and that trust can be withdrawn when needed.

Deepen your knowledge

NHI governance, machine identity security, and secrets 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 Announces New EV Code Signing Requirements. Read the original.