Windows Code Signing CI Costs by Monthly Signing Volume — What Real Vendor Binaries Reveal in 2026

Earlier posts on this blog (“Distributing Windows Desktop Apps Safely from a Japanese Entity” and “Obtaining OV/EV Code Signing Certificates from Japan”) covered distribution paths and certificate eligibility. What remained unaddressed was the operational side: how much does CI signing actually cost per month, and how are established vendors really wired up? This post continues those two, laying out a per-volume CI cost comparison and reading operational patterns off real vendor binaries.

Some ground rules first. Since the CA/Browser Forum rule change in June 2023, the private key for any code signing certificate must live in FIPS 140-2 Level 2 or higher hardware (a physical USB token or a cloud HSM). To sign on a hosted runner such as GitHub Actions, that means a cloud signing service or a self-managed cloud HSM like Azure Key Vault. Numbers below assume 1 USD = 150 JPY for conversion. Because we assume no kernel-mode driver signing, and because SmartScreen no longer grants EV a first-launch bypass after the 2024 change, OV certificates are treated as sufficient.

The Realistic CI Options

Start by lining up the options a Japanese entity, or an individual based in Japan, can actually use.

SSL.com Certificate + eSigner (Cloud Signing)

SSL.com sells directly to Japan in USD with English-language onboarding, and provides the official SSLcom/esigner-codesign GitHub Action. On top of the certificate fee (OV from $129/year, EV from $349/year) you pay a monthly eSigner tier that meters signing operations.

Tiers can be changed from the dashboard at any time (upgrade is prorated immediately, downgrade takes effect next month) and unused signings roll over. New accounts also get 30 days of unlimited-signing trial, which is the right window for measuring your actual monthly volume before committing.

DigiCert Certificate + KeyLocker (Cloud Signing)

DigiCert KeyLocker is easiest to buy in Japan through a local reseller, which lets you settle in JPY with an invoice. A reference reseller (Esrogical) sells OV at 89,000 JPY/year including the KeyLocker service, and 1,000 signings per certificate-year are bundled in. That 1,000 is an annual hard limit, not a monthly quota, and going over will fail the CI job until you top up. Extra capacity comes as 1,000-signing packs (roughly $170 ≒ 25,500 JPY from overseas resellers). GitHub Actions integration is done by calling smctl from your workflow.

Azure Artifact Signing (Formerly Trusted Signing, Not Available in Japan)

Azure Artifact Signing, which Microsoft renamed from Trusted Signing in 2026, is Microsoft’s own cloud signing service, priced from $9.99/month with effectively unlimited signings and clean CI integration. Its geographic footprint is limited, and Japanese entities and residents cannot use it as of July 2026. If you have a US legal entity in the group, it belongs on the shortlist; if not, it stays a reference data point.

GlobalSign or DigiCert + Azure Key Vault Premium (Self-Managed Cloud HSM)

Ditch the .pfx and hold your own HSM. Store the CA-issued key in Azure Key Vault Premium and sign from CI with AzureSignTool. GlobalSign direct-from-US is about $434/year for OV (≒ 65,000 JPY), and GMO GlobalSign’s Japan-facing arm offers an HSM-stored variant that pairs with Azure Key Vault (quote required, JPY invoicing available).

On the Azure Key Vault side, per the Azure price list as of July 2026, an HSM-protected key costs about $5/month per key, and signing operations run at $0.15 per 10,000 (essentially free at any realistic volume). Annualized, HSM alone is about $60/year ≒ 9,000 JPY. Certificate 65,000 JPY + HSM 9,000 JPY gives you around 74,000 JPY/year with practically unlimited signings.

Azure Key Vault only integrates with DigiCert and GlobalSign as of July 2026. Sectigo is not on that list.

AWS CloudHSM (Not a Real Option)

For completeness: AWS CloudHSM hsm2m.medium runs about $1.60/hour in the Tokyo region as of July 2026 = $1,168/month single, $2,336/month in HA. That is 210,000 to 420,000 JPY per year, complete overkill as a code-signing-only vehicle. Skip it unless you are already operating CloudHSM for other reasons.

Annual Cost by Monthly Signing Volume

The table below rolls the same configurations up as annual totals (excluding tax, 1 USD = 150 JPY) across representative monthly volumes. Numbers are calculated from list prices as of July 2026 and will move with your quote and the exchange rate.

The break-even shape is:

• Up to 20 signings a month, SSL.com eSigner is the cheapest and has virtually no setup overhead
• Above 50 to 100 signings a month, GlobalSign + Azure Key Vault takes over and stays flat no matter how much you sign afterwards
• The middle band (30 to 100 a month) is where DigiCert KeyLocker remains competitive

If your release cadence is spiky, use SSL.com eSigner while you still can (tiers move on-demand) and switch to the Azure Key Vault build once you clearly cross 50 monthly signings on a sustained basis.

What Major Vendors Actually Ship

Reading price sheets does not build operational intuition. So instead, let us osslsigncode verify the real installers of well-known apps from a macOS box, and infer the service from the Issuer name.

Four things fall out of that:

1. OpenAI’s answer: commit fully to Microsoft Store distribution and reduce external CA cost to zero. The tradeoff is Store fees and review, but you delete certificate management from your CI on the way in
2. Established vendors’ answer: Anthropic and Adobe scale into a DigiCert EV enterprise contract. There is no visible trace of them running on per-signing metered services
3. The newcomer’s answer: for a US-eligible outfit, Azure Artifact Signing at $9.99/month with a 3-day disposable certificate simply works. Unlimited signings at that price point lets Cursor treat certificates as ephemeral
4. The “fix the entry, refresh the payload” principle: Adobe is the extreme example (Creative Cloud’s entry installer is still the one signed in 2018 and it works fine). With an RFC 3161 timestamp, you can prove the certificate was valid at signing time and the signature stays valid forever, even after the certificate expires

Even at Anthropic or Adobe scale, per-build signing is scoped to just the main .exe and the updater, not every artifact the CI touches. Before you plan around “1,000 signings a month,” redesign what you actually need to sign per release.

Evaluating the “Unsigned Auto-Updates” Shortcut

The urge to save money by signing only the outer installer and leaving the app body and auto-updates unsigned looks arithmetically clean but is not a real option. Three reasons.

1. AV and EDR heuristics get louder: an unsigned .exe that changes frequently is the exact signature Windows Defender and EDR vendors look for. Expect quarantines on user machines
2. You have to reinvent tamper protection: auto-update frameworks like electron-updater verify that updates share the same publisher signature as the currently installed app. Skipping signatures means either dropping that check or building your own verification, which cancels the savings on the engineering side
3. It will not start in enterprise environments: any org running AppLocker or WDAC with signed-only policies will refuse to launch the app entirely

The realistic path is the opposite: keep the outer installer signed and long-lived, and per release, sign only the small set (main .exe, updater, a handful of native modules) that actually change. Anthropic and Adobe do exactly this, and it is how you keep CI signing volume down without giving up on trust.

Switching Vendors Mid-Journey

“Start cheap, switch when volume warrants” is a legitimate strategy, both technically and contractually. A few points to keep in mind.

• Binaries you already shipped stay verifiable after the old certificate expires as long as they carry an RFC 3161 timestamp. User impact of the switch is zero
• SmartScreen reputation is bound to the certificate, not the publisher name, and starts over on a new certificate. You lose the trust you accumulated
• Mitigation: do not stack a large release right after the swap, and run the old and new certificates in parallel for a warm-up period before cutting over

Moving from SSL.com eSigner to DigiCert KeyLocker, or from KeyLocker to an Azure Key Vault setup, is done in the field regularly. The SmartScreen warm-up is the only step you cannot skip.

Verifying Other Vendors Yourself

Whether you are evaluating a new provider or debugging your own release, the verification tools are cheap and cross-platform.

On macOS or Linux, use osslsigncode.

brew install osslsigncode
osslsigncode verify -in Something-Setup.exe

On Windows, PowerShell exposes Get-AuthenticodeSignature.

Get-AuthenticodeSignature .\Something-Setup.exe | Format-List

If you do not want to download the file at all, VirusTotal surfaces the Issuer and validity dates under the “Details” tab, “Signature info” section. The Issuer name pins down the service almost every time.

• Microsoft ID Verified CS EOC CA 03 → Azure Artifact Signing (formerly Trusted Signing)
• SSL.com Code Signing CA → SSL.com
• DigiCert Trusted G4 Code Signing RSA4096 → DigiCert
• GlobalSign GCC R45 CodeSigning CA → GlobalSign

Bake this verification into your release CI too. Catching a broken chain or an expired certificate before shipping is much cheaper than the incident that follows.

Interim Recommendations by Situation

Putting it all together, the recommendation matrix for a Japanese entity or Japan-based individual as of July 2026 looks like this.

“Start on SSL.com, migrate to GlobalSign + Azure Key Vault once monthly signings stabilize above 50” is the lowest-risk arc for a Japanese entity.

That’s all from breaking down CI code signing costs by monthly volume and reading operational patterns off real 2026 vendor binaries, from the Gemba.

References

• Microsoft Defender SmartScreen (Microsoft Learn)
• CA/Browser Forum: Code Signing Working Group
• SSL.com eSigner
• DigiCert KeyLocker
• Azure Artifact Signing (Microsoft Learn)
• Azure Key Vault: HSM-protected keys
• GMO GlobalSign: HSM-supported code signing
• AzureSignTool (GitHub)
• osslsigncode (GitHub)
• RFC 3161: Time-Stamp Protocol