Code Signing Certificates

Introduction

Code Signing is the process of applying a digital signature to a software program intended for distribution over the internet. Code signing helps to verify that the software is authentic, i.e., from the original developer, and also helps to validate that the code has not been tampered with by an attacker while in transit, e.g., by the insertion of malicious code or malware. The digital signature used for code signing is contained in a digital certificate called the code signing certificate.

Quick Answer: What Is a Code Signing Certificate?

A code signing certificate is an X.509 digital certificate, issued by a certificate authority, that a software publisher uses to apply a digital signature to code before distribution. It proves the software’s origin and confirms the code hasn’t been altered since signing. Certificates are self-signed, Standard Validation, or Extended Validation (EV), and rely on time stamping to remain valid after certificate expiry and on revocation to invalidate compromised keys.

Executive Summary

Code signing certificates let software publishers prove authenticity and integrity to end users, browsers, and operating systems. This post covers how code signing certificates differ from SSL certificates through the X.509 Key Usage field, the vendor-specific implementations (Authenticode, Apple, Java, Adobe AIR), the three certificate types (self-signed, Standard Validation, and Extended Validation), how time stamping keeps signed code trusted after certificate expiry, and how certificate revocation protects users when a private key is compromised. It also covers a practical glossary and checklist for managing code signing certificates at scale and how this connects to broader certificate lifecycle management.

Who Should Care About Code Signing Certificates

Code signing certificates touch software release engineering, security architecture, platform operations, and compliance. Here is what each role should do.

PKI Administrators

Track every code signing certificate’s validation type and expiry date, and ensure time stamping is applied to every signed release so expired certificates don’t break already-installed software.

Security Architects

Design private key protection for signing keys around the certificate’s validation level, requiring HSM-backed storage for EV code signing certificates and recommending it for Standard Validation as well.

Platform Teams

Integrate code signing into the build and release pipeline for every platform in use, Windows Authenticode, Apple, Java, and Adobe AIR, so no artifact ships unsigned.

Compliance Teams

Confirm that EV code signing certificates are used wherever required and that private keys behind them meet FIPS 140 Level-2 or equivalent hardware protection for audit purposes.

CISOs

Treat a compromised code signing key as a supply-chain incident, since attackers who obtain one can sign malware that appears legitimate to every downstream user, and sponsor immediate revocation processes for exactly this scenario.

Why This Matters: Data and Deadlines

According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced a certificate-related outage in the past year, and 18.5% of affected organizations reported losses exceeding $250,000, with 37.5% of those incidents tied specifically to expired certificates. An expired code signing certificate without time stamping can silently break every previously distributed build, making this risk directly relevant to release engineering.

The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, phases maximum public TLS certificate validity down to 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. While this schedule targets TLS/SSL certificates rather than code signing certificates directly, it signals the same industry-wide push toward shorter validity periods and stronger certificate automation that code signing programs should anticipate.

NIST finalized its post-quantum cryptography standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. Code signing certificates rely on the same public-key signature algorithms these standards will eventually replace, so building crypto agility into signing infrastructure now avoids a disruptive migration later.

Code Signing Certificates

Like any other digital certificate, code signing certificates are based on the X.509 standard and also need to be signed by a trusted third party such as a Certificate Authority (CA). However, code signing certificates cannot be used interchangeably with other certificates such as SSL certificates. The main reason for this is that, as per the X.509 specification, any digital certificate contains a “Key Usage” field, which indicates the intended use of the certificate and is filled in at the time the certificate is generated. Additional information regarding the use of the certificate can also be contained in the “Extended Key Usage” extension. The X.509 specification mandates that a certificate cannot be used other than for it’s intended purpose. For example, an SSL certificate has the key usage field set to “Digital Signature” whereas a code signing certificate has the key usage field set to “Code Signing”.

While X.509 provides the specification for the certificate format, the technology implementations to generating certificates will vary by vendor. For example, Authenticode is code signing technology from Microsoft that helps developers sign applications for the Windows operating system. Authenticode certificates are used to sign files with extensions such as .exe, .dll, .ocx, .cab, and .xpi. Similarly, Apple code signing certificates are used to sign applications for iOS, Java code signing certificates are used to sign .jar files for the Java Runtime Environment (JRE), and Adobe AIR certificates are used to sign .air or .airi files.

The process of obtaining a code signing certificate is similar to other digital certificates. Any organization that wishes to publish software for distribution over the internet applies for a code signing certificate with a CA, submitting their public key and other organization information. Note that the public-private key pair needs to be separately generated, like in the case of any digital certificate. The CA validates the developer (organization) applying for the certificate, signs the certificate as proof of validation, and issues the same to the developer or software publisher. The certificate that the CA issues includes information such as the publisher identity, the public key of the publisher, the certificate validity period, the digital signature of the CA, and other details.

Types of code signing certificates

Self-signed certificates

It is possible for software publishers to generate their own self-signed certificates. In such cases, however, the signature verification process during software installation will generate a warning that the software was created by an unknown publisher. Self-signed certificates could be used for testing and local development of software, before it is made generally available for public distribution. However, self-signed certificates should not be used for production software being distributed to end users.

For public software distribution, CA-issued certificates are the best option. There are two types of CA-issued code signing certificates based on the type of validation.

Standard Validation Certificates

This is the default type of code signing certificate and involves basic validations of the publisher or developer by the CA. To be issued a standard code signing certificate, software publishers need to meet some basic requirements such as minimum key length, maximum validity period, and time stamping for digital signatures.

Extended Validation (EV) Certificates

EV code signing certificates involve the highest levels of validation and vetting of the software publisher by the CA and are usually issued on a hardware token for additional levels of security. To be issued an EV certificate, apart from the basic requirements of standard certificates, software publishers also need to conform to much more stringent requirements – for example, maintaining private keys in a Hardware Security Module (HSM) that is compliant with FIPS (Federal Information Processing Standards) 140 Level-2 or equivalent.

Certificate Expiry and Time Stamping

Like any digital certificate, code signing certificates also expire at the end of their validity period. On expiry, the signature will not be validated, and the software may cease to install or execute properly, although nothing is wrong with the software itself. This issue is addressed by the process of time stamping, in which a time stamp is applied to the code at the time of signing the file. This is usually done through another trusted third party called a Time Stamp Authority (TSA), to prove the validity and authenticity of the time stamp. The presence of a time stamp ensures that the software continues to run even though the code signing certificate has expired, giving the publisher time to renew the certificate.

Certificate Revocation

We have seen in earlier articles that the strength of Public Key Infrastructure (PKI) systems depends on how the private keys are managed and secured. If the private key for any digital certificate is compromised, the certificate needs to be invalidated, or revoked by the CA that issued the certificate. Certificate revocation is critical in the event of a breach: it ensures that end users are alerted that the certificate can no longer be trusted, discouraging the download, installation, and further usage of the software. Certificate revocation is done by including the revoked certificate in a Certificate Revocation List (CRL), or by updating the certificate status using the Online Certificate Status Protocol (OCSP). Further details about CRLs and OCSP will be covered in a later article.

Code Signing Certificates Glossary

Quick, extractable definitions for the terms used throughout this post.

Term	Definition
Code Signing Certificate	An X.509 digital certificate used to apply a digital signature to software, proving publisher identity and code integrity.
Key Usage Field	An X.509 field that restricts a certificate to its intended purpose, set to “Code Signing” for code signing certificates and “Digital Signature” for SSL certificates.
Authenticode	Microsoft’s code signing technology for signing Windows executables, DLLs, and installer files.
Time Stamp Authority (TSA)	A trusted third party that applies a verifiable time stamp to signed code, keeping the signature valid after the certificate itself expires.
Extended Validation (EV) Certificate	A code signing certificate requiring the strictest publisher vetting, typically issued on a hardware token or HSM for maximum key protection.
Certificate Revocation List (CRL)	A list published by a CA identifying certificates that have been revoked before their scheduled expiration.

Code Signing Certificate Issue Checklist

Use this checklist to map common code signing issues to business impact and ownership.

Issue	Business Impact	Recommended Action	Owner
Signing certificate expires without time stamping	Previously distributed software fails signature validation and may stop installing or running	Apply time stamping to every signed release and monitor certificate expiry proactively	PKI Administrator
Signing key stored without hardware protection	A compromised key lets an attacker sign malware that appears to come from a trusted publisher	Move signing keys behind an HSM, mandatory for EV certificates and recommended for all	Security Architect
Self-signed certificate used in production	End users see an “unknown publisher” warning, damaging trust and adoption	Restrict self-signed certificates to development and testing; require CA-issued certificates for release builds	Platform Team
Compromised key not revoked promptly	Attackers continue signing malicious code that end users trust as legitimate	Establish an incident process to revoke compromised certificates via CRL/OCSP immediately	CISO
Validation level mismatched to distribution requirements	Software fails third-party platform or OS-level trust requirements, blocking distribution	Confirm EV certificates are used wherever platform or compliance policy requires them	Compliance Team

Certificate Lifecycle Management and PKI Modernization

Code signing certificates need the same discovery, issuance, and renewal discipline as any other part of a PKI modernization program. CertSecure Manager automates certificate discovery, issuance, and renewal, including certificate automation for time stamping and expiry tracking, so no signing certificate lapses unnoticed.

Organizations issuing certificates at scale without operating that infrastructure entirely in-house can rely on PKI-as-a-Service for a managed, cloud-hosted certificate authority. Building a machine identity inventory and running certificate discovery through CBOM Secure helps surface every signing certificate already in use across build and release pipelines, and completing a PQC readiness assessment ensures your signing infrastructure has a migration path toward crypto agility and post-quantum signature algorithms. Encryption Consulting’s PQC Center of Excellence provides guidance on sequencing that migration.

For more on why certificate automation matters across the environment, see our Education Center articles on the stages in a certificate’s lifecycle and how to avoid certificate outages. For related content on code signing specifically, see Code Signing: Top 5 Benefits, Code Signing: Top 5 Best Practices, Code Signing: Potential Threats, Code Signing Architecture, and Time Stamping Code Signing Certificates – Significance.

Measuring Success and Ongoing Audits

Track the percentage of code signing certificates with time stamping enabled, the percentage of signing keys protected by hardware-backed key management, and how quickly a compromised certificate can be revoked once detected. Audit signing certificate inventories and expiry dashboards on a recurring basis, quarterly for policy-driven factors like validation-level requirements and CA/Browser Forum guidance, and continuously for certificate expiry, so a signing certificate never silently lapses mid-release-cycle.

Frequently Asked Questions

What is the main takeaway from Code Signing Certificates?

A code signing certificate proves software authenticity and integrity through an X.509 digital signature, and it depends on time stamping to stay trusted after expiry and on revocation to stop trusting a compromised key.

Why does this matter for enterprise PKI teams?

PKI teams need to select the right validation level for each signing use case and ensure every release is time stamped, since an unstamped certificate that expires can break already-installed software fleet-wide.

What risks increase if this topic is handled manually?

Manually managing code signing certificates increases the risk of shipping unsigned or unstamped builds, storing signing keys without hardware protection, and missing a certificate expiry that breaks distributed software.

Which teams should own this change?

Security architects design key protection for signing keys, platform teams integrate signing into build pipelines, PKI administrators track certificate validation types and expiry, and compliance teams confirm EV usage where required.

How does this connect to certificate lifecycle management?

Code signing certificates need the same discovery, issuance, renewal, and revocation discipline as any other certificate type; treating them as part of one certificate lifecycle management program prevents a signing certificate from being overlooked.

How should organizations measure success?

Track the percentage of signing certificates with time stamping enabled, the percentage of signing keys in hardware-backed protection, and how quickly a compromised certificate can be revoked once detected.

What should be audited or monitored regularly?

Regularly audit the code signing certificate inventory and expiry dashboard, confirm time stamping is applied to every release, and verify signing keys remain in hardware-backed storage.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Organizations signing code across multiple platforms and CAs need centralized visibility into every signing certificate in use, since a certificate from an untracked CA is just as likely to expire unnoticed mid-release-cycle.

What common mistakes should teams avoid?

Common mistakes include shipping production software with a self-signed certificate, skipping time stamping, storing signing keys without hardware protection, and delaying revocation after a key compromise.

What should be refreshed quarterly?

Review validation-level requirements against current platform and compliance policy, confirm signing certificates still meet current CA/Browser Forum guidance, and re-verify that key protection methods remain adequate as signing volume grows.