Windows SmartScreen and the "Unknown publisher" warning

What is Windows SmartScreen?

SmartScreen is a Windows security feature that checks programs downloaded from the internet before they run. It looks at whether the file is known to be malicious and how much reputation the file and its publisher have built up. Rare or unsigned files get a warning screen instead of running straight away.

The check mainly applies to files Windows has marked as coming from the internet, which is what browsers do with downloads. That is why the same installer runs silently when you build it locally and triggers a warning when a customer downloads it.

What do users see when SmartScreen warns?

Users see a blue dialog titled "Windows protected your PC", saying that SmartScreen prevented an unrecognised app from starting. Only a Don’t run button is visible at first. Clicking More info reveals the file name, the publisher, shown as "Unknown publisher" for an unsigned file, and a Run anyway button.

Many users stop at that first screen, and some organisations block Run anyway by policy. Browsers may also show their own download warning before Windows ever gets involved. For a new app, that first screen can cost you a real share of installs.

Does "Unknown publisher" mean the file is malware?

No. "Unknown publisher" means Windows cannot tell who made the file, because it carries no valid code signature, and that the file is not yet common enough to have a reputation. Any brand-new program can trigger it, including your own. It is a statement about identity and familiarity, not a malware verdict.

A file that Microsoft Defender actually detects as malicious is handled differently, with a block rather than a reputation warning. If your own installer is flagged as malware, you have a separate problem, covered under submitting files to Microsoft below.

Why does SmartScreen warn about my installer?

SmartScreen warns when it has too little evidence that a file is trustworthy. Two things build that evidence: a valid code signature that ties the file to a publisher, and reputation, which grows as many users download and run files from that publisher without problems. A new, unsigned installer has neither.

Reputation attached to a signing identity can carry over from one release to the next. Reputation of an unsigned file belongs to that exact file, and starts again from zero with every new build.

Which code-signing certificate do you need?

You need an Authenticode code-signing certificate from a certificate authority that Windows trusts. They come in two broad kinds: standard (organisation validated, OV) and extended validation (EV), which requires stricter checks of your organisation. Since mid-2023, the private keys for new code-signing certificates must live on hardware: a USB token or a cloud HSM.

• Standard (OV) certificates show your verified name as the publisher. Reputation still has to build up over downloads.
• EV certificates were long sold as removing the SmartScreen warning from day one. Microsoft has changed how SmartScreen treats EV certificates over time, so check Microsoft’s current documentation and your certificate authority before paying extra for that alone. Some enterprise policies require EV for other reasons.
• Managed cloud signing services, including one Microsoft offers in Azure, keep the key in the provider’s hardware and sign over an API. Eligibility rules vary, so check them for your organisation and country.

How do you sign the installer in your build pipeline?

Sign as the last step before you publish, on a machine or service that can reach the hardware key, with Microsoft’s SignTool or your signing provider’s tool. Sign every executable you ship, not only the setup file, and always add a timestamp so the signature stays valid after the certificate itself expires.

1. 1

   Get a certificate

   Buy an OV or EV certificate, or sign up for a managed signing service, and complete the identity checks.

2. 2

   Make the key reachable from the build

   Install the token driver or the provider’s client on the signing machine so the certificate appears in the Windows certificate store, or configure the cloud signing client.

3. 3

   Sign with a timestamp

   Sign each .exe and the installer with SHA-256 and a timestamp server from your certificate authority.

4. 4

   Verify the signature

   Run Get-AuthenticodeSignature in PowerShell on the file you will publish and confirm the status is Valid.

5. 5

   Test on a clean machine

   Download the installer through a browser on a fresh Windows VM and look at exactly what a new user sees.

6. 6

   Keep the same identity

   Sign every release with the same publisher identity so reputation accumulates instead of restarting.

Can you submit your installer to Microsoft?

Yes, through the Microsoft Security Intelligence file submission page. It is meant for files you believe are wrongly detected as malicious. Submitting can clear a false detection, but it is not a reliable way to skip the reputation warning for a new, legitimate file. Signing and time do that.

What should you tell users in the meantime?

Tell users before they download, on the download page itself, what they will see and why. A short, calm explanation with a screenshot keeps far more people than a warning they meet unprepared.

• Say plainly that Windows may show "Windows protected your PC" because the installer is new or unsigned.
• Show the two clicks: More info, then Run anyway, and the file name they should expect to see.
• Link to your official download page only, and ask users never to run your installer from anywhere else.
• For companies, offer IT a checksum of the installer and a contact for questions.

Omnihorn installers and SmartScreen

Installers that Omnihorn builds are unsigned by default today, so SmartScreen will warn your users with "Unknown publisher" until signing is turned on. Code signing is configured on Omnihorn’s build machine, not per app, and there is no dashboard setting to upload your own certificate. The Installer tab shows whether each installer was signed.

The builder supports signing with a certificate held on a hardware token or cloud HSM. Once one is configured, new installers are signed when they are built. Until then, follow the advice above about warning users. The files of your own app are delivered by the installer after it starts; signing those executables with your own certificate is up to you.

This is separate from update security. Every update Omnihorn delivers carries an Ed25519 signature that the installer checks before applying anything, whether or not the installer itself is Authenticode-signed. How to sign desktop app updates explains the difference, and Security and Troubleshooting cover the details.