CRA 來了，你的產品規格準備好了嗎？
2026年5月22日Cyber Security從波蘭攻擊事件到 EU CRA：網通、工控與儲能產品的安全規格變更清單
2025 年 12 月，波蘭超過 30 座能源場站的工業控制設備遭到大規模破壞性攻擊。攻擊者利用的不是零日漏洞，而是每一台設備出廠時就存在的設計選擇：預設密碼不強制變更、韌體上傳無簽章驗證、非加密管理協定預設開啟。被攻擊的設備類別——RTU 控制器、序列埠伺服器、保護繼電器、HMI——與台灣製造商的核心產品線直接重疊。
這篇文章不談產業趨勢或經營策略，而是直接回答一個問題：你的產品規格需要改什麼、改到什麼程度、先改哪些？
本文將 EU CRA（歐盟網路韌性法案Cyber Resilience Act，預計 2027 年底全面施行）的核心安全要求，對照波蘭事件中的實際失效模式，轉化為產品經理與研發主管可直接帶入下一次產品規格審查會議的具體變更清單。
一、30 秒背景：波蘭事件中每一台設備是怎麼被打穿的
如果你只需要知道一件事，就是這個：攻擊者的每一步都利用了「產品設計階段就能消除的弱點」。
步驟 ③④⑤ 是你的產品設計能直接影響的環節。以下所有規格變更建議，都對應這三個環節。
二、產品安全規格變更總表
以下表格將 CRA 核心安全要求，對應到具體的產品規格變更項目。優先序定義：
| P0 立即 | 波蘭事件中被直接利用、CRA 明文要求、實施成本低，建議盡快透過韌體更新解決。 |
| P1 短期 | CRA 明文要求、需要架構調整或新增模組，目標在 2026 年底前完成。 |
| P2 中期 | CRA 要求或市場趨勢驅動、需要較大的開發投入，目標在 2027 年底 CRA 施行前完成。 |
| CRA 要求 | 產品規格變更 | 適用產品類別 | 目前常見現況 | 優先序 | 驗證方式 |
| 安全預設配置Annex I Part I §2.b | 首次開機強制設定管理員密碼，未設定前僅允許執行初始化設定功能，不開放操作介面 | RTU, IED, 序列埠伺服器, 閘道器, HMI, EMS | 出廠即可用原廠帳密登入操作 | P0 立即 | 功能測試：以預設帳密嘗試登入 |
| 安全預設配置Annex I Part I §2.b | 密碼複雜度強制要求（最少 8 字元、含大小寫與數字），禁止與預設密碼相同 | 所有具管理介面之設備 | 無密碼策略或僅建議性要求 | P0 立即 | 功能測試：驗證弱密碼被拒絕 |
| 攻擊面最小化 Annex I Part I §2Part I d | 支援 RBAC（角色型存取控制），區分管理員、操作員、唯讀等角色，預設以最低權限啟用 | RTU, HMI, EMS, 閘道器 | 多數僅有單一管理員帳號 | P1 短期 | 功能測試：驗證不同角色的權限隔離 |
| 攻擊面最小化 Annex I Part I §2Part I d | 登入失敗鎖定機制（連續多次登入失敗後鎖定帳號或延遲回應），並產生安全事件日誌 | 所有具管理介面之設備 | 無帳號鎖定，可無限嘗試 | P0 立即 | 功能測試：暴力破解嘗試 |
| CRA 要求 | 產品規格變更 | 適用產品類別 | 目前常見現況 | 優先序 | 驗證方式 |
| 安全更新機制 Annex I §2.Part I c | 韌體更新前透過數位簽章驗證其完整性與真實性，簽章驗證失敗則拒絕更新並記錄事件 | RTU, IED, 序列埠伺服器, 閘道器, EMS | 部分高階型號支援但非預設啟用，多數無此功能 | P0 立即 | 安全測試：上傳未簽章/偽造簽章韌體，驗證被拒絕 |
| 安全開機 Annex I Part I §3Part I 2f | 實施 Secure Boot：設備啟動時驗證開機載入程式與韌體的完整性，偵測到竄改時進入安全模式 | RTU, IED, 閘道器, EMS | 多數設備不驗證開機程式完整性 | P1 短期 | 安全測試：修改韌體映像後重啟，驗證進入安全模式 |
| 安全更新機制Annex I Part I §2.c | 韌體更新支援回滾機制（Rollback），保留上一版已知良好韌體，更新失敗時自動回復 | RTU, IED, 閘道器, EMS | 更新失敗可能導致設備磚化（Brick） | P1 短期 | 功能測試：模擬更新中斷，驗證自動回復 |
| 持續安全更新Annex I Part I §2.c | 設計 OTA（Over-the-Air）或遠端安全更新架構，支援批次更新但不共用認證憑證 | RTU, 序列埠伺服器, 閘道器, EMS | 多數需現場手動更新韌體 | P2 中期 | 架構審查：驗證更新通道安全性與身分驗證機制 |
| CRA 要求 | 產品規格變更 | 適用產品類別 | 目前常見現況 | 優先序 | 驗證方式 |
| 攻擊面最小化 Annex I Part I §2Part I a, j | 預設僅啟用加密管理協定（SSH、HTTPS）；FTP、Telnet、HTTP 須由使用者主動啟用，啟用時顯示風險警語並記錄操作日誌 | RTU, IED, 序列埠伺服器, 閘道器, HMI | FTP/Telnet/HTTP 為預設開啟 | P0 立即 | 組態審查：驗證出廠預設僅開啟加密協定 |
| 傳輸資料保護 Annex I Part I §3Part I 2e | 管理介面通訊強制 TLS 1.2 以上，停用不安全的加密演算法，自簽憑證在管理介面顯示警示，支援匯入客戶憑證 | 所有具網頁管理介面之設備 | 部分支援 HTTPS 但允許降級至 HTTP | P0 立即 | 滲透測試：嘗試降級攻擊（Downgrade Attack） |
| 攻擊面最小化 Annex I Part I §2Part I j | 預設關閉所有非必要服務與網路埠；提供服務/埠管理介面，使用者可依需求啟用並記錄變更 | 所有網路連線設備 | 出廠開啟多項服務以兼顧向下相容 | P0 立即 | 連接埠掃描：驗證出廠狀態僅開放必要埠 |
| CRA 要求 | 產品規格變更 | 適用產品類別 | 目前常見現況 | 優先序 | 驗證方式 |
| 安全事件記錄 Annex I Part I §3Part I 2l | 記錄所有安全相關事件：登入成功/失敗、設定變更、韌體更新、服務啟停。日誌須含時間戳、來源 IP、帳號 | RTU, IED, 閘道器, HMI, EMS | 多數設備僅記錄操作日誌，不含安全事件 | P1 短期 | 功能測試：觸發各類安全事件後驗證日誌完整性 |
| 安全事件記錄 Annex I Part I §3Part I 2l | 支援 Syslog 輸出至外部 SIEM / 日誌收集器，確保設備本地日誌空間不足時不會覆寫未送出的紀錄 | RTU, 閘道器, HMI, EMS | 本地日誌循環覆寫，無外部輸出 | P1 短期 | 整合測試：驗證 Syslog 輸出格式與連線可靠性 |
| 偵測異常 Annex I Part I §3Part I 2f | 設備端韌體完整性與真實性自檢：定期驗證韌體雜湊值是否與預期一致，異常時發出告警 | RTU, IED, 閘道器 | 多數設備無完整性與真實性驗證 | P2 中期 | 安全測試：修改韌體後驗證告警觸發 |
| CRA 要求 | 產品規格變更 | 適用產品類別 | 目前常見現況 | 優先序 | 驗證方式 |
| SBOM Annex I Part II §1 | 為每個產品版本產出機器可讀 SBOM（CycloneDX 或 SPDX 格式），涵蓋所有第三方函式庫與開源元件 | 所有含軟體/韌體之產品 | 無 SBOM，或僅有內部使用的手動清單 | P1 短期 | 流程審查：驗證 SBOM 自動產出與版本關聯 |
| 弱點處理 Annex I Part II §5 | 建立弱點接收、分級、修補與揭露流程（PSIRT）；外部通報管道公開於產品文件與官網 | 公司層級（非單一產品） | 無正式弱點處理流程，依賴個案處理 | P1 短期 | 流程審查：模擬外部弱點通報，驗證回應時效 |
| 弱點通報 Art. 14 | 建立能在發現漏洞被利用或重大漏洞的24 小時內通報主管機關（ENISA）的內部流程與通報範本 | 公司層級 | 無通報流程 | P1 短期 | 桌面演練：模擬 24 小時通報情境 |
| 持續監控 Annex I Part II §3 | 將 SBOM 與 CVE 資料庫建立自動化比對，新 CVE 發布時自動識別受影響產品版本 | 公司層級 | 手動追蹤或未追蹤第三方元件弱點 | P2 中期 | 工具驗證：模擬新 CVE 發布，驗證自動比對與通知 |
三、快速參考：P0 項目清單——下一個韌體版本就該做的事
從上述總表中提煉所有 P0 項目，這是你可以帶進下一次 Sprint Planning 或韌體版本規劃會議的最小可行清單：
- 項目 1、2、4、5、6 屬於組態層變更，多數可在現有韌體架構上實施，典型開發週期 4-8 週。
- 項目 3（韌體簽章）涉及開機流程與密鑰管理架構，若為新增功能，典型開發週期 3-6 個月。已有簽章能力但未預設啟用者，可在 2-4 週內完成預設啟用的版本更新。
四、怎麼驗證做對了：安全測試的檢核邏輯
規格變更寫入 PRD 只是第一步。如何驗證實施的正確性，是產品經理與 RD 主管需要同步規劃的環節。以下是依據 CRA 合規評估與 IEC 62443 產品安全評估的實務經驗，建議的驗證邏輯：
4.1 每個韌體版本發布前（CI/CD 整合）
- 靜態分析：使用 SAST 工具掃描原始碼，識別直接寫死在程式碼裡面的密碼、不安全的加密函式呼叫、緩衝區溢位風險。將已知危險函式（如 strcpy、sprintf）加入編譯警告或阻擋規則。
- SBOM 自動產出與 CVE 比對：在建置（Build）流程中自動產出 SBOM，並與 NVD / OSV 等國際弱點資料庫比對。任何含已知高風險 CVE 的第三方元件須在發布前評估風險並決定修補或緩解方案。
- 組態基線(Configuration Baseline)驗證：自動化測試確認出廠預設組態符合安全基線——預設密碼已移除、非必要服務已關閉、加密協定已啟用。
4.2 產品發布前（獨立安全評估）
- 滲透測試：由獨立第三方對產品進行黑箱與灰箱滲透測試，驗證身分驗證機制的強韌性、韌體更新流程的安全性、通訊協定的抗攻擊能力。測試範圍應涵蓋波蘭事件中的所有攻擊向量——預設帳密登入、未簽章韌體上傳、協定降級攻擊、橫向移動嘗試。
- 模糊測試（Fuzzing）：針對工業協定解析器（Modbus、DNP3、IEC 104 等）與網頁管理介面進行模糊測試，識別記憶體損壞與異常處理缺陷。波蘭事件中 Hitachi RTU560 被 0xFF 韌體癱瘓，本質上就是處理器對非預期輸入的處理缺陷。
- CRA 合規差距評估：對照 CRA Annex I 的完整安全要求清單，逐項確認產品的技術文檔（Technical Documentation）是否齊備，識別合規缺口。
五、做這些事的商業理由
CRA 預計 2027 年全面施行。屆時，不符合安全要求的「具數位元件之產品」將無法取得 CE 標誌，不得於歐盟市場銷售。罰則最高可達 1,500 萬歐元或全球營收 2.5%。
但合規壓力只是一半，另一半是市場拉力：波蘭事件後，歐洲能源營運商正在提高設備採購的安全門檻。能提供韌體簽章驗證、SBOM、第三方滲透測試報告的供應商，在 RFQ 評比中直接勝出。對台灣 ODM/OEM 而言，這是從報價競爭走向信任競爭的轉折點。
類似的狀況也同樣出現在美國市場同樣收緊：CISA 於 2026 年 2 月發布 BOD 26-02，要求聯邦機構在 18 個月內汰換所有已終止支援的邊界設備，並在波蘭事件後五天聯合 DOE 發布專項警示。你的產品如果被列入 EOS 清單且沒有安全合規的替代機種，將直接從美國聯邦採購選項中消失。歐盟 CRA 從供給端要求產品安全設計，美國 BOD 26-02 從需求端清除不安全產品——兩個市場的方向正在收斂，而上面那張 P0 清單恰好是兩邊都需要的基礎。
先完成 P0 項目的廠商，在 2027 年前就能以安全合規作為銷售工具。還在等的廠商，到時候要補的不只是技術債，還有已經被競爭者搶走的客戶。
Onward Security（DEKRA德凱集團成員）提供產品安全評估、IEC 62443 合規諮詢、CRA 差距分析、滲透測試與模糊測試服務。如果你正在評估產品線的安全規格升級路徑，或需要獨立第三方的安全驗證，歡迎與技術團隊交流。
DEKRA 是全球少數同時具備功能安全、網路安全與 AI 保證三合一服務能力的 TIC 機構，既是合規顧問也是第三方驗證機構，不銷售特定工具，以法規合規為出發點提供中立建議。
歡迎預約免費 CRA 合規快速診斷。