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

一開始，我以為這又是一個 Compliance Project
第一次比較認真接觸 CRA 時，我的直覺其實很單純：
「一部跟 Cybersecurity 有關的歐盟法規。」
做資安治理或 Compliance 的人，對這種情境應該不陌生。
新的法規進來，第一件事情通常就是：
Scope 是什麼？
哪些產品適用？
什麼時候生效？
要做哪些 Gap Analysis？
要新增哪些 Process？
要準備哪些文件？
所以一開始，我也是用自己比較熟悉的方式去看 CRA。但資料越看越多，我開始覺得，CRA 好像不能只用傳統企業資訊安全管理的角度來理解。
因為它關心的核心，不只是公司內部的 IT Environment，而是 Product。
而且是 Product 從設計、開發、上市，到後續維護與 Vulnerability Handling 的一整段生命週期。
這讓我開始重新調整自己看 CRA 的方式。

CRA 是什麼？
CRA，全名：Cyber Resilience Act
正式名稱是：Regulation (EU) 2024/2847
它主要針對Products with Digital Elements建立橫向的 Cybersecurity Requirements。
European Commission 對 CRA 的說明，簡單來說，就是希望在歐盟市場提供的數位產品具備較適當的 Cybersecurity，並讓 Manufacturer 在產品生命週期中承擔相應的安全責任。
CRA 已於2024 年 12 月 10 日生效。但它不是所有要求在同一天開始適用。
目前很值得記住的兩個時間點是：
2026/09/11部分 Reporting Obligations 開始適用。
以及2027/12/11 CRA主要要求全面適用。
也就是說，現在並不是「2027 年再來研究就好。」
至少對 Vulnerability / Incident Reporting 相關準備而言，時間其實已經很近。

Products with Digital Elements？
這是我一開始很想先搞懂的名詞。因為看到「Digital Product」，很容易先想到：Software。
但 CRA 的範圍其實不只是 Software。
CRA 對 Product with Digital Elements 的概念，涵蓋符合條件的Software 或 Hardware Product，以及其Remote Data Processing Solutions
而且 Product 的 Intended Purpose 或 Reasonably Foreseeable Use，涉及與 Device 或 Network 的直接或間接 Data Connection。所以可能涉及的產品範圍很廣。例如 ICT 領域常見的Router、Firewall、NAS、Operating System、IoT Device、Network Equipment、Software Product……
都可能需要進一步評估。
但對我自己目前工作環境來說來說，更有意思的另一個問題，那 Semiconductor 呢？

一顆 IC，也可能需要看 CRA？
第一次看到 CRA 時，如果只從「Cybersecurity Product」的直覺出發，可能會覺得：
Router 有 CRA，可理解。IoT Device 有 CRA，也可理解。但Memory、MCU、SoC、Security IC 呢？
這時事情就開始變得有意思。例如一顆 MCU：
有 Processing Capability。可能還有Secure Boot、Cryptographic Function、Firmware、SDK、Communication Interface。
它最後可能被整合進Industrial Equipment、Automotive-related System、IoT Device、Consumer Electronics。
那麼我們可能就不能只問「它是不是一顆 Chip？」，而是要進一步看它是不是 CRA 所稱的 Product with Digital Elements？
它如何被放到 EU Market？
Intended Purpose 是什麼？
是否存在 CRA 的 Exclusion 或特殊法規情況？
這也是我開始研究 CRA 後的一個心得：
Product Applicability 可能比想像中更需要逐項判斷。
因為實際情況可能還需要看Product Function、Market Role、Integration Model 與適用法規。

CRA 也讓我重新思考「Cybersecurity 到底是誰的工作？」
如果今天公司內部Firewall 被攻擊。我們可能會想到：SOC、IT Security、Incident Response……。
但如果今天是公司賣出去的 Product 發現 Vulnerability，事情就不太一樣了。
例如一台 Router發現 Authentication Bypass；或者某個 Semiconductor Product 搭配的Firmware / SDK出現 Security Issue。這時可能需要參與的人，就不只有傳統 Security Team。可能還包括：
R&D、Product Security、Product Management、QA、Legal / Compliance、Sales / FAE、Supply Chain、Customer Support……。
所以我現在比較傾向把 CRA 看成：一個需要跨 Product Lifecycle 協作的 Cybersecurity Regulation。
至於每家公司最後怎麼分工則不一定會有完全相同的答案。

第一個讓我真正有「時間壓力」的，是 Article 14
如果問我2026 年現在研究 CRA，哪一件事情最容易讓企業先有時間感？
我自己會選Article 14 Reporting Obligations。
CRA 對符合條件的Actively Exploited Vulnerability，以及Severe Incident having an impact on the security of the product with digital elements建立了相關 Reporting Requirements。
其中 Actively Exploited Vulnerability 的 Early Warning，原則上需要在 Manufacturer aware 後24 小時內提出；後續還有 Notification 與 Final Report 等要求。
這些 Reporting Obligations在2026/09/11就開始適用。
所以當我看到這裡時，第一個想到的反而不是「我們有沒有一份 CRA Incident Procedure？」
而是「如果明天真的收到一個 Product Vulnerability，我們 24 小時內做得到什麼？」
這兩件事情好像不完全一樣。

用 Router 想一次
假設星期五下午5點，公司收到 Security Researcher 通知：某款 Router 存在 Vulnerability。
接下來可能要問：
這個 Vulnerability 是真的嗎？
哪些 Firmware Version 受影響？
有沒有被利用的跡象？
Product 有沒有在 EU Market？
哪些 Member States？
誰負責判斷 CRA Reporting？
誰可以進 Reporting Platform？
如果這些資訊：
分散在五、六個不同部門，那 24 小時可能一下就過去了。

再換成 Semiconductor 想一次
假設：Friday Evening，Third-party Component Supplier 通知某個 Cryptographic IP IP 存在 Vulnerability。
公司第一時間可能還不知道：
哪些 Product 使用這個 IP？
接著可能要查：
哪些 Part Number？
哪些 Silicon Revision？
Firmware / SDK 是否受影響？
Customer 怎麼使用？
是否真的存在 Exploit Path？
哪些產品已經進 EU？
這時我才開始覺得：
CRA Reporting 看起來是在談「通報」。
但背後真正考驗的：
可能是公司的 Product Traceability、Vulnerability Management 與跨部門協作能力。

然後，我開始看到 SBOM，前面那個問題「哪些 Product 使用這個 Vulnerable Component？」
很自然就會把我帶到SBOM — Software Bill of Materials。
以前看到 SBOM很容易把它理解成 Software Ingredient List。
但放進 CRA 的 Product Lifecycle 後，我開始覺得SBOM 的價值可能不是「我有沒有產出一份表」。而是 Vulnerability 發生時能不能很快知道哪些 Product 可能受影響。
這又把 CRA從 Compliance Document帶回Operational Capability。(SBOM 後面我們會另外花一天談)
因為光是「有 SBOM」跟「SBOM 真的能用」也許中間可能還有一段距離。

接著還有 Secure Development
CRA Annex I：
不只是談 Vulnerability Reporting。它也對 Product 的Cybersecurity Properties，以及Vulnerability Handling提出 Essential Cybersecurity Requirements。
這就開始碰到：
Security by Design
Risk Assessment
Secure Development
Security Testing
Vulnerability Remediation
Security Update。
所以我逐漸發現CRA 不是等 Product 做完，再請 Compliance Team補文件、做 CE。而是很多 Cybersecurity Requirement可能要更早進 Product Development Lifecycle。

這也是我開始想到 IEC 62443 的地方
如果公司本來就在做Industrial Cybersecurity，可能已經很熟IEC 62443。
尤其IEC 62443-4-1本來就涉及Secure Product Development Lifecycle。
所以我自己研究 CRA 時也會自然想問：
既有 IEC 62443 能不能拿來支援 CRA？
我目前的看法是很值得 Mapping。
但IEC 62443 不等於 CRA。
一個是Cybersecurity Standard。一個是EU Regulation。
未來 CRA 還會搭配Harmonised Standards與Presumption of Conformity等機制。這部分我們後面也會慢慢談。

還有正在發展的 CRA Standards
2026 年這個時間點其實滿特別。因為CRA 已經生效。但Harmonised Standards還在陸續發展。
European Commission 已透過 Standardisation Request M/606 推動 CRA 相關 Horizontal 與 Product-specific Standards，希望把 Essential Cybersecurity Requirements 進一步轉成可操作的 Technical Specifications。
其中EN 40000 系列就是後續值得關注的發展之一。
但在目前階段會特別注意 Draft、正式 Publication，以及未來是否取得 Harmonised Standard 地位之間的差異。
也就是不會因為看到一個 Draft Standard，就直接把它當成歐盟已經正式接受的唯一 CRA Compliance Method。

所以，我現在怎麼看 CRA？
走到目前我自己的理解其實還在持續調整。但如果要用一張很簡單的圖來表示：

Product
↓
Cybersecurity Risk Assessment
↓
Secure Development
↓
Component / Supplier Security
↓
Security Testing
↓
SBOM / Technical Evidence
↓
Conformity Assessment
↓
EU Market
↓
Vulnerability Monitoring
↓
Article 14 Reporting / Security Update
↓
Support Period / End of Support

這條線：
大概就是我現在理解 CRA 的方式。不是某一個 Security Control。
也不是某一份 Compliance Document。
而比較像Cybersecurity 開始跟著 Product 一起走完整個 Lifecycle。

Day 1 小結｜先把 Product看清楚
如果今天剛開始接觸 CRA，我可能會先瞭解我們
有哪些 Product？
哪些進 EU？
哪些有 Software / Firmware？
哪些有 Network Capability？
哪些使用 Third-party Component？
哪些可能需要 Security Update？
哪些：Lifecycle 很長？
因為Product Map 沒畫出來，後面的Risk Assessment、SBOM、PSIRT、Conformity Assessment可能都很難真正落地。
所以 Day 1：
我自己覺得很重要的一個思維轉變：
CRA 讓我開始從「保護公司的資訊系統」，往前多看了一步：「我們交到客戶手上的產品，整個生命週期要怎麼維持 Cybersecurity？」
至於答案我現在也還在學。而這正是我想寫這 30 天的原因。
希望接下來一天一個主題。把自己目前看到的 CRA一點一點整理出來，也和大家一起交流。

Day 2 預告｜不是有網路才算 CRA？我開始重新理解「Product with Digital Elements」
第一天我們先從大方向看 CRA。但真正開始盤點 Product，第一個問題馬上就來了：
「到底什麼產品算 Product with Digital Elements？」
一定要Connected to Internet才算嗎？
沒有 Wi-Fi 的Hardware是不是就不算？
一顆MCU、Memory、Security IC到底要怎麼看？
Software又有哪些情況可能進 Scope？
Day 2，我想從 CRA 最基本、但實務上可能也是最容易一開始就卡住的問題開始：我們的產品，到底是不是 CRA 管的？