Notifications
Clear all
Topic starter
25/06/2026 10:36 pm
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.
NHIMG editorial — based on content published by DigiCert: Microsoft Announces New EV Code Signing Requirements
By the numbers:
- 1.2% of all mobile applications are legitimate applications that have been repackaged to deliver ads and collect user information.
Questions worth separating out
Q: How should organisations govern code signing certificates for software releases?
A: Treat code signing certificates as privileged identity assets.
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.
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.
Practitioner guidance
- 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.
- 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.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- The Microsoft policy timeline for new UEFI submissions and existing submitter migration
- The identity verification requirements behind EV code signing certificates
- How SmartScreen reputation changes when code is backed by higher-assurance signing
- The practical differences between standard and EV code signing for software publishers
👉 Read DigiCert's analysis of Microsoft’s EV code signing requirements →
EV code signing requirements: what changed for trust governance?
Explore further
25/06/2026 11:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: EV code signing rules and software trust governance
