Windows Code Signing Certificate

A Windows code signing certificate is a digital certificate associated with a private key that is used to sign supported Windows software. The certificate represents the publisher identity that appears in the signature information, while the cryptographic signature provides evidence that the signed content has not changed since it was signed.

The certificate is only one part of the trust model. A production release also involves the artifact hash, private key, certificate chain, certificate status and usually a timestamp. When a user or verification tool checks the file, these pieces are evaluated together. That is why buying a certificate and actually operating a reliable Windows signing process are separate tasks.

For a commercial software publisher, the practical goal is to make every release traceable to the intended publisher while keeping the signing key protected. For a developer shipping one installer, that may be a simple token based workflow. For a software company producing many releases, the same certificate identity may be integrated with an HSM or controlled cloud signing service.

The certificate is only the first line item. A Windows publisher also needs a compliant private key storage method and a process for issuing, using, renewing and eventually retiring that key. For a small developer, a certificate plus a hardware token can be the complete setup. For a release team, the recurring cost may instead come from cloud signing, HSM infrastructure or signing service usage.

This is why a useful Windows code signing comparison should show the product basis rather than one universal “price.” SSL.com currently lists a $129 annual IV certificate and separate storage options such as a YubiKey or cloud HSM. DigiCert separates Standard Code Signing, EV and KeyLocker pricing. Sectigo also distinguishes its certificate product from its storage and issuance model.

This distinction is the most important Windows specific decision on the page. An application publisher signing an EXE or MSI is using a normal software distribution workflow. A driver publisher is participating in Microsoft's hardware and driver ecosystem, where account enrollment, certificate registration, testing and submission rules apply.

Microsoft currently states that an EV certificate is required for a Hardware Dev Center dashboard account used for attestation signing or Windows Hardware Lab Kit certification submissions. Microsoft also documents a workflow in which a registered certificate is used to sign a file and upload it to Partner Center. That is materially different from simply signing an EXE with SignTool and publishing it on a website.

Authenticode is Microsoft's code signing model for supported Windows software. At signing time, the signing tool calculates or processes the file's signing data and uses the private key to create a digital signature. The certificate and chain accompany the signature so the verifier can identify the signer and evaluate the trust path.

SignTool is part of the Windows SDK and supports signing, verification and timestamping. Microsoft currently recommends specifying the file digest algorithm and timestamp digest algorithm, with SHA-256 as the recommended digest algorithm in the current SignTool documentation.

This distinction is important because older code signing material often reduces the Windows user experience to a simple certificate warning. A signed application can still encounter security or reputation prompts, and an EV certificate should not be described as a permanent shortcut around SmartScreen decisions.

There is no single storage method that fits every Windows publisher. A developer who signs once or twice a month may prefer a physical token. A company with multiple release engineers may need centralized access controls. A CI/CD pipeline may need an API driven signing service that allows the build system to request a signature without exporting the production key.

The important security question is not whether the signing happens on Windows. It is whether the production private key can be copied out of the protected environment. The signing architecture should make unauthorized signing difficult, traceable and revocable.

For EXE, DLL and MSI releases, the reliable pattern is the same: finish the artifact, sign it, timestamp it, verify it and then distribute that exact file. Do not sign an intermediate build and then run a packaging or compression operation that modifies the artifact.

SignTool is Microsoft's standard command line utility for these operations. It can sign files, verify signatures and apply timestamps. The Windows SDK documentation also requires the digest parameters in current SDK versions, making explicit SHA-256 configuration preferable to relying on older examples.

Driver signing should be treated as a Microsoft platform workflow rather than an ordinary application signing task. Microsoft currently documents EV certificate enrollment, Hardware Developer Program registration, driver testing, submission and publication through Partner Center for the relevant driver scenarios.

For public driver release, the exact route can involve attestation signing or Windows Hardware Lab Kit certification depending on the driver and distribution requirement. Microsoft recommends HLK tested and dashboard signed drivers for the relevant compatibility workflow, while its documentation also describes attestation signed drivers for certain scenarios.

Timestamping adds evidence about when a signature was applied. That matters because a public code signing certificate is no longer a multi year certificate in the way older buying guides often described it. Current 2026 CA/B Forum rules limit public code signing certificate validity to approximately 15 months, while providers can still sell multi year subscription structures that involve annual issuance or reissuance.

GlobalSign currently lists one year code signing certificates, while DigiCert and Sectigo publish their own current validity and subscription models. The practical release rule is simple: renew before the active certificate expires, test the replacement certificate, update the signing environment and continue timestamping new releases.

A certificate should be managed as part of the software release lifecycle, not as a one time purchase. Before issuance, decide who can request it and where the private key will live. During operation, restrict signing access, record signing activity and verify releases. Before expiry, renew early enough to validate the replacement certificate and update automation without delaying a production release.

At retirement, remove the old certificate from signing systems and document the replacement. If the key is suspected to be compromised, the process becomes an incident response rather than a normal renewal.

The provider comparison should be used to narrow the market, not to declare one CA universally best. Product pricing, certificate types and storage options are not identical across providers.