EN 303 645、EN 18031、IEC 62443-4-2 各自能接多少、還缺什麼——實驗室視角的落差分析
CRA（Cyber Resilience Act，Regulation (EU) 2024/2847）將於 2027 年 12 月 11 日全面適用。理想的準備路徑是等對應的協調標準公布，照著標準做，取得推定合規效力——但現實的時程並不允許這樣等。
對應 CRA 的協調標準家族是 prEN 40000 系列（1-1 詞彙、1-2 網路韌性原則、1-3 漏洞處理、1-4 通用安全要求）。截至目前，這一系列沒有任何一份正式刊登於歐盟官方公報（OJEU），因此都還不具推定合規效力。其中進度最快的 1-1、1-2 已進入最終草案／正式投票階段，1-3 仍在投票收尾，而與產品技術要求關係最直接的 1-4，開發進度最慢，據公開的標準工作項目資訊，其交付時程預估落在 2027 年底前後。
而即便以樂觀的時程估算，「標準交付」與「刊登於官方公報、取得推定合規效力」之間仍有一段落差，兩者相加，距離 2027 年 12 月 11 日全面適用往往只剩數週。換句話說，等 EN 40000-1-4 公布您才開始動工，時間幾乎不可能來得及設計變更、重新測試與補齊技術文件。既使如此，現階段還是可以往前推進。
第一個、也是最根本的理由：法律義務來自 CRA 本文，不是來自標準。廠商要符合的是 Annex I 的基本網路安全要求；協調標準的作用，只是提供一條「證明符合」的捷徑——依 CRA Article 27，符合已刊登於官方公報之協調標準者，方推定符合對應要求。標準未公布，義務不會延後，也不妨礙製造商現在就依 Annex I 條文建立技術文件。
其次，據標準化組織釋出的方向，1-4 是在 EN 18031:2024 系列基礎上擴充而成。這代表以 EN 18031 為起點的準備工作具有相當程度的延續性，不至於在標準定案後全部作廢。
第三，既有標準的技術控制與 Annex I 高度概念相通。存取控制、認證、加密、安全更新、日誌記錄這些控制項，在既有的產品安全標準裡都已經有成熟的做法與檢測經驗，可以直接沿用。
以下的落差評估，除 EN 18031 系列官方公告的對照附件外，涉及 EN 303 645、IEC 62443-4-2 與 CRA 之間的比對，目前並沒有官方發布的逐條對照文件，屬於技術專家依現有公開資料所做的專業判斷。它的價值在於幫助你決定「先投資哪裡」，而不是替代正式的合規評估。
| 標準 | 適用產品類型 | 現況地位 |
|---|---|---|
| EN 303 645（ETSI） | 消費性物聯網產品：智慧家庭裝置、穿戴裝置、連網玩具等 | 已生效的消費性 IoT 基線安全標準 |
| EN 18031 系列（-1／-2／-3） | 落入無線電設備指令（RED, Directive 2014/53/EU）範圍的連網產品 | 2025 年 1 月正式公告為 RED 協調標準，具推定符合效力（附帶限制條款） |
| IEC 62443-4-2 | 工業自動化與控制系統相關產品與元件 | 國際標準，工業控制領域廣泛採用 |
選擇原則：依產品的主要應用場域選一份當起點，不需要三份都套。若產品橫跨多個場域（例如工業用連網閘道器），才需要合併參考多份標準的技術要求。
三者中與 CRA 落差最大的一份，原因不是標準品質，而是它的定位本來就是「基線」——技術深度低於 EN 18031。
| CRA 要求面向 | 現況 | 需要加強的部分 |
|---|---|---|
| 已知漏洞管理 | 僅原則性提及，無產品層級要求 | 建立出廠前漏洞掃描與 CVE 比對機制 |
| 資料與通訊完整性 | 部分缺口 | 補強通訊完整性驗證機制 |
| 日誌記錄與監控 | 完全無對應機制 | 從零建立日誌功能：持久儲存、最少事件數量、時間戳記，以及使用者可關閉的選項 |
| 網路行為控制 | 完全無對應 | 補建網路流量異常防護與監控機制 |
| 攻擊面文件化 | 部分缺口 | 補齊暴露介面與服務的正式文件記錄 |
| Part II 漏洞處理義務 | 僅有原則性的揭露政策概念，無具體流程要求 | 最大缺口，需從零建置：SBOM 產出機制、漏洞回報窗口、定期測試排程、安全公告發布流程 |
顧問建議：消費性產品製造商若目前僅依循 EN 303 645，優先投入資源在日誌記錄機制與漏洞處理全流程（SBOM ＋ 協調式揭露政策）這兩塊——這是現況與 CRA 落差最大、也最花時間建立的部分。
三者中與 CRA 技術控制概念最接近的一份。據標準化組織釋出的方向，規劃中的 prEN 40000-1-4 正是在 EN 18031:2024 系列基礎上擴充而成；同時，RED 的網路安全授權法案（Delegated Regulation (EU) 2022/30）已確定自 2027 年 12 月 11 日起廢除，由 CRA 接手。若產品已依 EN 18031 完成過 RED 合規，這是目前最值得優先延伸利用的基礎。
| CRA 要求面向 | 現況 | 需要加強的部分 |
|---|---|---|
| 存取控制、認證、加密、安全更新、安全儲存與通訊 | 涵蓋度高，已有完整機制對應 | 相對輕微，主要是確認機制版本與適用的子標準 |
| 系統性風險評估流程 | 僅隱含於各機制的適用性判斷，無獨立系統化的風險評估文件框架 | 建立正式的風險評估與風險處理文件：產品情境分析、風險接受準則、風險評鑑、風險溝通與監控 |
| 產品生命週期治理 | 較聚焦技術控制點本身 | 補建涵蓋規劃、需求、架構設計、實作、驗證、生產配送、退役的全生命週期治理文件 |
| Part II 漏洞處理義務（8 項） | 完全未涵蓋，RED 架構下不要求 SBOM 或漏洞處理流程 | 與 EN 303 645 相同，需從零建置完整漏洞處理流程與 SBOM |
| 推定符合的限制條款 | EN 18031 在 RED 底下本身即有若干限制條款，受限部分無法完全自我聲明 | 過渡到 CRA 時重新檢視這些受限項目是否仍需第三方公告機構驗證 |
顧問建議：RED 產品製造商轉銜 CRA，技術控制部分負擔最輕，既有的 EN 18031 檢測與文件經驗可直接延續。投入重點應放在兩塊全新的治理性要求：建立正式風險評估框架，以及建置 Part II 漏洞處理能力。
工業場景下的技術控制相當扎實，落差集中在「漏洞管理」與「使用者溝通」兩個面向，以及一塊工業廠商過去較少接觸的領域——面向終端市場的合規文件。
| CRA 要求面向 | 現況 | 需要加強的部分 |
|---|---|---|
| 存取控制、資料完整性、通訊安全、日誌記錄 | 涵蓋度良好，技術控制對應完整 | 相對輕微 |
| 已知漏洞管理 | 無對應要求，標準本身未涵蓋此概念 | 建立出廠前已知漏洞清查機制（CVE 比對、弱點掃描） |
| 使用者通知與 opt-out 機制 | 無對應要求 | 補建使用者通知功能與相關說明文件 |
| 利用緩解機制 | 無明確對應 | 補強深度防禦、權限隔離等緩解措施的設計與文件 |
| Part II 漏洞處理義務 | 標準本身未涵蓋（較接近的流程概念屬 IEC 62443-4-1 範疇） | 對照 CRA Part II 逐項補齊 SBOM、CVD 政策、漏洞回報窗口等 |
| 消費者／市場合規文件 | 完全欠缺，B2B 情境通常無 CE 標誌、EU 符合性聲明的對應概念 | 補建 EU 符合性聲明、CE 標誌張貼流程、使用說明書應載明事項（如支援期截止日） |
顧問建議：工業產品製造商除了技術面補強漏洞管理與使用者通知，特別要留意市場合規文件這一塊。工業控制系統過去多半聚焦技術驗證，對 CE 標誌、EU 符合性聲明這類面向終端市場的合規動作較陌生，這部分應及早納入合規時程規劃，因為它牽涉的是流程與人員，不是改個設計就能補上。
無論起點是哪一份標準，以下兩項都無法從現有基礎直接沿用，建議列為第一優先：
第二項需要再解釋的部分是 -- 既有標準多半聚焦產品出廠時的技術品質；CRA 則把要求延伸到上市之後——你是否具備持續維護的能力。這不是一份文件或一次測試能解決的，而是要建立常設的組織能力，所以它也是最不該留到最後才動的一項。
談「提早準備」時，常被忽略的是 CRA 的義務並非全部落在 2027 年底。Article 14 的製造商通報義務自 2026 年 9 月 11 日起適用：主動被利用的漏洞須於 24 小時內早期預警、72 小時內通知，並於修補後提出最終報告；而且這項義務適用於所有已上市且落入 CRA 範圍的產品，不限於 2027 年後的新品。
要在 24 小時內回答「我們的產品是否受這個漏洞影響」，靠的正是 SBOM 與元件清冊——也就是 Part II 那個「共同最大缺口」。換句話說，這項準備工作的實質期限不是 2027 年 12 月，而是現在。
實務上還有兩件事建議一併確認：ENISA 單一通報平台（Single Reporting Platform）的註冊需要製造商指定的代表先申請 EU Login 帳號並啟用多因子驗證，建議提早卡位；同時，法定通報時限不會因平台狀況而放寬，因此請先確認所屬會員國 CSIRT 的聯絡窗口，並準備人工備援的通報流程。
這篇文章給的是通則性的落差地圖。實際落到個案，還是要看產品實際依循哪一份標準、既有測試報告涵蓋了哪些機制、以及風險評估與技術文件目前的完整度——這三件事決定了落差清單的真正長度。
如果想確認產品目前的合規落點、盤點過渡到 CRA 的缺口清單，或需要專業意見協助覆核既有測試報告與技術文件能否延續使用，歡迎與我們聯繫，由安合規律 SVS 與 Applus+ Laboratories 的顧問與實驗室工程師協助評估個案狀況。
歡迎參加 9 月 18 日（五）台北實體研討會，直接向來自西班牙的 CRA 專家提問，進一步說明 2027 合規規劃佈局及導入所需的時間與成本估算。報名連結：實體研討會報名連結
Q：等 EN 40000-1-4 出來再準備，來得及嗎？
時程上很緊迫、風險很高。依目前公開資料，prEN 40000-1-4（通用安全要求）的開發進度落後於 1-1、1-2、1-3，交付時程預估落在 2027 年底前後，而交付並不等於已刊登官方公報並取得推定合規效力。等標準確定才動工，通常已來不及完成設計變更、重新測試與補齊技術文件。務實的做法是先依既有標準與 Annex I 條文動工。
Q：已經做過 EN 18031（RED）合規，可以直接用在 CRA 嗎？
技術控制部分可以大幅延續。據標準化組織釋出的方向，prEN 40000-1-4 是在 EN 18031:2024 系列基礎上擴充，因此存取控制、認證、安全更新等機制與檢測經驗都能沿用。但兩塊必須新建：系統化的風險評估文件框架，以及 Annex I Part II 的 8 項漏洞處理義務——RED 架構下並不要求 SBOM 或漏洞處理流程。
Q：EN 303 645 與 CRA 的落差在哪裡？
最主要是兩塊：日誌記錄與監控機制（EN 303 645 完全無對應要求，需從零建立）以及 Part II 漏洞處理全流程（僅有原則性的揭露政策概念）。此外，已知漏洞管理、通訊完整性、網路行為控制與攻擊面文件化也都有不同程度的缺口。
Q：IEC 62443-4-2 的工業產品，過渡到 CRA 最容易漏掉什麼？
面向終端市場的合規文件。工業 B2B 情境通常沒有 CE 標誌、EU 符合性聲明、使用說明書應載明事項（如支援期截止日）這些概念，而 CRA 要求這些一併具備。技術面則以已知漏洞管理與使用者通知／opt-out 機制的缺口較明顯。
Q：如果只能先做一件事，該做什麼？
建立 SBOM 產出機制與漏洞回報窗口。這兩項是三份既有標準的共同缺口、屬於 Annex I Part II 的核心要求，也是支撐 2026 年 9 月 11 日起生效的 Article 14 通報義務所必需，且不會因為 EN 40000 系列最終如何定稿而作廢。
本文所引法規條文、標準狀態與時間點，均以下列文件為準：
文／安合規律 × Applus+ Laboratories 顧問團隊
＊本文為法規與標準解讀性質，非法律意見。文中除 EN 18031 系列官方公告之對照附件外，EN 303 645、IEC 62443-4-2 與 CRA 之間的落差評估並無官方逐條對照文件，屬技術顧問依現有公開資料所做之專業判斷與建議，非官方保證的合規路徑。prEN 40000 系列截至本文撰寫時仍為草案，內容與時程於正式公布前可能變動；個案之最終合規認定，仍應以 CRA 法規本文與主管機關解釋為準。
