四步判定法，半導體、模組、SaaS、T-Box 案例解析
收到歐盟客戶來信，要求提供「CRA 合規證明」時，多數廠商的第一反應不是去翻條文，而是焦慮：「我是不是一定得先花錢找顧問，才能知道自己答不答得上這題？」
其實未必。判斷產品是否落在 CRA 適用範圍，有一套多數廠商可以自己先跑一遍的四步邏輯。先照著走完，抓出產品「大概屬於哪一類」，再決定是否需要進一步委託 Gap Analysis，會比一開始就把整題外包，來得省時也省成本。
這套邏輯並非我們自創，而是整理自 Regulation (EU) 2024/2847（Cyber Resilience Act）的官方條文，加上顧問端協助各類廠商判定時累積的實務經驗。以下依序拆解。
CRA 適用於「在商業活動過程中，於歐盟市場提供」的產品（Art. 2(1)）。重點在商業價值，而非售價：即使產品本身免費，只要伴隨商業目的——例如藉此蒐集使用者資料、搭售加值服務——仍屬商業活動。反之，純研究用途、未於歐盟市場流通的產品，第一步即可排除。
CRA 規範的對象是「具數位元素的產品」（product with digital elements），法律定義見 Art. 3(1)：涵蓋軟體與硬體產品及其遠端資料處理解決方案，包含單獨上市的軟硬體零組件；硬體內建電子元件、韌體的產品亦在其中。換言之，不只 App 與系統軟體，一台內建 MCU 的家電、一顆帶韌體的感測器，都可能落在此定義之內。
判定門檻是產品能否透過 Wi-Fi、藍牙、USB 等介面，與外部設備或網路進行直接或間接的邏輯或物理資料連接（此條件規定於 Art. 2(1)，而非定義條款）。只要具備任一連接能力，即符合此步驟的條件。完全孤立、無任何對外資料交換能力的產品相當罕見，多數廠商會在這一步確認自己「進入」了 CRA 的討論範圍。
CRA 明文排除已由其他歐盟法規覆蓋資安要求的產品類別（Art. 2(2)–(8)），主要包括：
另外有兩類產品，經常被誤認為「排除清單」的一部分，但性質其實不同——它們不是被清單排除，而是從一開始就沒有進入 CRA 的門檻：
進入案例解析之前，先提醒一點：屬於某個產業，不等於自動排除。CRA 認的不是產業別，而是「該產品的資安要求是否已被其他歐盟法規覆蓋」。同一產業內，有的產品被排除、有的沒有，須逐項確認。
同樣是 MCU，分類結果可能天差地遠。具防篡改（tamper-resistant）設計的 MCU——例如銀行卡、支付應用所使用者——屬 Important Class II，須經 Notified Body 第三方驗證；僅具基本安全功能、無防篡改機制的一般 MCU，則屬 Class I，可採自我評估——但前提是完整適用相關協調標準；在標準刊登於官方公報之前，這條路徑實務上尚未開通，Class I 產品若須在此期間證明合規，仍須經由 Notified Body。差別不在「是不是晶片」，而在晶片承載的安全功能等級。對半導體廠而言，第一件事是逐一盤點產品線中各型號的安全功能定位，而非以公司或產品線為單位一概而論。對應的垂直協調標準由 CENELEC（CLC/TC 47X）負責：具安全功能的微處理器／微控制器對應 prEN 50765，防篡改微處理器／微控制器對應 prEN 50766，智慧卡平台與安全元件則對應 prEN 50764（屬 Critical 類）。三者均已完成公眾諮詢、進入批准程序——這也正是前述 Class I 自我評估路徑實務上尚未開通的原因：廠商須完整適用的標準，目前尚未刊登於官方公報。
外賣給不同下游品牌廠的通訊模組，天生就是為了「與外部交換資料」而存在，Step 3 幾乎必然成立，通常需要獨立取得 CRA 合規——不能假設下游品牌廠會「順便」涵蓋。這裡最常出現的疑問是：「這類模組不是已經受 RED 指令規範、也做完 EN 18031 認證了嗎？照 Step 4 的邏輯，被其他歐盟法規覆蓋，不就該排除了？」這個疑問正好踩中 Step 4 最容易誤會的一個特例，值得單獨說清楚——見下一節。
純 SaaS 原則上不在 CRA 範圍內。但有一個關鍵例外：如果拿掉這個雲端服務，會讓產品的安全功能失效——例如產品須仰賴雲端才能接收安全更新——該雲平台即構成產品的「遠端資料處理解決方案」（定義見 Art. 3(2)；Recital 12 並以智慧家庭裝置的雲端遙控功能為例說明），必須連同產品一起納入評測範圍。實務建議：通用型 App 或平台，與個別產品分開、單獨送審，避免每推出一項新產品，就得把整個平台重新評估一次。標準對應上，雲端與一般軟體以水平的 EN 40000 系列為主；若軟體本身屬特定分類（作業系統、瀏覽器、密碼管理器等），ETSI 另有對應的 EN 304 6xx 垂直標準草案。
受歐盟車輛型式認證法規（Regulation (EU) 2019/2144）規範的車輛排除於 CRA 之外，但這個排除未必延伸到零組件。若 T-Box 是獨立生產、對外銷售給不同車廠使用的零組件，仍可能需要單獨取得 CRA 合規。「母產品排除」不等於「零組件排除」——這與通報義務一文的邏輯一致：零組件是否適用，是一項獨立判斷。T-Box 目前沒有專屬的垂直標準，適用水平的 EN 40000 系列；其內建的通訊模組與安全晶片，則可能各自對應前述模組與半導體的標準。
Step 4 的排除邏輯，前提是歐盟「選擇讓另一部法規繼續主管」——醫療器材歸 MDR／IVDR、汽車歸車輛型式認證法規、航空與船用設備各有其法。這些領域的資安要求由原法規持續覆蓋，CRA 才明文退讓。
但 RED 走的是完全相反的路：歐盟並未把無線電設備排除於 CRA 之外，而是決定把 RED 底下的資安要求「交棒」給 CRA。執委會已於 2026 年 2 月通過授權法規 Regulation (EU) 2026/339（4 月 29 日刊登於歐盟官方公報），明定 RED 資安授權法規（Delegated Regulation (EU) 2022/30）自 2027 年 12 月 11 日起廢止——正是 CRA 全面適用的同一天，無縫交接、不產生雙重義務。換言之，「被 RED 覆蓋」的正確解讀不是「被 CRA 排除」，而是「你的主管法規正在換成 CRA」。
對已在 RED 範圍內的廠商，時間表是這樣走的：2025 年 8 月 1 日起，RED 資安要求（Art. 3(3)(d)(e)(f)）生效，EN 18031 為其合規推定依據（EN 18031-1／-2／-3 於 2025 年 1 月經執委會施行決定引用刊登於歐盟官方公報，附帶部分限制條件）；2026 年 9 月 11 日起，CRA Article 14 通報義務生效，兩法進入並行期——同一顆模組，既要維持 EN 18031 合規，也要履行 CRA 通報義務；2027 年 12 月 11 日，RED 資安授權法規廢止，CRA 全面接手。
已完成 EN 18031 認證的投入，並不會歸零。EN 18031 三部曲（網路保護、個資保護、金融交易安全）與 CRA Annex I 第一部分的技術要求有實質重疊——存取控制、加密通訊、安全更新機制、預設安全組態等，既有的技術控制與測試證據，都是 CRA 技術文件與 gap analysis 的現成起點。但 CRA 新增的義務仍是全新的：弱點處理流程與 CVD 政策、Article 14 通報義務、SBOM、支援期間承諾，這些 EN 18031 都未涵蓋。
關於時間軸還有一點要補充：2027 年 12 月 11 日之後，合規將主要改依 CRA 協調標準證明，而非透過 EN 18031 的合規推定。這些標準仍在制定中——包含適用所有數位產品的水平標準（EN 40000 系列，依 CEN／CENELEC 已釋出的方向，其通用技術要求 EN 40000-1-4 預計以 EN 18031 的技術基礎為底），以及依產品類別制定的垂直標準（軟體與網通類由 ETSI 制定 EN 304 6xx 系列，半導體類由 CENELEC 制定 EN 50764–50766）。正因協調標準延續同一套技術基礎，依 EN 18031 完成的工作仍可直接沿用——改變的是證明合規的法律依據，而不是底層的工程投入。
最後，這一節還照出另一群讀者：產品沒有無線介面的廠商——純有線設備、純軟體。這些產品從來不在 RED 範圍內，過去不曾面對歐盟的產品資安法規，也因此最容易誤以為「資安合規與我無關」。CRA 是技術中立的，只要走完前面四步、確認落在範圍內，這將是他們第一次被歐盟產品資安法規接住——沒有既有認證可以沿用，更需要及早盤點。
誤解一：「我的產品是舊款，應該不用管。」舊品在架、未經實質修改者確實不受影響；但只要進行實質性修改，該修改版本起就須合規。「舊款」不是永久豁免，而是一個隨改版而失效的狀態。
誤解二：「海關沒卡我，應該就沒事。」海關查驗只是進口端的一道關卡。產品進入歐盟市場後，各會員國的市場監督機關仍可能抽查；責任不會因為繞過了海關而消失。
誤解三：「客戶是跟美國網站下載的，跟歐盟版不算同一個。」CRA 的適用與下載來源無關。只要產品在歐盟市場流通、具商業價值，不論使用者從哪個網站、哪個地區的管道取得，均落在適用範圍內。
適用範圍判定只是第一步。判定產品落在 CRA 範圍之後，接下來還有一連串工作：確認產品的風險分類（Default、Important 或 Critical）、選擇符合性評估模組（自我評估或第三方驗證）、建置弱點通報義務所需的內部流程——這些在本系列其他文章中均有說明。
如果照著四步判定法走完，仍難以確定自家產品的定位，或是判斷完成後希望有專業意見協助覆核，歡迎與我們聊聊。歡迎參加 9 月 18 日（五）台北實體研討會，直接向來自西班牙的 CRA 專家提問，進一步說明 2027 合規規劃佈局及導入所需的時間與成本估算。報名連結：實體研討會報名連結
Q：如何判斷產品是否屬於 CRA 範圍？
用四個步驟來檢查：（1）是否在歐盟市場並具有商業價值；（2）是否具備數位元素；（3）是否可能與外部交換資料；（4）是否屬於排除清單（醫療、車輛、航空、航海用途等）。如果前三個步驟都是「是」，第四步是「否」，則落入範圍。
Q：純 SaaS 需要 CRA 嗎？
純 SaaS 原則上不是 CRA 定義的「產品」，也不在範圍內。但若是產品「遠端資料處理方案」——拿掉它產品安全功能無法運作——則將納入產品的評估範圍。
Q：產品已經符合 RED/EN 18031 規範，還需要做 CRA 嗎？
需要。「受 RED 涵蓋」並不代表「被 CRA 排除」——RED 的網路安全要求將於 2027 年 12 月 11 日移交給 CRA。現有的 EN 18031 技術控制與測試文件可繼續使用，但 CRA 新增的義務（漏洞管理、SBOM、通知、支援期）仍需補齊。
Q：舊型號是否需要 CRA 認證？
市面上已流通且未經實質修改的舊產品，基本網路安全要求不會追溯適用。然而，一旦做了影響安全功能進行重大修改，從該版本起必須符合 CRA；Article 14 的通報義務則不考慮上市日期，一律適用。
本文所引法規條文與時間點，均以下列官方文件為準：
文／安合規律 × Applus+ Laboratories 顧問團隊
＊本文為法規解讀性質，非法律意見。個案適用範圍之最終認定，仍應以歐盟官方文件與主管機關解釋為準。
