--- title: ENISA 對照底稿 subtitle: 31 條 CRA 要求逐條對到 ENISA／JRC 對照報告的子要求與標準 eyebrow: FR-135 CRA 合規框架 · 工作底稿 · 2026-10-11 lede: 給之後拆評估目標（AO）與寫建議證據的人用的底稿。每條正式版要求對到 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 ## 一、對照總表 「對應程度」三種：**完整**＝正式版與草案意思相同；**部分**＝正式版多出報告沒分析的內容（見各節「報告沒涵蓋」）；**無**＝報告沒有這條。 | 正式版 | 主題 | ENISA 草案編號 | 報告頁 | 對應程度 | |---|---|---|---|---| | Annex I Part I (1) | 依風險設計出適當資安水準 | 3.1.1 (1) | 5–7 | 完整 | | Part I (2)(a) | 上市時無已知可利用漏洞 | 3.1.2 (2) | 7–9 | 完整 | | Part I (2)(b) | 預設安全設定、可重設 | 3.1.3 (3)(a) | 9–11 | 部分 | | Part I (2)(c) | 能以安全更新處理漏洞（含自動更新） | 3.1.13 (3k) | 34–35 | 部分 | | Part I (2)(d) | 防未授權存取並回報 | 3.1.4 (3b) | 11–14 | 部分 | | Part I (2)(e) | 資料機密性 | 3.1.5 (3c) | 15–17 | 完整 | | Part I (2)(f) | 資料、指令、程式、設定的完整性 | 3.1.6 (3d) | 17–19 | 完整 | | Part I (2)(g) | 資料最小化 | 3.1.7 (3e) | 20–21 | 完整 | | Part I (2)(h) | 基本功能可用性、抗 DoS | 3.1.8 (3f) | 22–24 | 部分 | | Part I (2)(i) | 降低對其他設備與網路的影響 | 3.1.9 (3g) | 24–26 | 部分 | | Part I (2)(j) | 限縮攻擊面 | 3.1.10 (3h) | 26–28 | 完整 | | Part I (2)(k) | 漏洞利用緩解、降低事件衝擊 | 3.1.11 (3i) | 28–31 | 完整 | | Part I (2)(l) | 記錄與監控內部活動 | 3.1.12 (3j) | 32–34 | 部分 | | Part I (2)(m) | 使用者能永久刪除資料與設定、安全轉移 | — | — | **無** | | Part II (1) | 找出並記錄漏洞與元件、SBOM | 3.2.1 (1) | 36–37 | 完整 | | Part II (2) | 依風險即時處理漏洞、安全更新與功能更新分開 | 3.2.2 (2) | 37–39 | 部分 | | Part II (3) | 有效且定期的安全測試與審查 | 3.2.3 (3) | 39–41 | 完整 | | Part II (4) | 修補後公開已修漏洞資訊 | 3.2.4 (4) | 41–43 | 部分 | | Part II (5) | 協調式漏洞揭露（CVD）政策 | 3.2.5 (5) | 43–44 | 完整（但子要求很薄） | | Part II (6) | 促進漏洞資訊分享、提供通報聯絡處 | 3.2.6 (6) | 45–46 | 完整 | | Part II (7) | 安全發送更新的機制 | 3.2.7 (7) | 46–48 | 部分 | | Part II (8) | 更新即時、免費發送並附通告 | 3.2.8 (8) | 48–50 | 部分 | | Annex II 1～9 | 給使用者的資訊 | — | — | **無**（報告不涵蓋 Annex II） | ## 二、Annex I Part I 產品安全屬性 ### 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) 項（安全除役與刪除使用者資料的說明）是它的使用者文件面。 ## 三、Annex I Part II 漏洞處理義務 ### 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）：沒有標準要求「免費」，也沒規定通知使用者的方法。 - **報告沒涵蓋**：正式版新增「**客製化產品另有約定者除外**」的免費例外。 ## 四、Annex II 給使用者的資訊 ENISA 報告**完全不涵蓋 Annex II**，九條都沒有子要求與對照標準。它們本身就是「附上某項資訊」，證據就是那份資訊在哪，AO 依法條列出的項目自拆即可。與 Annex I 的關聯： | Annex II | 內容 | 相關的 Annex I 條 | |---|---|---| | 1 | 製造商名稱、地址、聯絡方式、網站 | — | | 2 | 漏洞通報單一聯絡窗口、CVD 政策位置 | Part II (5)(6) | | 3 | 產品名稱、類型與唯一識別資訊 | Part II (4)「讓使用者識別受影響產品」 | | 4 | 預定目的、安全環境、基本功能、安全特性 | Part I (2)(g) 的「預定目的」 | | 5 | 可能導致重大資安風險的已知或可預見情境 | Part I (1) 風險評估 | | 6 | 歐盟符合性聲明的網址（適用時） | —（Annex V） | | 7 | 技術安全支援類型與支援期結束日 | Part I (2)(c)、Part II (2)(8) | | 8 | 詳細使用說明，六個子項 (a)～(f) | (b)→Part I (2)(f)；(c)(e)→Part I (2)(c)；(d)→Part I (2)(m)；(f)→Annex VII | | 9 | SBOM 取得位置（製造商決定提供時） | Part II (1) | ## 五、給拆 AO 的人：兩份清單 ### 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)**：即時修補加安全更新與功能更新分開。