Why Windows Shows "Windows protected your PC"

SmartScreen, code signing, EV/OV certificates, and MSIX/Store distribution, organized from a practitioner’s perspective

When you build and distribute a Windows app, this warning is one of the first walls you hit.

Windows protected your PC
Microsoft Defender SmartScreen prevented an unrecognized app from starting.

When this warning appears, users get nervous. Developers, too, agonize over questions like “It’s not a virus, so why is it being blocked?” and “I code-signed it, so why is the warning still showing?”

This article organizes SmartScreen warnings in Windows app distribution from the perspectives of code signing, EV/OV certificates, MSIX, the Microsoft Store, ClickOnce, and internal distribution.

1. This Article in One Sentence

Code signing is necessary when distributing Windows apps.
However, code signing is not a magic spell that always makes SmartScreen warnings disappear.

What matters is keeping three perspectives separate.

A rough decision guide looks like this.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (20 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. SmartScreen Is Not Just “Virus Detection”

When a SmartScreen warning appears, users wonder whether the app is dangerous.

But SmartScreen is not simply checking “virus or not.” According to Microsoft’s explanation, for downloaded files it primarily looks at the following reputation information.

The important point here is that a newly built file has no reputation yet.

Even if the app is legitimate from your point of view, from Windows’s point of view it is “a file seen for the first time.” Even when signed, SmartScreen warnings can appear while the file hash and publisher reputation are still insufficient.

In other words, the SmartScreen warning is easiest to understand framed like this:

It does not mean the file has been determined to be malware.
It does mean, however, that Windows has not yet judged it sufficiently trustworthy.

If you don’t understand this distinction, you end up with misunderstandings like “I signed it but it didn’t fix anything” and “I bought an EV certificate but nothing changed.”

3. What Does Code Signing Actually Guarantee?

Code signing guarantees primarily two things.

1. That the file was signed by the publisher shown
2. That the file has not been tampered with since signing

Conversely, it does not directly guarantee any of the following:

• That the app is absolutely safe
• That the app has no bugs
• That SmartScreen warnings will never appear
• That enterprise policy will always allow it

Even so, code signing is close to mandatory.

Without a signature, users cannot tell who the publisher is. In enterprise environments, unsigned files can be blocked by App Control, EDR, Defender, proxies, and mail gateways. If you build auto-update, signatures also become important for verifying that update files are genuine.

In other words, code signing is not just “for making the warning go away” - it is the foundation of distribution, updates, auditing, and enterprise adoption.

4. “EV Certificates Remove Warnings from the First Download” Is an Outdated Understanding

In the past, it was widely understood that using an EV code signing certificate gave you favorable treatment in SmartScreen.

Today, however, buying an EV certificate solely to bypass SmartScreen is, at the very least, a risky decision. Microsoft’s developer documentation, SmartScreen reputation for Windows app developers, states outright that EV certificates no longer bypass SmartScreen, and that paying a premium for EV purely to avoid SmartScreen warnings is no longer justified. The certificate-type table on that same page also groups OV and EV into a single row for a valid certificate (OV/EV), and describes the first-download behavior as a warning until reputation accumulates. Files signed with an EV certificate have to be treated on the same assumption as OV certificates: reputation accumulates over time.

That is not to say EV certificates are entirely meaningless.

• The stricter identity verification is valued in corporate procurement
• A business partner’s security review requires EV
• You already hold an EV certificate and want to keep using it

If you have reasons like these, using one is fine.

But we do not recommend buying an EV certificate for this purpose alone:

Buying an EV certificate because you want the SmartScreen warning gone from day one

If that is your goal, you should first revisit your distribution channel, signing method, communication to early users, update cadence, and whether Store distribution is possible.

5. Signing Options

Here is a summary of the signing and distribution options that commonly come up in Windows app distribution.

Microsoft Store / MSIX

If you are distributing to general users, the first thing to consider is the Microsoft Store.

The combination of MSIX and Store distribution is especially advantageous in terms of certificate management and SmartScreen warnings. MSIX packages submitted to the Store are re-signed by Microsoft, which also reduces the developer’s burden of purchasing and renewing certificates individually.

That said, not every Windows app is a good fit for MSIX.

• Heavy use of Windows services
• Drivers required
• Shell extensions present
• Legacy COM registration or ActiveX assets
• Complex OS changes needed at install time

In cases like these, MSI or a traditional installer can be more natural than MSIX.

Azure Artifact Signing

Azure Artifact Signing is a cloud-based code signing service provided by Microsoft. It was previously called Trusted Signing; the current official name is Azure Artifact Signing (Artifact Signing). Microsoft’s own product page writes it as “Artifact Signing (formerly Trusted Signing).” Plenty of articles and internal documents still use the old name, so search under both. The official documentation is Microsoft Learn: What is Artifact Signing? and Azure: Artifact Signing (formerly Trusted Signing).

Its appeal is that it does not require a physical USB token and is easy to integrate into CI/CD. It is a strong signing option for outside-the-Store distribution, but there are conditions on eligible regions and accounts.

As of 2026, Microsoft’s documentation lists the US, Canada, the EU, and the UK for organizations, and the US and Canada for individual developers. If you intend to use it as a company or individual in Japan, be sure to verify the eligibility conditions. If you cannot use it, a traditional OV code signing certificate becomes the realistic candidate.

Also, signing with Azure Artifact Signing does not grant SmartScreen trust instantly. As with OV certificates, reputation accumulates with distribution track record.

OV code signing certificates

For developers and companies in Japan distributing Windows apps outside the Store, OV code signing certificates remain a realistic choice today.

With an OV certificate, users see the publisher name. That is clearly a better state than no signature. However, SmartScreen warnings can still appear for new apps and new files.

When using an OV certificate, these are the points to keep in mind:

• Use the publisher name consistently over time
• Sign as the same publisher every time
• Do not modify files after signing
• Apply a timestamp
• Check not only the EXE but also DLLs, MSIs, and the updater
• Prepare a migration plan for certificate renewal

Self-signed certificates

Self-signed certificates are convenient for development and testing.

But they basically cannot be used for public distribution. From the perspective of the user’s Windows machine, that certificate is not trusted.

Self-signed certificates are usable in environments like these:

• A developer’s local PC
• A tester’s validation environment
• Internal machines where trusted certificates can be distributed via Intune or GPO
• Air-gapped environments where the machine configuration is fully managed

Even when using a self-signed certificate, you need to manage “when it will be removed,” “who put it in the trusted store,” and “whether it could leak into production environments.”

6. What Should You Actually Sign in Practice?

“I signed the EXE, so I’m done” is not how it works.

In Windows app distribution, go through the full set of signing targets.

When using SignTool, the /fd and /td options matter with the current Windows SDK. Typically you specify SHA256.

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

Here is what each option means.

For the timestamp server URL, use the one your certificate issuer publishes. Microsoft’s SignTool documentation uses http://timestamp.digicert.com in its examples, and the Artifact Signing signing procedure uses https://timestamp.acs.microsoft.com. Applying a timestamp records that the certificate was valid at the moment of signing, so the signature remains usable after the certificate expires.

How you point SignTool at a certificate depends on the environment.

The easy thing to miss is that unless you pass /sm, SignTool only looks at the personal store of the user running it. “Certificate not found” often comes down to putting the certificate in the Local Computer certificate store without writing /sm, or running the build under a service account while the certificate sits in a different user’s personal store. When signing in CI, settle up front which account’s store holds the certificate.

Confirm that signing succeeded on these three points.

• signtool verify /pa /v .\MyApp.exe succeeds
• The command’s exit code is 0 (in PowerShell, check $LASTEXITCODE immediately afterward)
• Opening the file’s properties in File Explorer shows the publisher and the timestamp on the Digital Signatures tab

The key point is to sign the final artifact.

If you rewrite the EXE after signing, swap files inside a ZIP, or modify embedded files after building the installer, the signature can break or verification results can differ from expectations.

In your build pipeline, fix this order:

Build
  ↓
Collect dependent files
  ↓
Create installer / package
  ↓
Sign
  ↓
Verify the signature
  ↓
Record hashes
  ↓
Distribute

7. Thinking by Distribution Method

MSI / EXE installer

When distributing via an MSI or EXE installer, always sign the file the user runs first.

In addition, review the EXEs and DLLs placed after installation as signing targets too. Even if only the installer is signed, an unsigned updater or helper deployed afterward can get blocked in enterprise environments.

The things to think about are largely fixed:

• Sign the installer itself
• Sign the EXEs/DLLs inside it as well
• Separate out any processing that needs UAC elevation
• Audit the updater and service helpers as a separate category
• Keep the download page URL stable
• Communicate the publisher name to early users

MSIX

MSIX is a method with strong consistency as a package.

If Store distribution is possible, it becomes considerably easier to handle in terms of SmartScreen warnings and certificate management. On the other hand, for internal sideloading or outside-the-Store distribution, you need to properly design MSIX package signing and certificate trust.

Points to note:

• Self-signing is fine for development and testing
• Use a publicly trusted signing method for production distribution
• Make the Publisher in the appxmanifest match the certificate Subject
• Expect that SmartScreen warnings may appear for outside-the-Store distribution
• Check in advance for OS integration that is a poor fit for MSIX

ClickOnce

ClickOnce is convenient for distributing .NET line-of-business apps (WinForms/WPF, etc.) to standard users.

However, using ClickOnce does not make the SmartScreen problem disappear. The path by which users download and launch, manifest signing, the distribution source, and file changes during updates all play a role.

These are the things to check with ClickOnce:

• Signing of the application manifest and deployment manifest
• Management of the distribution URL or shared folder
• Handling of certificate changes during updates
• Whether internal proxies or Defender will block it
• User guidance for first-time installation

ClickOnce’s strength is “easy to distribute,” but unless you design it through to publisher trust and the distribution channel, it will get blocked in the field.

xcopy / ZIP distribution

Distribution that is just “drop a folder” or “extract a ZIP” is simple.

It can be effective in air-gapped environments and for internal tools. For web distribution to general users, however, it is also the method most exposed to SmartScreen, Defender, and Mark of the Web.

The Mark of the Web (MOTW) just mentioned is an alternate data stream named Zone.Identifier that browsers and mail clients attach to the files they download. It is the mark that says “this file came from the internet,” and it feeds SmartScreen checks, Office macro blocking, and the PowerShell execution policy (RemoteSigned) decision. You can remove the mark by opening the file’s properties in File Explorer and selecting the Unblock checkbox in the Security section, or with PowerShell’s Unblock-File. Whether the mark is carried over to the files inside a ZIP when it is extracted depends on the tool used for extraction. This is covered in more detail in the chapter “Zone.Identifier (Mark of the Web) and Unblock-File” of PowerShell Execution Policy and Script Signing.

If you go with xcopy distribution, these are the things to hold the line on:

• Sign the EXEs/DLLs
• Don’t rely on the ZIP alone - verify the files inside
• Fix the distribution source
• Display the version, hash, and changelog explicitly
• If you bolt on auto-update later, include signature verification

Rather than “it’s easy because we don’t build an installer,” think of it as “we carry the responsibilities an installer would carry, ourselves.”

Custom updaters

Custom updaters are convenient, but they are a security boundary in their own right.

An updater fetches new files and replaces existing ones. In some cases it runs with administrator privileges. If this breaks, it is more dangerous than the app itself.

At minimum, verify the following:

• Sign the update metadata
• Include version, hash, size, channel, and expiry in the metadata
• Verify the hash and signature after download
• Fail closed when verification fails
• Have a rollback procedure
• Decide how the updater itself gets updated
• Separate the production signing key from the development environment

This topic is easiest to understand alongside our existing article “Security Design for Auto-Update.”

8. For Internal Distribution, Looking Only at SmartScreen Is Not Enough

With internal apps, there is a common misconception:

It’s only used internally, so we don’t need to sign it

This is dangerous.

In internal environments, several mechanisms beyond SmartScreen come into play.

Especially in environments using App Control for Business, the question is not just “is it signed” but “is that publisher allowed,” “did it come through a managed installer,” and “is the hash or path on the allow list.”

Microsoft’s deployment guide also describes the approach of first deploying App Control policy changes in audit mode, confirming that block events match expectations, and then expanding to enforcement mode.

For internal distribution, designing in this order is the realistic approach:

1. Segment the target machines
   - Developers
   - Testers
   - Selected departments
   - Company-wide

2. Decide the distribution channel
   - Intune
   - GPO + file share
   - Internal portal
   - VDI / RemoteApp
   - Manual distribution in air-gapped environments

3. Decide the trust rules
   - Publisher rules
   - Certificate distribution
   - Managed installer
   - Hash allow rules
   - Path allow rules

4. Verify in audit mode
   - What gets blocked
   - Which DLLs or helpers were missed
   - Whether updates get treated as different files

5. Roll out in stages
   - Distribute small
   - Watch the logs
   - Adjust the allow rules
   - Expand

The essence of internal distribution is not evading SmartScreen - it is making the distribution channel explainable to Windows.

9. Common Misconceptions and the Correct View

10. How to Communicate with Users at Initial Release

For a new app, SmartScreen warnings can appear in the first few weeks and for early users.

At that point, simply telling users “run it even if a warning appears” is bad practice. A safe explanation includes the information they should verify.

Items to include in the guidance:

• The official download URL
• The publisher name that will be displayed
• The file name
• The version number
• The release date
• The SHA-256 hash where appropriate
• How to verify that the file is signed
• An instruction not to run files obtained through unknown channels

For example, for internal users, guidance like this is safe:

This app is distributed only from the following page on the company portal.
Verify that the displayed publisher name is "XX Corporation."
Do not run EXEs forwarded by email attachment or chat.
If a SmartScreen warning appears, share your screen with the IT department.

For general users, either prioritize Microsoft Store distribution or place publisher-verification instructions on the download page.

What users actually click on the warning screen

Your guidance material should go as far as spelling out where the user will end up clicking. In the SmartScreen warning dialog, the only button available in the initial state is “Don’t run.” To run the app, users go through these steps.

The "Windows protected your PC" dialog
  → Choose "More info"
  → The app name (file name) and the publisher are displayed
  → Press the "Run anyway" button

Microsoft’s developer documentation likewise explains that for an unsigned file the user has to select “Run anyway” to run the app. In your guidance text, the key point is not just these two steps but also having the user confirm that the publisher name shown along the way is your company’s name. If the publisher shows as “Unknown publisher,” the file is either unsigned or its signature is broken.

Note that, depending on enterprise policy settings, “Run anyway” itself can be disabled so there is no way forward. Internal guidance should include a contact for that case.

How long before the warning goes away

“How much do we have to distribute before the warning goes away” is a frequent question, but Microsoft does not publish a concrete threshold. What the developer documentation says is that there is no exact threshold, but it can take weeks and hundreds of clean installs from a broad set of users. The same page also states the following.

• On consumer devices there is no mechanism for manually submitting a file for reputation review; reputation accumulates through download track record
• Enterprise IT administrators can submit files through the Microsoft Security Intelligence portal. For internal distribution and managed devices, this can sometimes speed up gaining trust
• Continuing to sign with the same certificate builds reputation on the certificate itself, so newer versions can become less likely to trigger warnings. Unsigned files start accumulating from zero again with every update

In short, prepare the guidance for an initial release on the assumption that warnings will appear for a while, and keep distributing without changing the certificate or the publisher name.

11. Decision Flow

When deciding on a distribution method, thinking in this order reduces second-guessing.

flowchart TD
    A[Distribute a Windows app] --> B{For general users?}
    B -->|Yes| C{Can it go to the Microsoft Store?}
    C -->|Yes| D[Prefer Store / MSIX]
    C -->|No| E[Sign with an OV certificate or Artifact Signing]
    B -->|No, internal| F{Is there device management?}
    F -->|Intune/GPO available| G[Signing + certificate distribution + App Control audit]
    F -->|Unmanaged| H[Fixed distribution source + signing + user guidance]
    E --> I[Expect initial SmartScreen warnings]
    G --> J[Staged rollout starting from audit mode]
    H --> J

The first-choice options in practice can be summarized like this.

12. The Minimum Checklist

Checklist items before publishing and distributing a Windows app.

Signing

• The EXE is signed
• DLLs are signed
• The MSI or installer EXE is signed
• The updater is signed
• Timestamps are applied
• Files have not been modified after signing
• Verified with signtool verify

Distribution

• The official distribution URL is decided
• The publisher name is shown on the download page
• The version number and release date are shown
• The possibility of initial SmartScreen warnings is anticipated
• Microsoft Store distribution was considered
• For outside-the-Store distribution, OV certificates or Artifact Signing were considered

Updates

• Update files are also signed
• With a custom updater, the metadata is signed
• Hash, size, and version are verified
• On failure, it stops fail-closed
• A rollback procedure exists

Internal distribution

• Checked for the presence of Intune / GPO / App Control
• Decided how certificates will be distributed
• Reviewed block events in audit mode
• Staged rollout by department segment
• Verified that updates do not get re-blocked

13. Conclusion

A Windows app is not finished when it is built - the distributed files need to be in “a trustworthy form” as seen by Windows, by users, and by enterprise policy.

These are the points to keep in mind:

• SmartScreen looks at the reputation of files and publishers
• Code signing is necessary but does not guarantee zero warnings
• Do not choose EV certificates for instant SmartScreen avoidance
• For general distribution, consider Microsoft Store / MSIX first
• For outside-the-Store distribution, use OV certificates or Artifact Signing and expect initial warnings
• For internal distribution, look beyond SmartScreen to Intune, GPO, and App Control
• Design the updater not as a distribution feature but as the product’s security boundary

In one sentence:

Distributing a Windows app is not about “where to put it” - it is the design of “how to get Windows to trust it.”

Related Reading

• A Guide to Choosing a Windows App Distribution Method
• ClickOnce Primer: Distribution, Updates, and Selection Criteria
• Security Design for Auto-Update
• A Minimum Security Checklist for Windows App Development
• Where Windows Administrator Privileges Are and Are Not Required
• The Limits and Practice of Single-Binary Windows Apps

Reference Links

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: What is Artifact Signing? - An overview of Azure Artifact Signing (formerly Trusted Signing) and its current official name.
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Why do I get the "Windows protected your PC" warning?

Because Microsoft Defender SmartScreen has not yet judged that file sufficiently trustworthy. SmartScreen is not a simple virus verdict: it looks at publisher reputation, file hash reputation, whether a signature is present, and the distribution channel. A newly built file is, from Windows's point of view, a file it is seeing for the first time, so warnings can appear even for a signed file until reputation accumulates. It does not mean the file has been determined to be malware, but it does mean Windows has not yet judged it sufficiently trustworthy.

Will code signing make the SmartScreen warning go away?

Not necessarily. Code signing guarantees two things: that the file was signed by the publisher shown, and that the file has not been tampered with since signing. It does not guarantee zero warnings. Even a signed file can trigger a warning while the reputation of the file or the publisher is still insufficient. Even so, code signing is close to mandatory as the foundation for distribution, updates, auditing, and enterprise adoption. Without a signature, enterprise environments can block the file through App Control, EDR, Defender, and similar controls.

If I buy an EV certificate, will the SmartScreen warning stop appearing from the first download?

That is an outdated understanding. In Microsoft's current documentation, the behavior where an EV certificate automatically bypassed the SmartScreen warning on first download is gone, and files signed with an EV certificate have to be treated on the same assumption as OV certificates: reputation accumulates over time. EV is worth using when corporate procurement requirements or a partner's security review call for it, but buying an EV certificate solely to avoid SmartScreen is not a decision we recommend. If that is the goal, revisit the distribution channel, the signing method, and whether Store distribution is possible first.

How should I distribute an app to reduce SmartScreen warnings?

For broad distribution to general users, consider Microsoft Store / MSIX first. MSIX packages submitted to the Store are re-signed by Microsoft, which makes it the channel that tends to be the most stable on the SmartScreen side. If the Store is not an option, sign with an OV certificate or Azure Artifact Signing, assume initial warnings are possible, and tell users the official download URL, the publisher name, the version, and the hash. For internal distribution, you need to design the distribution channel through Intune / GPO / App Control on top of signing.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.