ENISA 對照底稿

• 這是我們的詮釋，不是官方對照。 依據只有兩份：法條原文（docs/reference/CRA/annex-I-II-original-text.md，EUR-Lex 2024/2847）與 ENISA／JRC《Cyber Resilience Act Requirements Standards Mapping》（JRC137340，2024，CC BY 4.0）。子要求一律用自己的話改寫，不逐字照抄；標準只列編號，不抄內容。
• ENISA 報告是對法案草案（2022 提案版）做的。 它的編號是 Article 10(2)、(1)～(3k)，正式版是 Article 13(2)、(1)～(2)(m)，條目有新增、有搬位置、有補字。不能拿編號直接對，下面每條都是逐句比對後的結果。
• ENISA 報告只涵蓋 Annex I。 Annex II（給使用者的資訊）九條報告完全沒分析，本底稿只列它跟 Annex I 哪條有關。
• 頁碼是報告內文印的頁碼（目錄用的那套），PDF 檢視器的頁數要再加 5。
• 報告自己說子要求只是範例，不是完整清單（p.4），拆 AO 時要回頭看法條本身。
• EN 40000-1-4（CRA 調和標準）出版後（預估 2027 秋），本底稿與據此拆的 AO 都要以框架新版本替換，舊專案沿用舊版。
• 原文報告：https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping

「對應程度」三種：完整＝正式版與草案意思相同；部分＝正式版多出報告沒分析的內容（見各節「報告沒涵蓋」）；無＝報告沒有這條。

Part I (1) 依風險設計出適當資安水準

• ENISA：3.1.1 (1)，p.5–7，Table 1。草案與正式版文字相同。
• 子要求（改寫）：
  • 產品整個生命週期都要做資安風險分析，並持續追蹤。
  • 產品開發每個步驟都要納入資安考量，例如安全程式撰寫、從設計就考慮安全。
• 對照標準：EN ISO/IEC 27002:2022、EN ISO/IEC 27005:2022、EN IEC 62443-3-2:2020、EN IEC 62443-4-1:2018、ETSI EN 303 645 V2.1.1。
• 報告指出的缺口（p.7）：硬體設計面的涵蓋比軟體少；針對「系統設計」的風險分析流程只有工控（IACS）標準有，27005 是通用的、不針對產品。
• 底稿註記：這條是總綱，(2)(a)～(m) 都寫「依據 Article 13(2) 的風險評估」，所以它的證據其實是那份風險評估本身。

Part I (2)(a) 上市時無已知可利用漏洞

• ENISA：3.1.2 (2)，p.7–9，Table 2。
• 子要求（改寫）：
  • 對產品的數位元件做弱點評估。
  • 已知可利用的漏洞要在產品發布前修掉。
• 對照標準：ISO/IEC 18045:2022、ITU-T X.1214 (03/2018)、EN IEC 62443-4-1:2018、ETSI EN 303 645 V2.1.1。
• 報告指出的缺口（p.9）：多數標準只管「找漏洞」不管「修漏洞」；18045 只提滲透測試一種手法。
• 草案與正式版差異：草案這條獨立在「依風險評估」那句之前；正式版把它收進 (2) 底下，變成也要「依風險評估、在適用時」。

Part I (2)(b) 預設安全設定、可重設

• ENISA：3.1.3 (3)(a)，p.9–11，Table 3。
• 子要求（改寫）：
  • 若預設有初始帳密，密碼要夠複雜、隨機產生、每台不同。
  • 預設設定中涉及資安的項目，每項都要有合理的安全水準。
  • 預設設定要存在不可抹除的記憶體。
  • 要有把設定重設回預設值的功能。
• 對照標準：EN ISO/IEC 27002:2022、ETSI EN 303 645 V2.1.1、ISO/IEC 18031:2011。
• 報告指出的缺口（p.11）：亂數與金鑰產生有標準；設定與帳密管理只有高階描述；「預設值放不可抹除記憶體」這類實作細節沒有標準涵蓋。
• 報告沒涵蓋：正式版新增「製造商與企業用戶就客製化產品另有約定者除外」的例外。

Part I (2)(c) 能以安全更新處理漏洞

• ENISA：3.1.13 (3k)，p.34–35，Table 13。位置搬過：草案排在 Part I 最後一條，正式版提到 (2)(c)。
• 子要求（改寫）：
  • 在合理期間內及時提供軟體元件的安全更新。
  • 要有自動檢查更新並安裝、或通知使用者有更新的功能；適用時應為出廠預設。
  • 要有安全的更新安裝機制。
  • 有更新時通知使用者。
• 對照標準：EN ISO/IEC 27002:2022、ISO/IEC 30111:2019、ETSI EN 303 645 V2.1.1、IEC 62443-2-1:2010、EN IEC 62443-4-2:2019。
• 報告指出的缺口（p.35）：標準提到要安全更新，但沒寫安裝機制怎麼做才安全，也沒明寫要通知使用者。
• 報告沒涵蓋：正式版要求自動安全更新「在適當時限內安裝」、預設開啟、清楚好用的退出機制、可暫時延後。這三項草案沒有，報告也沒分析。

Part I (2)(d) 防未授權存取並回報

• ENISA：3.1.4 (3b)，p.11–14，Table 4。
• 子要求（改寫）：
  • 依產品性質與風險分析結果，實作適當的身分驗證與授權。
  • 個人或受保護資料、管理與設定功能，只開放給已驗證且已授權的使用者。
  • 依風險分析，防止未授權的實體接觸。
• 對照標準：ISO/IEC 9798-1～6、ISO/IEC 24760-1～3、ISO/IEC 29146:2016、ITU-T X.1253 (09/2011)、ITU-T X.812 (11/1995)、ETSI EN 303 645 V2.1.1、EN IEC 62443-4-2:2019。
• 報告指出的缺口（p.14）：涵蓋良好，但標準多為通用性質，未涵蓋特定機制。
• 報告沒涵蓋：正式版新增「回報可能的未授權存取」。草案沒有，子要求也沒拆到。

Part I (2)(e) 資料機密性

• ENISA：3.1.5 (3c)，p.15–17，Table 5。
• 子要求（改寫）：
  • 產品內部儲存的資料以現行、未被淘汰的技術做靜態加密。
  • 傳輸協定要支援加密通訊，且預設開啟。
  • 以對稱或非對稱加密（含 PKI）保護交換資料的機密性。
• 對照標準：ITU-T X.805 (10/2003)、ISO/IEC 18033-1～7、ITU-T X.814 (11/1995)、ETSI EN 303 645 V2.1.1、EN IEC 62443-4-2:2019。
• 報告指出的缺口（p.17）：涵蓋良好；標準是通用概念與具體演算法兩種混合。
• 草案與正式版差異：正式版補了「以及其他技術手段」，意思不變。

Part I (2)(f) 資料、指令、程式、設定的完整性

• ENISA：3.1.6 (3d)，p.17–19，Table 6。
• 子要求（改寫）：
  • 產品內部儲存的資料、程式、設定以現行技術（如雜湊）確保完整性。
  • 傳輸協定要能察覺傳輸中的竄改（如訊息鑑別碼）。
  • 以對稱或非對稱加密（含 PKI）保護交換資料的完整性。
  • 產品要能自我檢測關鍵程式碼或資訊（如韌體）的完整性。
• 對照標準：ISO/IEC 9796-2/3、ISO/IEC 9797-1～3、ISO/IEC 14888-1～3、ITU-T X.815 (11/1995)、ETSI EN 303 645 V2.1.1、EN IEC 62443-4-2:2019。
• 報告指出的缺口（p.19）：涵蓋良好。
• 底稿註記：法條的「回報資料損毀」子要求沒拆出來，AO 要補。

Part I (2)(g) 資料最小化

• ENISA：3.1.7 (3e)，p.20–21，Table 7。
• 子要求（改寫）：參照 GDPR 慣例：
  • 不向使用者索取執行該功能不必要的資料。
  • 不再需要的資料及時刪除。
• 對照標準：ISO/IEC 27701:2019、ISO/IEC 29100:2011、ETSI TS 103 485 V1.1.1、ETSI EN 303 645 V2.1.1。
• 報告指出的缺口（p.21）：涵蓋很好，27701 有對到 GDPR。
• 草案與正式版差異：「預期用途（intended use）」改為「預定目的（intended purpose）」，與 Annex II 第 4 項的用語一致。

Part I (2)(h) 基本功能可用性、抗 DoS

• ENISA：3.1.8 (3f)，p.22–24，Table 8。
• 子要求（改寫）：產品要強化抵禦（分散式）阻斷服務攻擊，視情況採用：反向代理與網段切分、負載平衡、流量限制、備援與高可用、備援站點、災難復原計畫、關掉不必要的服務。
• 對照標準：EN ISO/IEC 27002:2022、ISO/IEC 22237-1:2021、ITU-T X.805 (10/2003)、ETSI EN 303 645 V2.1.1、EN IEC 62443-4-2:2019。
• 報告指出的缺口（p.24、p.54）：標準偏向機房與基礎設施，對一般使用者產品缺乏具體指引。
• 報告沒涵蓋：正式版從「essential functions」擴大為「essential and basic functions」，並新增「事件發生後也要維持」。事件後復原這半條報告沒分析。

Part I (2)(i) 降低對其他設備與網路的影響

• ENISA：3.1.9 (3g)，p.24–26，Table 9。
• 子要求（改寫）：
  • 對外連線限縮到真正需要的範圍。
  • 用逾時與例外處理，避免對忙碌或無回應的服務一直重送請求。
• 對照標準：ETSI EN 303 645 V2.1.1、ITU-T Y.4810 (11/2021)。
• 報告指出的缺口（p.26、p.54）：只有 IoT 文件涵蓋，而且只有少數高階條文；非 IoT 產品能否套用要另外評估。
• 報告沒涵蓋：正式版把範圍從「產品本身」擴大到「產品本身或所連接的設備」。

Part I (2)(j) 限縮攻擊面

• ENISA：3.1.10 (3h)，p.26–28，Table 10。
• 子要求（改寫）：
  • 硬體設計只保留執行預定功能必要的連接埠與介面。
  • 風險評估要求時，實體產品要有防拆設計。
  • 非必要的網路埠出廠預設關閉。
  • 軟體不留不必要、可被外部未授權者呼叫的入口（如 API）。
• 對照標準：ISO/IEC TS 19249:2017、ISO/IEC 15408-2:2022、EN IEC 62443-4-2:2019、ETSI EN 303 645 V2.1.1。
• 報告指出的缺口（p.28）：理論面涵蓋好，但缺少「做了就能確保攻擊面縮小」的具體控制；只有 62443-4-2 有具體要求且限工控。

Part I (2)(k) 漏洞利用緩解、降低事件衝擊

• ENISA：3.1.11 (3i)，p.28–31，Table 11。
• 子要求（改寫）：
  • 縱深防禦：拿到一個功能或資料的存取權，不等於自動拿到全部。
  • 產品內部的敏感資料靜態加密。
  • 不存放與任務無關或不必要的資料。
• 對照標準：ISO/IEC 27001:2022、ISO/IEC 27002:2022、ISO/IEC 27034-1:2011、EN ISO/IEC 15408-3:2022、EN ISO/IEC 18045:2022、ETSI EN 303 645 V2.1.1、EN IEC 62443-3-2:2020。
• 報告指出的缺口（p.31）：縱深防禦、沙箱、部分緩解技術沒有明確涵蓋。
• 底稿註記：子要求有兩條與 (2)(e)、(2)(g) 重疊。拆 AO 時這條應聚焦在「緩解機制」（隔離、沙箱、權限切分），避免同一份證據被三條重複計算。

Part I (2)(l) 記錄與監控內部活動

• ENISA：3.1.12 (3j)，p.32–34，Table 12。
• 子要求（改寫）：
  • 產品要有資安相關事件的紀錄。
  • 對資料、服務、功能的存取或修改要留紀錄。
  • 紀錄要讓特權使用者看得到。
  • 紀錄要防止被未授權修改或損毀。
• 對照標準：EN ISO/IEC 27002:2022、ISO/IEC 13888-1:2020、ETSI EN 303 645 V2.1.1、EN IEC 62443-4-2:2019。
• 報告指出的缺口（p.34）：未列明顯缺口；13888-1 管不可否認性，27002 為高階。
• 報告沒涵蓋：正式版新增「使用者可選擇退出」機制；「記錄和／或監控」改成「記錄和監控」，兩者都要做。

Part I (2)(m) 使用者能永久刪除資料與設定、安全轉移

• ENISA：無。草案沒有這條，報告沒有對應章節，也沒有對照標準。
• 最接近的報告內容：3.1.7 子要求「不再需要的資料及時刪除」（p.20）——但那是製造商端的保留政策，不是使用者自己刪除。
• 底稿註記：AO 只能依法條自拆，兩件事：①使用者能安全、輕鬆地永久刪除全部資料與設定；②資料可轉移到其他產品時，轉移過程安全。Annex II 第 8(d) 項（安全除役與刪除使用者資料的說明）是它的使用者文件面。

Part II (1) 找出並記錄漏洞與元件、SBOM

• ENISA：3.2.1 (1)，p.36–37，Table 14。
• 子要求（改寫）：
  • 監控整條供應鏈的資安狀態，涵蓋產品所用元件的取得。
  • 軟體使用的所有函式庫與外部元件連同版本號，列在使用者可取得的 SBOM。
  • SBOM 符合通用格式標準（報告舉 SPDX、CycloneDX）。
• 對照標準：ISO/IEC 27036-1～3。報告另提 SPDX、CycloneDX、NTIA 軟體元件透明計畫、ECSO、IIoTSBOM 等倡議（非標準）。
• 報告指出的缺口（p.36–37）：27036 管供應商關係，不管 SBOM 的產生、管理與交換。
• 陷阱：報告把 SPDX 寫成「ISO/IEC 5921:2021」，正確編號是 ISO/IEC 5962:2021。引用時不要照抄。
• 草案與正式版差異：報告子要求說 SBOM「讓使用者取得」，但正式版 Part II (1) 只要求「製作並記錄」；要不要給使用者看是 Annex II 第 9 項的選擇（「若製造商決定提供」）。寫證據時不要把「SBOM 公開給使用者」當成 Part II (1) 的必要項。

Part II (2) 依風險即時處理漏洞

• ENISA：3.2.2 (2)，p.37–39，Table 15。
• 子要求（改寫）：
  • 發現的漏洞依標準嚴重度指標（如 CVSS）分級。
  • 能直接修的，依嚴重度與風險即時修。
  • 第三方元件或函式庫有漏洞時，盡快準備並發送更新。
  • 訂閱 CERT 與資安組織的通報，分析是否影響自家產品。
  • 追蹤所用函式庫與第三方元件的新版，含安全修正時就升級。
• 對照標準：ISO/IEC 27001:2022、ISO/IEC 27002:2022、EN ISO/IEC 30111:2020、EN ISO/IEC 29147:2020、EN IEC 62443-4-1:2018。
• 報告指出的缺口（p.39）：沒有單一標準涵蓋分級、修補、修補管理、處理 CERT 通報、第三方元件更新全部面向，要組合使用。
• 報告沒涵蓋：正式版新增「技術可行時，安全更新要與功能更新分開提供」。

Part II (3) 有效且定期的安全測試與審查

• ENISA：3.2.3 (3)，p.39–41，Table 16。
• 子要求（改寫）：
  • 定期做弱點評估，高風險元件優先。
  • 開發與維護時，每次提交、建置或發版都跑自動測試，可行時走 CI/CD。
  • 威脅、漏洞等條件有重大變化或發新版時，重新評估風險。
• 對照標準：ISO/IEC 27001:2022、ISO/IEC 27002:2022、ISO/IEC TS 27034-5-1:2018、ISO/IEC 27005:2022。
• 報告指出的缺口（p.41）：沒有標準完整定義「有效」的測試方法、CI/CD 做法、頻率與範圍。
• 底稿註記：「有效」與「定期」法條沒定義，AO 要讓客戶自己宣告頻率與範圍，稽核看有沒有照宣告做。

Part II (4) 修補後公開已修漏洞資訊

• ENISA：3.2.4 (4)，p.41–43，Table 17。
• 子要求（改寫）：安全更新釋出或套用後，盡快公開發布新的 CVE。
• 對照標準：EN ISO/IEC 29147:2020、EN ISO/IEC 30111:2020、ETSI EN 303 645 V2.1.1、EN IEC 62443-4-1:2018。
• 報告指出的缺口（p.43）：沒有規定揭露時程與跨產業資訊格式；可參考 CVE、NVD、FIRST VRDX。
• 報告沒涵蓋：正式版新增「分享」（不只公開）、「清楚易取得」的修補資訊，以及「有正當理由時可延後公開，直到使用者有機會修補」的例外。報告子要求只有一條 CVE，對公開內容的五項要素（描述、受影響產品識別、影響、嚴重度、修補方式）沒有拆。

Part II (5) 協調式漏洞揭露（CVD）政策

• ENISA：3.2.5 (5)，p.43–44，Table 18。
• 子要求（改寫）：公司要訂定並落實 CVD 政策（只有這一條，等於重述法條）。
• 對照標準：EN ISO/IEC 29147:2020、EN ISO/IEC 30111:2020、ETSI EN 303 645 V2.1.1。報告另提 NIST SP 800-61 Rev.2、FIRST VRDX SIG。
• 報告指出的缺口（p.44）：沒有涵蓋「落實（enforce）」怎麼做，也沒有依產業或產品類型的指引。
• 底稿註記：子要求沒拆，等於模糊。AO 要依 29147／30111 的結構自拆（政策內容、受理流程、時程承諾、執行紀錄）。

Part II (6) 促進漏洞資訊分享、提供通報聯絡處

• ENISA：3.2.6 (6)，p.45–46，Table 19。
• 子要求（改寫）：
  • 有一個公開宣告、專收產品漏洞資訊的聯絡窗口；公司有 PSIRT 就用 PSIRT。
  • 告知相關主管機關（如國家 CERT／CSIRT）怎麼及時聯絡到公司處理漏洞。
• 對照標準：EN ISO/IEC 29147:2020、EN ISO/IEC 30111:2020。報告另提 NIST SP 800-61 Rev.2、FIRST PSIRT Services Framework、CSIRTs Network。
• 報告指出的缺口（p.46）：第三方元件的漏洞資訊分享沒被完整涵蓋。

Part II (7) 安全發送更新的機制

• ENISA：3.2.7 (7)，p.46–48，Table 20。
• 子要求（改寫）：
  • 安全更新以程式碼簽章憑證做數位簽章，確認發行者身分。
  • 公開更新檔的雜湊值，並附驗證方法說明。
• 對照標準：ISO/IEC 27002:2022、IEC 62443-4-1:2018。報告另提 NIST SP 800-53、NIST SP 800-63B、OWASP SSDLC、EUCC 的修補管理機制。
• 報告指出的缺口（p.48）：沒有涵蓋公布更新雜湊與驗證說明。
• 報告沒涵蓋：正式版新增「安全更新在適用時以自動方式」發送；草案的「可利用漏洞」改為「漏洞」，範圍變大。

Part II (8) 更新即時、免費發送並附通告

• ENISA：3.2.8 (8)，p.48–50，Table 21。
• 子要求（改寫）：
  • 透過自動發送、彈出提示、電子報等方式讓使用者知道有安全更新。
  • 通告內容包含修了什麼、怎麼套用。
  • 安全更新免費。
• 對照標準：EN ISO/IEC 30111:2020、ISO/IEC 27002:2022、EN IEC 62443-4-1:2018。
• 報告指出的缺口（p.50）：沒有標準要求「免費」，也沒規定通知使用者的方法。
• 報告沒涵蓋：正式版新增「客製化產品另有約定者除外」的免費例外。

ENISA 報告完全不涵蓋 Annex II，九條都沒有子要求與對照標準。它們本身就是「附上某項資訊」，證據就是那份資訊在哪，AO 依法條列出的項目自拆即可。與 Annex I 的關聯：

ENISA 沒對應或對應模糊

• 完全沒有：Part I (2)(m)；Annex II 1～9。
• 子要求等於重述法條：Part II (5)（只有一句「訂並落實 CVD 政策」）。
• 只指向外部法規：Part I (2)(g)（只說參照 GDPR）。
• 正式版有一半報告沒分析：Part I (2)(b) 客製例外；(2)(c) 退出機制與延後；(2)(d) 回報未授權存取；(2)(h) 事件後維持與 basic functions；(2)(i) 連接的設備；(2)(l) 退出機制；Part II (2) 安全與功能更新分開；(4) 延後公開例外與公開內容五要素；(7) 自動發送；(8) 客製例外。
• 報告自承標準涵蓋薄：Part I (2)(i)（只有 IoT 文件、少數高階條文）；(2)(j)（缺具體控制）；(2)(h)（偏基礎設施）。

一條包多件事（AO 優先拆的候選）

依「法條自帶的獨立事項數」排序：

1. Annex II 8：(a)～(f) 六個子項，各自是一份說明。
2. Part I (2)(c)：五件事——提供安全更新、自動更新預設開啟並在時限內安裝、退出機制、通知使用者、可暫時延後。
3. Part II (4)：公開與分享已修漏洞資訊，內容五要素，加延後公開的例外判斷。
4. Part I (2)(b)：預設安全設定、可重設回原始狀態、客製例外。
5. Part II (8)：即時發送、免費、附通告（含建議動作）。
6. Part I (2)(f)：保護完整性（資料／指令／程式／設定）加回報損毀。
7. Part I (2)(d)：存取控制加回報未授權存取。
8. Part I (2)(h)：基本功能可用性、事件後維持、抗 DoS。
9. Part I (2)(l)：記錄、監控、使用者退出機制。
10. Part I (2)(m)：永久刪除加安全轉移。
11. Annex II 1：名稱、地址、電子郵件或其他數位聯絡、網站。
12. Part II (2)：即時修補加安全更新與功能更新分開。