Master Windows Code Signing with Artifact Signing

Users demand that downloaded Windows applications are safe, authentic, and tamper-free. Code signing is essential to building that trust. By digitally signing software, developers can prove that an application came from a verified publisher and that its contents have not been modified after release. For organizations distributing Windows applications, code signing is no longer just a best practice – it is a fundamental part of software delivery. Despite its importance, traditional code signing presents operational challenges. Obtaining and managing certificates is time-consuming, especially given the strict identity verification requirements. Protecting private keys adds complexity, often requiring hardware security modules (HSMs), USB tokens, or dedicated infrastructure. Certificate renewals, access controls, and compliance demands further increase administrative overhead.

These issues are amplified in modern development environments where software is built, tested, and released using automated CI/CD pipelines. Development teams seek seamless signing processes that fit into their workflows and avoid bottlenecks or manual steps. Managing tokens, safeguarding keys, and maintaining inventories can hinder releases and create friction between security and development.

Recognizing these ongoing challenges, Microsoft recently announced the general availability (GA) of Artifact Signing, a cloud-based signing service designed to directly address them. With Artifact Signing, enterprises can offload the burden of managing traditional code-signing certificates and signing infrastructure. The service provides a managed, integrated approach that streamlines workflows, reduces manual effort, and helps ensure secure, trustworthy software delivery.

Solutions such as our CodeSign Secure complement modern signing services by providing a centralized inventory of cryptographic assets, helping security teams understand where critical certificates and keys are being used and identify potential risks before they become problems.

As security risks to the software supply chain increase, solutions that both simplify code signing and provide insight into cryptographic usage offer security teams a tangible advantage: they strengthen overall security while reducing complexity and operational cost. This dual benefit is increasingly critical to maintaining trust and competitiveness.

Master Windows code signing with Artifact Signing, defined: using Microsoft’s cloud-based, Microsoft-managed-HSM signing service, formerly Trusted Signing, to sign Windows executables and packages via signtool.exe or the dotnet sign CLI, without provisioning or protecting a private key yourself, then verifying the result with signtool’s own verify command before shipping.

Key Takeaways

• Trusted Signing was renamed Artifact Signing in 2026 with no functional change; existing accounts, certificate profiles, billing, and APIs continue working, only client-tool references need updating.
• Signing still runs through signtool.exe (digest signing: only a file hash is sent to Azure, never the full file) or the newer, simpler dotnet sign CLI; both require the Artifact Signing Client Tools installed locally.
• The private key never leaves Microsoft’s managed HSM; there is no customer-side key provider or HSM setup step, which is the key architectural difference from a customer-controlled platform like CodeSign Secure.
• Exact CLI syntax, minimum tool versions, and flag names have changed more than once during this service’s rollout; treat the commands below as verified at time of writing and cross-check against Microsoft Learn’s Artifact Signing documentation before a production rollout.
• Identity verification for new accounts runs through a third-party vendor (au10tix) and is a common source of onboarding delay, not a tooling problem.

Challenges of Traditional Code Signing

While code signing is essential for establishing trust in Windows applications, the traditional approach often comes with several operational and security challenges.

The first hurdle is procuring and renewing certificates. Obtaining a code-signing certificate typically involves identity verification, approval processes, and ongoing certificate management. Organizations must also track expiration dates and ensure timely renewals to avoid disruptions in software releases.

Protecting signing keys is another major concern. Because a compromised signing key can be used to distribute malicious software under a trusted identity, many development teams rely on hardware tokens or Hardware Security Modules (HSMs) to securely store private keys. While these solutions improve security, they also introduce additional costs, infrastructure requirements, and administrative overhead.

Manual signing workflows can further complicate the release process. In many environments, signing is treated as a separate step that requires specific tools, credentials, or personnel. This can create delays, especially when development teams need to release updates quickly or frequently.

The shift toward CI/CD-driven software delivery has highlighted another challenge: integration. Traditional code-signing methods were not originally designed for highly automated build and deployment pipelines. Managing hardware-based keys, granting secure access to signing infrastructure, and maintaining signing consistency across multiple environments can become difficult as development teams scale.

Compliance and audit requirements add another layer of complexity. Security teams often need to demonstrate who signed a particular artifact, when the signing occurred, and whether proper controls were followed. Maintaining accurate records and proving compliance during audits can be time-consuming when signing activities are spread across multiple tools and systems.

Altogether, these challenges are motivating organizations to seek code signing solutions that deliver clear value: reducing manual effort, streamlining automation, simplifying compliance, and maintaining robust security. The ideal solution eliminates friction, makes secure software delivery seamless across the entire development lifecycle, and aligns technical and business objectives.

What is Artifact Signing?

Artifact Signing is Microsoft’s cloud-based signing service designed to simplify how businesses sign Windows applications and other software artifacts. Announced as generally available (GA), the service helps developers move away from many of the operational challenges associated with traditional code-signing certificates and on-premises signing infrastructure.

Artifact Signing builds on Microsoft’s earlier Trusted Signing service and expands the concept of managed signing for modern software development workflows. Instead of requiring enterprises to handle certificate lifecycle management, key storage, and signing infrastructure themselves, Microsoft manages much of that complexity behind the scenes.

A major advantage is managed certificates, so they don’t need to handle provisioning, renewals, or key protection. The service verifies publisher identities to establish trust and ensure only authorized organizations sign under their names.

To support enterprise security requirements, Artifact Signing includes role-based access control (RBAC), allowing administrators to define who can perform signing operations and manage signing resources. Audit logging provides visibility into signing activities, making it easier to track usage and support compliance requirements.

Because the service is cloud-based, it fits naturally into modern CI/CD pipelines and automated release processes. Development teams can integrate signing directly into build and deployment workflows without maintaining dedicated signing infrastructure.

According to Microsoft’s GA announcement, Artifact Signing aims to make code signing more accessible, scalable, and operationally efficient while maintaining the trust and security that Windows software publishers require.

Hands-On: Signing a Windows Artifact with Artifact Signing

This walkthrough covers the current, verified path for signing a Windows executable: the environment it runs on, what to set up before signing anything, how authentication works, the actual signing and verification commands, what to expect back, and how to wire it into CI/CD.

Environment Matrix

Component	Supported / Required	Notes
Build agent OS	Windows x64	Required for signtool.exe-based signing; confirm current cross-platform support for the dotnet sign CLI before relying on a Linux or macOS agent
Build agent architecture	x64 confirmed; ARM64 unconfirmed	At least one client tool has been reported as unsupported on ARM; verify with Microsoft Learn for your specific tool and version before using ARM64 runners
signtool.exe	A recent Windows SDK build	Microsoft Learn specifies a minimum SignTool version; confirm the current exact minimum on the Artifact Signing setup page rather than relying on a cached number, since this has been updated as the SDK ships new builds
.NET runtime (for dotnet sign)	.NET 8 or later	Earlier client tooling had strict single-version requirements where a mismatched .NET version failed silently; current Artifact Signing Client Tools support rolling forward to later .NET versions
Azure subscription	Required	Microsoft.CodeSigning resource provider must be registered on the subscription before an account can be created

Prerequisites

1. An Azure subscription with the Microsoft.CodeSigning resource provider registered.
2. An Artifact Signing account and at least one certificate profile, created after completing identity verification (via au10tix) for the publishing organization or individual.
3. A decision on trust model: Public Trust (software distributed to the general public) or Private Trust (internal or limited-distribution software), since this is set per certificate profile and affects which one you reference in the signing command.
4. The Artifact Signing Client Tools installed on the build machine, via winget: winget install -e --id Microsoft.Azure.ArtifactSigningClientTools.
5. Either the sign .NET global tool (dotnet tool install -g sign) for the newer CLI workflow, or a recent signtool.exe from the Windows SDK for the traditional workflow.

Key Provider / HSM Model

There is no customer-facing HSM setup step, and that’s a deliberate architectural choice, not a gap in this guide. Artifact Signing generates and holds the private key inside Microsoft’s own managed HSM infrastructure; the signing operation happens through a digest-signing flow, where the local client computes a hash of the file and sends only that hash to the service, which returns a signature. The full file, and the key, never leave their respective sides of that boundary. This is different from a customer-controlled signing platform such as CodeSign Secure, where the organization chooses and controls its own HSM (Thales, Entrust, Utimaco, Securosys, or cloud HSM) and can enforce its own key-isolation and approval policy independent of any single cloud vendor. Neither model is wrong; they answer different questions, “do I want to operate signing infrastructure at all” versus “do I want direct control over where my keys live and how signing is governed across multiple platforms and CAs.”

Secure Authentication

Three authentication paths are supported, in order of preference for automated environments:

• Federated credentials (OIDC), for GitHub Actions or Azure DevOps: configure a federated credential on the app registration scoped to the specific repository, organization, and branch or pull request, so the pipeline authenticates without a stored secret at all. This is the preferred option for CI/CD.
• Managed identity, for signing from an Azure VM: assign a user-assigned managed identity to the VM and grant it the Artifact Signing Certificate Profile Signer role at the resource group or subscription level.
• Service principal via environment variables, for other CI systems or local testing: set AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET in the environment; signtool and the sign CLI both check for these automatically. For interactive local use, az login is simplest.

Before any of these work, register the resource provider once per subscription:

az login
az provider register --namespace Microsoft.CodeSigning
az provider show --namespace Microsoft.CodeSigning --query "registrationState"

Wait until the last command reports "Registered" before creating a signing account; registration typically takes a couple of minutes.

Signing Command

Using the sign CLI (the current, simpler officially-supported path):

sign code artifact-signing `
  --verbosity warning `
  --timestamp-url http://timestamp.acs.microsoft.com `
  --artifact-signing-endpoint https://eus.codesigning.azure.net/ `
  --artifact-signing-account <your-account-name> `
  --artifact-signing-certificate-profile <your-profile-name> `
  path\to\your-app.exe

The endpoint URL is region-specific; confirm the correct regional endpoint for your Artifact Signing account in the Azure portal rather than assuming eus (East US) applies to your account. For signing many files, add --max-concurrency 10 (default is 4) to reduce total signing time.

Using signtool.exe directly (the traditional path, still supported for existing scripts):

signtool.exe sign /v /fd SHA256 /tr http://timestamp.acs.microsoft.com /td SHA256 ^
  /dlib "<path-to-Azure-Artifact-Signing-dlib>" ^
  /dmdf "<path-to-metadata-json-file>" ^
  path\to\your-app.exe

The metadata file referenced by /dmdf is a small JSON file you create once, pointing to your Artifact Signing account, certificate profile, and endpoint; generate it following the current Microsoft Learn setup steps rather than hand-copying an example, since the exact schema has changed between tool versions.

Verification Command and Expected Output

Verify with signtool’s own verify command, directly from Microsoft’s documentation:

signtool.exe verify /v /debug /pa path\to\your-app.exe

A successful verification reports the signature as valid, names the signing certificate’s subject (which should match what you configured for your certificate profile in the Azure portal), and confirms a valid countersignature timestamp. If the signature doesn’t show up under the file’s Properties > Digital Signatures tab in Windows Explorer, that’s not necessarily a failure on its own, not every file type surfaces that tab, so treat the signtool verify output as authoritative over the Explorer UI.

Common Errors

Symptom	Likely Cause	What to Check
Signing “succeeds” but the output file is unsigned	A mismatched .NET runtime version with older client tooling, which can fail silently rather than erroring	Confirm the .NET version the client tool expects; current Artifact Signing Client Tools support .NET 8+ with rolling forward compatibility
Certificate or EKU-related failure	signtool.exe picked up is the wrong architecture (x86 instead of x64, or vice versa)	Check the SIGNTOOL_PATH environment variable and any hardcoded path in your build script
GitHub Action fails with an undocumented “error code 3”	Reported by multiple users without a documented root cause as of this writing	Check the Action’s current issue tracker and Microsoft’s Artifact Signing FAQ for updates before assuming it’s specific to your setup
Azure DevOps extension install fails with InvalidSignature or NullReferenceException	The .vsix was run directly through VSIXInstaller.exe on a workstation instead of installed through the Marketplace into the organization	Install the extension only via the Visual Studio Marketplace, into the Azure DevOps organization, not as a local Visual Studio extension
Signing times out on a large batch	The default request timeout (300 seconds in the PowerShell module) is exceeded	Increase the timeout parameter for large batches, or split the batch, or raise –max-concurrency with the sign CLI
Onboarding stuck at identity verification	au10tix (the third-party identity verification vendor) backend error during document or selfie verification	This is a known, intermittent friction point in account setup, not a signing bug; retry or contact support through the Artifact Signing FAQ channel

CI/CD Example

GitHub Actions, using a federated credential (no stored client secret) and the sign CLI:

- name: Install sign CLI
  run: dotnet tool install -g sign

- name: Sign artifact
  env:
    AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
    AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
  run: |
    sign code artifact-signing `
      --timestamp-url http://timestamp.acs.microsoft.com `
      --artifact-signing-endpoint ${{ secrets.AZURE_SIGNING_ENDPOINT }} `
      --artifact-signing-account ${{ secrets.AZURE_SIGNING_ACCOUNT }} `
      --artifact-signing-certificate-profile ${{ secrets.AZURE_SIGNING_PROFILE }} `
      path\to\your-app.exe

Note this omits AZURE_CLIENT_SECRET deliberately; with a federated credential configured on the app registration for this specific repository, GitHub’s own OIDC token satisfies authentication without a long-lived secret ever being stored. Azure DevOps uses a first-party extension instead of a raw CLI step: install “Artifact Signing” from the Visual Studio Marketplace into your organization (requires the Manage Extensions permission), then reference the AzureArtifactSigning@<version> task in your pipeline YAML, following the task’s current input reference on the Marketplace listing for the exact parameter names for your installed version.

Cleanup

• If you used a service principal secret for local testing, remove it from your shell environment and, if it was only needed temporarily, delete the client secret from the app registration in Azure AD.
• Run az logout on any shared or ephemeral build agent where you authenticated interactively.
• Remove any federated credential scoped to a branch, repository, or pull request that’s no longer active, since a stale federated credential is a standing trust relationship even without a stored secret.
• If the Artifact Signing Client Tools were installed only for a one-off test, uninstall with winget uninstall --id Microsoft.Azure.ArtifactSigningClientTools rather than leaving signing tooling on a machine that doesn’t need it long-term.

Supporting Modern Software Supply Chains

Code signing has traditionally been associated with executable files, but today’s software delivery process involves far more than just applications and installers. Organizations now build, package, distribute, and deploy a wide range of software artifacts, including containers, libraries, scripts, configuration files, packages, and deployment manifests. As a result, trust must extend beyond the final executable.

This shift has made software supply chain security a major priority. Attackers increasingly target build environments, dependencies, and distribution pipelines because compromising a single component can impact thousands of downstream users. In many cases, the software itself may not be altered directly; instead, malicious changes are introduced somewhere along the delivery process.

This is where signing plays an important role. Digital signatures help establish provenance by providing evidence of where an artifact originated and who approved it for distribution. They also support integrity verification by allowing recipients to confirm that an artifact has not been modified after signing.

As development teams automate, build pipelines, and adopt distributed development, artifact-level trust is essential. Security teams need confidence in each component contributing to application creation and deployment. Regardless of type, every artifact should be traceable to a trusted source.

Research and industry guidance continue to identify code signing as a key control for strengthening software provenance and supply chain assurance. When implemented consistently, signing helps create a verifiable chain of trust throughout the software delivery process, making it easier to detect unauthorized changes, reduce the risk of tampering, and improve confidence in released software.

In short, modern code signing is no longer just about proving an executable is authentic. It is about establishing trust across the entire software supply chain.

Beyond Signing: Why Cryptographic Visibility Matters

Artifact Signing helps simplify software signing, but signing is only one part of a larger cryptographic security picture. Organizations may have a streamlined signing process, yet still struggle to answer important questions such as: Which certificates are being used across development environments? Where are signing keys stored? Which cryptographic algorithms are deployed? Are there any expired, weak, or unmanaged assets that are creating risk?

Without clear visibility, these questions become difficult to answer, especially in large enterprises where cryptographic assets are spread across cloud services, HSMs, CI/CD pipelines, servers, applications, and developer environments.

While Artifact Signing simplifies the signing process, businesses also need visibility into the cryptographic assets that support their software delivery pipelines. This is where our CodeSign Secure complements modern code-signing programs by discovering, inventorying, and tracking certificates, keys, and cryptographic dependencies across cloud, HSM, DevOps, and enterprise environments.

Our solution provides automated discovery of code-signing certificates and related cryptographic assets, helping security teams understand what exists, where it is located, and how it is being used. Instead of relying on spreadsheets or manual audits, organizations gain a centralized cryptographic inventory that provides a clear view of certificates, keys, algorithms, trust chains, and signing infrastructure.

This visibility is valuable for identifying risks before they impact software delivery. Security teams can detect expired certificates, weak algorithms, unmanaged keys, duplicate assets, or cryptographic dependencies that may require attention. Having this information readily available also simplifies audits and supports stronger governance practices.

Beyond operational security, cryptographic visibility has become increasingly important for long-term planning. As they prepare for post-quantum cryptography (PQC) transitions, understanding where cryptographic assets and algorithms are deployed becomes a critical first step. Organizations cannot effectively plan a migration strategy without first understanding which cryptographic assets are deployed across their environment.

By combining the simplicity of Artifact Signing with the discovery and intelligence capabilities of our solution, enterprises can strengthen software trust while improving cryptographic governance. Signing helps establish authenticity and integrity, while our solution provides the visibility needed to manage, assess, and future-proof the cryptographic foundations that support modern software delivery.

How Our CodeSign Secure Helps

Artifact Signing simplifies signing software, but many security teams still need a comprehensive solution for managing signing operations across multiple platforms, environments, and use cases. This is where Encryption Consulting’s CodeSign Secure adds value.

Our CodeSign Secure provides centralized control over code-signing activities, helping organizations enforce consistent signing policies across development teams and release pipelines. Whether signing Windows applications, containers, scripts, drivers, or other software artifacts, teams can manage the entire signing process from a single platform.

One of the key advantages of our solution is its flexibility. Enterprises can integrate with cloud-based signing services, public and private CAs, HSMs, and existing DevOps tools while maintaining full visibility and control over signing workflows. This allows security teams to define approval processes, enforce access controls, and ensure that signing keys are used only by authorized users and systems.

The platform also provides detailed audit trails, making it easier to track who signed what, when, and which credentials were used. This helps support compliance requirements and simplifies security reviews.

When used alongside services such as Artifact Signing, our solution serves as a governance and orchestration layer that integrates signing operations, policy enforcement, and visibility. The result is a more controlled, scalable, and secure code-signing program that supports both development efficiency and enterprise security requirements.

Artifact Signing vs. a Customer-Controlled Platform: Which Fits?

Consideration	Artifact Signing	CodeSign Secure (customer-controlled)
Key custody	Microsoft-managed HSM; you never choose or touch the hardware	Your chosen HSM (Thales, Entrust, Utimaco, Securosys, or cloud HSM)
Platform scope	Windows-focused (Authenticode, MSIX, driver signing)	Cross-platform: Windows, Java/Android, Linux, containers, firmware, PQC
CA/trust model	Microsoft’s own signing CA, Public or Private Trust	Your choice of public or private CA
Governance across multiple signing tools	Governs Artifact Signing activity only	Single policy engine across every signing tool and platform in use
Best fit	Windows-only shops that want to avoid operating any signing infrastructure at all	Organizations signing across multiple platforms, or that need direct control over key custody and CA choice

Frequently Asked Questions

Is Trusted Signing the same as Artifact Signing?

Yes. Microsoft renamed Trusted Signing to Artifact Signing in 2026 with no functional change. Existing accounts, certificate profiles, billing, and APIs continue working unchanged; only client-tool references need updating to the new name.

Do I need my own HSM to use Artifact Signing?

No. Artifact Signing generates and stores the private key inside Microsoft’s own managed HSM infrastructure. This is the core trade-off versus a customer-controlled platform: less setup, but no choice over key custody or hardware vendor.

Does the full file get uploaded to Azure for signing?

No. Signing uses a digest-signing approach: the local client computes a hash of the file and sends only that hash to the service, which returns a signature. The file itself never leaves the build machine.

Which is the current recommended CLI, signtool.exe or dotnet sign?

Both are officially supported. The sign .NET global tool (dotnet sign) has emerged as the simpler, faster path for new setups, while signtool.exe with the Artifact Signing dlib remains the option for teams with existing signtool-based build scripts they don’t want to rewrite.

Why did my Azure DevOps extension install fail?

Most commonly because the .vsix was run directly through VSIXInstaller.exe on a workstation, which produces a misleading InvalidSignature or NullReferenceException even though the package’s signature is valid. Install it only through the Visual Studio Marketplace into your Azure DevOps organization.

Conclusion

For many businesses, traditional code signing has long been a necessary but often complicated part of software delivery. Managing certificates, protecting signing keys, maintaining signing infrastructure, and supporting compliance requirements can create significant operational overhead, particularly as development teams adopt faster release cycles and automated deployment pipelines.

Microsoft’s Artifact Signing represents a meaningful step toward simplifying this process. By shifting certificate management and signing operations to a cloud-based service, you can reduce administrative effort, improve scalability, and integrate signing more naturally into modern CI/CD workflows. This allows development teams to focus more on building and delivering software rather than maintaining signing infrastructure.

However, signing software is only one piece of the security puzzle. Security teams also need visibility into the certificates, keys, algorithms, trust chains, and signing systems that support their software supply chains. Without that visibility, it becomes difficult to assess risk, enforce governance policies, or prepare for future cryptographic changes.

This is where solutions such as our CodeSign Secure play an important role. By providing automated discovery and inventory of cryptographic assets across cloud, HSM, DevOps, and enterprise environments, our solution helps you understand and manage the cryptography behind their software delivery processes. Combined with our solution, teams gain greater control over signing operations while maintaining the visibility needed for governance and compliance.

Together, Artifact Signing and our solution help development teams build a stronger foundation for software trust. They simplify signing workflows, improve cryptographic oversight, and support a more secure software supply chain from development through deployment.