Distributing a Windows Desktop App Safely from Japan — Code Signing and the SmartScreen Reality (2026)

When you try to hand a desktop app to Windows users, you always hit one wall at the very end. Run an unsigned installer and Windows throws up the blue Microsoft Defender SmartScreen screen, stopping the user once with a “publisher unknown” warning. Antivirus may quarantine the executable. The app you worked hard to build fails to earn trust at the final step of distribution.

This post lays out the practical steps to clear that wall from a Japanese company, as of June 2026. The target is the common case: a regular user-mode desktop app with no kernel driver, distributed to a broad or unspecified set of Windows users. We state the conclusion first, then work through the reasoning behind it (certificate types, recent rule changes, and the traps).

The conclusion narrows to two

The answer to this problem collapses, in practice, to two configurations. Which one you pick is mostly decided by whether distribution from your own site is mandatory, and whether a Microsoft Store listing is acceptable.

Microsoft itself, in its distribution-path guide, recommends the Store for broad distribution and states that off-Store distribution requires building SmartScreen reputation separately. So if avoiding the first-run warning matters most, it is Store MSIX; if loading onto your existing build pipeline matters most, it is a self-distributed signed installer.

One premise needs underlining here. The old wisdom that an EV certificate silences SmartScreen the instant you sign no longer holds in 2026. The next section explains why.

Why signing does not mean zero warnings

EV (Extended Validation) code-signing certificates once carried a perk: SmartScreen evaluated them positively from the moment you signed. The reason so many guides said “buy EV for public distribution” was this instant-bypass effect.

That behavior disappeared in 2024. Microsoft’s official documentation now states that EV certificates no longer bypass SmartScreen, and that paying the EV premium solely to avoid SmartScreen is no longer justified. Today, regardless of EV or OV, a new off-Store binary must accumulate file hash reputation and publisher reputation over time and through actual download history.

What this means is that signing is a necessary condition but not a sufficient one. An unsigned binary is unfit for public distribution, but signing does not make the first-run warning vanish. SmartScreen reputation only accumulates as you keep signing under the same publisher and stack up clean download history.

So the practical difference between EV and OV now reduces to these points:

• EV is required for Windows kernel-mode driver signing, which is irrelevant to a typical user-mode app
• EV displays the publisher as a “verified publisher.” It has branding value but no warning-suppression effect
• EV has stricter vetting, slower issuance, and higher cost

Unless you have driver signing or strict procurement/audit requirements, OV (standard code signing) is enough in 2026. If the SmartScreen effect is identical, OV wins on cost-effectiveness by being cheaper and faster to issue.

The trap: Azure Trusted Signing excludes Japanese companies

Research the cost of code signing and one option always catches the eye: Microsoft’s own cloud signing service, Azure Trusted Signing (now renamed Azure Artifact Signing; formerly Trusted Signing). At 9.99 USD per month it is strikingly cheap, with FIPS 140-2 Level 3 HSMs, short-lived certificates issued daily, and a GitHub Actions integration. Technically it looks flawless.

But here lies the biggest trap. Microsoft Learn’s official FAQ states that Public Trust certificates are offered to “organizations in the USA, Canada, the European Union, and the United Kingdom, and individual developers in the USA and Canada,” and Japan is not on that list. In other words, Japanese organizations cannot use Azure Trusted Signing. Since this cheap cloud-signing shortcut is closed to Japanese companies, this post leaves it out of the recommendations.

That fact decides the options for a Japanese company. With cheap cloud signing unavailable, obtaining an OV/EV certificate from a traditional CA is the only realistic path for now. Microsoft has stated it will expand eligible regions, so confirm the current country list before you commit. If Japan is added, it is worth considering a full migration to this 9.99-USD-per-month service.

Choosing a code-signing certificate

OV vs EV, and the hardware-key-storage mandate

Before choosing a certificate, there is one more rule change to absorb. Under the CA/Browser Forum Code Signing Baseline Requirements, since June 2023 both OV and EV require the private key to be generated and stored on hardware meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+ or higher (HSM, USB token, or cloud HSM). The key must be non-exportable.

This has a major practical implication: the old automated-signing approach of exporting the private key to a .pfx file and dropping it on the CI is no longer possible. GlobalSign’s own guidance states that certificates must be installed directly onto a FIPS-compliant device and can no longer be downloaded as .pfx. The former “OV is cheap and easy with a software key” advantage is gone. Both OV and EV now assume hardware storage.

Comparing CAs for a Japanese company

The most workable candidate for a Japanese company is GlobalSign (its Japanese joint venture, GMO GlobalSign, offers a Japanese-language application flow, yen-denominated pricing, published shortest issuance times, and guidance on the English legal name tailored to Japanese entities). The ability to procure in yen with deferred payment and a qualified invoice, as a domestic entity, pays off in everyday operations that include accounting.

If full CI/CD automation is the top priority, cloud HSM signing, which needs no physical token insertion, fits best. SSL.com’s eSigner is fully cloud-based and needs no self-hosted HSM; DigiCert KeyLocker is FIPS 140-2 Level 3 and supports high-volume signing. On the other hand, if your monthly build count is low and local signing suffices, GMO GlobalSign’s standard token type is the cheapest and simplest.

Note that certificate validity periods are shrinking. Under CA/Browser Forum Ballot CSC-31, from March 1, 2026, the maximum validity of code-signing certificates is capped at about 460 days (roughly 15 months, down from the former 39 months). Plan your operations assuming a shorter renewal cycle than before.

Documents to line up before applying

GlobalSign’s new-application guide states that the English organization name can be verified via the English notation registered in Japan’s National Tax Agency corporate-number lookup, the English trade name on the commercial registry, the articles of incorporation, or the seal certificate. So firming up the consistency of your English trade name before applying is the key to avoiding the bottleneck for fastest issuance. The Legal Affairs Bureau supports online requests for registration and seal certificates, so request them online ahead of time if you are in a hurry.

For standard code signing, the shortest-path timeline looks roughly like this. EV slides back by the extra strict vetting.

gantt
    title Shortest self-distribution route
    dateFormat  YYYY-MM-DD
    axisFormat  %m/%d

    section Preparation
    Confirm English name & corp number   :a1, 2026-07-01, 1d
    Order registration documents         :a2, 2026-07-01, 2d

    section Standard code signing
    Apply for standard cert              :b1, after a1, 1d
    CA vetting                           :b2, after b1, 3d
    Receive token, set up driver         :b3, after b2, 1d
    Signing test                         :b4, after b3, 1d
    Build & sign installer               :b5, after b4, 1d
    Publish distribution site            :b6, after b5, 1d
    Accumulate SmartScreen reputation    :b7, after b6, 14d

    section EV code signing
    Apply for EV                         :c1, after a1, 1d
    Submit application documents         :c2, after c1, 1d
    EV vetting                           :c3, after c2, 7d
    Receive token, set up               :c4, after c3, 1d
    Build & sign installer               :c5, after c4, 1d
    Publish distribution site            :c6, after c5, 1d
    Accumulate SmartScreen reputation    :c7, after c6, 14d

SmartScreen reputation does not accumulate on a fixed schedule; it depends on usage. The final 14 days in the timeline are only an estimate.

Signing with SignTool

Windows’ official signing tool is SignTool, bundled with the Windows SDK. On newer SDKs, /fd and /td are effectively mandatory and SHA256 is recommended. And an RFC 3161 timestamp (/tr and /td) is strongly recommended. With a timestamp, signature verification continues even after the certificate is revoked or expires, and installation keeps being accepted. Always enable it.

Here is an example of selecting a token-stored certificate from the Windows My store and signing. Replace THUMBPRINT with the certificate’s SHA-1 thumbprint.

# Sign the main binary
signtool sign `
  /sha1 THUMBPRINT `
  /s My `
  /fd SHA256 `
  /tr http://timestamp.digicert.com `
  /td SHA256 `
  .\dist\MyApp.exe
 
# Sign the installer
signtool sign `
  /sha1 THUMBPRINT `
  /s My `
  /fd SHA256 `
  /tr http://timestamp.digicert.com `
  /td SHA256 `
  ".\dist\MyApp Setup 1.0.0.exe"
 
# Verify the signature
signtool verify /v ".\dist\MyApp Setup 1.0.0.exe"

Always sign the final installer, and in practice it is safer to also sign the main bundled .exe and .dll files. The Microsoft Store submission requirements also demand that the installer and PE files be signed with a trusted CA chain, and meeting that bar even for off-Store distribution helps with verification, false-positive handling, and customer explanations alike.

Also fill in the executable metadata (CompanyName, ProductName, FileDescription, FileVersion). As covered below, the antivirus vendors’ false-positive review checks whether this information is present.

Cloud HSM signing in CI/CD

Now that hardware key storage is mandatory, automated signing on cloud CI like GitHub Actions uses a cloud HSM signing service. You invoke each service’s CLI (SSL.com’s CodeSignTool, DigiCert KeyLocker’s CLI, and so on) from the build pipeline and sign with the key held in the HSM. A few gotchas when signing on cloud CI:

• PFX no longer works: with mandatory hardware key storage, the old approach of parking the private key in CI is impossible. Use cloud HSM signing instead
• EV token physical insertion: USB-token EV certificates require physical insertion into the server and do not suit cloud CI. Cloud HSM signing avoids this
• Missed signatures: among the executables and installers in your distribution, missing a signing target trips you up in verification and reputation building. Keep an explicit list of what to sign

Choosing an installer format and distribution channel

Installer format

The main options are an EXE installer for public distribution, MSI for enterprise distribution, and MSIX for the Store and sandboxed delivery. Organized by signing and distribution implications:

Distribution channel

Beyond direct distribution from your own site, there are auxiliary channels. Combine them to fit your goals.

If you want to drive the warning to zero with certainty, the strongest move is to register on the Microsoft Store (MSIX) in parallel with your own-site distribution. Microsoft automatically re-signs, no SmartScreen warning appears, and hosting, delivery, and auto-update are all handled for free. There is overhead for store review and MSIX packaging, but if you serve consumers and get a lot of first-run-warning complaints, it is worth promoting the Store to your main channel.

Enterprise distribution needs care. A typical EXE installer tends to be per-user, which is unsuited to Intune’s system-context distribution; per-machine is required. Microsoft’s recommendation is to generate a per-machine MSI (ALLUSERS=1) and package it as .intunewin. Note too that corporate customers often want to pin versions via WSUS, Intune, or SCCM rollouts and tend to dislike an independent auto-update feature.

For a product that updates continuously, sign update binaries with the same certificate as the main build, and verify the signature before distributing. The update mechanism depends on the distribution format (App Installer or the Store for MSIX; a custom updater for self-distribution). The update path is the channel that continuously delivers new binaries to users, so if it is left unsigned, the reputation you are building gets cut off.

Growing SmartScreen reputation and preparing for false positives

Operations that grow reputation

In self-distribution, it is not “buy a certificate and you’re done” but “operations that grow reputation.” The principles for accumulating SmartScreen reputation quickly and reliably are:

• Sign every release under the same publisher ID. Going unsigned or changing the publisher restarts reputation from zero
• Do not modify the file after signing. A broken signature invalidates the reputation
• Do not include unwanted bundles, ad payloads, or homepage-changing behavior. These are the main causes of a PUA (potentially unwanted application) verdict
• Standardize the distribution URL on an HTTPS official domain and do not change it often. Do not route through third-party download sites or shady ad networks
• Do not change the certificate frequently. Reputation accumulates per certificate thumbprint, and there is a known problem where renewal does not carry it over

Install from a browser download on a clean Windows 10/11 VM and record SmartScreen’s behavior. SmartScreen evaluates internet-sourced downloads and execution, so verifying only by running from an internal shared folder is insufficient.

Preparing for false positives

Even widely used desktop apps have a track record of being falsely flagged by Microsoft Defender. On September 4, 2022, a Defender signature update Microsoft shipped falsely flagged apps such as Chrome, Edge, and Discord all at once, and a corrected signature resolved it. Assume false positives can happen at any time and have submission channels ready.

The main vendors’ false-positive submission channels are below. Submissions commonly require the digital signature, VERSIONINFO, distribution URL, product description, detection name, hash, and the installer technology used.

The standard flow for a false positive is: reproduce, isolate the detection source (which of AV, EDR, PUA, or SmartScreen), submit, rescan, add a temporary exclusion if needed, confirm the definition update, then redistribute. In its developer FAQ, Microsoft states it does not accept known-good lists or pre-registration programs for false positives, while explaining that consistently signing with a certificate from a trusted root authority helps research teams identify the publisher. So rather than relying on a custom whitelist application, the baseline is consistent legitimate signing plus appropriate sample submission.

Note that merely being uncommon (reputation not yet established) is not a false positive, so it is out of scope for the submission form. In that case there is nothing to do but wait for reputation to accumulate.

Execution checklist

Finally, here is a checklist for a Japanese company to start self-distributing in the shortest path. Even if you go to the Store, the earlier setup work mostly carries over.

Before applying:

• Confirmed the English legal name and aligned it with the English notation on the National Tax Agency corporate-number site
• Requested registration and seal certificates online if needed
• Confirmed there is no kernel driver and reconsidered whether EV is truly necessary
• Made GMO GlobalSign the lead candidate and compared against DigiCert, Sectigo, and SSL.com eSigner

Before building:

• Filled in CompanyName, ProductName, FileDescription, FileVersion
• Decided the installer format (EXE/MSIX for public, MSI for enterprise)
• Included no unnecessary bundles or ad components
• Standardized the distribution URL on an HTTPS official domain

Before release:

• Signed the main .exe, .dll, and final installer
• Applied an RFC 3161 timestamp
• Verified the signature with signtool verify
• Verified from a browser download on a clean Windows 10/11 VM and recorded SmartScreen’s behavior
• Saved the SHA256, detection screen, and distribution URL in case of a false positive

After distribution:

• Tracking download counts and install success rate
• Set up an intake channel for SmartScreen/AV warning reports
• Prepared submission templates for Defender, Avast, ESET, and Symantec

Wrapping up

The shortest path for a Japanese company to start distributing safely off-Store right now, in one sentence: obtain a standard code-signing certificate from GMO GlobalSign, build a signed installer, sign with SignTool using SHA256 plus an RFC 3161 timestamp, distribute from an official HTTPS site, and submit any first-run false positives to each vendor immediately. If a Store listing is possible, the stronger answer is to ship MSIX through the Microsoft Store.

Three things to internalize about the 2026 reality: Azure Trusted Signing is cheap and attractive, but Japanese companies are excluded. Buying EV no longer gets you an instant SmartScreen bypass. And signing is the starting point of growing reputation, not the finish line. With those three in mind, you can connect every decision from certificate selection through operations along the shortest path without hesitation.

That is the shortest path for a Japanese company to distribute a Windows desktop app safely, sent from the field.

References

• Microsoft: Choose a distribution path
• Microsoft: Code signing options
• Microsoft: SmartScreen reputation-based protection
• Microsoft: SignTool
• Microsoft: Developer FAQ (false positives, SmartScreen)
• Microsoft: WDSI file submission
• Microsoft: Azure Trusted Signing
• Microsoft: Windows Package Manager (winget)
• Microsoft Intune
• CA/Browser Forum: Code Signing Working Group
• GlobalSign: Code Signing Certificates
• DigiCert: Compare code signing certificates
• DigiCert: KeyLocker
• Sectigo: Code Signing
• SSL.com: eSigner
• Japan National Tax Agency: Corporate Number Publication Site
• Legal Affairs Bureau: Online request for registration certificates