Azure Key Vault Code Signing: The Complete Setup, Installation, and Use-Case Guide

Most Azure Key Vault code signing tutorials still read like it’s 2021. They walk you through Access Policies that Microsoft has since replaced with RBAC, skip the June 2023 CA/Browser Forum rule that made vault-based signing mandatory in the first place, and never mention that Microsoft quietly renamed its competing service twice in the last two years. This guide covers what actually works right now, including where Key Vault fits next to Azure Artifact Signing and which certificate authorities it will and won’t work with.

Why Azure Key Vault Exists for Code Signing in the First Place

Before June 1, 2023, code signing certificates shipped as downloadable .pfx files. You could drop the private key on a build server, a laptop, a USB drive, wherever. That’s exactly the problem the CA/Browser Forum’s Code Signing Certificate (CSC) requirements were written to close, after a string of high-profile incidents where stolen signing keys were used to push malware that looked perfectly legitimate to Windows.

The rule now is simple: private keys for OV and EV code signing certificates must live in a FIPS 140-2 Level 2 (or higher) hardware security module, and the key can never be exportable. A physical USB token satisfies that. So does Azure Key Vault’s Premium tier, because it’s backed by FIPS 140-2 Level 3 HSMs under the hood. The certificate authority never sees your private key at all — it only ever touches a certificate signing request generated inside the vault.

That’s the trade Key Vault offers: no token to lose, no hardware to ship between remote team members, and signing operations that work from any CI/CD runner with the right credentials.

Prerequisites Before You Start

Confirm each of these before opening the Azure portal, since missing one of them is the most common reason setups stall halfway through:

• An active Azure subscription with permission to create resources and assign roles
• A code signing certificate order in progress (or ready to place) with DigiCert or GlobalSign — this matters, see the CA compatibility section below
• Owner or User Access Administrator rights on the subscription or resource group, so you can grant yourself Key Vault Administrator
• The Windows SDK installed somewhere in your build chain, since AzureSignTool still relies on the Authenticode signing engine that ships with it

Part 1: Setting Up Azure Key Vault for Code Signing

Step 1: Create the Key Vault on the Premium Tier

In the Azure portal, search for Key Vaults and select Create. Fill in the resource group, region, and vault name as usual, but pay attention to one field: Pricing Tier.

Pick Premium, not Standard. Standard tier vaults can only generate software-protected keys, which don’t satisfy the CA/B Forum’s HSM requirement. Premium is what unlocks HSM-backed RSA keys, and it’s the whole reason you’re using Key Vault instead of just storing a .pfx somewhere. Premium runs roughly $5 a month for the vault itself, separate from whatever you pay the CA for the certificate.

Leave networking and recovery options at their defaults unless your organization has a specific private-endpoint policy, then finish through Review + Create.

Step 2: Assign Yourself Key Vault Administrator

Creating the vault makes you its Owner, but Owner alone doesn’t let you manage keys and certificates inside it — that’s a separate, more granular permission model now that Microsoft has moved Key Vault to Azure RBAC by default.

Open the vault, go to Access control (IAM), and select Add role assignment. Assign yourself (and anyone else who needs to manage certificates) the Key Vault Administrator role at the vault scope. Skip Access Policies entirely; that’s the legacy permission model and new vaults default to RBAC.

Step 3: Generate the Certificate Signing Request

Inside the vault, go to Objects > Certificates, then Generate/Import. Choose Generate as the method, then fill in the form:

• Certificate Name — an internal reference only, it won’t appear on the issued certificate
• Type of CA — select “Certificate issued by a non-integrated CA,” since DigiCert and GlobalSign aren’t among Key Vault’s built-in partner CAs for code signing specifically
• Subject — CN=Your Legal Company Name, matching exactly what’s registered with your CA
• Key Type — this is the field people get wrong most often. Choose an option ending in -HSM (for example, RSA-HSM 3072). Anything without the HSM suffix generates a software key, and your certificate will later be flagged non-compliant and can be revoked
• Extended Key Usage — add 1.3.6.1.5.5.7.3.3, the OID for code signing

Click Create. The certificate now shows status In Progress. Open it, go to Certificate Operation, and download the CSR file. That file contains only your public key — the private key was generated inside the HSM and never leaves it.

Step 4: Submit the CSR and Get It Signed

Upload the CSR through your CA’s order form (DigiCert’s CertCentral or GlobalSign’s Certificate Center, depending on which brand you bought). Complete organization validation if you haven’t already — this can take one to several business days depending on how quickly your CA can confirm your business registration. Once approved, the CA issues a signed certificate file back to you, typically as a .cer or .p7b.

Step 5: Merge the Signed Certificate Back Into the Vault

Go back to the same in-progress certificate object in Key Vault and choose Merge Signing Request, uploading the file your CA sent back. Key Vault pairs it with the private key it already generated in Step 3 and the certificate moves to Enabled. From this point, the certificate and its HSM-backed key are ready to sign code — they never need to leave the vault.

Part 2: Installing and Using AzureSignTool

Windows’ built-in signtool.exe doesn’t know how to reach a key stored in Azure. That’s what AzureSignTool is for: an open-source, drop-in replacement that speaks the same command syntax but authenticates to your vault instead of pulling a certificate from the local machine store.

Installing AzureSignTool

If you have the .NET SDK installed, the simplest path is the global tool install:

dotnet tool install --global AzureSignTool

Pin to a specific version in CI/CD pipelines (--version 7.0.1, for example) rather than always pulling latest, since major-version bumps occasionally change flag behavior.

Authenticating to the Vault

You’ll need an app registration (service principal) with a Sign and Get permission on certificates, scoped to your vault, or a managed identity if you’re signing from an Azure-hosted build agent. Either way, you need four values in hand before your first sign: the vault URI, the certificate name, and either a client ID/tenant ID/client secret trio or a managed identity context.

Signing a File

AzureSignTool.exe sign ^
  -kvu "https://your-vault-name.vault.azure.net" ^
  -kvc "your-certificate-name" ^
  -kvi "your-app-client-id" ^
  -kvt "your-tenant-id" ^
  -kvs "your-client-secret" ^
  -tr "http://timestamp.digicert.com" ^
  -td sha256 ^
  -fd sha256 ^
  -v ^
  "C:\build\output\YourApp.exe"

A few flags worth understanding rather than copy-pasting blind:

• -tr and -td add an RFC 3161 timestamp, which is what keeps your signature valid after the certificate itself expires. Never skip this — it’s the difference between software that stays trusted for years and software that starts throwing warnings the day your certificate lapses
• -fd sets the file digest algorithm; sha256 is the current standard, sha1 is deprecated and will trip modern Windows security checks
• You can pass multiple file paths, a wildcard pattern, or an -ifl text file listing paths, which is the practical way to sign an entire build output folder in one call

The same command signs .exe, .dll, .msi, .msix, and .ps1 files — AzureSignTool inherits whatever file-type support the underlying Authenticode SIP providers on the build machine support. One caveat worth flagging: MSIX signing specifically requires Windows Server 2019 or later on the build agent; Server 2016 doesn’t have the SIP handler for it and will fail with an unhelpful “corrupt file” error.

Wiring It Into CI/CD

The same command drops directly into a pipeline step. In GitHub Actions, store the vault URL, client ID, tenant ID, and client secret as repository secrets, install AzureSignTool in a setup step, then call it after your build step produces the binaries. In Azure DevOps, the equivalent is a PowerShell or .NET Core CLI task running after your build, pulling the same four values from a variable group or Key Vault-linked pipeline variables so the secret never sits in plain text in your YAML.

Azure Key Vault vs. Azure Artifact Signing: Don’t Confuse the Two

This is where a lot of guides get muddled, partly because Microsoft renamed the competing service twice — first “Azure Code Signing,” then “Trusted Signing,” now Azure Artifact Signing as of early 2026.

The two services solve the same underlying compliance problem in opposite ways:

Azure Key Vault code signing means you buy a certificate from a public CA (DigiCert or GlobalSign), and Key Vault just stores and protects the private key. You own the certificate, you control renewal timing, and it works for any workflow that expects a standard third-party Authenticode certificate.

Azure Artifact Signing is Microsoft acting as the certificate authority itself. There’s no certificate to buy — you complete a one-time identity validation with Microsoft, and the service then issues short-lived certificates automatically (each valid for roughly 72 hours, renewed continuously, and timestamped so the signature outlives the cert). It’s billed monthly through your Azure subscription rather than purchased per certificate.

Artifact Signing is genuinely faster to set up and cheaper for pure Windows-only signing if your organization qualifies — but eligibility is restricted to businesses in the US, Canada, the EU, and the UK, with a minimum of three years of verifiable business history for Public Trust organization validation. Key Vault has no such age or geography restriction, because you’re bringing your own CA-issued certificate rather than relying on Microsoft’s own trust program.

If you distribute software outside those eligible regions, need a certificate that also works for non-Windows signing contexts, or already have an established relationship with a CA, Key Vault is the more flexible path. If you’re a Windows-only shop in an eligible country and want to remove certificate purchasing from the equation entirely, Artifact Signing is worth evaluating alongside it.

Which Certificate Authorities Actually Work With Key Vault

This trips up more people than anything else in the setup process: Azure Key Vault’s HSM-backed key generation only works with certificate authorities that support Key Vault’s specific key attestation format — currently DigiCert and GlobalSign. Sectigo and Comodo-issued certificates are not compatible with Key Vault’s native “Generate” workflow, because they use a different attestation mechanism that Key Vault doesn’t recognize.

If your organization already standardizes on Sectigo, that doesn’t rule out cloud-based key protection — it just means Key Vault’s certificate-generation flow isn’t the right fit, and you’d look at an HSM or token option that Sectigo directly supports instead.

Common Use Cases for Azure Key Vault Code Signing

Automated release pipelines for ISVs. Software vendors shipping frequent builds don’t want a human plugging in a USB token for every release. Key Vault lets the signing step run unattended as part of the same pipeline that builds and tests the code, with every signing operation logged.

Enterprise driver and kernel-mode signing. Organizations that sign drivers or system-level components benefit most from HSM-backed keys, since the compliance bar for kernel-mode signing already assumes hardware-grade key protection.

Distributed teams without a shared physical token. A physical HSM token has to live somewhere, and only one person can hold it at a time. A vault-backed key can be reached by anyone with the right role assignment, from any location, without shipping hardware.

PowerShell and internal tooling signing. Enterprises enforcing execution policies that require signed scripts use the same AzureSignTool workflow to sign internal automation scripts, not just shipped binaries.

Centralized key governance across multiple product teams. A single Premium vault can hold certificates for several product lines, with role assignments controlling exactly who can invoke a sign operation for which certificate — useful for security teams that need an audit trail of every signature issued company-wide.

MSIX packaging for Microsoft Store and sideloaded enterprise apps. Both Store submissions and internally distributed MSIX packages require a certificate chaining to a trusted root, and Key Vault-stored certificates satisfy that requirement without exporting the key to the packaging machine.

Troubleshooting Notes Worth Knowing Up Front

• “Signing failed with error 800B0003” almost always means the file type isn’t recognized by the SIP provider on that machine, or MSIX signing was attempted on Windows Server 2016
• Key generation succeeds but the certificate is later flagged non-compliant — check the key type chosen in Step 3. If it doesn’t end in -HSM, the key wasn’t hardware-protected
• Access denied errors after a recent role change — RBAC role assignments in Key Vault can take several minutes to propagate; this isn’t a misconfiguration, just a timing issue

Frequently Asked Questions

Do I need Azure Key Vault Premium, or does Standard work for code signing? You need Premium. Standard tier can’t generate HSM-backed RSA keys, and CA/Browser Forum rules require code signing private keys to be hardware-protected.

Can I use a Sectigo or Comodo code signing certificate with Azure Key Vault? No, not through Key Vault’s native certificate generation. Only DigiCert and GlobalSign currently support the key attestation format Key Vault requires.

What’s the difference between Azure Key Vault and Azure Artifact Signing? Key Vault stores a certificate you purchased from a CA and keeps its private key in an HSM. Artifact Signing is Microsoft’s own managed service — Microsoft is the CA, issuing short-lived certificates automatically after a one-time identity check, with no separate certificate purchase.

Is Azure Trusted Signing the same thing as Azure Artifact Signing? Yes. Microsoft renamed Azure Trusted Signing to Azure Artifact Signing in early 2026. The underlying service is unchanged, only the name and branding.

How much does Azure Key Vault cost for code signing? The Premium vault itself runs roughly $5 a month with a generous included operation quota. That’s separate from the certificate cost you pay your CA.

What tool do I use to sign files with a certificate stored in Key Vault? AzureSignTool, an open-source command-line tool that mirrors Windows’ native signtool.exe syntax but authenticates against Azure Key Vault instead of a local certificate store.

Can Azure Key Vault code signing be automated in CI/CD pipelines? Yes. AzureSignTool runs as a standard command-line step in GitHub Actions, Azure DevOps, Jenkins, or any pipeline capable of running Windows commands, authenticating via a service principal or managed identity.

Does Azure Key Vault support signing MSIX, PowerShell, and driver files, or just EXEs? It supports any file type the Windows Authenticode signing engine recognizes, including .exe, .dll, .msi, .msix, and .ps1. Driver signing follows the same mechanism, though kernel-mode drivers have additional Microsoft submission requirements beyond signing itself.

Why does my Key Vault-issued code signing certificate only last one year now? This follows the CA/Browser Forum’s SC-31 code signing baseline requirement changes, which shortened maximum code signing certificate validity. Multi-year terms are being phased out industry-wide, not just for Key Vault-issued certificates.

Is the private key ever exposed when using Azure Key Vault for code signing? No. The private key is generated inside the HSM and never leaves it. Signing requests are sent to the vault, and only the resulting signature is returned — the key itself is never exported or transmitted.