Windows Code Signing
For the complete release checklist, see Windows Production Requirements. For update hosting and the files to publish after each build, see Windows App Updates.
A code signature identifies the publisher of your Windows softphone and lets Windows check that the signed files have not been modified. Production builds distributed to customers should use a publicly trusted signing identity.
In App Store > Windows > Signing method, choose SessionTalk signing for test whitelabel builds or Customer Azure signing for production builds using your company’s publisher identity. SessionTalk signing is the default.
Test and production signing
SessionTalk signing uses our Public Trust certificate and displays SessionTalk Ltd as the publisher. Testers do not need to install a self-signed test certificate. The portal no longer offers test-certificate generation, PFX upload or a certificate password field.
For public distribution under your own company name, select Customer Azure signing and configure your own verified Public Trust profile. Microsoft manages the signing certificate and private key; no PFX is required.
Recommended service: Azure Artifact Signing
Azure Artifact Signing, formerly Trusted Signing, provides managed code signing. Microsoft manages the signing certificates and private keys. Your organisation must complete identity validation and create a Public Trust certificate profile.
The certificate identifies your verified publisher. The app’s product name and logo can be different from the legal company name that Windows displays as its publisher.
Follow Microsoft’s setup guide for current eligibility, supported regions and account requirements.
1. Prepare your Azure account
You will need an Azure subscription, permission to create signing resources, and an authorised representative who can complete your organisation’s identity validation.
Create an Artifact Signing account in a supported region. Complete identity validation using your organisation’s correct legal details, then create a Public Trust certificate profile for that verified identity. A test or private-trust profile does not provide the same public-distribution trust.
2. Authorise signing for your project
Ask your Azure administrator to:
- Create a Microsoft Entra application for signing your app.
- Open your project’s App Store → Windows section and select Customer Azure signing.
- In the Entra application, open Certificates & secrets → Federated credentials → Add credential and select Other issuer. Copy the Issuer, Audience and full Subject displayed in the portal into the credential. Use the values shown for your project exactly.
- Grant the application’s service principal the Artifact Signing Certificate Profile Signer role, scoped to the certificate profile you created.
This authorises signing without sharing your Azure login password or exporting a private key. Use the federation values from the project you are configuring; values from another project will not authorise this one.
3. Enter the portal connection details
Open your whitelabel desktop project and go to App Store → Windows → Signing method → Customer Azure signing. Fill in all seven fields below using your own Azure resources.
| Portal field | What to enter and where to find it |
|---|---|
| Azure Tenant ID | Open Microsoft Entra ID → App registrations → your signing application → Overview. Copy Directory (tenant) ID. This identifies the directory containing your signing application. |
| Application / Client ID | On the same application Overview page, copy Application (client) ID. Use the application you configured with the federated credential in step 2. Do not use its Object ID. |
| Azure Subscription ID | Open your Artifact Signing account → Overview and copy Subscription ID. Enter the ID, not the subscription’s display name, such as Pay-As-You-Go. |
| Signing endpoint | On the signing account’s Overview page, copy Account URI. It must match the account’s Azure region. For example, North Europe uses https://neu.codesigning.azure.net/. |
| Signing account name | Enter the name of your Artifact Signing account, shown at the top of its Azure page. Use the account name alone, not its resource group, Account URI or full Azure resource ID. |
| Certificate profile name | In your signing account, open Certificate profile and copy the name of your approved Public Trust profile. Use the profile name, not the identity validation ID. |
| Publisher / certificate subject | Open that certificate profile and copy its complete certificate subject. Include every component shown, preserving its spelling and order. This is the verified legal publisher identity that the build checks against the signing certificate. |
Microsoft’s guides cover finding your application and tenant IDs and signing accounts, regional endpoints and certificate profiles .
For example, a certificate subject might look like:
CN=Example Communications Ltd, O=Example Communications Ltd, L=London, S=Greater London, C=GBThis is an illustration only. Copy your own profile’s full subject rather than constructing it from your app name or copying the example. Publisher / certificate subject is different from the federation Subject used in step 2: one identifies your certificate’s publisher; the other authorises this project’s build to access Azure.
4. Check access and save
The Issuer, Audience and federation Subject shown beneath the Azure fields are values to copy from the portal into Microsoft Entra. They are provided for your project; you do not replace them with your company name or enter them into the seven connection fields above. No client secret, PFX file or certificate password is required.
Before saving, check that the application identified by Application / Client ID has both the project’s federated credential and the Artifact Signing Certificate Profile Signer role for the selected profile. When assigning that role, select your application’s service principal as the member.
These identifiers alone do not grant access: the federated identity and profile permissions must also be configured. Save the settings and complete the normal project approval/publishing flow before building. Your build checks the signing connection and verifies the resulting signatures. There is no separate Test connection button. A failed Azure signing attempt stops the build; it does not fall back to a test certificate.
Download and publish your release
After the build completes, download the Windows ZIP from the portal.
The Windows customer ZIP contains exactly three files:
<product>-x64.msiwinconfig.xmlwinconfig.xml.signature
Windows code signing and the update-feed signature serve different purposes. The update signing keys configured for your project remain necessary for the signed update feed; an Azure signing profile does not replace them.
A valid signature does not guarantee that every new build immediately avoids SmartScreen warnings. See Microsoft’s signing guidance .
Costs
As checked on 10 September 2026, Microsoft publishes these USD prices:
| Azure tier | Monthly price | Included signatures per month |
|---|---|---|
| Basic | $9.99 | 5,000 |
| Premium | $99.99 | 100,000 |
Additional signatures cost $0.005 each. Basic is normally sufficient for a whitelabel app’s release builds. Signing usage is based on files signed, not the number of customers downloading the app. Provider charges are separate from SessionCloud and build charges. Confirm current pricing, currency and taxes on Microsoft’s pricing page .
Before your first production release
Confirm that your publisher identity is correct, your signing connection is authorised, and your update URL and update signing keys are configured. Test installation and updates on a separate Windows computer. Keep using the same application identity and MSI upgrade code for later releases so Windows recognises them as updates to the same app.