Code Signing Certificates Explained: How They Protect Software

Updated May 2026  |  Category: Code Signing / OV / EV / SmartScreen / Software Distribution  |  Reading time: 10 min

A code signing certificate is a digital certificate issued by a Certificate Authority that lets software developers and publishers apply a cryptographic signature to their software. That signature does two things: it proves the software came from a specific, verified publisher, and it proves the software has not been changed since it was signed.

When a user downloads and runs signed software, the operating system verifies the signature automatically. On Windows, this determines what appears in the security prompt before installation: a named publisher with a verified identity instead of the generic ‘Unknown Publisher’ warning that unsettles users and suppresses downloads. On macOS, Gatekeeper checks the signature and notarization status before allowing software to run at all.

This guide covers what code signing certificates are, what types exist, what they do and do not protect against, how they differ from SSL certificates, and what has changed recently in the industry requirements that every publisher needs to know.

What a Code Signing Certificate Is

A code signing certificate is an X.509 digital certificate with the Code Signing extended key usage (EKU) set. This flag distinguishes it from TLS certificates (which authenticate servers) and S/MIME certificates (which authenticate email senders). The certificate binds a verified identity (an individual developer or an organization) to a public key. The corresponding private key is what the developer uses to sign software.

The certificate is issued by a Certificate Authority after identity verification. The CA checks that the person or organization requesting the certificate is who they claim to be. The strength of that identity check depends on the certificate type. The CA’s signature on the certificate is what makes it trusted: all major operating systems and platforms trust specific root CAs, and certificates that chain to those trusted roots are accepted automatically.

When software is signed, the developer’s signing tool computes a hash of the binary content, signs that hash with the private key, and embeds the resulting signature along with the certificate into the binary. Recipients can verify the signature using the public key from the certificate without contacting the CA or the developer directly.

What Code Signing Does and Does Not Do

Code signing is commonly misunderstood as a safety guarantee. It is not. Understanding what it actually provides prevents both overconfidence and dismissal of a genuinely useful control.

The most important limitation: a valid signature proves signing access was used, not that the software is safe. In early 2025, cybercriminals abused Microsoft’s own Azure Trusted Signing service to sign malware. The signatures were technically valid. The certificates verified correctly. The only failure was that the attacker had obtained signing service access. Code signing works as an accountability mechanism; it does not substitute for malware analysis or security review.

The Three Types of Code Signing Certificates

Code signing certificates come in three validation levels. Each requires a different level of identity verification by the CA. The cryptographic signing operation is identical across all three types; what differs is how thoroughly the CA has verified the identity behind the certificate.

Individual Validation (IV)

An IV certificate is issued to a private individual rather than a business. The CA verifies the applicant’s personal identity, typically requiring a government-issued ID and proof of address. The signed software displays the individual’s name as the publisher.

IV certificates are used by independent developers, hobbyists, and open-source contributors who do not have a registered business entity. They are less common in enterprise contexts because most organizations prefer their software to be associated with the organization’s name rather than an individual employee’s name.

Organization Validation (OV)

An OV certificate is issued to a registered business or legal entity. The CA verifies the organization’s legal registration, physical address, and that the person requesting the certificate is authorized to act on behalf of the organization. The signed software displays the organization’s verified name as the publisher.

OV is the most widely used certificate type for commercial software distribution. It satisfies the vast majority of code signing requirements: it removes the Unknown Publisher warning on Windows, enables macOS distribution, and allows SmartScreen reputation to build through download volume. For most software publishers, OV provides all the trust signaling they need.

Extended Validation (EV)

An EV certificate requires the most rigorous verification process. The CA checks the organization’s legal existence, physical address, operational status, and the requestor’s authority to sign on behalf of the organization through a documented multi-step process. EV verification typically takes several days longer than OV.

EV certificates are required for one specific technical purpose: signing Windows kernel-mode drivers. Microsoft requires that drivers loading into the Windows kernel be signed with an EV certificate. Device driver developers, security software vendors, and any software requiring kernel access must use EV regardless of other considerations.

A significant change occurred in 2024: EV certificates previously provided an immediate SmartScreen reputation bypass, meaning new software signed with EV passed SmartScreen on first download without any warming period. Microsoft removed this behavior in 2024. Both OV and EV certificates now build SmartScreen reputation identically through download volume over time. EV no longer provides an instant trust advantage for general software distribution.

Because EV no longer provides SmartScreen instant trust, the decision between OV and EV for most software publishers comes down to one question: does the software include kernel-mode drivers or kernel-level components? If yes, EV is required. If no, OV provides equivalent SmartScreen behavior at lower cost and with faster issuance.

OV vs EV: Current Comparison

What Has Changed Recently: Industry Requirements Through 2026

Three significant changes to code signing requirements have occurred since 2023. Many articles and guides predate these changes and are no longer accurate.

June 2023: Hardware security module requirement for all certificates

The CA/B Forum Code Signing Baseline Requirements, effective June 1, 2023, mandated that private keys for both OV and EV code signing certificates must be stored on hardware meeting FIPS 140-2 Level 2 standards or equivalent. Before this change, OV certificates were routinely issued as PKCS12 files stored on disk. A developer could receive their certificate as a downloadable file.

After this change, all publicly trusted code signing private keys must be on a hardware token or HSM. CAs now ship certificates on physical USB security tokens or offer cloud HSM signing services where the key is stored in their secure infrastructure. Developers who signed software by pointing a tool at a certificate file on disk can no longer do this with newly issued certificates.

This change significantly affects CI/CD pipeline signing: automated build systems cannot use physical USB tokens. Cloud HSM signing services (DigiCert KeyLocker, SSL.com eSigner, Azure Trusted Signing) emerged as the standard solution for pipeline-compatible signing.

2024: EV instant SmartScreen bypass removed

Microsoft changed SmartScreen behavior in 2024. Previously, Extended Validation certificates provided an immediate reputation bypass: software signed with EV passed SmartScreen on first download without any download history. This was widely promoted as a major advantage of EV over OV.

Microsoft removed this behavior. Both OV and EV certificates now go through the same reputation-building process based on download volume. The practical implication: publishers who purchased expensive EV certificates specifically for the SmartScreen bypass no longer receive that benefit. The primary remaining reason to choose EV over OV is kernel-mode driver signing.

March 2026: Maximum certificate validity reduced to 458 days

Effective March 1, 2026, the CA/B Forum reduced the maximum validity period for publicly trusted code signing certificates to 458 days (approximately 15 months). Before this change, code signing certificates could be valid for up to 3 years.

CAs enforce this at issuance: certificates issued after the effective date cannot exceed 458 days of validity. Multi-year pricing plans from CAs still exist, but the individual certificate issued within that plan has a shorter validity. Organizations on multi-year plans receive more frequent certificate reissuances within their purchase term.

The operational consequence: renewal processes and automation become more critical. Certificate expiry in a signing pipeline blocks software releases. Organizations without automated renewal and monitoring for code signing certificates face more frequent manual renewal events.

If you have a code signing certificate issued before March 2026 with a validity period of more than 458 days, that certificate remains valid until its original expiry date. The new 458-day cap applies to certificates issued from March 1, 2026 onward. However, planning renewal processes and automation now, before the certificate expires, avoids an emergency when the expiry date arrives.

How Code Signing Certificates Differ From SSL/TLS Certificates

Code signing certificates and SSL/TLS certificates both use X.509 certificate technology and PKI infrastructure. They are issued by the same Certificate Authorities and use the same underlying cryptographic mechanisms. They are designed for fundamentally different purposes.

A developer building a web application needs both: an SSL/TLS certificate for the website (ensuring HTTPS) and a code signing certificate for the downloadable installer or application package (ensuring publisher identity). They address different attack surfaces: SSL protects the connection, code signing protects the file.

Where Code Signing Certificates Are Used

Code signing applies across multiple software distribution contexts, each with its own verification mechanism and trust requirements:

• Windows executables and installers: Authenticode signing of .exe, .msi, .dll, and .cab files. Windows SmartScreen and User Account Control check signatures at install and run time. Unsigned software triggers the ‘Unknown Publisher’ UAC prompt.
• Windows kernel-mode drivers: Must be signed with an EV certificate. Windows 10 and 11 enforce this strictly; unsigned drivers are blocked from loading into the kernel entirely on modern Windows.
• macOS applications and packages: Apple Developer ID signing plus notarization (automated malware scanning by Apple) is required for software distributed outside the Mac App Store. Gatekeeper blocks unsigned and unnotarized software.
• Android applications: APKs must be signed using Android’s APK Signature Scheme. Unlike Windows and macOS, Android uses developer self-generated keys rather than CA-issued certificates; the trust model is based on key consistency between app versions.
• Office macros and add-ins: Microsoft Office can be configured to run only signed macros. Enterprise environments often require macro signing to prevent unauthorized script execution.
• PowerShell scripts: Windows execution policies can require that PowerShell scripts be digitally signed before running. Script signing uses the same Authenticode mechanism as executable signing.
• Java JAR files: jarsigner applies signatures to JAR archives. Used in enterprise application distribution and Java Agent integrity verification. The original consumer use case (browser applets and Java Web Start) is defunct.
• Container images and cloud-native artifacts: Sigstore/cosign signing is increasingly standard for container images, Python packages, and npm packages in CI/CD pipelines. Uses a different trust model (keyless OIDC-based signing) from CA-issued certificate signing.

How to Choose the Right Code Signing Certificate

The choice between IV, OV, and EV depends on three factors: the type of entity doing the signing, the type of software being signed, and the distribution context.

Frequently Asked Questions

What is a code signing certificate?

A code signing certificate is a digital certificate issued by a Certificate Authority that enables software developers and publishers to digitally sign their software. The signature proves two things: the software came from the identified publisher, and the software has not been changed since it was signed. When a user downloads and installs signed software, the operating system automatically verifies the signature and displays the publisher’s verified name rather than the generic ‘Unknown Publisher’ warning.

Is code signing required to distribute software?

It depends on the distribution channel and platform. Windows does not legally require code signing, but unsigned software receives security warnings that significantly suppress installation rates. macOS Gatekeeper blocks software that lacks Apple Developer ID signing and notarization from running unless users override security settings. Android apps must be signed but do not require CA-issued certificates. Enterprise environments frequently enforce signing requirements through Group Policy. For any software distributed publicly to Windows or macOS users, code signing is a practical requirement even if not a legal one.

Does EV code signing still give instant SmartScreen trust?

No. Microsoft removed the EV instant SmartScreen bypass in 2024. Before that change, Extended Validation certificates allowed new software to pass SmartScreen on first download without any download history. Now both OV and EV certificates build SmartScreen reputation identically through download volume over time. The primary remaining reason to use EV over OV is kernel-mode driver signing, which Microsoft specifically requires EV certificates for.

How long is a code signing certificate valid?

As of March 1, 2026, the CA/B Forum limits publicly trusted code signing certificates to a maximum of 458 days (approximately 15 months) per issuance. Before this change, certificates could be valid for up to 3 years. Multi-year pricing plans still exist from many CAs, but individual certificates issued within those plans are shorter and require more frequent reissuance. Always include an RFC 3161 timestamp when signing software so that the signature remains valid after the certificate expires.

What is the difference between code signing and SSL?

Both use the same underlying X.509 certificate technology, but they serve different purposes. An SSL/TLS certificate authenticates a web server by domain name and encrypts connections between browsers and servers. A code signing certificate authenticates a software publisher and proves the integrity of a software artifact. SSL protects data while it travels across the network. Code signing protects software files at distribution time. A developer typically needs both: SSL for their website and code signing for the software they distribute from it.

Gloria Bradford

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.