Windows SmartScreen and Code Signing: How Publisher Reputation Works

Why SmartScreen flags your app

SmartScreen flags your app because neither the file nor its signing certificate has enough recorded history for Microsoft to vouch for it. When a user runs a file that was downloaded from the internet, Windows queries Microsoft's reputation service with identifiers for that file and its signature. Files with established good reputation run silently, known-malicious files are blocked, and everything in between gets the warning — including perfectly legitimate, correctly signed new software.

Two details of this flow are worth pinning down, because they explain most of the confusion. First, the check only fires for files carrying the Mark of the Web — a marker Windows attaches when a browser saves a file from the internet. That's why you never see the warning on your own dev machine (your build was never downloaded) and why a colleague copying the file from a network share doesn't see it either. Second, the warning is a reputation verdict, and a verdict of "unknown" is the default state of every file Microsoft's service hasn't observed at scale. It isn't an accusation, and it isn't a signature failure.

File reputation vs certificate reputation

SmartScreen tracks reputation at two levels. File-hash reputation attaches to one exact binary: it grows as users download and run that specific file without incident, and it dies the moment you ship a new build, because a new build is a new hash. Certificate reputation attaches to the certificate that signed the file, so it persists across releases and can pre-clear files SmartScreen has never seen.

The interplay between the two lanes is what publishers actually experience. A young publisher's releases each ride the file-hash lane alone: version 1.0 earns trust over a few weeks, then version 1.1 ships with a fresh hash and the warning is back. Once the signing certificate has accumulated enough history of its own, Microsoft's documentation describes the effect you want: files signed by a certificate with established reputation can skip the warning even on day one. Reaching that point is gradual and Microsoft publishes no numbers, but the direction is clear — every signed, cleanly-behaving download you ship is a deposit into an account that outlives the release.

Does code signing remove the warning?

Not by itself, and any vendor telling you otherwise is selling yesterday's behavior. What a signature changes is the trajectory: unsigned files show "Unknown publisher", never build a durable identity, and restart from zero with every release, while signed files display your verified company name and feed a certificate reputation that compounds. Signing is the mechanism that makes escaping the warning possible; downloads are what actually do it.

Worth keeping straight: that "Unknown publisher" label is a different warning from SmartScreen, with a different cause and a faster fix. It's an identity problem a valid signature clears immediately, whereas SmartScreen is the reputation problem this article is about. Our guide to the "Unknown Publisher" warning covers why the two get confused and how to fix that one on its own.

The last row deserves the emphasis, because the internet is still full of advice written before it changed. For years, EV code signing certificates earned positive SmartScreen reputation by default — buy EV, skip the warning. Microsoft removed that behavior in 2024, and as of July 2026 its developer documentation says plainly that it no longer exists. OV and EV now build reputation the same way. If you're weighing the two certificate types on other grounds — validation depth, driver signing, procurement requirements — our code signing certificates explainer walks through what still genuinely differs.

How to build SmartScreen reputation faster

You can't buy reputation, and Microsoft doesn't publish the formula, but publishers have real levers: keep every download feeding one certificate identity, keep the files themselves clean and stable, and use Microsoft's free review channel to shortcut obvious false positives. In practice that comes down to five habits.

1. Sign everything, with the same certificate. The installer, the uninstaller, and the executables inside it. An unsigned stub inside a signed installer is a classic way to keep triggering warnings after you thought you'd fixed them — and every file signed with your certificate is another contribution to its history. Our SignTool walkthrough covers the exact command.
2. Timestamp every signature. The timestamp keeps signatures valid after the certificate expires, which means old releases keep verifying — and keep counting — instead of turning into invalid-signature noise attached to your name.
3. Hold your identity steady. Reputation attaches to the certificate and the validated publisher behind it. Changing company names, switching certificates mid-lifecycle, or juggling certificates from several CAs splits your download history into pools too small to earn trust.
4. Distribute cleanly and let volume work. Serve downloads from one stable HTTPS URL, and keep the binary free of anything resembling bundleware — download managers and ad-supported wrappers are exactly the patterns reputation systems are trained to distrust. From there, the curve is download volume over time; wide, steady distribution moves it fastest.
5. Submit the file to Microsoft for review. As of July 2026, the Microsoft Security Intelligence portal accepts file submissions from software developers. Upload the flagged build, include the SHA-256 and the download URL, and if analysis confirms it's clean, Microsoft can adjust the verdict without waiting for the organic curve. Worth doing for every major release while your certificate is young.

Renewals, new keys, and reputation resets

A certificate renewal is where publishers most often lose reputation they'd already earned. A renewal issues a new certificate — and since the CA/Browser Forum began requiring code signing keys to live on certified hardware (June 1, 2023), it nearly always means a new key pair as well. SmartScreen offers no supported way to transfer reputation from the old certificate to the new one: files signed after the renewal start rebuilding certificate reputation, while previously shipped files keep the file-hash history they've earned.

You can't avoid renewals, but you can space them out and soften the landing. Buying the longest term you can justify is the blunt, effective move — a three-year certificate goes through the reset once where an annual one goes through it three times, which is why the multi-year options on our code signing page tend to pay for themselves in saved warning-weeks alone. Beyond that: time the switch just after a major release rather than just before one, so the new certificate starts its climb on a build that's already had its download surge, and resubmit your first newly-signed release to Microsoft's review portal rather than waiting out the cold start twice.

Where Microsoft's Artifact Signing fits

Azure Artifact Signing — renamed from "Trusted Signing" — is Microsoft's subscription signing service: your key lives in an Azure-managed HSM, Microsoft's CA issues short-lived certificates against your validated identity, and signing plugs into CI/CD without a physical token. As of July 2026 it's available to organizations in the USA, Canada, the EU, and the UK, plus individual developers in the USA and Canada.

What it is not, despite the name, is a reputation shortcut. Microsoft's own documentation puts Artifact Signing under the same reputation-building model as OV certificates: new files warn until history accumulates. Its real appeal is operational — no token on a build server, tight GitHub Actions and Azure DevOps integration — and its trade-offs are the regional eligibility list, an Azure subscription, and identity checks comparable to a CA's validation anyway. A traditional certificate on a token remains the straightforward path for publishers outside those regions, or for anyone who wants the certificate, not a subscription, as the durable asset. Whichever route you take, the mechanics in the sections above apply unchanged.