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.

2. SmartScreen Is Not Just “Virus Detection”

When a SmartScreen warning appears, users feel “is this app 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. In Microsoft’s current documentation, the behavior where EV certificates automatically bypassed the SmartScreen warning on first download is gone. Files signed with EV certificates must also be treated on the assumption that reputation accumulates, just like OV certificates.

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.

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 <timestamp-server-url> /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

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 package-level integrity.

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.

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.

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: 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.

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.