Updated May 2026 | Category: EV Code Signing / Certificate Types / CA/B Forum / Key Storage / Validation Process | Reading time: 11 min
Extended Validation (EV) code signing is a type of code signing certificate that carries a higher level of organizational identity verification than standard Organization Validation (OV) certificates. The ‘Extended’ in Extended Validation refers specifically to the validation process: the Certificate Authority performs additional identity checks beyond what OV requires, and the resulting certificate embeds more verified organizational identity information.
EV code signing certificates also carry a mandatory hardware storage requirement that OV certificates only acquired recently: the private key for an EV certificate must be stored on a hardware security module meeting FIPS 140-2 Level 2 standards. The key cannot be exported to a software container or a file. This hardware requirement has been part of the EV standard since before OV certificates adopted similar requirements in 2023.
This guide explains what EV code signing is from the certificate standard down, how the validation process works, what the certificate contains technically, and how signing with EV works in practice.
Where EV Code Signing Comes From: The CA/B Forum Standard
The CA/Browser Forum is the industry body that publishes the requirements governing publicly trusted SSL/TLS and code signing certificates. The CA/B Forum publishes a separate document specifically for code signing: the Code Signing Certificate Requirements (CSBRs). This document defines two validation levels for code signing certificates: Standard (what most people call OV) and Extended Validation.
The EV distinction in code signing is encoded in the certificate itself via a specific Object Identifier (OID) in the Certificate Policies extension. An EV code signing certificate contains OID 2.23.140.1.3 in its Certificate Policies extension. This OID is defined by the CA/B Forum as the Extended Validation Code Signing Policy OID. Its presence is what tells Windows, and other platforms that understand it, that the certificate was issued under EV validation procedures.
Certificate Authorities that issue EV code signing certificates must themselves be audited against the CA/B Forum’s requirements and the CA Security Council’s NetSec requirements. Only CAs that have passed these audits and are included in Microsoft’s Trusted Root Program can issue EV code signing certificates that Windows accepts.
What Distinguishes an EV Certificate Technically
Comparing an EV code signing certificate to an OV certificate in a certificate viewer reveals specific differences:
- Certificate Policies extension: An EV certificate contains the OID 2.23.140.1.3 (CA/B Forum EV Code Signing OID) alongside the CA’s own policy OID. An OV certificate contains 2.23.140.1.2 (Standard Code Signing OID) or similar standard policy OIDs.
- Subject organizational information: EV certificates contain more detailed organizational identity fields: Subject Name (the verified legal organization name), Subject Jurisdiction of Incorporation Country, Subject Jurisdiction of Incorporation State or Province, and Subject Business Category. OV certificates typically contain fewer Subject fields.
- Jurisdiction fields: EV certificates embed the jurisdiction and registration number of the organization. These fields are visible in certificate details and provide verifiable links to official registration records.
- Key storage requirement: EV private keys must be generated and stored on hardware meeting FIPS 140-2 Level 2 or equivalent standard. The hardware requirement is verified by the CA during issuance. OV certificates adopted the same hardware requirement in June 2023, but EV has required hardware storage since the standard was established.
The EV OID (2.23.140.1.3) embedded in the certificate is what various systems use to identify EV-issued certificates. Windows uses it to classify drivers for Hardware Dev Center submissions. CAs use it when reporting to audit bodies. The OID is a machine-readable identifier that connects the certificate to the specific CA/B Forum policy under which it was validated. It is not visible to end users as a label, but it is checked programmatically by systems that enforce EV requirements.
The EV Validation Process: What the CA Verifies
EV code signing validation is a superset of OV validation. Everything OV verifies is also verified for EV, with additional requirements on top. The complete EV validation involves:
Legal entity verification (shared with OV, but more detailed for EV)
The CA verifies that the organization legally exists in its declared jurisdiction. For EV, the CA must confirm the specific jurisdiction of incorporation or formation, and the registration number within that jurisdiction. This information is embedded in the certificate’s Subject fields and links the certificate to a specific registered legal entity in a specific government registry.
Operational existence: the three-year requirement
EV requires the CA to confirm that the organization has been in active operation for at least three years. For most organizations this is confirmed through the registration date in government business registries combined with evidence of ongoing operation. Organizations that have been registered for less than three years can still obtain EV certificates, but must provide a letter from a qualified professional (licensed attorney, certified accountant, or banking officer) confirming the organization is operational and in good standing. The letter must be on the professional’s letterhead and the CA verifies the professional’s identity separately.
Operational phone number verified through a QIIS
EV requires the organization’s phone number to appear in a Qualified Independent Information Source (QIIS), a third-party database such as Dun and Bradstreet, state business registries, or equivalent: unlike OV where a QIIS-listed number can sometimes be supplemented with documentation, EV requires the phone number to be findable in a QIIS. This is a hard requirement. Organizations whose phone number does not appear in any QIIS must obtain a DUNS number and ensure their listing is current before EV validation can complete.
Authorization chain from corporate officer to requester
EV requires the CA to verify a chain of authorization from the organization to the specific individual ordering the certificate. Either the requester must be a verified corporate officer of the organization (verifiable through government registries that list officers), or the requester must have explicit written authorization from a verified corporate officer. The CA verifies that the officer who signed any authorization letter is actually an officer of the organization through independent sources.
Final verification callback
EV includes a final verification step: a CA representative calls the organization’s QIIS-listed phone number to confirm that the organization initiated this specific certificate request. The call is to the QIIS-listed number (not the requester’s personal number), and the person answering must be able to connect to someone who can confirm the certificate request. This callback is the final step after all other verifications are complete.
| Validation step | OV required | EV required | EV additional detail |
| Legal entity exists and is active | Yes | Yes | EV adds jurisdiction of incorporation and registration number in certificate |
| Physical operational address verified | Yes | Yes | Same requirement; PO boxes not accepted for either |
| Phone number in QIIS | Yes (documentation may substitute) | Yes (QIIS required, no substitute) | EV is stricter: documentation cannot substitute for QIIS listing |
| Operational existence of 3+ years | No | Yes | Newer organizations need a professional attestation letter |
| Authorization chain: corporate officer to requester | Verification of requester’s organizational relationship | Explicit documentation of authorization chain required | EV requires the officer’s identity to be independently verifiable |
| Final verification callback | No | Yes | CA calls QIIS-listed number to confirm the specific certificate request |
| Validation timeline | 1-3 business days when prepared | 3-7 business days when prepared | Additional steps add time; callback scheduling is often the final bottleneck |
The Hardware Storage Requirement: Why EV Keys Cannot Be Exported
The CA/B Forum requires EV private keys to be stored on a cryptographic hardware module meeting FIPS 140-2 Level 2 (or Common Criteria EAL 4+) standards. The requirement exists because the private key for an EV certificate represents verified organizational identity: its compromise would allow an attacker to sign malware as that organization. Hardware storage ensures the key cannot be extracted as a file and copied.
In practice, EV certificates are delivered in two forms:
- Physical hardware token: A USB token (typically a Thales/Gemalto SafeNet or Yubico device) with the private key generated and stored inside the hardware. The key never leaves the token. Signing operations are performed by the token itself, which requires a PIN to authorize the operation.
- Cloud HSM service: The CA stores the private key in cloud-based hardware security modules on your behalf. Signing operations are performed via API call to the cloud service. The key never leaves the CA’s HSMs. Services such as DigiCert KeyLocker, SSL.com eSigner, and Sectigo cloud signing implement this model.
Neither form allows the private key to be exported as a .pfx or .pem file for installation on a server or workstation. This is by design and by standard requirement. If a CA offered to deliver an EV certificate as an exportable private key file, that would violate the CA/B Forum requirements and the certificate would not be a legitimate EV certificate.
The physical hardware token delivery model creates practical challenges for automated CI/CD signing pipelines: a USB token cannot be plugged into a cloud build server. Cloud HSM signing services exist specifically to solve this problem. If you need to sign in automated pipelines, evaluate cloud HSM options before purchasing. All major CAs that issue EV code signing certificates offer cloud HSM alternatives to physical token delivery.
How Signing With an EV Certificate Works
The mechanical signing process for EV certificates is the same as for OV: you use signtool.exe (for Windows binaries), jarsigner (for Java), or equivalent tools, pointing them at the certificate to use for signing. The resulting signature is an Authenticode signature embedded in or attached to the file.
What differs is how the signing tool accesses the private key. With a physical token, signtool accesses the token via a PKCS#11 interface or the Windows CryptoAPI, prompting for the token’s PIN if required. With a cloud HSM service, the signing tool communicates with the service over an authenticated API connection.
The resulting Authenticode signature contains the full certificate chain: the EV leaf certificate (your organization’s certificate), the intermediate CA certificate, and a reference to the trusted root. The signature also contains a timestamp if one was requested, and the content hash that verifies the signed file has not been modified.
Verifying an EV signature
| # Verify an Authenticode signature and display certificate details:
signtool verify /pa /v SignedFile.exe # Confirms: signature validity, certificate chain, timestamp presence
# Display detailed certificate information including EV OID: > certutil -dump SignedCertificate.cer | findstr /i “EV\|2.23.140.1” # Look for: 2.23.140.1.3 = EV Code Signing # 2.23.140.1.2 = Standard (OV) Code Signing
# View certificate in Windows: # Right-click the signed .exe > Properties > Digital Signatures tab # Select the signature > Details > View Certificate # Certificate Policies field in Extensions shows the EV OID if present |
EV Code Signing in 2026: What It Provides Now
The EV code signing landscape changed meaningfully in 2023 and 2024. Understanding the current state avoids purchasing decisions based on outdated information:
June 2023: Hardware requirement extended to OV
Before June 2023, OV code signing certificates could be delivered as software credentials (exportable .pfx files). The CA/B Forum’s Baseline Requirements change effective June 1, 2023 extended the hardware storage requirement to all code signing certificates, including OV. From this date, both OV and EV private keys must be stored on compliant hardware. The hardware storage distinction no longer differentiates EV from OV.
August 2024: SmartScreen instant reputation bypass removed
Before August 2024, EV certificates carried a specific override in Microsoft SmartScreen’s evaluation: new software signed with EV received immediate reputation credit, bypassing the warning period that OV-signed software experiences. Microsoft removed this behavior in August 2024 as part of a Trusted Root Program update. Both OV and EV now build SmartScreen reputation through the same mechanism: accumulated download telemetry over time. EV no longer provides faster SmartScreen clearance for new software.
What EV still provides that OV does not
Following these changes, EV code signing retains two technical advantages:
- Kernel-mode driver signing: Microsoft’s Windows Hardware Dev Center requires at least one EV certificate associated with the account for driver submissions. OV certificates cannot fulfill this requirement. For organizations distributing Windows kernel-mode drivers, EV is not optional.
- Deeper identity verification embedded in the certificate: EV certificates contain jurisdiction of incorporation and registration number fields not present in OV certificates. The validation process is more rigorous and the resulting certificate carries more verifiable organizational identity. This has value in enterprise procurement, compliance frameworks that specify EV, and situations where the certificate is evaluated as part of a vendor security assessment.
Frequently Asked Questions
What does Extended Validation mean for code signing?
Extended Validation refers to the CA/B Forum’s enhanced validation process for code signing certificates. Compared to standard (OV) validation, EV requires: confirmation of the organization’s jurisdiction of incorporation and registration number, verification that the organization has been operational for at least three years (or a professional attestation for newer organizations), a mandatory phone number verification through independent databases with no documentation substitute, an explicit authorization chain from a corporate officer to the certificate requester, and a final verification callback to the organization’s QIIS-listed phone number. These requirements are defined in the CA/B Forum’s Code Signing Certificate Requirements document.
Why can’t I download my EV certificate’s private key as a .pfx file?
EV private keys are required by the CA/B Forum to be stored on hardware security modules meeting FIPS 140-2 Level 2 standards. The hardware storage requirement ensures the key cannot be copied or extracted. This is not a limitation of a specific CA; it is a requirement of the EV standard that all CAs must follow. Your private key exists either on a physical USB hardware token or in a cloud HSM operated by the CA. Signing operations are performed by the hardware, not by software with access to an extractable key file.
Is EV code signing still worth the extra cost in 2026?
EV is worth the cost for two specific situations: kernel-mode driver signing (EV is technically required for Windows Hardware Dev Center and WHQL) and organizations whose compliance framework, procurement requirements, or customer contracts specifically mandate EV. For general software distribution where the goal is removing Windows security warnings and building SmartScreen reputation, OV now provides equivalent outcomes since Microsoft removed EV’s SmartScreen instant bypass in August 2024. Evaluate based on whether you have a specific technical or contractual requirement for EV, rather than on the historical SmartScreen advantage.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.