Windows Code Signing: A Comprehensive How-To Guide

Code signing is an important step when distributing executable applications on Windows. A valid digital signature identifies the software publisher and helps users verify that an application has not been modified since it was signed.

Unsigned executables can trigger Microsoft Defender SmartScreen warnings or be blocked by Windows 11's Smart App Control. Code signing improves trust, although signing alone does not guarantee that SmartScreen warnings will disappear immediately.

This guide covers the entire process, from obtaining a certificate to signing applications built with Rust, C#, C++, and other languages. We'll also explain modern certificate requirements, Microsoft's cloud-based signing service, and the best ways to verify signatures before distributing your software.

Table of Contents

Introduction

Windows uses several security mechanisms to help protect users from untrusted or potentially malicious applications.

Microsoft Defender SmartScreen evaluates downloaded applications based on factors including their reputation, publisher identity, and download history.

Windows 11 also includes Smart App Control, which can block unfamiliar unsigned applications unless Microsoft recognizes them as trustworthy.

Code signing uses a cryptographic signature to establish two important properties:

  1. Publisher Identity: The signature identifies the individual or organization associated with the signing certificate.
  2. File Integrity: The signature helps detect unauthorized modifications to the executable after signing.

These protections are particularly important for independent developers distributing software directly from their websites rather than through the Microsoft Store.

For example, businesses developing custom software and applications may need to distribute desktop utilities, installers, and internal tools to customers or employees. A consistent code-signing process helps establish the publisher's identity and reduces uncertainty when users install the software.

Code signing should be part of a broader approach to software security and secure development, rather than treated as proof that an application is free from vulnerabilities.

Prerequisites

Before beginning, ensure you have:

The Windows SDK includes SignTool, Microsoft's command-line utility for applying and verifying Authenticode signatures.

SignTool can also be installed through compatible Visual Studio components.

Finding SignTool

After installing the Windows SDK, SignTool is typically located under a directory similar to:

C:\Program Files (x86)\Windows Kits\10\bin\

Inside this directory, you'll find folders corresponding to different SDK versions and processor architectures.

For example:

C:\Program Files (x86)\Windows Kits\10\bin\10.0.xxxxx.0\x64\signtool.exe

The exact version number depends on your installed SDK.

A Visual Studio Developer Command Prompt may already include the appropriate directory in your PATH.

Check availability with:

signtool /?

If Windows cannot find the command, use its full executable path or add the appropriate SDK directory to PATH.

Obtaining a Code Signing Certificate

Code-signing certificates are issued by trusted certificate authorities after validating the applicant's identity.

Two traditional certificate categories are commonly used for Windows software signing.

OV Certificates (Organization Validation)

OV certificates verify the identity of the organization purchasing the certificate.

The certificate identifies the verified publisher when users inspect the application's digital signature.

These certificates are suitable for businesses distributing commercial software, desktop utilities, and application installers.

EV Certificates (Extended Validation)

EV certificates involve additional identity verification requirements.

Historically, EV certificates provided an immediate SmartScreen reputation advantage over ordinary OV certificates.

That is no longer the case. Microsoft states that EV certificates no longer automatically bypass SmartScreen reputation warnings.

For many independent software developers, purchasing an EV certificate solely to avoid SmartScreen warnings therefore offers little benefit.

Hardware-Backed Private Keys

Modern publicly trusted code-signing certificates generally require private keys to be generated and protected using compliant hardware-backed systems.

Common arrangements include:

As a result, purchasing a new certificate does not necessarily mean receiving a downloadable .pfx file containing an exportable private key.

That older workflow remains applicable to certificates and systems that support it, but developers should verify the certificate provider's current requirements.

Where to Buy a Code Signing Certificate

Certificate authorities and resellers include:

Pricing varies according to validation level, subscription duration, hardware requirements, and certificate provider.

Budget for the full cost of certificate issuance, token hardware, shipping, and renewal rather than assuming that every certificate is available for a low annual fee.

Microsoft Artifact Signing

Microsoft offers a managed signing service called Artifact Signing, previously known as Trusted Signing.

This service provides cloud-based certificate management and signing capabilities without requiring developers to handle their own physical USB signing token.

It is particularly attractive for teams building applications through automated development pipelines.

Microsoft's service starts at approximately $9.99 per month, although eligibility, regional availability, and pricing should be confirmed before adopting it.

Artifact Signing still requires identity verification and does not automatically guarantee an established SmartScreen reputation.

Installing the Certificate

The installation procedure depends on how your certificate's private key is stored.

Option 1: Importing a PFX Certificate

If you have a .pfx certificate containing an exportable private key:

  1. Double-click the .pfx file.
  2. Follow the Certificate Import Wizard.
  3. Select the appropriate certificate store.
  4. Enter the certificate password.
  5. Complete the import.

For user-specific signing operations, the Personal certificate store is commonly used.

You can inspect imported certificates using the Windows certificate management tools.

However, newer publicly trusted certificates frequently use hardware-backed private keys and may not support this workflow.

Option 2: Using a USB Token

If your certificate provider supplies a USB signing token:

  1. Install the token's required software.
  2. Connect the token to your computer.
  3. Verify that Windows recognizes the certificate.
  4. Confirm that the signing utility can access the token's private key.
  5. Follow the provider's instructions for PIN authentication.

The certificate's private key remains protected by the token.

Option 3: Cloud Signing

Cloud-signing services handle private-key operations remotely.

Instead of importing a private key, developers configure authentication credentials and use the provider's supported signing integration.

This approach is particularly useful when signing software in automated build environments.

Signing Your Executable with SignTool

The Windows SDK includes signtool.exe, which can apply Authenticode signatures to Windows executables and other supported file types.

Basic Command

For a certificate stored in a PFX file, use:

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /f your-cert.pfx /p your-password your_executable.exe

This command performs several operations:

The command assumes that your certificate supports PFX-based signing.

Signing with a Certificate from the Windows Store

If your certificate is available through the Windows certificate store, you may be able to select it using its SHA-1 certificate thumbprint:

signtool sign /sha1 YOUR_CERTIFICATE_THUMBPRINT /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 your_executable.exe

Here, /sha1 identifies the certificate by its thumbprint. It does not mean that the executable is being signed using the SHA-1 digest algorithm.

Hardware-backed certificates may require additional authentication through their provider's software.

Why Timestamping Matters

Timestamping records when an executable was signed.

Without a trusted timestamp, a signature may no longer validate as expected after the signing certificate expires.

A properly timestamped signature can remain valid after certificate expiration, provided the certificate was valid when the signature was created and other trust requirements remain satisfied.

Timestamping should therefore be enabled for production releases.

Advanced SignTool Options

Additional useful options include:

Avoid placing production certificate passwords directly into shell scripts, command histories, or publicly accessible build logs.

A hardware-backed key or signing service is generally preferable for automated distribution.

Verifying the Signature

After signing an executable, confirm that Windows recognizes its digital signature.

Run:

signtool verify /pa /v your_executable.exe

The /pa option uses the default Authenticode verification policy.

The /v option displays detailed information about the signature and certificate chain.

You can also inspect signatures using PowerShell:

Get-AuthenticodeSignature .\your_executable.exe

A properly trusted signature generally reports a Valid status when its certificate chain and file integrity checks succeed.

Verifying Through File Properties

Windows also provides a graphical method:

  1. Right-click the executable.
  2. Select Properties.
  3. Open the Digital Signatures tab, if present.
  4. Select the signature.
  5. Click Details.

This allows you to inspect the publisher's certificate and signature status.

If the signature is missing or invalid, confirm that the correct certificate was selected and that the executable was not modified after signing.

Signing a Rust Executable

Rust produces native Windows executables that can be signed using the same Authenticode process as applications written in other compiled languages.

If you're developing desktop tools, utilities, or other native applications, code signing can be integrated directly into your Rust release workflow.

Step 1: Compile Your Rust Application

Build your project in release mode:

cargo build --release

For a Windows binary target, Cargo places the compiled executable in a directory similar to:

target\release\your_rust_app.exe

If you're cross-compiling, the output may instead be located under a target-specific directory.

For developers interested in distributing applications across several operating systems, cross-platform development with Rust involves compiling platform-specific binaries and preparing the appropriate packaging and signing process for each operating system.

Step 2: Sign the Executable

Using a PFX-based certificate:

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /f your-cert.pfx /p your-password target\release\your_rust_app.exe

For hardware-backed certificates or cloud signing, substitute the provider's supported signing method.

Step 3: Verify the Signature

Run:

signtool verify /pa /v target\release\your_rust_app.exe

You should also inspect the resulting executable through Windows File Properties.

Step 4: Distribute the Signed Binary

Once your executable is signed and verified, it can be packaged for distribution.

Common approaches include:

If you create an installer, sign the installer itself after packaging.

Do not assume that signing the executable automatically signs every component of the distribution package.

Signing Applications in Other Languages

Windows code signing is largely independent of the programming language used to build the application.

The same Authenticode tools can sign executables produced by C#, C++, Delphi, Rust, and numerous other development environments.

C# with Visual Studio

For developers working with C# and .NET, it is important to distinguish between assembly signing and Authenticode signing.

Strong-name signing is not the same as Windows Authenticode code signing.

Strong-name signing gives a .NET assembly a cryptographic identity but does not establish the verified publisher information used by Windows SmartScreen.

To Authenticode-sign a compiled .NET executable:

  1. Build the application in Release mode.
  2. Locate the final .exe file.
  3. Sign it using SignTool or your certificate provider's supported signing service.
  4. Verify the resulting signature.

Example:

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /f your-cert.pfx /p your-password bin\Release\net8.0-windows\YourApp.exe

The actual output directory depends on your project's target framework and publishing configuration.

When publishing self-contained applications or single-file executables, perform signing after the final publish step.

C++ Applications

C++ executables can be signed with SignTool after compilation and linking.

For example:

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /f your-cert.pfx /p your-password build\Release\YourApp.exe

If your application includes DLL files, those binaries may also require signing.

Other Programming Languages

The signing process is similar for applications created with:

The important requirement is that you sign the final distributable files after all build and packaging operations that modify them.

Automating Code Signing

Manually signing every software release is manageable for small projects, but it becomes inefficient as an application grows.

Automated build systems can compile, test, package, sign, and publish software through a repeatable process.

A typical workflow is:

  1. Developers commit changes to version control.
  2. Automated tests run.
  3. The production executable is compiled.
  4. Distribution packages are created.
  5. A trusted signing service signs the artifacts.
  6. Signatures are verified.
  7. Signed releases are published.

For teams already using Git for version control, integrating code signing into continuous integration and deployment pipelines provides a consistent release process.

Cloud-based signing is often preferable here because private keys can remain protected without exposing them to individual build machines.

Signing in GitHub Actions

For example, a Rust application might use GitHub Actions to compile a Windows executable and then invoke a signing service.

The compilation stage might include:

name: Build Windows Release

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: windows-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Rust
        run: rustup toolchain install stable --profile minimal

      - name: Build release
        run: cargo +stable build --release

A production workflow would add the provider's signing action, securely supplied credentials, signature verification, and artifact publishing.

The specific signing implementation depends on your certificate provider.

Do not upload private signing keys or certificate passwords to a Git repository.

SmartScreen and Application Reputation

A common misconception is that purchasing a code-signing certificate automatically eliminates Windows SmartScreen warnings.

This is not generally true.

Microsoft Defender SmartScreen uses reputation signals that include publisher identity and the history of downloaded files.

A newly released executable may still display an unrecognized application warning even when it has a valid digital signature.

Over time, a publisher's certificate and properly signed releases may accumulate a positive reputation.

Does an EV Certificate Bypass SmartScreen?

No.

Microsoft's current documentation explicitly states that EV certificates no longer provide the automatic SmartScreen reputation advantage they once offered.

Both OV and EV certificates may initially encounter warnings.

Does Smart App Control Work Differently?

Yes.

Windows 11 Smart App Control evaluates whether applications are recognized as safe or signed with a trusted certificate.

Unlike SmartScreen's downloaded-file reputation warnings, Smart App Control can enforce restrictions on unfamiliar unsigned executables regardless of whether they were downloaded from the internet.

For a better understanding of these protections, Windows security settings and application controls determine how different Windows features evaluate unfamiliar software.

Microsoft Store Distribution

Applications distributed through the Microsoft Store are signed through Microsoft's publishing process.

This can eliminate the typical SmartScreen download warnings associated with independently distributed executables.

However, Store distribution has its own submission, packaging, and policy requirements.

Windows Code Signing Changes in 2026

Windows code-signing infrastructure continues to evolve as Microsoft updates certificate authorities and cryptographic algorithms.

In an August 2026 announcement about next-generation Windows code signing, Microsoft described plans to replace expiring signing certificates, introduce stronger algorithms, and prepare its infrastructure for post-quantum cryptography.

The announced transition includes stronger configurations such as RSA-3072 and SHA-384, with further cryptographic changes planned for 2027.

For developers, the important lesson is to avoid building applications that assume certificates will always use a particular issuer, thumbprint, or cryptographic algorithm.

Software that validates signatures should generally rely on supported Windows trust APIs rather than manually comparing certificates against hard-coded values.

These changes also reinforce the importance of maintaining an adaptable signing process that can accommodate new certificates and security requirements.

Troubleshooting Common Code Signing Problems

SignTool Cannot Find a Certificate

Confirm that the certificate is installed in the correct store or accessible through your hardware token.

If you're using a PFX file, confirm the file path and password.

The Signature Is Invalid

Check whether the executable was modified after signing.

Rebuilding an executable, changing its embedded resources, or modifying the installer after signing may invalidate its signature.

The Timestamp Server Is Unavailable

Try again later or use another trusted RFC 3161 timestamp server supported by your signing configuration.

A temporary network or server issue can prevent timestamping even when the certificate itself is valid.

SmartScreen Still Displays a Warning

A valid signature does not guarantee an established SmartScreen reputation.

Verify that the publisher identity is correct and continue signing releases consistently.

The Certificate Has Expired

Determine whether the executable was timestamped correctly.

A valid trusted timestamp may allow the signature to remain valid after the signing certificate expires.

For new software releases, obtain or renew a valid signing certificate.

Conclusion

Code signing is an important part of professionally distributing Windows software.

It establishes a verifiable publisher identity, helps detect changes to executables, and supports Windows security features such as SmartScreen and Smart App Control.

Modern signing workflows increasingly rely on hardware-backed certificates and managed signing services rather than traditional downloadable private keys.

Whether you're developing desktop applications in Rust, C#, C++, or another language, the essential process remains the same: compile the final application, sign the distributable files, timestamp the signatures, and verify them before publishing.

Integrating these steps into an automated release pipeline can reduce mistakes and help maintain consistent software quality as your projects grow.