Azure Trusted Signing vs a Code Signing Certificate: Which to Use?

The two options at a glance

Azure Trusted Signing and a CA code signing certificate both end at the same place — a signed, publicly trusted Windows file — but they get there differently. Trusted Signing is a Microsoft-run subscription that issues short-lived certificates on demand and only signs Windows artifacts, open to eligible entities in a set list of countries. A CA certificate is a flat-fee credential you own outright, signs across platforms, and is available almost anywhere. The table lines up the differences that actually decide it.

What is Azure Trusted Signing?

Azure Trusted Signing is Microsoft's fully managed code signing service, renamed Azure Artifact Signing in 2026 (and briefly called Azure Code Signing before that). Instead of selling you a certificate, it validates your identity once and then issues short-lived certificates on demand from Microsoft's own certificate authority, which Windows already trusts. You never hold a long-lived key: the service renews the signing certificate daily, each one valid for roughly 72 hours, and you sign through it using standard tools like SignTool.

The appeal is that it removes the two things developers find fiddly about traditional code signing: buying and guarding a hardware token, and managing key storage. Microsoft handles the key protection and the certificate lifecycle, and billing runs through your Azure subscription. Because the certificates come from a publicly trusted Microsoft CA, signed files are recognized on up-to-date Windows without any extra trust configuration on the user's machine.

What a CA code signing certificate is

A CA code signing certificate is a credential a certificate authority issues to you after validating your identity, and it stamps your verified name onto everything you sign. You own it for its validity — up to 460 days under the current rules — and the private key lives on compliant hardware or in a cloud signing service such as Certum's SimplySign, which removes the physical token while keeping the key protected. It isn't tied to any one cloud platform or operating system: the same certificate signs Windows executables, installers, and Java JARs alike.

This is the model most software publishers have used for years, and it comes in two validation levels — standard (OV) and EV. The distinction between them, and when EV's extra vetting is actually worth it, is covered in our EV vs OV code signing guide. The point that matters against Trusted Signing is ownership: the certificate is yours to use with any tool, in any pipeline, for its whole validity.

How the two models differ

The real split is rent versus own. Trusted Signing rents you signing capacity inside Microsoft's ecosystem: your identity is validated once, but the certificates are Microsoft's, short-lived, and only usable through the service to sign Windows files. A CA certificate gives you a durable credential you control, carrying your identity, usable with any signing tool on any platform. Everything else — cost, eligibility, what you can sign — flows from that one difference.

That ownership gap has practical consequences. With Trusted Signing, if you leave Azure or lose eligibility, your ability to sign stops; there's no certificate to export or carry to another provider. With a CA certificate, the credential travels with you — the same one works on a self-hosted CI runner, a developer's machine, or a cloud pipeline, which is why remote and cross-tool teams often prefer it. Both approaches still depend on timestamping so signatures outlive the certificate that made them.

What each one costs

As of July 2026, Azure Trusted Signing costs $9.99 a month on the Basic tier (up to 5,000 signatures) and $99.99 a month on Premium (up to 100,000 signatures), with overage at $0.005 per signature — a usage-based subscription billed through Azure. A CA code signing certificate is a flat annual fee with no per-signature charge: My-SSL's Certum-issued standard (OV) certificate is $99 a year and EV is $299 a year. Basic Trusted Signing works out to roughly $120 a year, so for Windows-only work the running costs sit close together.

Because the headline numbers are similar, cost alone rarely decides this. The subscription shape favors low, steady signing volumes inside Azure; the flat certificate fee favors high-volume signing, cross-platform output, or anyone who dislikes a per-signature meter. If your signing happens in a pipeline, weigh both against how you'd wire them in — our guide to code signing in CI/CD covers connecting either model to an automated build without exposing a key.

Who can actually use each

Eligibility is where the two diverge most sharply. As of 2026, Microsoft offers Trusted Signing to businesses in the United States, Canada, the EU, and the UK, and has opened sign-up to self-employed individuals — dropping the earlier public-preview rule that a company needed three or more years of trading history. It's expanding, but it's still a defined list, and you need an Azure subscription and to pass Microsoft's identity validation. If your organization sits outside those regions, the door is closed for now.

A certificate authority has no such geographic gate. CAs validate and issue code signing certificates to organizations and individuals worldwide, which is why a CA certificate is the default answer for anyone outside Microsoft's current eligibility — or anyone who simply doesn't want their signing capability bound to an Azure account. Because eligibility rules change, confirm the current list with Microsoft before committing if you're near a boundary.

What you can sign with each

Trusted Signing covers Windows Authenticode artifacts and nothing else: .exe, .dll, .msi, .msix, .appx, .cab, .sys, .cat, and PowerShell scripts among them — the same set SignTool handles. That's a complete answer if everything you ship is a Windows executable, installer, or package. It is not an answer for a Java JAR, which uses a different signature format entirely, or for any other non-Windows artifact. Microsoft's service simply doesn't produce those signatures.

A CA certificate spans both worlds. The same credential signs Windows PE files and installers through SignTool and Java archives through jarsigner, so a team shipping a Windows app and a Java component can cover both with one certificate. If JARs are part of your build, the mechanics are in our guide to signing a JAR with jarsigner. Whichever model you pick, one thing is identical: neither guarantees an instant Microsoft SmartScreen pass. Reputation builds from download telemetry over time, a reality we set out in the SmartScreen publisher reputation guide.

Which should you choose?

Choose Azure Trusted Signing if you ship only Windows software, your organization is on Microsoft's eligibility list, you already work in Azure, and renting managed signing suits you better than owning a certificate. Choose a CA code signing certificate in every other case — cross-platform output, an entity outside the eligible regions, high-volume signing, or a preference for a portable credential you control. The decision path below routes most teams in a couple of questions.

Here's where My-SSL fits the common situations:

FAQ