Trusted Signing FAQ

The Trusted Signing service supports all versions of Windows that support the general user-mode code integrity (UMCI) security policy.

Support for signed binaries was added in the July 2021 Certificate Trust List (CTL) update for Windows. In a typical scenario, when an end-entity certificate from a chain is encountered on a computer, the system retrieves the root certificate authority (CA) certificate and adds it to the trust root store.

For more information about Windows support for Trusted Signing, see Trusted Signing Program Windows Support.

Ask your Microsoft Entra admin to approve your request for access. For more information about permissions, see these articles:

• Overview of consent and permissions
• Configure the admin consent workflow
• Review permissions granted to applications

To register the Microsoft.CodeSigning app, go to the subscription Resource providers pane as shown in this example:

• Currently, an organization that has a year-founded date of less than three years can't be onboarded, and identity validation fails.
• If your organization has a year-founded date of more than three years, ensure that you didn't miss an email verification link that was sent to the primary email address you entered when you created your identity validation request. The link expires after seven days. If you overlooked the email or if you didn't select the link in the email within seven days, create a new identity validation request.
• If identity validation fails, but not because of a missed email verification, the Microsoft validation team wasn't able to make a determination about your request based on the information that you provided. Even if you provide more documentation when we request it, if we can't validate the information, we can't onboard you to Trusted Signing. In this scenario, we recommend that you delete your Trusted Signing account so that you aren't billed for unused resources.

Be sure to use a government issued ID with address on it, in order to successfully go through the process.

Verify you are using the same email address to access the Identity Validation link, that you entered in the Identity Validation request.

Follow the steps to present your existing VID for Trusted Signing. For this process, VIDs must include your address in addition to your name. Ensure that your VIDs have your address on them before using them for Trusted Signing.

For questions about identity validation in Trusted Signing, contact us by using Microsoft Q&A (use the tag Azure Trusted Signing) or Stack Overflow (use the tag trusted-signing). Azure support doesn't resolve identity validation issues for Trusted Signing.

For pricing information, see Trusted Signing pricing.

You can create a support ticket in the Azure portal to get Azure support. Also, you can post a question or search for related questions on Microsoft Q&A (use the tag Azure Trusted Signing) or Stack Overflow (use the tag trusted-signing).

For Windows app MSIX packages, follow the guidance in MSIX persistent identity.

No. If you delete a certificate profile, any certificates that were previously issued or used under that profile remain valid. The certificates aren't revoked.

No, you can't use a custom Common Name (CN) or a custom Organization (O) with Trusted Signing. Currently, the Trusted Signing service doesn't support customization. Also, keep in mind that per the Certification Authority Browser Forum (CA/Browser Forum) in the Code Signing Baseline Requirements (CSBRs) for publicly trusted code signing certificates, CN values must always be the legal entity's validated name (for example, Microsoft Corporation).

If the New identity validation button in the Azure portal is inactive and you can't select it, you don't have the Trusted Signing Identity Verifier role assigned to your account. To assign yourself the role, complete the steps in Assign roles in Trusted Signing.

If you don't renew identity validation before the expiration date, certificate renewal stops. All signing processes that are associated with those specific certificate profiles stops. To continue signing by using the Trusted Signing service, create another identity validation and associate it with the relevant certificate profiles. We send multiple reminders starting at 60 days before an identity validation's expiration date to help you begin the process of renewing your identity validation.

You can sign all file types that SignTool supports.

FIPS 140-2 Level 3 (mHSMs).

For information about the Early Launch Antimalware (ELAM) driver configuration for protecting antimalware user-mode services, see the following guidance:

"Beginning in 2022, all user mode anti-malware service binaries must be signed by Microsoft's Trusted Signing signing service. The Trusted Signing issued Authenticode certificate for signing anti-malware binaries is updated every 30 days for security. To prevent the need to update the ELAM driver every time the certificate is updated, we recommend that anti-malware vendors include the Trusted Signing PCA certificate TBS hash in the CertHash portion of the ELAM driver resource file info. Additionally, the anti-malware vendor must include their unique Trusted Signing EKU identity in the EKU field of the resource file info. The EKU identity will begin with the prefix 1.3.6.1.4.1.311.97.*."

For the Microsoft ID Verified Code Signing PCA 2021 certificate, see the Microsoft PKI Services repository.

• If an /INTEGRITYCHECK flag is set, the user's signature isn't validated at runtime and it isn't run with /INTEGRITYCHECK.
• To check whether the Trusted Signing update is installed, we recommend that you check against one of your packaged /INTEGRITYCHECK-linked DLLs. You can use a test version. This way, you can complete your check and determine the availability of our /INTEGRITYCHECK-linked binaries outside the platform.

Currently, we don't extend cross-signed certificates. You must sign by using the Trusted Signing service.

Signing with the Partner Center is kernel-mode signing (no change with the introduction of Trusted Signing). Sign your user-mode binaries by using Trusted Signing. For your apps that interact with the Windows Security Center (WSC) service, you must include the Code Integrity bit (/INTEGRITYCHECK). Without the Trusted Signing signature, you can't register with the WSC, and Windows Defender runs in parallel.

The Authenticode certificate that's used for signing with the profile is never given to you. All certificates are securely stored within the service and are accessible only at the time of signing. The public certificate is always included in any binary that the service signs.

Run the following command: curl http://timestamp.acs.microsoft.com. If status code 200 is returned, the time stamp service is healthy and running.

If you get an internal error, check that the CN name that you used matches the certificate name. Verify the package name, and copy the complete value for the subject from the Azure portal to the manifest file during signing.

If the signature doesn't appear in the digital signature property, run this command: .\signtool.exe verify /v /debug /pa fileName. Not all file types include the Signature tab in Properties.

1. Create a user-assigned managed identity.
2. Add the user-assigned managed identity to the VM:
   1. Select the VM.
   2. On the left menu, select Identity, and then select User assigned.
   3. Select Add to add the managed identity.
3. In the resource group (or subscription) that has the Trusted Signing Certificate Profile Signer role, add the user-assigned managed identity to the role. To assign the correct role, go to Access control (IAM) > Role assignments.

• Because Google Cloud Platform (GCP) doesn't have an Azure managed identity resource by default, set up an environment credential. Use the EnvironmentCredential class to set up the credential. We recommend that you use these variables:

  • AZURE_TENANT_ID for the Microsoft Entra tenant (directory) ID.
  • AZURE_CLIENT_ID for the client (application) ID of an app registration in the tenant.
  • AZURE_CLIENT_SECRET for a client secret that was generated for the app registration.

• To create a client ID and secret, follow the guidance in Create a service principal.

• After you create the client ID and secret, go to the resource group (or subscription) that has the Trusted Signing Certificate Profile Signer role, and add this app to the role.

If a certificate is misused or abused per the service Terms of Use, Trusted Signing suspends the account or revokes a signing certificate or both. In this scenario, we engage with you directly and follow the guidelines in the CA/Browser Forum CSBRs.

Currently, Trusted Signing resources can't be migrated across subscriptions or tenants or resource groups or resources. If you want to make any change to your tenant ID or subscription ID, you must create all your Trusted Signing resources again.

No, Trusted Signing doesn't issue Extended Validation (EV) certificates. We don't plan to issue EV certificates in the future.

Looping multiple times is expected in MSIX signing because each application file and manifest file inside the package is signed.

To review cost information, in the Azure portal, go to your subscription overview. On the left menu, select Cost Management. For more information, see Cost Management.

To review billing information, go to your subscription overview. On the left menu, select Billing. For more information, see Billing.

The pricing is not calculated on a pro rata basis. The invoice is generated with the full amount for the SKU that you selected when you created the account, regardless of when you begin to use the service after you create your account.

To unenroll from Trusted Signing, delete your Trusted Signing account. Deleting the account also deletes the associated identity validation and certificate profiles. This stops certificate renewal, effectively halting the signing process that's associated with those specific certificate profiles. However, deleting the account doesn't affect the certificates that were already used to sign your files.