Windows 為什麼會出現「Windows 已保護您的電腦」

以實務角度整理 SmartScreen、程式碼簽章、EV/OV 憑證、MSIX/Store 發佈

開發並發佈 Windows 應用程式時，最先容易碰到的一道牆，就是這個警告。

Windows 已保護您的電腦
Microsoft Defender SmartScreen 已阻止無法識別的應用程式啟動。

出現這個警告時，使用者會感到不安。開發者也常常困惑：「明明不是病毒，為什麼會被擋？」、「明明已經做了程式碼簽章，為什麼還是出現警告？」。

本文從程式碼簽章、EV/OV 憑證、MSIX、Microsoft Store、ClickOnce、內部發佈的角度，整理 Windows 應用程式發佈時的 SmartScreen 警告問題。

1. 本文一句話總結

發佈 Windows 應用程式時，需要做程式碼簽章。
不過，程式碼簽章並不是能保證消除 SmartScreen 警告的魔法。

重要的是把三個觀點分開來看。

大致的判斷準則如下。

2. SmartScreen 不只是「病毒判定」

出現 SmartScreen 警告時，使用者會覺得「這是危險的應用程式嗎」。

但 SmartScreen 並不是單純只看「是不是病毒」。根據 Microsoft 的說明，對於下載的檔案，主要會看以下這些信譽資訊。

這裡重要的是，新建立的檔案還沒有信譽。

對開發團隊來說是正確無誤的應用程式，但在 Windows 眼中是「第一次見到的檔案」。即使已經簽章，只要檔案雜湊或發行者的信譽還不足，SmartScreen 警告仍可能出現。

也就是說，SmartScreen 警告可以這樣理解會比較清楚。

不代表已經被判定為惡意軟體。
但確實代表 Windows 目前還不夠信任這個檔案。

不理解這個差異，就容易產生「明明簽章了怎麼還是沒解決」、「明明買了 EV 憑證怎麼還是沒變」之類的誤解。

3. 程式碼簽章保證的是什麼

程式碼簽章能保證的主要有兩件事。

1. 該檔案確實由所顯示的發行者簽署
2. 簽署之後檔案沒有被竄改

反過來說，以下這些事情並不會直接被保證。

• 該應用程式絕對安全
• 該應用程式沒有錯誤
• SmartScreen 警告一定不會出現
• 一定會被企業原則允許

儘管如此，程式碼簽章幾乎是必要的。

沒有簽章的話，使用者無法得知發行者是誰。在企業環境中，未簽章的檔案也可能被 App Control、EDR、Defender、Proxy 或郵件閘道擋下。開發自動更新機制時，也需要靠簽章來驗證更新檔案是否為真。

換句話說，程式碼簽章不只是「為了消除警告」，而是發佈、更新、稽核、企業導入的基礎。

4. 買 EV 憑證就能從第一次開始不出現警告，是過時的理解

過去普遍認為，使用 EV 程式碼簽章憑證，會在 SmartScreen 上獲得較有利的待遇。

但現在，至少「只為了避開 SmartScreen 而購買 EV 憑證」的判斷是有風險的。根據 Microsoft 目前的說明，EV 憑證已經不再具備自動避開首次下載 SmartScreen 警告的效果。用 EV 簽章的檔案，也要和 OV 憑證一樣，假設信譽需要逐步累積。

EV 憑證並非完全沒有意義。

• 企業採購上，較嚴格的身份驗證會被納入評估
• 客戶的資安審查要求使用 EV
• 已經持有 EV 憑證，所以持續使用

如果有這些理由，使用它是可以的。

但不建議只為了這個目的去購買 EV 憑證。

想從第一次下載開始就消除 SmartScreen 警告，所以買 EV 憑證

如果目的僅止於此，應該先檢討發佈途徑、簽章方式、對初期使用者的說明、更新頻率，以及能否透過 Store 發佈。

5. 簽章方式的選項

整理一下 Windows 應用程式發佈時常見的簽章與發佈選項。

Microsoft Store / MSIX

若要發佈給一般使用者，第一個該考慮的就是 Microsoft Store。

特別是 MSIX 搭配 Store 發佈的組合，在憑證管理與 SmartScreen 警告方面都比較有利。提交到 Store 的 MSIX 套件會由 Microsoft 重新簽章，也減少了開發者自行購買、更新憑證的負擔。

不過，並不是所有 Windows 應用程式都適合 MSIX。

• 深度使用 Windows 服務
• 需要驅動程式
• 有 shell extension
• 有舊式 COM 註冊或 ActiveX 資產
• 安裝時需要複雜的系統變更

遇到這類情況時，用 MSI 或傳統安裝程式往往比 MSIX 更自然。

Azure Artifact Signing

Azure Artifact Signing 是 Microsoft 提供的雲端型程式碼簽章服務，過去稱為 Trusted Signing。

不需要使用實體 USB Token，容易整合進 CI/CD，是它的優勢。作為 Store 外發佈的簽章方式相當有力，但有可用地區與帳號條件的限制。

根據 2026 年當時的 Microsoft 資料，適用對象為美國、加拿大、歐盟、英國的組織，以及美國、加拿大的個人開發者。台灣等其他地區的法人或個人若要使用，務必先確認使用條件；若無法使用，傳統的 OV 程式碼簽章憑證是較現實的候選方案。

另外，即使用 Azure Artifact Signing 簽章，SmartScreen 的信任也不會立即生效。和 OV 憑證一樣，信譽會依發佈實績逐步累積。

OV 程式碼簽章憑證

對於在 Store 之外發佈 Windows 應用程式的開發者或法人來說，OV 程式碼簽章憑證現在仍是現實的選項。

使用 OV 憑證後，使用者會看到發行者名稱，狀態明顯優於完全未簽章。不過，新應用程式或新檔案仍可能出現 SmartScreen 警告。

使用 OV 憑證時，值得留意的地方如下。

• 持續使用同一個發行者名稱
• 每次都以同一個發行者身份簽章
• 簽章之後不再變更檔案
• 加上時間戳記
• 不只確認 EXE，也要確認 DLL、MSI、updater
• 準備憑證更新時的轉移計畫

自我簽署憑證

自我簽署憑證在開發或驗證階段很方便。

但在公開發佈時基本上無法使用，因為從使用者 Windows 的角度來看，這個憑證並未受到信任。

自我簽署憑證可以使用的環境有：

• 開發者的本機電腦
• 測試人員的驗證環境
• 可以透過 Intune 或 GPO 部署受信任憑證的內部裝置
• 能夠完全管理裝置設定的封閉網路環境

即使使用自我簽署憑證，也需要管理「何時刪除」「誰把它加入信任清單」「是否混入正式環境」等問題。

6. 實務上該替哪些東西簽章

「幫 EXE 簽章就結束了」是不夠的。

Windows 應用程式發佈時，需要完整確認一遍簽章對象。

使用 SignTool 時，目前的 Windows SDK 中 /fd 與 /td 的指定很重要，通常會指定 SHA256。

signtool sign /fd SHA256 /tr <timestamp-server-url> /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

重點是要對最終成品簽章。

如果簽章之後又重寫 EXE、替換 ZIP 內的檔案，或是在建立安裝程式之後再修改內嵌檔案，簽章就可能損毀，或是驗證結果和預期不同。

在建置流程中，要把這個順序固定下來。

建置
  ↓
收集相依檔案
  ↓
建立安裝程式 / 套件
  ↓
簽章
  ↓
驗證簽章
  ↓
記錄雜湊值
  ↓
發佈

7. 依發佈方式的不同考量

MSI / EXE 安裝程式

使用 MSI 或 EXE 安裝程式發佈時，一定要對使用者最先執行的檔案簽章。

此外，也要重新檢視安裝後部署的 EXE 或 DLL 是否需要簽章。就算安裝程式已經簽章，部署後的 updater 或 helper 若未簽章，在企業環境中仍可能被擋下。

該考慮的事項大致固定：

• 對安裝程式本體簽章
• 內含的 EXE/DLL 也要簽章
• 把需要 UAC 提升權限的處理分離出來
• 把 updater 或 service helper 另外列管並稽核
• 讓下載頁面的網址保持穩定
• 向初期使用者說明發行者名稱

MSIX

MSIX 是套件一致性較強的方式。

如果能透過 Store 發佈，在 SmartScreen 警告與憑證管理方面會相當容易處理。另一方面，若是內部旁載（sideload）或 Store 外發佈，就需要好好設計 MSIX 套件的簽章與憑證信任。

列出幾個注意事項：

• 開發、驗證階段可以使用自我簽署憑證
• 正式發佈要使用公開受信任的簽章方式
• 讓 appxmanifest 的 Publisher 與憑證的 Subject 一致
• Store 外發佈時要假設可能出現 SmartScreen 警告
• 事先確認是否存在不適合 MSIX 的系統整合需求

ClickOnce

ClickOnce 對於把 WinForms/WPF 這類 .NET 業務應用程式發佈給一般使用者相當方便。

不過，並不是用了 ClickOnce，SmartScreen 的問題就會消失。使用者下載並啟動的途徑、資訊清單簽章、發佈來源，以及更新時的檔案變更都有關係。

在 ClickOnce 中該確認的事項如下：

• 應用程式資訊清單與部署資訊清單的簽章
• 發佈網址或共用資料夾的管理
• 更新時憑證變更的處理方式
• 是否會被內部 Proxy 或 Defender 擋下
• 首次安裝時對使用者的說明

ClickOnce 的優勢是「容易發佈」，但如果不連同發行者信任與發佈途徑一起設計，實際運作時仍會卡關。

xcopy / ZIP 發佈

只放個資料夾、或是解壓縮 ZIP 就完成的發佈方式很單純。

在封閉網路或內部工具中可能有效，但對一般使用者的網頁發佈而言，卻是最容易受到 SmartScreen、Defender 與 Mark of the Web 影響的方式。

如果要用 xcopy 發佈，這些地方要守住：

• 對 EXE/DLL 簽章
• 不只依賴 ZIP，也要驗證內部檔案
• 固定發佈來源
• 明確標示版本、雜湊值與更新歷程
• 如果之後補上自動更新，要加入簽章驗證

不該想成「因為不用做安裝程式所以簡單」，而是「自己扛起安裝程式本來該負的責任」。

自訂 updater

自訂 updater 很方便，但本身就是一個安全邊界。

updater 會取得新檔案並取代既有檔案，有時甚至以系統管理員權限運作。這個環節一旦出問題，會比應用程式本體更危險。

至少要確認以下事項：

• 對更新用 metadata 簽章
• 在 metadata 中包含 version、hash、size、channel、expiry
• 下載後驗證雜湊值與簽章
• 驗證失敗時採用 fail-closed 方式停止
• 準備 rollback 程序
• 決定 updater 本身的更新方式
• 將正式簽章金鑰與開發環境分離

這個主題可以搭配既有文章「自動更新的安全性設計」一起思考，會更容易理解。

8. 內部發佈光看 SmartScreen 並不夠

在內部應用程式的情境中，常見一個誤解。

反正只在內部使用，不需要簽章

這樣的想法很危險。

在內部環境中，牽涉的不只是 SmartScreen，還有多個機制。

特別是在使用 App Control for Business 的環境中，問題不只在於「是否簽章」，還包括「該發行者是否被允許」「是否經由 managed installer」「雜湊值或路徑是否被允許」等。

Microsoft 的部署指南中也提到，App Control 的原則變更，應先以稽核模式部署，確認封鎖事件是否符合預期後，再擴大到強制模式。

內部發佈時，依下列順序設計較為現實：

1. 分開對象裝置
   - 開發者
   - 測試人員
   - 部分部門
   - 全公司

2. 決定發佈途徑
   - Intune
   - GPO + 檔案共用
   - 內部入口網站
   - VDI / RemoteApp
   - 封閉網路的手動發佈

3. 決定信任規則
   - 發行者規則
   - 憑證發佈
   - managed installer
   - 雜湊值允許清單
   - 路徑允許清單

4. 以稽核模式確認
   - 什麼會被封鎖
   - 哪些 DLL 或 helper 被遺漏
   - 更新時是否被視為不同檔案

5. 分階段展開
   - 先小範圍發佈
   - 檢視日誌
   - 調整允許規則
   - 逐步擴大

內部發佈的重點，不是規避 SmartScreen，而是建立一條 Windows 端能夠理解、可以說明的發佈途徑。

9. 常見誤解與正確想法

10. 初期發佈時該如何向使用者說明

新的應用程式在最初幾週或初期使用者階段，可能出現 SmartScreen 警告。

這時，若只是告訴使用者「出現警告也請直接執行」，並不是好做法。安全的說明應該包含足以確認真偽的資訊。

以下是說明中該包含的項目：

• 正式下載網址
• 顯示的發行者名稱
• 檔案名稱
• 版本號
• 發佈日期
• 必要時提供 SHA-256 雜湊值
• 如何確認檔案已簽章
• 不要執行從不明途徑取得的檔案

舉例來說，內部使用的情況下，這樣的說明比較安全：

本應用程式僅透過內部入口網站的以下頁面發佈。
請確認顯示的發行者名稱是否為「○○股份有限公司」。
請不要執行透過信件附件或聊天工具轉發的 EXE。
若出現 SmartScreen 警告，請將畫面截圖並回報資訊系統部門。

對一般使用者，則可以優先採用 Microsoft Store 發佈，或是在下載頁面加上確認發行者的說明。

11. 判斷流程

決定發佈方式時，依這個順序思考比較不會迷失方向。

flowchart TD
    A[要發佈 Windows 應用程式] --> B{是給一般使用者用嗎}
    B -->|是| C{能上架 Microsoft Store 嗎}
    C -->|能| D[優先採用 Store / MSIX]
    C -->|不能| E[以 OV 憑證或 Artifact Signing 簽章]
    B -->|不是，是內部用| F{有裝置管理機制嗎}
    F -->|有 Intune/GPO| G[簽章 + 憑證發佈 + App Control 稽核]
    F -->|沒有管理| H[固定發佈來源 + 簽章 + 使用者說明]
    E --> I[假設會出現初期 SmartScreen 警告]
    G --> J[從稽核模式開始分階段展開]
    H --> J

實務上的第一候選可以這樣整理：

12. 最低限度的檢查清單

發佈 Windows 應用程式前的檢查項目。

簽章

• EXE 已簽章
• DLL 已簽章
• MSI 或安裝程式 EXE 已簽章
• updater 已簽章
• 已加上時間戳記
• 簽章後未再修改檔案
• 已用 signtool verify 驗證

發佈

• 已決定正式發佈網址
• 下載頁面已顯示發行者名稱
• 已顯示版本號與發佈日期
• 已假設可能出現初期 SmartScreen 警告
• 已檢討能否上架 Microsoft Store
• Store 外發佈時，已檢討 OV 憑證或 Artifact Signing

更新

• 更新檔案也已簽章
• 自訂 updater 已對 metadata 簽章
• 已驗證 hash、size、version
• 失敗時以 fail-closed 方式停止
• 有 rollback 程序

內部發佈

• 已確認 Intune / GPO / App Control 的狀況
• 已決定憑證發佈方式
• 已用稽核模式確認封鎖事件
• 依部門分開，分階段展開
• 已確認更新時是否會再次被封鎖

13. 總結

Windows 應用程式不是做完就結束，發佈出去的檔案必須讓 Windows、使用者、企業原則都認為是「值得信任的形式」。

該記住的重點大致如下：

• SmartScreen 看的是檔案與發行者的信譽
• 程式碼簽章是必要的，但不保證警告為零
• EV 憑證不應以立即避開 SmartScreen 為目的選用
• 一般發佈優先檢討 Microsoft Store / MSIX
• Store 外發佈使用 OV 憑證或 Artifact Signing，並假設會有初期警告
• 內部發佈不只要看 SmartScreen，也要看 Intune、GPO、App Control
• updater 不是一個發佈功能，而是產品的安全邊界，需要如此設計

用一句話總結：

Windows 應用程式的發佈，重點不在「怎麼放上去」，而在「怎麼讓 Windows 信任」的設計。

相關閱讀

• Windows 應用發布方式怎麼選 - MSI / MSIX / ClickOnce / xcopy / 自訂 updater 的判斷表
• ClickOnce 入門：發佈・更新・選定基準
• 自動更新的安全性設計
• Windows 應用程式開發中遵守最低限度安全性的檢核表
• Windows 系統管理員權限的必要／不必要界線
• Windows 單一執行檔化的極限與實踐

參考連結

• 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

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

為什麼會出現「Windows 已保護您的電腦」的警告？

因為 Microsoft Defender SmartScreen 判斷該檔案目前還不夠值得信任。SmartScreen 並不是單純的病毒判定，而是會看發行者信譽、檔案雜湊信譽、是否有簽章，以及發佈途徑。新建立的檔案對 Windows 而言是「第一次見到的檔案」，即使已經簽章，在信譽累積之前也可能出現警告。這不代表被判定為惡意軟體，但確實代表 Windows 目前還不夠信任這個檔案。

做了程式碼簽章，SmartScreen 警告就會消失嗎？

不一定會消失。程式碼簽章能保證的只有兩件事：檔案確實由所顯示的發行者簽署，以及簽署之後檔案沒有被竄改，並不保證警告完全不會出現。即使已簽章，只要檔案或發行者的信譽還不足，警告仍可能出現。話雖如此，程式碼簽章幾乎是發佈、更新、稽核與企業導入的必要基礎。沒有簽章的檔案，在企業環境中也可能被 App Control、EDR 或 Defender 擋下。

買 EV 憑證就能從第一次下載開始不出現 SmartScreen 警告嗎？

這是過時的理解。根據 Microsoft 目前的說明，EV 憑證已經不再具備自動避開首次下載 SmartScreen 警告的效果，用 EV 簽章的檔案，也要和 OV 憑證一樣，假設信譽是需要累積的。如果企業採購要求，或客戶的資安審查需要 EV 憑證，使用它仍有意義，但不建議只為了避開 SmartScreen 警告而購買 EV 憑證。若目的只是如此，應該先檢討發佈途徑、簽章方式，以及能否透過 Store 發佈。

要怎麼發佈才能減少 SmartScreen 警告？

如果要廣泛發佈給一般使用者，第一個該考慮的是 Microsoft Store / MSIX。提交到 Store 的 MSIX 套件會由 Microsoft 重新簽章，是 SmartScreen 方面最穩定的途徑。無法上架 Store 的話，就用 OV 憑證或 Azure Artifact Signing 簽章，並假設初期仍可能出現警告，同時提供正式下載網址、發行者名稱、版本、雜湊值等資訊給使用者。在內部發佈的情境下，除了簽章外，還需要一併設計 Intune / GPO / App Control 的發佈途徑。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。