EV Code Signing: Complete Guide, Requirements & CI/CD Automation

An EV code signing certificate is a Windows code signing certificate issued only after a Certificate Authority has verified your company's legal existence, physical address and operational status against independent records, and whose private key is required to live on certified cryptographic hardware. It is the highest assurance level available for signing software, and it is what Microsoft requires before you can submit kernel-mode drivers. This guide covers what EV actually verifies, how it differs from OV, why Microsoft SmartScreen no longer treats it differently, what the CA/Browser Forum rules mean for your build pipeline, and how the two storage options (a USB token you hold or a cloud HSM you rent) compare over three years.

What Is an EV Code Signing Certificate?

Extended Validation code signing sits at the top of a three-tier system. A certificate binds a cryptographic key pair to a verified identity; when you sign an executable with the private key, Windows can prove two things about the file: it came from the organisation named in the certificate, and it has not been altered by a single byte since signing. That second property is why signing matters even inside a trusted network — an installer modified in transit or on a mirror fails signature verification immediately.

What makes validation "extended" is the depth of the vetting. For an OV (organisation validated) certificate, a CA confirms your organisation exists and that you control the request. For EV, the CA works through a defined checklist: legal existence in a government registry, an operational existence check, a verified physical address, a third-party business database or professional opinion letter, and a callback to a phone number the CA independently sources rather than one you supply. The process typically runs three to ten business days for a company with clean records, and considerably longer if your registry entry is stale or your entity was incorporated recently.

The result is a certificate whose subject field carries a company identity that a CA has staked its audit on. Windows surfaces that name in the User Account Control prompt and in the file properties. Microsoft Defender SmartScreen, however, no longer gives EV certificates any head start: EV and OV build reputation the same way.

Standard (OV) vs. EV Code Signing: Core Differences

The most common misconception about OV vs EV code signing is that only EV requires hardware. That stopped being true in June 2023, when the CA/Browser Forum extended the hardware key storage mandate to every code signing certificate. If you are comparing an OV quote against an EV quote on the assumption that OV lets you keep a PFX file on the build server, the comparison is out of date.

The prices above are our own published reseller list prices, current at the time of writing; every CA reprices, so treat them as an order of magnitude rather than a quote. The practical gap between the two tiers is narrower than the price difference suggests for most teams, unless you ship drivers, in which case EV is not optional, or a customer's procurement rules ask for EV. SmartScreen is no longer a reason to choose EV, because both tiers now build reputation the same way.

Key Benefits: SmartScreen Reputation and Kernel-Mode Signing

For years the main reason to buy EV was SmartScreen. That reason is gone, and it is worth being precise about what is left.

• SmartScreen: no longer an EV advantage. Microsoft Defender SmartScreen evaluates a download's reputation before letting it run, and a newly signed binary can trigger the blue "Windows protected your PC" interstitial until enough clean downloads accumulate. Microsoft's own SmartScreen documentation now states that EV certificates no longer bypass SmartScreen and that paying a premium for EV solely to avoid the warning is no longer justified. Any signature (OV or EV) still replaces "Unknown publisher" with your verified company name. See why SmartScreen still warns after code signing.
• Access to the Windows Hardware Developer Center. Since Windows 10 version 1607, kernel-mode drivers must be signed by Microsoft, not by you. To submit a driver package for that signature you register with Partner Center, and registration requires an EV code signing certificate. There is no OV path to signed drivers.
• Authenticode integrity for everything else. EXE, DLL, MSI, CAB, SYS, OCX, APPX and MSIX all carry Authenticode signatures that enterprise customers can pin in AppLocker or Windows Defender Application Control policies — increasingly a procurement requirement rather than a nice-to-have.
• Signatures that outlive the certificate. An RFC 3161 timestamp from a trusted TSA records when the signature was made, so binaries you shipped in 2026 keep verifying after the certificate expires in 2027. Skipping the timestamp is the single most expensive mistake in code signing, because the fix is re-signing and re-shipping everything.

What EV does not buy you is exemption from malware scanning, a faster reputation for a brand-new domain, or immunity from revocation if your key leaks. It buys identity assurance and access to driver signing, nothing more.

CA/Browser Forum Hardware Requirements & Storage Options

Since June 2023, the CA/Browser Forum baseline requirements for code signing state that private keys must be generated and stored on hardware meeting FIPS 140-2 Level 2, FIPS 140-3 Level 2, or Common Criteria EAL4+. The subscriber has to attest to it, and the CA has to verify the attestation. Since 1 March 2026 the same requirements (Ballot CSC-31) also cap the validity of every new code signing certificate at 460 days, down from 39 months; certificates issued earlier keep their original expiry. We have written about how that rule evolved and what is coming next in more detail.

Read the clause carefully, because a great deal of marketing depends on you not doing so. The mandate is hardware key storage. It is not cloud key storage. There are exactly two compliant shapes:

A cryptographic USB token you hold — a SafeNet eToken, YubiKey, or Feitian ePass2003, usually shipped by the CA or bought alongside the certificate. The key is generated on the device and cannot be exported. You own the hardware outright, and the same token can often be reused at renewal, including with another CA if that CA accepts the token model and its key attestation.

A cloud HSM the CA or a hyperscaler operates: DigiCert KeyLocker, SSL.com eSigner, Microsoft Artifact Signing (formerly Trusted Signing), or your own HSM in Azure Key Vault or AWS CloudHSM. The key is generated inside the provider's certified module and is equally non-exportable. You rent access to it, typically as an annual subscription plus a per-signature or per-quota fee.

Both satisfy the same clause. The certified hardware in your server room and the certified hardware in a vendor's datacentre differ in custody, in failure modes, and in who bills whom every month — not in compliance standing. The one genuine compliance distinction worth knowing: a small number of regulated environments specifically require a managed FIPS 140-2 Level 3 HSM, which most USB tokens do not meet. If a contract names Level 3, that decides it for you.

The historical argument against tokens was never compliance. It was operations: a token prompts for a PIN, and it is physically attached to one machine, which is awkward when your build agents are ephemeral containers in someone else's cloud.

USB Token vs. Cloud HSM: Deployment and Cost Breakdown

The two models have fundamentally different cost curves, and that is what makes the comparison worth doing properly rather than by gut feel. The cloud model has a low entry price and a marginal cost per signature. The token model has a higher entry price and a marginal cost of zero.

Written as a formula over three years:

• Cloud HSM route = (certificate per year × 3 years) + (signing service subscription × 3 years) + (signatures × per-signature fee)
• Token route = (certificate per year × 3 years) + token hardware, once + signing software, once

"Certificate per year" matters: a certificate issued from 1 March 2026 is valid for at most 460 days, so a three-year term is a plan, not a single certificate. CAs sell 1, 2 or 3-year plans depending on the CA, and the certificate is re-issued each time it expires during the term.

Here is the token side with real, verifiable numbers — our own list prices, so you can check them against the certificate catalogue rather than take our word for it:

We are deliberately not printing competitors' numbers here, because cloud signing vendors reprice frequently and a stale figure in a comparison table is worse than no figure. Take their current list price and put it in the formula above. The structural point survives any repricing: the token route is flat, the cloud route is a slope. Work out roughly how many signatures a year you produce — count every EXE, DLL, MSI and installer across every build, not just releases, because that is what gets metered — and find where the two lines cross for your volume. Teams shipping nightly builds across a multi-binary product usually find the crossover arrives faster than they expected.

Cost is not the only axis. A cloud signature is a network call to a third party inside your release path: provider outage, expired credential, or rate limiting blocks the build. A local token adds no such dependency and no per-signature round trip. Conversely, the token is a physical object in a specific building, and if that machine is off, nobody signs. Neither risk is theoretical, and which one you would rather own is a real engineering decision — not a marketing one.

How to Automate EV Code Signing in CI/CD Without Cloud Lock-in

The PIN prompt and the single-machine attachment are solvable, which removes the only serious argument for renting an HSM. The pattern is to keep the token on one always-on Windows host and expose signing — never the key — to your build agents:

1. Install the token on one Windows host (Windows 10/11 or Server 2019+) that stays powered on. This is your signing server; it can be a small VM or an office box.
2. Enter the token PIN once so signing runs unattended. OneSigner keeps it in the service configuration file (appsettings.json), so restrict that file to SYSTEM and administrators. It also manages the interactive-session requirement that Windows imposes on token access.
3. Enable the Key Vault proxy and map a certificate name to the certificate on the token. The host now answers the Azure Key Vault signing API.
4. Issue a signing code per pipeline. Each partner code is revocable on its own and cannot reach the admin API, and the certificate mapping can be limited to an allowlist of certificate thumbprints, so a leaked code cannot sign with any other certificate.
5. Point your build at the host. Stock AzureSignTool works unchanged; OneSignTool is our drop-in build of it.

OneSignTool sign -kvu https://sign.yourcompany.com -kva <PIPELINE_SIGNING_CODE> \
  -kvc ev-cert -fd sha256 -tr http://ts.ssl.com -td sha256 myapp.exe

Only file hashes cross the network; the binary and the private key both stay put. The full walkthrough is in the OneSignTool CLI guide and the CI/CD setup article.

How to Obtain an EV Code Signing Certificate

1. Choose a CA and a storage model. Decide up front whether the key lands on a token you own or in a vendor's cloud, because moving it afterwards is impossible by design — you would buy a new certificate.
2. Prepare for corporate validation. The CA checks a government registry (ACRA in Singapore, Companies House in the UK, Secretary of State filings in the US) plus a business database such as Dun & Bradstreet, verifies a physical address, and calls a number it sources independently. Confirm your registry entry and D&B listing are current before you order; stale records are the single biggest cause of delay.
3. Receive the hardware. The CA ships a preloaded token, or you generate the key on a token you already own and submit an attestation. Plan for international shipping time if your entity is not in the CA's home region.
4. Install and automate. Install the token driver, verify the certificate appears in the Windows store, then configure your signing profile and timestamp URL. Our code signing setup guide covers this end to end.

A mismatch between where your company is registered and where you operate is normal and does not block EV issuance — CAs validate the registered entity, and the operating address does not have to match.

When a Cloud HSM Is the Right Answer

We build token automation software, so treat this section as the one where we argue against ourselves. Rent the HSM if: nobody on your team can own an always-on Windows machine; a contract or regulator specifically names FIPS 140-2 Level 3; your signing volume is high enough that token throughput becomes the bottleneck; or you sign so rarely that a perpetual licence never pays for itself. Those are real cases, and in them a managed service is the honest recommendation. Our full comparison page lists every case where we are not the right tool.

Frequently asked questions

What is the primary difference between OV and EV code signing?

EV certificates undergo more rigorous corporate vetting: legal, operational and physical existence checks plus an independent callback. OV requires standard organisation validation. Microsoft SmartScreen treats both the same: EV no longer bypasses SmartScreen, and both build reputation gradually as clean downloads accumulate. Only EV grants access to the Windows Hardware Developer Center for kernel-mode driver signing.

Why does an EV code signing certificate require a physical USB token or HSM?

CA/Browser Forum baseline requirements mandate that code signing private keys be generated and stored on hardware certified to FIPS 140-2 Level 2 or Common Criteria EAL4+, so that a compromised build server cannot yield an exportable signing key. Since June 2023 this applies to OV certificates as well, not only EV.

Can EV code signing certificates be used in automated CI/CD pipelines?

Yes. The PIN prompt that historically broke automation is solved by entering the PIN once on the signing host (kept in a service configuration file restricted to SYSTEM and administrators), and the single-machine limitation is solved by exposing an Azure Key Vault compatible signing endpoint so remote build agents sign against the local token. Only hashes travel, and there are no per-signature fees.

Is an EV certificate required for Windows kernel-mode driver signing?

Yes. Microsoft requires an EV code signing certificate to register with and submit packages through the Windows Hardware Developer Center dashboard, which is the only route to a Microsoft-signed kernel-mode driver on Windows 10 version 1607 and later.