先把 CRA 當成產品上市前的合規路線圖
CRA 不是單純多一份法規文件，而是在問一件事：你的數位產品賣到歐盟市場時，能不能說清楚它的資安風險、更新責任與證據鏈？
這篇會先把時間線、產品分類、Annex I 要求、符合性評估與 CE 證據拆開來看。你不需要一開始就背條文，先看懂「產品屬於哪一類、需要留下哪些證據、出了漏洞誰要負責」就好。
讀的時候可以把 CRA 想成一張上市檢查表：不是最後補文件，而是從設計、開發、測試、漏洞處理到供應鏈溝通，都要留下能被檢查的紀錄。
CRA 的難點不在於背完條文，而在於把「法律要求」轉成產品分類、責任分工、設計控制、驗證證據與事件通報。這套漫畫可以當成地圖；本文則把每張圖接回真正的工程與合規決策。
先做三個重要校正
- CRA 是歐盟法規，不存在一張可單獨購買的「CRA 證書」。產品必須完成適用的符合性評估、技術文件與 EU Declaration of Conformity，之後才能在適用情形下貼附 CE。
- 2027 年 12 月 11 日是 CRA 全面適用日，但主動遭利用漏洞與嚴重資安事件的通報義務自 2026 年 9 月 11 日起先行適用。
- 漫畫中的 TOEFL／TOEIC／GEPT 是幫助記憶的比喻，不代表 CC、EUCC、SESIP、FIPS 或 NIST 可以一對一互換，也不代表任何一張證書必然自動符合 CRA。
1. CRA 是法律框架，不是一張「CRA 證書」
CRA（Regulation (EU) 2024/2847）是針對「具有數位元素的產品」建立的橫向資安法規。只要產品在商業活動中供應到歐盟市場，而且其預定用途或可合理預見用途包含直接或間接的邏輯／實體資料連線，就可能進入 CRA 範圍。它不只看最終設備，也可能涵蓋單獨投放市場的硬體或軟體元件。
「法律」與「市場標示」要分開理解。CRA 規定義務；製造商依產品類別走完適用的符合性評估，建立技術文件，簽署 EU 符合性聲明，再貼附 CE。CE 不是歐盟政府發出的安全保證書，而是製造商宣告產品符合所有適用的歐盟法規要求。若產品同時適用 LVD、EMC、RED 或其他法規，技術文件與聲明必須一起處理，而不是每部法規各貼一個 CE。
對晶片或安全 IP 團隊，關鍵問題是：你賣的是可獨立投放市場的產品、被整合的元件，還是只提供設計服務？真正的「manufacturer」又是誰？法規責任通常落在以自己名稱或商標把產品投放市場的一方，但上游仍需交付足以支持下游風險評估、整合與弱點處理的證據。
2. 誰要負責，以及為什麼 2026 年 9 月不能等
主要義務由製造商承擔：做資安風險評估、把 Annex I 要求落入設計與開發、管理元件弱點、提供安全更新、建立技術文件並完成符合性評估。進口商與經銷商不是只看箱子上有沒有 CE；他們也要確認適用文件與聯絡資訊齊備，發現不合規或弱點時採取相應行動。非歐盟製造商還要釐清歐盟境內的進口商與授權代表安排。
時程最容易被誤讀。CRA 自 2024 年 12 月 10 日生效，2027 年 12 月 11 日全面適用；但 Article 14 的強制通報義務自 2026 年 9 月 11 日適用。製造商發現「主動遭利用的漏洞」或「對產品安全造成嚴重影響的事件」時，要經 CRA Single Reporting Platform 通報：24 小時內先期警示、72 小時內完整通知；最終報告期限則依漏洞或事件類型不同，並非所有情況都固定為同一個 14 天。
工程上，24 小時是組織能力而不是表單能力。公司要事前定義誰能判斷「actively exploited」、誰是法務與 PSIRT 的責任人、產品與版本如何定位、如何保留日誌、誰有權對外通報、供應商如何升級通知。等事件發生才找 owner，幾乎一定來不及。
3. 先判斷產品類別，再決定符合性路徑
CRA 不是用「普通、很強、超強」替產品排名。一般產品是預設路徑；Annex III 列出重要產品 Class I 與 Class II；Annex IV 則列出關鍵產品類別。分類要看產品的核心功能與法定技術描述，不能只看產品名稱。例如作業系統、路由器，以及具有資安相關功能的微處理器或微控制器可能落入 Annex III，但一般記憶體晶片不會只因為是 IC 就自動成為重要產品。
分類會影響符合性評估選擇。一般產品通常可採內部生產控制（Module A）自評。Important Class I 只有在完整採用適用的調和標準、共同規格或可用且適用的歐盟資安認證機制時，才可能繼續走自評；否則需第三方評估。Class II 的路徑更嚴格，通常要由 notified body 參與。Annex IV critical products 的具體評估要求還要結合後續授權法規與適用方案判讀，不能只憑一張示意圖定案。
對 SoC 團隊，產品分類應該留下正式 decision record：產品功能、銷售型態、是否單獨投放市場、Annex 類別比對、排除條款、預定用途、可合理預見用途，以及法務／合規核准。這份判定會決定後面的標準、測試、文件與預算。
4. Annex I 是考綱：要求的是可證明的結果
Annex I 分成兩大塊：產品的資安特性，以及弱點處理要求。安全預設、適當的存取控制、機密性／完整性／可用性保護、資料最小化、攻擊面降低、安全更新、弱點識別與修補、協調式揭露與元件清單，都是產品生命週期的一部分。漫畫中的清單抓到了方向，但它不是完整條文，也不能取代逐條 traceability。
最實用的方法是建立「requirement → threat → control → evidence」矩陣。例如「不得使用已知可利用的漏洞」不是一句宣言，而要連到元件盤點、CVE 監控、風險接受規則、修補 SLA、回歸測試與發布紀錄。「Secure by default」則要連到出廠設定、初次啟用流程、權限最小化、預設服務與秘密管理。
SBOM 也不是交付一份 CSV 就結束。它必須能對應實際出貨版本，支援受影響版本查詢，並與供應商通知、弱點分析、更新機制與 EOS/EOL 政策連動。真正的目的，是在事件發生時快速回答「哪些產品、哪些客戶、哪些版本受影響」。
5. 自評與第三方評估：責任都不會消失
自評的正確意思是：製造商自己完成風險評估、控制設計、測試與文件，對結論負法律責任。它不是「沒有人管」，市場監督機關仍可抽查產品與技術文件，發現不合規時要求矯正、限制銷售、召回或處罰。技術文件與 EU 符合性聲明通常必須保存至少十年，且產品或法規發生重大變化時要更新。
第三方路徑則由 notified body 依適用 module 執行型式或品質系統相關評估。這條路徑增加獨立審查，但製造商仍要維護設計、變更、弱點、支援期與通報流程。拿到某次型式評估結果，不等於後續 firmware、BOM、開源元件或雲端相依性可以任意改動。
實務上應在專案早期做 route decision：分類依據、可用標準、標準涵蓋率、證據缺口、是否需要第三方、實驗室排程與預算。越晚決定，越容易發現測試介面、更新設計、log、secure boot、debug lifecycle 或供應商合約根本沒留下證據。
6. 「英文考試地圖」只能當比喻，不能當法規捷徑
CC／EUCC、SESIP、FIPS 140-3、NIST 文件各自解決不同問題。CC/EUCC 聚焦特定評估目標與保證等級；SESIP 常用於連網平台與 SoC 的安全能力評估；FIPS 140-3 驗證密碼模組；NIST 文件可能是標準、指南或參考框架。它們不是同一考試的不同分數，也不能用「有 FIPS，所以 CRA 通過」推論。
證據能否重用，要看四個對齊：scope（產品／模組邊界）、version（實際出貨版本）、requirement（CRA 要求是否被覆蓋）、assurance（測試深度與獨立性）。既有證書通常能降低重複工作，卻很少單獨覆蓋 CRA 的支援期、漏洞處理、通報、使用者資訊與整體產品生命週期。
目前 CRA 調和標準仍由歐洲標準組織依 Commission standardisation request M/606 推進，涵蓋水平與產品別標準。只有在標準正式成為 CRA 的調和標準、產品與條款落在其範圍內，而且製造商正確採用時，才可能對相應要求產生「符合性推定」。因此現在最務實的做法是先做 Annex I gap analysis，持續追蹤標準狀態，而不是等標準全部完成才開始設計。
7. 證據可以沿供應鏈重用，但責任不能向上游外包
最有效率的供應鏈不是每一層從零測試，而是交付可驗證的 evidence package。IP 供應商可提供安全主張、設計文件、測試報告、已知限制、整合指南、SBOM／簽章與弱點通知承諾；晶片商把它們整合進 SoC 威脅模型、系統測試與 lifecycle control；設備商再加入 firmware、OS、App、後端服務、預設設定與現場更新的證據。
證據重用必須有 configuration identity。至少要記錄供應商、元件名稱、版本、build hash、評估範圍、假設、有效期、已知限制與變更通知。若下游開啟未評估的 debug mode、改變 boot chain、換掉 entropy source 或不遵守 secure integration guide，上游證據可能立即失效。
因此供應鏈合約也要資安化：弱點通知時限、支援期、修補交付、SBOM 格式、CVE／VEX 資訊、變更通知、稽核權與停止供應後的責任。CRA 最有價值的「forcing function」，就是迫使技術、品質、法務與供應鏈用同一套證據語言合作。
8. 四個常見誤區與可執行的五步清單
第一個誤區是「有 FIPS／CC／SESIP 就等於 CRA」。正解是做 evidence mapping，把可重用部分與剩餘缺口分開。第二個誤區是「2027 才適用，所以 2026 不用管」。正解是先完成產品清冊、PSIRT、事件判定與 Single Reporting Platform 的通報演練。
第三個誤區是「去買 CRA 證書」。正解是確認分類與符合性評估路徑，完成技術文件、EU 符合性聲明與 CE 相關程序。第四個誤區是「標準未完成就不能開發」。正解是先以 Annex I、風險評估與成熟安全工程建立 baseline，再持續把調和標準映射進 traceability matrix。
可執行的五步是：
- 建立 EU 市場產品清冊，逐項確認產品、版本、manufacturer 與分類。
- 逐條做 Annex I gap analysis，指定 control owner、證據與完成日期。
- 在 2026 年 9 月前完成 PSIRT、24h／72h／final report 流程與桌上演練。
- 依產品類別、標準可用性與證據成熟度選擇自評或 notified body 路徑。
- 建立可稽核的技術文件、SBOM、版本／變更管理與至少十年的保存策略。
9. 總結：把合規做成產品工程，而不是上市前補文件
CRA 可以用一句話總結：把資安從最佳實務，變成進入歐盟市場的產品責任。 製造商要能證明產品在設計、開發、生產、交付、維護與弱點處理期間都受控；進口商與經銷商也有核對與協力義務。CE 是流程結果，不是資安起點。
對 RD Director 而言，最重要的管理物件不是單一 test report，而是五條彼此連接的鏈：產品分類鏈、需求追溯鏈、元件／SBOM 鏈、事件通報鏈，以及供應鏈證據鏈。五條鏈都能從出貨版本回溯到責任人與證據，CRA 才真正可執行。
對晶片產業而言，這也是機會。能提供 secure-by-design 元件、清楚的 security claims、可重用的評估證據、長期漏洞處理與穩定更新承諾的供應商，會更容易進入歐洲設備商的信任鏈。合規不是把創新變慢；做對了，它會減少重工、縮短客戶評估並提高產品可信度。
Reference｜官方資料
- Regulation (EU) 2024/2847 — Cyber Resilience Act（EUR-Lex）：法規全文、Annex I／III／IV、經濟營運者義務、符合性評估與適用時程。
- European Commission — CRA legislative summary：範圍、製造商／進口商／經銷商義務、Annex 與符合性評估的官方導讀。
- European Commission — CRA reporting obligations：2026 年 9 月 11 日起的通報義務，以及 24h／72h／final report 時程。
- ENISA — CRA Single Reporting Platform：SRP 法源、流程、通報對象與平台 FAQ。
- European Commission — CRA implementation FAQ：CRA 執行與適用問題的官方 FAQ。
- European Commission — CRA standardisation：M/606、調和標準與符合性推定的最新官方說明。
- European Commission — CE marking：CE 的法律意義、製造商責任與常見誤解。
本文是工程與法規教育材料，不取代針對特定產品、交易模式與歐盟成員國執法情境的法律意見。產品分類與符合性路徑應由公司的法務、合規、產品安全與適格第三方共同確認。
Hashtags
#CRA #CyberResilienceAct #EU20242847 #CE #CE標示 #產品資安 #SecurityByDesign #SecureByDefault #SBOM #漏洞管理 #VulnerabilityManagement #PSIRT #IncidentReporting #AnnexI #NotifiedBody #SESIP #EUCC #FIPS1403 #SupplyChainSecurity #SemiconductorSecurity #HardwareSecurity #漫畫小教室
學習指南
硬體安全入門
先備知識
- 基本產品資安與 CE 標示概念
我學會了什麼
- 區分 CRA 法規、符合性評估與 CE 標示
- 說明 2026 年通報義務
- 建立需求到證據的追溯鏈