Most articles about EV code signing certificates describe a benefit that no longer exists. Until August 2024, EV certificates provided an immediate Microsoft SmartScreen reputation bypass: new software signed with EV passed SmartScreen on first download without any warming period. Microsoft removed this behavior when it eliminated EV Code Signing OIDs from the Trusted Root Program in August 2024. Both OV and EV certificates now build SmartScreen reputation identically through download volume.
If you are reading about EV code signing to decide whether the premium over OV is justified, and the article you are reading describes instant SmartScreen trust as a benefit, that information is outdated and the decision you make based on it will be wrong.
EV code signing still has real and significant benefits. They are different from what most articles describe. This guide covers what EV actually provides in 2026, the specific technical requirements it satisfies that OV cannot, the validation process, and the honest answer to who needs it.
What an EV Code Signing Certificate Is
An Extended Validation (EV) code signing certificate is a digital certificate issued by a Certificate Authority after the most rigorous identity verification process available for code signing. EV verification goes substantially beyond Organization Validation (OV): the CA must confirm the organization’s legal existence, physical address, operational status, and the specific authority of the person requesting the certificate to sign on behalf of the organization.
The certificate uses the same X.509 cryptographic infrastructure as OV certificates. The signing operation is identical. What distinguishes EV is the depth of identity verification behind the certificate and two specific technical capabilities that follow from it: the ability to sign Windows kernel-mode drivers, and the ability to establish a Microsoft Hardware Dev Center account for WHQL driver submission.
The Actual Benefits of EV Code Signing in 2026
The benefits listed here are genuine and current. They exclude the instant SmartScreen bypass, which was removed in 2024.
Benefit 1: Windows kernel-mode driver signing (non-negotiable technical requirement)
This is the primary remaining reason most organizations choose EV over OV. Microsoft requires EV code signing certificates for all kernel-mode driver submissions on Windows 10 and Windows 11. Kernel-mode drivers load directly into the Windows kernel and run with the highest system privileges. A compromised or malicious kernel driver can take complete control of a system. Microsoft’s requirement for EV signing reflects the extreme trust level kernel-mode code requires.
The requirement applies to both kernel-mode and user-mode drivers submitted through the Microsoft Hardware Dev Center. OV certificates cannot satisfy this requirement, regardless of how long they have been in use or how established the publisher’s reputation is. There is no alternative to EV for kernel driver signing on modern Windows.
This affects: device driver developers, hardware manufacturers distributing Windows drivers, security software vendors whose products load kernel components (antivirus, endpoint detection, disk encryption), and any software requiring kernel-level access such as virtualization products and low-level system utilities.
Benefit 2: Microsoft Hardware Dev Center and WHQL access
The Microsoft Hardware Dev Center (formerly Dev Portal) is Microsoft’s platform for driver submission, WHQL (Windows Hardware Quality Labs) testing and certification, and Windows Update driver distribution. To create a Hardware Dev Center account and submit drivers, an organization must have a valid EV code signing certificate.
WHQL certification is the process through which Microsoft tests and approves hardware drivers for distribution through Windows Update. End users who connect hardware see driver updates delivered automatically through Windows Update when the driver has passed WHQL. Non-WHQL drivers can still be distributed but require user action to install and may show unsigned driver warnings on strict Windows configurations.
Any hardware manufacturer, device driver developer, or OEM that wants their drivers distributed through Windows Update must go through this process, which requires EV from the start.
Benefit 3: Stronger verified identity in Authenticode details
EV verification requires the CA to confirm more identity information than OV. The resulting certificate contains the organization’s legal name as confirmed through the extended validation process. When users or security tools inspect the Authenticode signature details on a signed binary, they see this verified organizational identity.
This matters in specific contexts: enterprise software procurement processes that inspect certificate details as part of vendor vetting, security software that evaluates code signing certificate type and identity depth, and regulated industry contexts where audit evidence requires demonstrating the highest available publisher identity assurance.
The organizational name displayed in UAC dialogs and SmartScreen is the same between OV and EV from the user’s perspective. The difference shows when the full certificate details are examined: EV certificates contain more thoroughly verified organizational information and can carry the EV policy OID, which some enterprise security tools check specifically.
Benefit 4: Hardware-protected private key (shared with OV since June 2023)
EV certificates have always required private key storage on a hardware token or HSM. This requirement was extended to OV certificates in June 2023 by the CA/B Forum. As a result, this is no longer a differentiating benefit between EV and OV: both now require hardware-protected keys.
The practical consequence: the operational setup for EV and OV is now more similar than it was before 2023. Both require working with hardware tokens or cloud HSM services. The cost and complexity gap between OV and EV has narrowed because OV now shares the hardware requirement that was previously EV-specific.
Benefit 5: Enterprise compliance and procurement requirements
Some enterprise procurement processes, government contract requirements, and industry compliance frameworks specifically require EV code signing. This is separate from any SmartScreen consideration and persists regardless of the 2024 SmartScreen change.
Organizations distributing software to federal agencies, defense contractors, or enterprises with strict vendor software vetting may encounter explicit EV requirements in their contracts or procurement checklists. In these contexts, EV is required regardless of whether the technical benefits justify the premium in isolation.
For publishers outside the driver and WHQL space, the honest assessment is: EV provides genuine value in specific enterprise and government procurement contexts where EV is explicitly required, and in high-assurance scenarios where the depth of identity verification matters for audit purposes. For general consumer software distribution where SmartScreen reputation is the primary concern, OV and EV now behave identically, and OV is the more cost-effective choice.
The 2024 SmartScreen Change: What Happened and Why
Microsoft published updated requirements for its Trusted Root Program stating that EV Code Signing OIDs would be removed from existing root certificates in August 2024. Before this change, SmartScreen used the presence of an EV OID in the certificate chain to grant immediate reputation status to new software. An EV-signed binary from a brand-new publisher would pass SmartScreen on first download with no download history.
After the change, SmartScreen evaluates all code signing certificates by the same reputation criteria regardless of validation level. Download volume, publisher history, and user reports determine reputation. A new publisher with an EV certificate experiences the same warming period as a new publisher with an OV certificate.
Microsoft’s stated rationale reflects a broader security philosophy: reputation-based trust systems should be based on actual observed behavior, not on administrative validation level. A certificate proving thorough identity verification does not prove the software is safe. The SmartScreen system is more accurately calibrated when it bases trust on actual distribution behavior rather than certificate tier.
Some sources give different dates for this change: SSL.com references March 2024, Microsoft’s own documentation references August 2024, and some third-party sources say the change was gradual across 2024. The precise timing of the SmartScreen behavior change is less important than the current state: as of 2026, EV and OV have equivalent SmartScreen treatment. Any publisher decision-making based on EV’s SmartScreen advantage should be made with the assumption that advantage no longer exists.
The EV Validation Process: What the CA Verifies
EV code signing validation is more thorough than OV and typically takes several business days to complete. Understanding the process helps applicants prepare the required documentation and avoid delays.
| Verification step | What the CA confirms | Documentation typically required |
| Legal entity existence | The organization is a legally registered entity in its claimed jurisdiction | Business registration documents; certificate of incorporation; articles of organization |
| Physical address | The organization has a verified operational address | Utility bill, lease agreement, or government document with the address |
| Operational status | The organization is actively operating (not dissolved, not shell entity) | Recent business registry confirmation; professional reference |
| Telephone verification | The organization can be reached at a verified, publicly listed number | DUNS number lookup; business directory verification; independent callbacks to listed numbers |
| Authorized requestor | The individual requesting the certificate has authority to act for the organization | Employment verification; authorization letter on letterhead; HR confirmation |
| Domain or trademark (where applicable) | The organization has rights to any domain or name in the certificate | Trademark registration, domain registration records |
The full validation process typically takes 3 to 7 business days when documentation is prepared. Delays most commonly occur when the CA cannot independently verify the phone number (the number must be listed in a verifiable directory, not just provided by the applicant), when address documents are dated too long ago, or when the authorized requestor’s authority cannot be confirmed.
Having documentation ready before submitting the certificate order significantly shortens the process. Applicants should confirm their organization appears in a business registry or directory accessible to the CA before beginning.
Private Key Storage: Hardware Tokens and Cloud HSM
EV code signing private keys must be stored on hardware meeting FIPS 140-2 Level 2 minimum standards. CAs fulfill this requirement in two ways: shipping a physical hardware token with the certificate, or providing access to a cloud HSM service where the key is stored remotely and signing operations happen via API.
Physical hardware token
The traditional delivery method. The CA ships a USB security token (SafeNet eToken, Entrust, or similar) with the certificate already provisioned on it. The signer plugs the token into the signing machine, enters the token PIN, and uses jarsigner, signtool, or another signing tool to perform the signing operation.
Physical tokens create operational challenges for CI/CD pipelines and distributed teams: the token must be physically present at the signing machine, cannot be shared across build servers, and requires secure custody procedures. For developer workstations doing manual release signing, physical tokens are straightforward. For automated build pipelines, they are impractical.
Cloud HSM signing services
Cloud HSM services store the private key in remote hardware security modules accessible via API. The signer authenticates to the service and submits the content to be signed; the signing operation happens inside the HSM and the signature is returned. The private key never leaves the HSM.
Cloud HSM is the standard approach for CI/CD pipeline signing and for distributed teams. Major CA cloud HSM services include DigiCert KeyLocker, SSL.com eSigner, and GlobalSign Document Signing Service. For EV specifically, cloud HSM eliminates the physical token distribution problem while maintaining the required hardware key protection.
Before purchasing an EV certificate, confirm whether cloud HSM signing is available for your use case. Some CAs ship physical tokens as the default for EV and offer cloud HSM as an add-on or separate tier. If your signing workflow is automated or your team is distributed, start the conversation about cloud HSM availability before committing to a specific CA.
Who Genuinely Needs EV Code Signing in 2026
With the SmartScreen instant bypass removed, the decision between OV and EV has become more straightforward. EV is genuinely needed in these situations:
- Device driver developers: Any software that loads as a kernel-mode or user-mode driver on Windows 10 or Windows 11 must be signed with EV and submitted through Microsoft’s Hardware Dev Center.
- Hardware manufacturers distributing through Windows Update: WHQL certification and distribution through Windows Update requires an EV certificate and a Hardware Dev Center account established with EV.
- Security software vendors with kernel components: Endpoint detection and response (EDR), antivirus, disk encryption, and similar security products that load kernel-level components require EV for those components.
- Virtualization and low-level system software: Hypervisors, virtual device drivers, and other software requiring kernel access fall under the same requirement.
- Government and defense contractors where EV is contractually required: Some procurement requirements specify EV regardless of technical necessity.
- Organizations with compliance requirements specifying EV: Some industry frameworks and enterprise security standards specify EV as the required certificate type.
EV is not necessary for these situations:
- General consumer application distribution: Desktop applications, utilities, and user-mode software that do not load kernel components. OV provides equivalent SmartScreen behavior and is sufficient.
- Enterprise internal software distribution: Internal tools distributed to company employees through managed deployment systems. Code signing requirements here depend on internal policy, not kernel access.
- Open-source software: Most OSS projects use SignPath Foundation (free, OV-level) or Sigstore for non-Windows artifacts. EV is rarely justified for OSS.
- Mobile applications: Android and iOS have different signing requirements unrelated to EV code signing.
EV vs OV: What Matters Now
| Factor | EV | OV |
| Kernel-mode driver signing on Windows 10/11 | Required | Not permitted |
| WHQL and Hardware Dev Center access | Required | Not permitted |
| SmartScreen instant reputation | No (removed August 2024) | No (same behavior) |
| SmartScreen reputation building | Same as OV: builds through download volume | Same as EV: builds through download volume |
| Identity verification depth | Multi-document legal, operational, address, authority verification | Legal registration, address, authorized requestor confirmation |
| Private key storage requirement | Hardware token or cloud HSM (always required for EV) | Hardware token or cloud HSM (required since June 2023) |
| Issuance time | 3-7 business days (validation-dependent) | 1-3 business days |
| Cost | Higher | Lower |
| Right choice for general software distribution | No benefit over OV post-2024 | Sufficient for all non-driver use cases |
Frequently Asked Questions
Does EV code signing still provide instant SmartScreen reputation?
No. Microsoft removed the EV Code Signing OIDs from its Trusted Root Program in August 2024, eliminating the distinction between EV and OV in SmartScreen’s evaluation. Both certificate types now build SmartScreen reputation identically through download volume over time. Any article or vendor page claiming EV provides instant or immediate SmartScreen reputation is describing pre-2024 behavior. The current state is that EV and OV are equivalent for SmartScreen purposes.
Why do I need EV for kernel-mode driver signing?
Microsoft’s driver signing policy requires EV certificates for kernel-mode driver submissions on Windows 10 and Windows 11. Kernel-mode drivers run with the highest system privileges and can take complete control of a machine if malicious or compromised. Microsoft’s requirement for EV reflects this: the extended identity verification process provides stronger accountability for the publisher of code running at kernel level. OV certificates are accepted for drivers targeting pre-Windows 10 versions of Windows, but not for Windows 10 or Windows 11 kernel-mode submissions.
What is WHQL and why does it require EV?
WHQL (Windows Hardware Quality Labs) is Microsoft’s testing and certification program for hardware drivers. WHQL-certified drivers can be distributed through Windows Update, appearing automatically to users who connect compatible hardware. To submit drivers for WHQL testing, a publisher must create a Microsoft Hardware Dev Center account, which requires a valid EV code signing certificate. This requirement exists because WHQL certification grants the highest level of driver distribution privilege (automatic Windows Update delivery), and Microsoft requires the strongest available publisher identity verification for it.
How long does EV code signing validation take?
Typically 3 to 7 business days when documentation is complete and correct. The most common delay is telephone verification: the CA must call a number listed in an independently verifiable directory (DUNS, local business registry, Yellow Pages equivalent), and if the organization’s listed number is not current, the verification cannot complete. Preparing documentation before submitting the order (business registration, address proof, authorized requestor authorization, and confirming the organization appears in verifiable directories) reduces delays significantly.
Can I use EV code signing in a CI/CD pipeline?
Yes, through cloud HSM signing services. Traditional EV certificates ship on physical hardware tokens that cannot be plugged into build servers. Cloud HSM services (DigiCert KeyLocker, SSL.com eSigner, GlobalSign) store the EV private key in remote hardware security modules accessible via API, allowing automated pipeline signing without physical hardware. Azure Trusted Signing is Microsoft’s managed signing service that provides equivalent SmartScreen reputation to OV/EV at lower cost and with better pipeline integration, though it currently supports only US and Canadian organizations for identity validation.
