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 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, and Microsoft's reputation systems weight it accordingly.
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.
| OV code signing | EV code signing | |
|---|---|---|
| Vetting | Organisation existence and requester authority | Legal, operational and physical existence, third-party database check, independent callback |
| Typical issuance time | 1–3 business days | 3–10 business days |
| SmartScreen reputation | Accrues gradually with download volume and clean history | Carries reputation from first release in practice |
| Kernel-mode driver signing | Not eligible | Required to register with the Windows Hardware Developer Center |
| Private key storage | Certified hardware (FIPS 140-2 Level 2 / CC EAL4+) since June 2023 | Certified hardware (same requirement) |
| Indicative list price | From US$129/year (SSL.com) to US$690/year (Sectigo) | From US$310/year (SSL.com) to US$790/year (GlobalSign, Sectigo) |
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 you release consumer-facing software, in which case the SmartScreen behaviour usually decides it.
Key Benefits: SmartScreen Reputation and Kernel-Mode Signing
Two benefits justify EV for most of the teams that buy it, and both are about what happens to a user in the first thirty seconds after they download your installer.
- No "Unknown Publisher" on day one. Microsoft Defender SmartScreen evaluates a download's reputation before letting it run. An unsigned or newly-signed OV binary triggers the blue "Windows protected your PC" interstitial until enough clean downloads accumulate. In practice, EV-signed binaries clear that screen from first release, which is the difference between a working download funnel and a support queue full of screenshots.
- 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 Microsoft's reputation systems price that assurance in.
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. 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 hold a certificate from any CA at renewal.
A cloud HSM the CA or a hyperscaler operates — DigiCert KeyLocker, SSL.com eSigner, Azure 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 × 3 years) + (signing service subscription × 3 years) + (signatures × per-signature fee)
- Token route = (certificate × 3 years) + token hardware, once + signing software, once
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:
| Line item | 3-year cost | Notes |
|---|---|---|
| SSL.com EV Code Signing certificate | US$930 | US$310/year; multi-year terms reduce the per-year figure |
| FIPS 140-2 USB token | US$199 | One-time. Reusable at renewal and across CAs |
| OneSigner signing automation | US$0 | A perpetual Basic licence is bundled free with the certificate; standalone it is US$99 |
| Per-signature fees | US$0 | No metering at any volume |
| Three-year total | US$1,129 | Unchanged whether you sign 500 times or 500,000 |
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:
- 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.
- Store the token PIN encrypted so signing runs unattended. OneSigner encrypts it with DPAPI and manages the interactive-session requirement that Windows imposes on token access.
- 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.
- Issue a signing code per pipeline. Each code is revocable on its own, cannot reach the admin API, and can be pinned to a single certificate thumbprint, so a leaked code cannot sign anything but your product.
- Point your build at the host. Stock
AzureSignToolworks 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.exeOnly 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
- 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.
- 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.
- 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.
- 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 rigorous corporate vetting — legal, operational and physical existence checks plus an independent callback — and carry Microsoft SmartScreen reputation from first release. OV requires standard organisation validation and builds 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 storing the PIN encrypted on the signing host, 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.