Ok, I’m confused. Isn’t Microsoft’s Trusted Code Signing supposed to remove the need for a regular code signing certificate?
Hi Jeff,
thank you for your order!
It’s an automated process in SetupBuilder 2025. You don’t need Marks instructions, because our “SignInstall (x86/x64) for SetupBuilder” tool downloads and installs the required runtimes (for Trusted Signing). For eTokens (with and without SafeNet support), we have developed the “eToken Config” tool (written in SetupBuilder 2025) to configure all settings.
We are busy preparing the BETA invitations and updating our servers…
Friedrich
Yes and no . At the moment the service is limited to new customer subscriptions from organizations based in the US and Canada with at least three years of verifiable (tax) history. Organizations from other countries are currently unable to submit new validation requests. New individual developer onboarding has been paused worldwide (including US and Canada).
Trusted Signing is a game changer (IMO). I really hope they’ll continue the service for new subscribers soon.
OV and especially EV certificates will continue to exist and remain available for purchase from major CAs (the Cartel).
Friedrich
For clarity you’ll still need my instructions to work with Azure to get the code signing service setup.
That said my directions for using the trusted signing service with setup builder will be quite different in setup builder 2025 than prior versions
Yes, sorry . I meant you do not need the instruction to setup the Trusted Signing system in SetupBuilder 
. It’s fully automated now. Download the SignInstall tool from within the SetupBuilder 2025 IDE and this will configure everything (on x86 and x64 machines). Point.Click.Sign
It’s a hell of a job to work with Azure to get the code-signing service setup. Of course, the step-by-step instructions from Mark are worth their weight in gold!!!
Sorry for my miscommunication!
Friedrich
I had the Microsoft Trusted Signing working well. I logged on with the credentials the first time, then it automatically used those with subsequent signings.
Then I had to implement signing for a second entity, which meant it could no longer use the single set of stored credentials. Instead, every time I signed something, it prompted me for the applicable user, preventing me from automating things.
After futzing for a while, I finally determined how to resolve it, using a combination of adjustments to the metadata.json and the signing script. My json looks like this:
{
"Endpoint": "https://wcus.codesigning.azure.net/",
"CodeSigningAccountName": "BoxSoftCodeSigningInst",
"CertificateProfileName": "BoxSoftCodeSigningCert",
"CorrelationId": "",
"ExcludeCredentials": [
"WorkloadIdentityCredential",
"ManagedIdentityCredential",
"VisualStudioCredential",
"VisualStudioCodeCredential",
"AzureCliCredential",
"AzurePowerShellCredential",
"AzureDeveloperCliCredential"
],
"_NotExcludedAbove_": [
"EnvironmentCredential",
"SharedTokenCacheCredential",
"InteractiveBrowserCredential"
]
}
Of course, for the other signing entity, I have another metadata.json with different Account and Profile entries, but the rest is the same.
Then in the top of CallCodeSign.cmd, I set two additional environment variables. Again, these are different for the other signing entity.
Set AZURE_TENANT_ID=d56f00a3-your-id-here-fb023a4e9e82
Set [email protected]
Hopefully, this saves you some time with this rather quirky service. 
2 Likes
Received an email blast today warning that the signing client needs to be updated by July 28.
Trusted Signing: Upgrade tooling by 28 July 2025 to maintain support and functionality
You’re receiving this notification because you’re associated with one or more Azure subscriptions that use Trusted Signing.
Starting 28 July 2025, versions older than Microsoft.Trusted.Signing.Client 1.0.52 will no longer be supported.
Recommended action
Please upgrade your Trusted Signing tooling to the latest version before 28 July 2025. You can download the latest version here.
If you have additional questions, please reach out to us through the support channels.
I tried updating the Microsoft.TrustedSigning.Client to 1.0.86, but get this error when attempting to code-sign:
Windows Data Protection API (DPAPI) is not supported on this platform
which led me to this link: Exception: "Windows Data Protection API (DPAPI) is not supported on this platform." using Microsoft.Trusted.Signing.Client 1.0.76 - Microsoft Q&A
I’ve got version 1.0.60 running that I installed last November, so I’m above the new minimum requirement. But wonder whether others have tried upgrading and had any issue?
If I swap the System.Security.Cryptography.ProtectedData.dll from my old version, the new version works… but requires a web sign-in to my Azure account each time.
Maybe Friedrich has a handle on this already, or somebody else.
Hi Jane,
I already have an internal SetupBuilder 2025 redistributable for Trusted Signing client version 1.0.86. It code-signs without issues. But… there is always a but in life… I must authenticate myself for every code-signing action now. For instance, when signing three files from within a project, along with the uninstaller and installer, I am required to authenticate in the browser five times!
I hope this is an unintended issue (bug!) with the client rather than a deliberate feature to enhance security.
Friedrich
When rolling back to client 1.0.60 then no additional authentication is required. After the update to 1.0.86 I must authenticate every code-sign action.
Perhaps 1.0.86 already checks the status of Azure multi-factor authentication?
IMO, I have enabled it, but I am not 100% sure yet.
Friedrich
1 Like
From a Microsoft Support Forum message:
“I encountered this same error today with 1.0.86. I did not try exchanging DLLs. I was using 1.0.60 and it still works, but 1.0.86 does not. Has this been resolved or am I encountering some other issue?”
I think 1.0.86 still has issues.
And IMO, this multiple-authentication issue started with Trusted Signing client 1.0.76.
Friedrich
1 Like
Thanks for the update, Friedrich.
Does 1.0.86 work for you without having to switch to an earlier version of the System.Security.Cryptography.ProtectedData.dll?
As for MFA, I just checked the page with my admin Azure account and get the “in app purchase” screen 
Would be interesting to know if this is a way to push people into the more expensive subscription.
Hi Jane,
yes, 1.0.86 does work for me without having to switch to an earlier version of the System.Security.Cryptography.ProtectedData.dll file. I “only” have the multi-authentication issue which itself is a showstopper.
BTW, I see the same “Get Free Premium Trial to use this feature” offer… 
Friedrich
I wonder why my DLL throws that error.
The old one (that works) has the same file version as the new one that doesn’t work.
Code-signing dates match the modified dates shown on the Properties tabs for both.
With the 25KB DLL, as I said the 1.0.86 works but with the authentication issue each time.
I’m sure YOU will figure it out, Friedrich! 
I’m going to stick with 1.0.60 until they pry it out of my cold, dead hands!
This is the error the bad DLL throws.
I’ve been dragging my feet on this
has anyone tried 1.0.92, which is what is currently showing at --v
Still the same problem with client 1.0.92. Multiple authentication requests.
Rollback to 1.0.60.
Friedrich
1 Like
The new 1.0.95 seems to fix this issue. I’ll make a new Trusted Signing runtime with v1.0.95 available in SB2025 BETA-3.
3 Likes
Many thanks to Rick Martin and Friedrich for pushing this with Microsoft!
I updated to 1.0.95. It asked for a browser sign-in once. Then smooth sailing since!
3 Likes