Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This guide walks you through signing an MSIX package for each stage of development — from local testing through production distribution. For a comparison of signing options and costs, see Sign an MSIX package overview.
Choose a signing approach
| Stage | Recommended approach | Windows version |
|---|---|---|
| Local development and testing | WinApp CLI (self-signed cert) | Windows 10 and later |
| Distribute to testers (sideloading) | Self-signed cert with cert trust step | Windows 10 and later |
| Production distribution | Azure Artifact Signing (formerly Trusted Signing) | Windows 10 version 1809 and later, Windows Server 2016 and later |
| Microsoft Store distribution | Signed by the Store on submission | All supported Windows versions |
Development: Sign for local testing
For local development, use a self-signed certificate. Self-signed packages can only be installed on machines where the certificate is explicitly trusted — this is intentional and appropriate for testing.
Option A: WinApp CLI (recommended for new projects)
Important
The Windows App Development CLI is currently in public preview and requires Windows 10 with WinGet installed.
The WinApp CLI handles certificate generation and signing in a single step.
Step 1: Install the WinApp CLI
winget install -e --id Microsoft.WinAppCLI --source winget
Step 2: Generate a self-signed development certificate
winapp cert generate --manifest .\appxmanifest.xml --output .\devcert.pfx --install
The --manifest flag reads the publisher name directly from your appxmanifest.xml. The --install flag adds the certificate to the local machine trust store, so you can immediately install your package.
Step 3: Sign the package
winapp sign MyApp.msix --cert .\devcert.pfx
Option B: PowerShell + SignTool (Windows 10 and later)
Use this approach if you're not using the WinApp CLI.
Step 1: Create a self-signed certificate
Run the following in an elevated PowerShell prompt. The Subject value must exactly match the Publisher in your appxmanifest.xml:
New-SelfSignedCertificate -Type Custom -KeyUsage DigitalSignature `
-Subject "CN=MyPublisher" `
-CertStoreLocation "Cert:\CurrentUser\My" `
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") `
-FriendlyName "MyApp Dev Cert"
Note the thumbprint in the output — you'll need it in the next steps.
Step 2: Export the certificate to a PFX file
$password = ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText
Export-PfxCertificate -cert "Cert:\CurrentUser\My\<Thumbprint>" `
-FilePath .\devcert.pfx -Password $password
Step 3: Trust the certificate locally
Import-PfxCertificate -CertStoreLocation "Cert:\LocalMachine\TrustedPeople" `
-FilePath .\devcert.pfx -Password $password
Step 4: Sign the package
SignTool sign /fd SHA256 /a /f .\devcert.pfx /p "YourPassword" MyApp.msix
For full SignTool usage, see Sign an app package using SignTool.
Testing: Distribute to testers with a self-signed certificate
To install a self-signed MSIX package on a tester's machine, the certificate must be trusted on that machine first.
Note
On Windows 10 version 2004 and later and Windows 11, sideloading is enabled by default. On earlier Windows 10 versions, testers must enable Sideload apps in Settings > Update & Security > For developers.
Give testers the certificate: Share the .pfx or .cer (public key only) file alongside the .msix package.
Testers run the following in an elevated PowerShell prompt:
# If you shared a .pfx file (testers need the password)
Import-PfxCertificate -CertStoreLocation "Cert:\LocalMachine\TrustedPeople" `
-FilePath .\devcert.pfx -Password (ConvertTo-SecureString "YourPassword" -Force -AsPlainText)
# If you shared a .cer file (public key only, no password needed)
Import-Certificate -CertStoreLocation "Cert:\LocalMachine\TrustedPeople" -FilePath .\devcert.cer
After trusting the certificate, testers can install the .msix by double-clicking it.
Important
Self-signed certificates should only be used for testing. Remove them from tester machines when no longer needed. For broad distribution, use a publicly trusted signing method instead.
Production: Azure Artifact Signing (formerly Trusted Signing)
Applies to: Windows 10 version 1809 and later, Windows 11 (all versions), Windows Server 2016 and later
Azure Artifact Signing is the new name for what was previously called Trusted Signing. The service is identical — only the name changed. You may still see "Trusted Signing" in some tooling (such as the azure/trusted-signing-action GitHub Action and the winget package ID) as those references are being updated over time.
Azure Artifact Signing is the recommended option for production MSIX signing. Reputation is tied to your verified identity rather than a specific certificate, which means your publisher identity builds SmartScreen reputation over time as users install your signed apps. See Sign an MSIX package overview for eligibility requirements and cost information before setting up an account.
Important
Azure Artifact Signing availability: Organizations in the USA, Canada, the European Union, and the United Kingdom can sign up. Individual developers are currently limited to the USA and Canada. If you're an individual developer outside those regions, use an OV code signing certificate from a CA instead (see Production: OV code signing certificate below).
Note
Signing with Azure Artifact Signing does not provide instant SmartScreen trust. Like OV certificates, your apps will initially show a SmartScreen warning until your publisher identity builds sufficient download reputation — typically several weeks and hundreds of clean installs. This is expected behavior for new publishers. For details on how SmartScreen reputation works and what to expect as a new publisher, see SmartScreen reputation for Windows app developers.
Prerequisites
- An Artifact Signing account with identity validation completed and a certificate profile created. See the Artifact Signing quickstart.
- The Trusted Signing Certificate Profile Signer role assigned to the identity used for signing.
Step 1: Install Artifact Signing Client Tools
The Artifact Signing Client Tools include the required dlib plugin, a compatible version of SignTool, and the .NET 8 runtime. Standard SignTool syntax does not work with Artifact Signing without this package.
winget install -e --id Microsoft.Azure.ArtifactSigningClientTools
If WinGet isn't available (for example on a Windows Server build agent), install via PowerShell as administrator:
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri "https://download.microsoft.com/download/70ad2c3b-761f-4aa9-a9de-e7405aa2b4c1/ArtifactSigningClientTools.msi" -OutFile .\ArtifactSigningClientTools.msi
Start-Process msiexec.exe -Wait -ArgumentList '/I ArtifactSigningClientTools.msi /quiet'
Remove-Item .\ArtifactSigningClientTools.msi
Step 2: Create a metadata JSON file
Create a file named metadata.json with your Artifact Signing account details. The endpoint URI must match the Azure region where you created your account (find it in the Azure portal under your Artifact Signing account as Account URI):
{
"Endpoint": "https://<region>.codesigning.azure.net/",
"CodeSigningAccountName": "<your-account-name>",
"CertificateProfileName": "<your-certificate-profile-name>"
}
For the full list of region-specific endpoint URIs, see Signing integrations.
Step 3: Authenticate
Set your Azure credentials as environment variables (use App Registration credentials for CI/CD):
$env:AZURE_CLIENT_ID = "<your-client-id>"
$env:AZURE_TENANT_ID = "<your-tenant-id>"
$env:AZURE_CLIENT_SECRET = "<your-client-secret>"
Alternatively, run az login for interactive local signing.
Step 4: Sign the package
Use the SignTool installed with the Artifact Signing Client Tools. The /dlib flag points to the dlib plugin installed in the previous step:
signtool sign /v /fd SHA256 `
/tr "https://timestamp.acs.microsoft.com" /td SHA256 `
/dlib "C:\Program Files (x86)\Microsoft\ArtifactSigningClientTools\bin\Azure.CodeSigning.Dlib.dll" `
/dmdf .\metadata.json `
MyApp.msix
Tip
Use the /debug flag to get detailed output if signing fails — it shows certificate chain and authentication details.
CI/CD: GitHub Actions
Use the official azure/trusted-signing-action:
- name: Sign MSIX with Azure Artifact Signing
uses: azure/trusted-signing-action@v0
with:
azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
azure-client-id: ${{ secrets.AZURE_CLIENT_ID }}
azure-client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
endpoint: ${{ secrets.AZURE_TRUSTED_SIGNING_ENDPOINT }}
trusted-signing-account-name: ${{ secrets.AZURE_CODE_SIGNING_NAME }}
certificate-profile-name: ${{ secrets.AZURE_CERT_PROFILE_NAME }}
files-folder: ${{ github.workspace }}\output
files-folder-filter: msix
For Azure DevOps, see Set up Azure DevOps with Trusted Signing.
Production: Microsoft Store distribution
Applies to: All supported Windows versions
If you're distributing through the Microsoft Store, you don't need to sign the package yourself — the Store signs it during the submission process. Build your package and submit it via Partner Center. The Store provides a globally trusted signature and handles all certificate management.
Production: OV code signing certificate
Applies to: Windows 10 and later
If Artifact Signing isn't available for your region or situation, you can purchase an OV (Organization Validation) code signing certificate from a certificate authority (CA) such as DigiCert, Sectigo, or GlobalSign. Costs typically range from $300–500/year.
Once you have a PFX file from your CA:
SignTool sign /fd SHA256 /a /f .\cert.pfx /p "YourPassword" `
/tr http://timestamp.digicert.com /td SHA256 `
MyApp.msix
For full signing options, see Sign an app package using SignTool.
Note
OV certificates don't provide instant SmartScreen trust. Reputation builds over time as your signed packages are installed without being flagged. For details, see SmartScreen reputation for Windows app developers.