EV Certificates No Longer Skip SmartScreen

For years the standard advice for Windows developers was simple: buy an EV code signing certificate and the SmartScreen warning goes away on day one. Plenty of tutorials, forum answers, and certificate resellers still say so.

That advice is out of date. Microsoft's own documentation now says it plainly:

"EV certificates no longer bypass SmartScreen. Years ago, signing files with an Extended Validation (EV) code signing certificate would result in positive SmartScreen reputation by default, but this behavior no longer exists. [...] Paying a premium for EV solely to avoid SmartScreen warnings is no longer justified."

That is from Microsoft Learn, SmartScreen reputation for Windows app developers. If you are about to spend several hundred dollars a year on EV to make a blue warning disappear, read this first.

What Microsoft says now

The same page lists every signing option next to what a user sees on first download. It is a short list:

• Microsoft Store: no warning. Store apps are re-signed by Microsoft.
• Valid certificate, OV or EV: warning. The app is flagged as unrecognized until reputation accumulates. The verified publisher name is shown.
• No signature: warning, "Windows protected your PC", and the user has to choose Run anyway.
• Self-signed: same as no signature.

OV and EV sit on the same row. So does Microsoft's own cloud signing service, Artifact Signing (the new name for Trusted Signing). Its listed SmartScreen behavior is "reputation accumulates over time based on download volume and behavior". Nothing you can buy skips the queue.

How reputation actually works

SmartScreen looks at two signals when someone runs a downloaded file:

1. Publisher reputation. Is the file signed, and is the signing certificate from a publisher SmartScreen has seen behave well?
2. File hash reputation. Has this exact file been downloaded and run by many people without trouble?

A new build has a new hash, so the second signal starts at zero with every release. Microsoft's estimate for building it up is vague on purpose: "there is no exact threshold, but it can take several weeks and hundreds of clean installs from a wide audience."

The first signal is the part that matters for anyone shipping updates. Per Microsoft, signing "can allow certificate reputation to build, potentially avoiding warnings on new files signed by the same trusted certificate". Unsigned files get no such help: they "must build reputation anew with every update".

Why this is hard on small projects

Do the arithmetic for a tool that gets a few dozen downloads per release. Hundreds of clean installs of one specific file may never happen before the next version replaces it. If the project is unsigned, every release resets to zero. If it is signed with its own fresh certificate, that certificate also starts with no history, and a low download count means it earns trust slowly.

We have watched open source maintainers reach this conclusion in their own issue trackers this year: the old plan of "buy a cert, warning goes away" no longer holds, and for a small audience the reputation may simply never accrue.

So is signing still worth it?

Yes, for reasons that have nothing to do with the old EV shortcut:

• The prompt changes. A signed app shows a verified publisher name. An unsigned one shows "Unknown publisher". Users click through the first far more readily.
• Reputation can carry between releases. Only signed files can inherit trust from the certificate that signed the last version.
• Antivirus false positives drop. Many heuristic engines score an unsigned, never-seen executable as suspicious on that basis alone.
• Smart App Control. On Windows 11, Microsoft notes this feature "will block execution of unsigned files unless the file has a positive reputation", and it checks every executable, not just downloads.
• Enterprise policy. Some organisations disable the Run anyway option entirely. Unsigned software does not get installed there at all.

What to do in 2026

1. Do not pay the EV premium for SmartScreen. Buy EV only if an enterprise customer's procurement rules demand it.
2. Consider the Microsoft Store if your app fits. It is the only route Microsoft describes as warning-free. It is also a real packaging change, so it is not right for every project.
3. Sign every release, with the same identity. Microsoft lists "use a consistent signing identity" as a way to reduce warnings. Switching certificates resets the publisher signal.
4. Do not modify files after signing. Patching an installer after the fact can break the signature.
5. Tell early users what to expect. Microsoft recommends exactly this: let beta users know they may see a prompt on first download, and that they should check the publisher name before continuing.
6. Publish a SHA-256 and a scan link with each release. It costs nothing and gives cautious users something to verify.

Where a shared certificate fits

Publisher reputation attaches to the certificate, not to your project. A certificate that signs one small app sees a few dozen downloads a month. A certificate that signs many apps from many developers sees the combined download volume of all of them, as long as everything it signs is clean.

That is the model behind Bamboo Deploy. Every build is scanned before it is signed, and builds are signed with our certificate, so the publisher shown to your users is Bamboo Deploy. There is no certificate to buy, no identity check on a company you may not have, and no hardware token. We cannot promise that a brand new file never shows a prompt, and neither can anyone else in 2026. What a shared, carefully guarded certificate can do is give a small project a publisher signal it would struggle to earn alone.