EU Cyber Resilience Act（CRA）
Regulation (EU) 2024/2847 + Corrigendum B / C1 / C2 / C3
適合產業界、驗證業、資訊安全、網路安全及軟/硬/韌體工程師、企業管理者或法規政策研究人員，具備大學教育背景但對歐盟法規未盡熟悉的亞洲讀者閱讀。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。法規內容可能隨時間修訂，具體符合決策宜諮詢歐盟專業法律及資安顧問或驗證機構。文中提及之市場資料係基於公開報告及邏輯估算，實際數值可能隨時變動。參考法規資訊截至2026年3月，後續修訂請查閱歐盟CRA官方網站和EUR-Lex資料庫。 © All Rights reserved。 版權聲明。CC BY-SA 4。0。 |
第六章 附錄 III & IV
— 重要及關鍵產品分類
6.1 三層分類制度
CRA條例將所有 PDE 產品按風險高低分為三層，對應不同的符合性評鑑程序：
|
分類 |
名稱 |
特徵 |
符合性評鑑方式 |
法規依據 |
|
一般產品 |
Default Products |
不屬於 附錄III 或 IV 的所有 PDE |
製造商自行評估（模組
A：內部控制） |
§32(1) |
|
重要產品—Class
I |
Important Products Class I |
附錄III
Class I 所列產品，如：身份管理軟體、密碼管理器、網路管理系統、基本作業系統（非個人電腦） |
自行評估
+ 調和標準；或
EU 型式審查（Module
B+C）；或完全品質保證（Module
H） |
§32(2) |
|
重要產品—Class
II |
Important Products Class II |
附錄III
Class II 所列，如：防火牆（企業用）、入侵偵測系統（IDS/IPS）、強化安全微處理器、智慧電錶閘道器 |
強制
EU 型式審查（Module
B+C）或完全品質保證（Module
H）——必須通過第三方公告機構 |
§32(3) |
|
關鍵產品 |
Critical Products |
附錄IV
所列，如：具安全盒的硬體設備、高安全微控制器、進階安全用途裝置、智慧卡 |
依委任法規指定（可能採用歐盟網路資訊安全驗證） |
§32(4) |
參考資訊：（非完整列出，須諮詢專業人士及更新至最新狀況）
一般型PDE產品，係指具有硬體、韌體或軟體元組件、包含開源軟體，可以獨立或依賴其他產品執行功能者，如；智慧型手錶、路由器、筆記型電腦、工業感測器等；即使是傳統產品加裝 Wi-Fi 模組，也屬於此類。
6.2 附錄 III
—重要產品（依 Implementing Regulation 2025/2392）
2025年11月28日，委員會依 §7(4) 發布CRA的實施條例（Implementing Regulation） (EU) 2025/2392，提供附錄III 產品的技術描述，可能對大量使用者造成風險的產品。以下列舉主要類別：
Class I（重要產品第一類：可能對大量使用者造成風險）
●
身份及存取管理軟體（Identity and
Access Management Software）
●
瀏覽器軟體（Browser
Software）
●
密碼管理器（Password
Managers）
●
惡意軟體掃描及防毒軟體
●
網路管理系統（Network
Management Systems）
●
非個人電腦之作業系統（Operating
Systems, non-SOHO）
●
虛擬私人網路（VPN）軟體
●
微控制器（Microcontrollers）
●
醫療與健康科技：遠距監測儀器（血壓計、血糖機）、數位聽診器、智慧假肢
●
路由器（SOHO 家用及小型企業用路由器）、交換器、基地台
●
智慧電錶（Smart Meters，除閘道器外）
Class II（重要產品第二類：可能影響關鍵基礎設施）
●
作業系統（供伺服器、個人電腦、行動裝置用）
●
超管程式（Hypervisors）及容器執行環境（Container Runtime Environments）
●
防火牆（Firewalls，企業及關鍵基礎設施用）
●
入侵偵測與防護系統（IDS/IPS）
●
防竄改微處理器（Tamper-resistant
Microprocessors）
●
智慧電錶閘道器（Smart Meter
Gateways）、智慧電網設備
●
公鑰基礎設施（PKI）管理軟體
●
工業自動化與控制系統（IACS）元件 、可程式邏輯控制器（PLC）
●
監督控制與資料獲取（Supervisory
Control and Data Acquisition, SCADA）
●
雲端基礎設施
6.3 附錄 IV
— 關鍵產品（Critical Products）
●
具備安全盒（Security Box）功能的硬體設備
●
進階安全用途微控制器（用於 TPM、智慧卡、SIM 等）
●
硬體安全模組（HSM）
●
高安全性電腦通用閘道器（gateway for
critical infrastructure）
對亞洲製造商而言，最需關注的是：若您的產品核心功能符合上述描述，即使品牌行銷上不使用相同術語，仍可能被主管機關認定為 附錄III / IV 產品，從而觸發第三方稽核的必要義務。建議在產品設計初期即向符合性評鑑機構（CAB）或法律顧問諮詢產品分類。
第七章 經濟營運者（Economic
Operators）的義務與責任
7.1 製造商的主要義務
下面引述的法規義務，都是以結果考量的義務，並不是流程性義務。也就是說就算製造商做了所有該做的程序和步驟，只要漏洞仍然出現或猛然冒出來，製造商還是違反CRA條例。沒有任何過失免責的抗辯資格。製造商是 CRA條例的核心義務承擔主體，主要義務涵蓋以下面向：
（一）設計、開發、生產義務（§13 + 附錄I Part I）
●
安全設計（Secure by
Design）：在整個產品開發生命週期（SDLC）中整合資安要求；
●
安全預設值（Secure by
Default）：出廠配置已達最高合理安全水準，沒有任何已知的嚴重漏洞，不使用預設通用密碼；
●
最小攻擊面：僅啟用必要功能，關閉非必要的通訊介面，須預防最常見的攻擊模式；
●
最小權限原則：軟體元件僅具備完成功能所需的最低權限；
●
保護資料完整性與機密性：傳輸及儲存資料必須受到適當加密保護；
●
可更新性：設計時確保產品能安全接收及安裝安全更新，且更新不能降低產品的安全性；
●
不得安裝任何未經使用者同意的軟體；
●
軟體物料清單（SBOM）：識別並管理所有第三方元件，包含開源軟體；
（二）漏洞處理義務（§13 + 附錄I Part
II）
●
建立並維護「協調式漏洞揭露（CVD）」程序，並提供公開聯絡管道（參見EU 2022/2555, §12(1)）；
●
在合理佐證及具備正當理由的情況下，製造商認為公布資訊安全的風險超過資訊安全效益時，可能會延遲公開有關已修復漏洞的資訊，直到使用者獲得適宜地執行相關補丁程式的機會；
●
漏洞發現之後必須在規定的時間內發布修補；免費向使用者提供安全更新及相伴的公告資訊，配合說明建議使用者須採取的因應措施，且安全補丁與功能更新宜分開提供；
●
定期測試及審查產品數位元素的安全性，包括第三者軟體元素的潛在漏洞，宜納入滲透測試的表現情形；
●
在支援期間（Support Period）內持續修補已知漏洞；
（三）通報義務（§14）
●
發現被主動利用的漏洞：24 小時內向 ENISA 及相關 CSIRT 發出早期預警；
●
72 小時內：提交更詳細的通報；
●
14 天內：提交最終報告（含根本原因分析及緩解措施）；
●
重大網路資訊安全事件：同上程序，依嚴重性向市場監督機關通報；
（四）技術文件與符合性義務
●
依附錄VII 建立技術文件，保留到產品暨數位元素最後支援期限結束之後至少兩年。並在係稱產品最後一次放入市場後保存至少 10 年；
●
簽署「EU 符合性聲明」（EU DoC）；
●
依適用分類完成符合性評鑑（自行評鑑或第三方審查）；
●
加貼 CE 標誌及必要標示（製造商名稱、地址、產品識別資訊）；
7.2 歐盟授權代表的義務（§18）
l 保存PDE產品的附錄VII技術文件及「EU 符合性聲明」（EU DoC），從係稱PDE產品放入歐盟市場起算，至少10年，備供市場監督機構索取查閱；
l 應市場監督機構的請求，提供任何資訊及支持性文件
l 配合市場監督機構，採取其命令的任何措施，消除係稱PDE產品風險；
7.3 進口商的義務（§19）
●
確認製造商已完成 附錄VII 技術文件並持有 EU DoC
●
確認產品已正確標示（CE 標誌、製造商資訊）
●
若知悉或有理由相信產品不符合要求，不得將其放入市場
●
在產品上標示自身名稱、商標及聯絡地址（如製造商位於歐盟外）
●
在市場監督機關要求時，保存技術文件至少 10 年備查
7.4 分銷商的義務（§20）
●
在供應 PDE 前確認 CE 標誌存在及必要文件齊備
●
不得在已知不符合 CRA 的情況下繼續供應
●
在市場監督機關調查時配合提供相關文件
7.5 軟體開發者特別指引
許多亞洲軟體開發者誤以為 CRA 只適用於硬體。事實上，以下軟體均在 CRA 範圍內：
●
獨立銷售的應用程式（App）
●
作業系統、韌體（Firmware）
●
供企業或消費者使用的 SaaS（若附帶可安裝的客戶端軟體）
●
嵌入式軟體（Embedded
Software）
對軟體開發者的具體建議：
l 在開發流程中採用「安全開發生命週期（SDL）」，如微軟 SDL 或 OWASP SAMM 架構
l 建立並維護 SBOM，使用 SPDX 或 CycloneDX 格式；
l 設計版本更新機制，確保補丁可在不影響核心功能的情況下部署；
l 建立 CVD 政策頁面，提供 security@yourdomain.com 等聯絡方式；
l 記錄所有安全決策登錄簿（Security Decision Log），納入為技術文件的一部分。
