寫在前面：
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

做 CRA 盤點後，我碰到的第一個問題不是 Security Control
Day 1 提到：如果重新開始 CRA，我可能會先把 Product 看清楚。
但真的開始盤點後，問題馬上來了：
「到底哪些東西算 CRA 的 Product？」
一開始我也很容易用「有沒有連網」來想。
例如：
Router → 應該要看。
IoT Camera → 應該要看。
Connected Device → 應該要看。
那沒有 Wi-Fi、Ethernet 的東西呢？
例如：
MCU？
Memory？
Embedded Software？
SDK？
Driver？
是不是沒有 Internet Connection，就跟 CRA 無關？
後來重新讀 CRA 的定義，我覺得事情沒有這麼簡單。

一、先從 Product with Digital Elements 的定義開始
CRA Article 3 對Product with Digital Elements（PDE）的定義，大意是：
一項 Software 或 Hardware Product，以及其 Remote Data Processing Solutions，包含單獨上市的 Software 或 Hardware Components。
但還有另一個很重要的條件。
CRA Article 2 的適用範圍，主要涵蓋其預期用途（Intended Purpose）或可合理預見的使用方式（Reasonably Foreseeable Use），包含與裝置或網路建立直接或間接（Direct or Indirect）的邏輯或實體（Logical or Physica）資料連線之 Products with Digital Elements。
我第一次看到這裡時，特別注意的是：
Direct or Indirect。以及Logical or Physical。
這讓我覺得如果只用「能不能直接上 Internet」來篩 CRA Scope，可能會篩得太快。

二、不是只有 Wi-Fi / Ethernet 才叫 Connection
這點對 ICT Product 比較容易理解。
Router：Ethernet / Wi-Fi。
NAS：Network Connection。
IoT Device：Wireless Connection。
這些相對較直覺。
但 CRA 使用的文字並不是只有 Internet Connection。而是Data Connection。
而且可以是 Direct / Indirect、Logical / Physical。
所以我自己在做 Applicability Assessment 時會把問題稍微放寬。
不是只問：「它會不會上網？」
而是問：「它在 Intended Purpose 或 Reasonably Foreseeable Use 下，會不會跟其他 Device / Network 發生 Data Connection？」
這兩個問題看起來很像，但實務上可能差很多。

三、例如 USB 呢？
假設一個 Hardware Product沒有Wi-Fi。沒有Ethernet。但它可以透過 USB 跟 Computer 交換 Data。
如果我們第一輪篩選條件只有Internet Connected = Yes / No，它可能直接被排掉。
但看到 CRA 的Physical Data Connection，我自己就不會這麼快下結論。至少我會再往下看它的 Intended Purpose、Product Function 與實際使用方式。
這也是我目前做 CRA Product Inventory 時覺得「Connection Type」值得留下來的原因。

四、這件事放到 Semiconductor，就更有意思
假設一顆 MCU，它自己沒有 Wi-Fi，也沒有 Ethernet。是不是就可以直接判定 CRA N/A？
我目前不會這麼快判。因為 MCU 本身可能透過：
SPI、UART、USB、CAN、PCIe等 Interface跟其他 Device 交換 Data。
而它的 Intended Purpose本來就可能是被整合到另一個 Digital Product。
這時我會想再確認 CRA 對Product、Component、Connection的實際適用方式。
但這裡也要很小心，有 Interface，不代表我就會直接說一定適用 CRA。
因為Scope 判斷還是需要回到完整產品情境。

五、Memory 又更有趣
例如DRAM，它當然不是我們一般理解的 Internet-connected Product。
但它本來就是透過 Physical Interface 與 Processor / System 交換 Data。
那CRA 到底怎麼看？
我自己會覺得這種 Product 不適合只靠「有沒有網路」這一題決定。
可能還需要進一步看：
Product 本身如何被 Made Available on the Market？
是否屬於 Software / Hardware Product 或 Component？
Intended Purpose 是什麼？
是否符合 CRA Scope 的 Connection 條件？
是否存在其他 Exclusion 或適用規則？
這些才比較接近完整的 Applicability Analysis。至於特定 DRAM、Flash 或其他 Semiconductor Product 最後是否落入 CRA，則不會在這裡直接替所有產品下一個共同結論。因為Product Architecture 與 Commercial Model 可能都不完全一樣。

六、「Component」也是我一開始很容易誤解的地方
直覺上Component 很容易讓人想到：
「只是別人產品的一部分，所以應該不用管 CRA。」
但 CRA Article 3 對 Product with Digital Elements 的定義本身就提到：software or hardware components being placed on the market separately。
所以「它是 Component」，本身不一定足以直接判定 N/A。
這對 Semiconductor特別值得注意。因為IC 很多時候本來就是 Component。
但它也可能以獨立 Part Number，被 Manufacturer Made Available on the Market。
所以我自己現在會把Component 跟 是否落入 CRA Scope分成兩個問題看。

七、Software 也是 Product
另一個我覺得需要轉換觀念的地方CRA 不只管 Hardware。
Software也可能是 Product with Digital Elements。
例如：Operating System、Application Software、Security Software、Network Management Software等。都可能需要依實際情況評估。
所以如果公司盤點 CRA，只請 Hardware Product Team 填資料，可能還不夠。
尤其有些 Hardware Manufacturer除了 Hardware，還會提供：
Firmware
SDK
Driver
Configuration Tool
Management Software。
這時，哪些是 Product 的一部分？哪些是單獨 Made Available on the Market 的 Software？我覺得很值得一起盤點。

八、Semiconductor 常見的 SDK，我自己也會特別標出來
例如 MCU Manufacturer，除了 Chip，還提供SDK。
SDK 裡可能有Driver、Library、Security Function、Sample Code、Middleware。
這時我不會看到「免費下載」就直接判定跟 CRA 無關。因為 CRA 對Commercial Activity的概念，並不完全等同於「這個 Software 有沒有另外收費」。
這個議題後面談 Open Source Software 時，我們會再碰到。目前我自己比較傾向先把它列出來，再判斷。不要在 Product Inventory 階段就先漏掉。

九、Remote Data Processing Solution 也不能忘記
CRA 對 Product with Digital Elements 的定義，還包含：Remote Data Processing Solutions。
但並不是Product Manufacturer 使用的所有 Cloud Service都自動變成 CRA Product 的一部分。CRA 關注的是：
我自己在理解這個概念時，會把它想成：Hardware 雖然在 User 手上，但產品有一部分 Function 其實在 Cloud。
如果這個 Cloud 端的 Remote Data Processing Solution 是由 Manufacturer 自行設計、開發，或由 Manufacturer 負責其設計與開發，而且少了它，產品就無法執行部分功能，那麼在判斷 CRA Scope 時，就不能只看 User 手上的 Hardware。

十、例如 Smart Camera + Cloud
假設Smart Camera本地端可以拍攝。但Security Event Analysis 或某個核心功能必須透過 Manufacturer Cloud 才能完成。那這個 Cloud Function是否屬於 CRA 所稱 Remote Data Processing Solution，我覺得就值得進一步分析。
反過來，公司內部用 Salesforce 管客戶，或者 用 Microsoft 365 管文件，顯然不能因為 Manufacturer 使用 Cloud，就全部算進某個 Product 的 CRA Scope。
所以還是要回到：它跟 Product Function 的關係。

十一、那 SaaS 呢？
這也是很容易讓人混淆的地方。CRA並不是把所有 SaaS / Cloud Service 都直接納入。某些 Cloud Services可能主要受到其他 EU Cybersecurity Regulatory Framework 規範。
而 CRA特別處理的是跟 Product Function 緊密結合的Remote Data Processing Solution。
所以如果公司同時有：Hardware + Cloud Service，我自己不會看到 Cloud 就全部算，也不會看到 SaaS 就全部排除。比較像逐一看它跟 Product 的關係。

十二、Scope 還有 Exclusions
CRA也不是所有符合前面概念的 Digital Product 都一定納入。
Article 2：
有一些特定排除或與其他 Union Legislation 的關係。例如部分受到特定 EU Sectoral Legislation 規範的產品：
Medical Devices
In-vitro Diagnostic Medical Devices
Motor Vehicles
Civil Aviation等，
可能有不同的適用處理。
所以我自己在做 Scope Analysis 時，不會停在：「它是不是 Digital Product？」
後面還會再問：「有沒有 CRA Exclusion？」

十三、Open Source Software 也不是一句「OSS 不適用」就結束
CRA 對Free and Open-source Software有特別的安排。簡單來說，在 Commercial Activity 之外開發或提供的 Free and Open-source Software，不會因為只是 OSS，就跟商業 Product 完全用相同方式處理。
但如果Software 被放在 Commercial Activity 的情境，判斷又可能不同。
而 CRA還另外建立了Open-source Software Steward的角色。
這個部分我覺得值得獨立談，所以先聊到這裡。

十四、做到這裡，我開始覺得 Product Inventory 不能只有「產品名稱」
如果公司問「請列出所有 CRA Product。」
我自己現在不太會直接丟一張只有 Product Name 的 Excel。
至少第一輪我可能會希望知道：
Product / Product Family
Hardware / Software
Function
Connection Type
Firmware / Software
SDK / Driver
Remote Data Processing
EU Market
Manufacturer / Importer / Distributor Role
Possible Exclusion。
不一定第一次就全部填得很精準。但至少可以讓後面的 Applicability Discussion 有基礎。

十五、而且我會把「不知道」留下來
以前做 Compliance Inventory很容易希望每一格：Yes / No。
但 CRA Product Scope有些產品第一輪真的不一定能立即判。
例如Semiconductor Component可能需要Product Team、R&D、Legal / Compliance一起看。
所以我自己反而會接受第三種狀態TBD / Further Assessment Required。
因為暫時不知道，可能比為了完成 Excel 而太早填一個 No，安全很多。

十六、Applicability 跟 Classification 也不要太早混在一起
這也是我自己剛開始很容易混淆的地方。
第一題應該是CRA 適不適用？也就是Applicability確認適用後才再看它屬於哪一類 Product？也就是後面會碰到的：
Default
Important Class I
Important Class II
Critical。
如果Scope 都還沒有確認，就直接問：「這顆 IC 是 Class I 還 Class II？」我自己覺得順序可能有點快。

十七、所以我現在會把 CRA Product 判斷想成一個 Funnel
第一層：它是不是 Product with Digital Elements？
↓
第二層：Intended Purpose / Reasonably Foreseeable Use 是否涉及 Direct / Indirect Logical or Physical Data Connection？
↓
第三層：是否存在 CRA Exclusion 或其他特殊規則？
↓
第四層：公司在 EU Market 中是什麼 Economic Operator？
↓
第五層：如果適用，Product Classification 是什麼？

我自己覺得這樣比較不容易一開始就跳到最後一題。

十八、ICT 跟 Semiconductor，最後可能需要不同的盤點方式
對 ICT：Model、Firmware、Cloud Function、Network Interface 可能比較直覺。
但 Semiconductor可能需要更多：
Part Number
Product Family
Silicon Revision
Firmware
SDK
Driver
Security Function
Integration Model。
所以CRA Product Inventory我自己不一定會要求全公司只用一張完全相同的 Template。至少有些欄位可能要依 Product Type 調整。

Day 2 小結｜「沒有 Internet」不是會用來直接排除 CRA 的理由
研究到這裡我自己最大的觀念調整，就是CRA Scope 不宜只用「有沒有上網」來理解。
因為 CRA 講的是Direct or Indirect, Logical or Physical, Data Connection。
而 Product with Digital Elements也可能包含 Software、Hardware、單獨上市的 Components，以及符合條件的 Remote Data Processing Solutions。
這對 ICT相對容易想像。但到了Semiconductor，就可能需要更細緻的 Product-level Analysis。
所以現在如果有人問：
「這顆 IC 沒有 Wi-Fi，所以 CRA 不適用吧？」我大概不會立刻回答Yes 或 No。而會先問：
它是什麼 Product？
怎麼使用？
怎麼連接？
怎麼上市？
公司扮演什麼角色？
有沒有其他適用或排除條件？
這些問題對我來說，可能才是CRA Scope Analysis 真正的開始。
當然，以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
特別是 Semiconductor、Software、Remote Data Processing Solution 與 Open Source Software實際產品情境可能差異很大。
所以還是應回到 CRA 正式條文與最新 Guidance，逐案確認。

Day 3 預告｜產品確定進 CRA 之後，下一題不是「要做 CE 嗎？」而是：它到底是哪一類？
如果 Day 2：
我們確認某個 Product 可能落入 CRA Scope，下一個很自然的問題就是：
「那它是哪一類？」
CRA 裡並不是所有 Product都用完全相同的Conformity Assessment Route。
我們會開始碰到Default Product、Important Product Class I、Important Product Class II以及Critical Product。
Router怎麼看？
Firewall怎麼看？
Operating System怎麼看？
那MCU、Memory、Security IC 呢？
Day 3：我們就來聊CRA Product Classification。