歐盟執委會關於 CRA 的指引

01這是什麼

Art. 26 要求執委會發布指引，協助經濟營運者適用 CRA，並特別著重使中小企業更容易達成合規。於 27 July 2026 執委會通過該指引之內容（文件編號 C(2026) 5252）。全文約 80 頁，逐一解答製造商最常提出的問題。

指引為 不具拘束力 且不會改變法律本身：CRA 之權威解釋僅能由歐盟法院作出。惟市場監督機關與公告機構仍會參照該指引，以求一致且協調之解讀，故其為本法規之自然配套文件。

02何謂產品

指引篇幅最大的部分，關於 適用範圍，是最常被詢問的領域。具數位元素之產品是指其使用包含直接或間接資料連線的軟體或硬體產品（及其遠端資料處理）。 Art. 3(1)

• 軟體執行之處決定其歸類；於使用者裝置上執行的軟體（下載安裝的應用程式、瀏覽器擴充功能、本機安裝的用戶端）屬於具數位元素之產品。僅透過瀏覽器遠端存取的軟體，單憑此點並不屬於此類。
• 網頁應用程式與網站；僅透過瀏覽器使用的網頁應用程式，以及僅呈現資訊的網站，通常不屬於具數位元素之產品。僅在其構成支援產品功能之遠端資料處理時，才會納入適用範圍。
• 原始碼；CRA 對軟體的定義涵蓋機器碼與原始碼，惟僅將開放原始碼於公開儲存庫中分享，通常不構成「上市」。 Art. 3(4)

若您不確定您的產品屬於哪一類別， 快速檢測 以及 淺白文字說明 說明實務上適用範圍之判斷方式。

03開源軟體

指引詳細規範針對開放原始碼量身打造之較寬鬆制度。於商業活動範圍外開發之非商業性開放原始碼軟體，大致不在適用範圍內；觸發適用之關鍵在於 商業活動 以及該軟體是否上市。

• FOSS 於何種情形下屬於「上市」；指引逐一探討收取費用、將相關服務貨幣化或要求提供個人資料、付費支援、捐款、融資安排與非營利架構，以及其他製造商整合 FOSS 等情形。
• 開放原始碼軟體維護者；一套明確且合乎比例的義務，著重於支援軟體的安全性與持續可行性。
• 重要的 FOSS；以自由與開放原始碼軟體形式上市之重要產品（第一類或第二類）得適用較寬鬆之預設類別符合性程序。 Art. 32(5)

04重大變更

變更是否屬於 substantial modification 決定是否需要新的符合性評估。Recital 39 對此作出說明：若變更以製造商於其風險評估中尚未考量之方式，改變產品之網路安全風險程度，該產品即屬經重大修改。 Art. 3(30)

• 安全更新通常不構成重大變更；其目的在於降低風險，因此若安全修補未改變產品的預期用途，亦未引入新風險，單憑此點並不構成重大變更。
• 重點在於風險，而非規模；判斷標準在於該變更對網路安全風險狀況的影響（新的威脅途徑、新的攻擊情境，或可能性或影響程度的改變），而非變更的規模。
• 後果；經重大修改之產品將被視為重新上市。若由原製造商以外之人進行變更，該人須就經修改部分承擔製造商義務。 Art. 21 · 22

該 CE 標誌指南 涵蓋因重新上市所觸發之符合性評估。

05支援期間

支援期間係指必須處理漏洞之期間，其長度應反映產品 合理預期會使用. Art. 13(8)

• 五年為下限，而非預設值；除非產品預期使用期間較短，否則該期間至少須為五年。合理預期使用期間較長之產品，其支援期間亦應較長。
• 告知使用者；於購買時載明結束日期（至少須包含月份與年份），並於技術可行時，在期限屆滿時通知使用者。 Art. 13(19)
• 軟體的彈性措施；在符合特定條件下，製造商得僅於最新版本中修復漏洞，惟使用者須能免費且無須額外費用升級。 Art. 13(10)
• 重大變更後；須依相同標準重新評估該期間；該期間不會自動重新起算或延長。

您可運用 支援期間與生命週期終止規劃工具.

06重要與關鍵產品

分類決定符合性途徑。產品屬於 重要 if its 核心功能 符合 Annex III 之類別（第一類或第二類），且 關鍵 若符合 Annex IV；其餘則為得自我評估之預設產品。 Art. 7 · 8 · 32

• 核心功能為判斷標準；產品若欠缺該等主要功能，即無法達成其預期用途。附屬功能不會改變類別，僅整合重要或關鍵元件，亦不會使整個產品成為重要或關鍵產品：內嵌作業系統的智慧型手機，本身並非「作業系統」。
• 單一核心功能；就選擇符合性途徑而言，產品被視為僅具單一核心功能，並於其技術文件中予以指明。
• 類別定義；重要與關鍵類別之技術說明，載於 Commission Implementing Regulation (EU) 2025/2392。

將您的產品對照各類別進行比對，可使用 產品類別查詢工具.

07遠端資料處理

遠端資料處理解決方案僅於符合以下情形時，方屬具數位元素產品的一部分： 產品執行其功能所必要. Art. 3(2) 指引提供一項實務判斷標準：該處理是否於「遠端」進行；若欠缺該處理，是否會導致產品無法執行其某項功能；以及該軟體是否由製造商設計開發，或在製造商之責任下設計開發。

指引以實際案例（行動銀行應用程式、智慧型溫控器、電子書閱讀器、工業機器人及行動通訊網路）說明此判斷標準，展現產品與純粹服務之間的界線所在。

08通報與漏洞

指引亦闡明持續性義務： Article 14 reporting 主動被利用的漏洞與嚴重事件，以及 Annex I vulnerability-handling 要求：向上游通報並分享安全修補、處理已知可被利用之漏洞，以及執行有效且定期的安全測試與審查。 Art. 14 · Annex I

09其他官方資料來源

本指引可與另外兩項值得一併閱讀之官方參考資料相互對照。

協調標準。 下列文件中的基本要求： 附件 I 係以結果導向方式撰寫；相關協調標準一經於官方公報中引用，遵循該標準即產生符合性推定。執委會的標準化請求 M/606 已於 2025 年獲 CEN、CENELEC 及 ETSI 接受，涵蓋約 41 項標準。兩項核心橫向標準（安全開發與漏洞處理）預計於 30 August 2026 前完成，垂直產品標準預計於 30 October 2026 前完成，其餘橫向標準則預計於 30 October 2027 前完成，約為全面適用前一年。