TL;DR: Microsoft’s EV code signing requirement for new UEFI submissions and migrated applications tightened software trust by tying code acceptance to stronger identity verification, according to DigiCert. The policy matters because it shifts application authenticity from a simple certificate check to a higher-assurance trust and reputation model that IAM and security teams should treat as governance, not just packaging.
At a glance
What this is: This article explains Microsoft’s EV code signing requirement for UEFI submissions and how stronger certificate validation changes software trust and authenticity checks.
Why it matters: It matters because identity assurance is part of software trust governance, and IAM, PKI, and application security teams need to treat signing policy as a control boundary.
Context
Software trust governance is the set of controls that decide whether code is accepted as authentic, reputable, and safe to distribute. In this case, the change is not about code syntax or packaging, but about stronger identity proofing for the party signing the software.
For IAM and security teams, the important shift is that a certificate is not just a technical token. It becomes evidence of who the signer is, how strongly that identity was verified, and whether downstream platforms should grant the software immediate 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 breaks when software trust is based only on a valid signature?
A: A valid signature alone can fail when attackers repurpose signed software, repackaging legitimate apps or drivers to carry malicious payloads. The control breaks because cryptographic validity does not prove that the publisher was strongly verified or that the release remains trustworthy after distribution.
Q: What is the difference between code signing and software reputation controls?
A: Code signing proves who signed the software under a given identity assurance process, while reputation controls influence whether users and platforms treat that software as safe or familiar. Both matter, but they solve different parts of the trust problem and should be governed together.
Technical breakdown
EV code signing and identity verification
Extended Validation code signing adds a stronger proofing layer before a certificate can be used to sign software. Instead of relying on a basic certificate issuance flow, the signer goes through a more detailed identity verification process defined by standards bodies such as the CA/Browser Forum and related industry groups. That changes the trust model from simple possession of a signing credential to assurance about the organisation behind it. In practice, the certificate becomes an identity-backed assertion about software origin, not just a cryptographic wrapper.
Practical implication: Treat code signing issuance as an identity assurance workflow, not only a PKI operation.
SmartScreen reputation and post-release trust
The article links EV signing to immediate reputation with Windows SmartScreen, even when a file or publisher has no prior reputation. That means the trust decision moves beyond the compiler or release pipeline and into the consumption environment, where reputation services influence whether users see warnings or proceed. This is important because software trust is not binary. It is a layered judgement combining signing identity, reputation history, and the receiving platform’s policy logic.
Practical implication: Map signing policy to the downstream trust systems that consume certificate signals.
Why software authenticity is now a governance issue
Software authenticity is often treated as a packaging concern, but EV code signing shows it is also a governance control. If identity verification is weak, then malicious repackaging, trojanised installers, and counterfeit updates become easier to pass off as legitimate. The control objective is not only to prevent tampering, but to make the signer economically and procedurally accountable. That is why code signing policy belongs in security governance, developer operations, and release approval design together.
Practical implication: Assign ownership for signing policy across security, platform, and release governance rather than leaving it with developers alone.
Threat narrative
Attacker objective: The attacker wants malicious code to inherit the trust of legitimate software so it can be distributed and executed at scale.
- Entry occurs when attackers repackage legitimate software or custom drivers with malware, spyware, adware, or Trojans to make malicious code appear trustworthy.
- Credential or signing abuse occurs when users and platforms rely on the apparent legitimacy of the signed package rather than verifying the true origin and reputation of the publisher.
- Impact is that end users install software that appears authentic while malicious code gains distribution, user trust, and access to sensitive data or devices.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
EV code signing is a trust governance control, not a certificate formality. The article shows that Microsoft tied code acceptance to stronger identity verification because the signer’s identity now matters as much as the signature itself. That makes release governance part of identity governance, because software trust depends on who is allowed to assert authenticity.
Identity assurance is being pushed closer to software consumption. Immediate SmartScreen reputation means trust is evaluated after release, not only during build or signing. That matters because modern distribution channels need controls that survive repackaging, redistribution, and publisher impersonation.
Software authenticity depends on the signer’s verified identity, not only on cryptography. A valid signature can still be misleading if the issuing process is weak or the publisher is not sufficiently verified. Practitioner teams should treat signing policy as an assurance boundary that determines which software is allowed to claim legitimacy.
Named concept: software trust governance. This article illustrates the point where code signing, identity proofing, and reputation services become one control surface. The implication is that release, PKI, and application security teams need a shared model for who can vouch for software and under what assurance level.
UEFI signing requirements show how platform trust is becoming policy-driven. Once a platform changes the acceptance criteria, organisations cannot rely on old assumptions about signature sufficiency or publisher reputation. The practical conclusion is that trust decisions now need lifecycle ownership, not ad hoc engineering approval.
From our research library:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Software trust governance is converging with identity governance. As signing policy becomes tied to stronger verification, release teams and IAM teams have to share ownership of who is allowed to assert authenticity. The practical shift is away from treating certificates as packaging artefacts and toward treating them as governance-backed identity claims.
Trust decisions now extend beyond the build pipeline. Reputation systems and platform warnings influence whether software is accepted after release, which means policy has to account for distribution context as well as signing context. Teams that only secure the build still leave a governance gap at the point of consumption.
For practitioners
- Review signing assurance levels Map each code signing certificate class to the identity proofing level required before software can be trusted by downstream platforms.
- Govern release trust as a policy control Document who can approve signing credentials, who validates publisher identity, and which software categories must use EV-grade assurance.
- Align distribution controls with reputation services Check how your release process interacts with platform reputation checks such as SmartScreen so that trust decisions are predictable after release.
- Separate developer convenience from trust assurance Do not let the ease of signing override the need for stronger validation when software will be distributed broadly or impersonation risk is high.
Key takeaways
- EV code signing raises the assurance bar for software publishers by requiring stronger identity verification before code is accepted.
- The key governance change is that software trust now depends on the signer’s verified identity and downstream reputation checks, not just on a valid certificate.
- Security and IAM teams should manage signing policy as a lifecycle control spanning issuance, approval, and post-release trust decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Signing certificates function as authenticators for software origin and release assurance. |
| Recommendation — Apply IA-5 governance to issuance, rotation, and revocation of code signing credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Software trust depends on who is authorised to assert authenticity through signing. |
| Recommendation — Align signing authority with PR.AA-05 so only approved publishers can assert software trust. | ||
| CIS Controls v8 | CIS-5 — Account Management | Signing accounts and publisher identities need lifecycle control like any privileged account. |
| Recommendation — Manage code-signing publishers under CIS-5 with explicit ownership and removal paths. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Code signing keys and publishers require controlled access because they confer trust authority. |
| Recommendation — Restrict signing key access under A.8.2 and review who can approve trust-bearing releases. | ||
Key terms
- Extended Validation Code Signing Certificate: An Extended Validation Code Signing Certificate is a digital certificate used to sign software so users and systems can verify who published it. It binds a code signer’s identity to a public key through a stricter validation process, helping establish trust in software integrity, publisher identity, and tamper detection during distribution and execution.
- Software Trust: Software trust is the ability to prove that code was produced, approved, deployed, and maintained under controlled conditions. It goes beyond finding defects to include provenance, verification, remediation, and evidence that the running software matches the trusted state.
- Publisher Reputation: Publisher reputation is the accumulated trust signal associated with a signing identity, vendor, or certificate over time. In reputation-based trust systems, the same signer can be treated differently depending on how often files are downloaded, whether behaviour is benign, and whether the identity has an established usage history.
- 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.
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.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org