寫在前面：

這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。

CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

走到 Day 29，今天我想稍微離開法條與 Checklist，不再增加新的 Requirement，而是回頭整理這一路研究下來，我自己對 CRA 的一些感受與觀察。

一開始研究 CRA，我最先看到的是「很多事情要做」

第一次把 CRA 展開來看，很容易看到一長串工作：

Product Classification、Cybersecurity Risk Assessment、SSDLC、SBOM、Vulnerability Handling、Article 14 Reporting、Technical Documentation、Conformity Assessment、EU Declaration of Conformity、CE Marking……

坦白說，一開始真的很容易把 CRA 看成一個龐大的 Compliance Project。
於是我們開始列 Requirement、找 Owner、寫 Procedure、做 Gap Assessment、排 Roadmap、追進度。
這些當然都需要。

但一路研究到 Day 29，我自己反而開始覺得：
如果最後只把 CRA 理解成「多了一套歐盟法規要符合」，好像少看了一些東西。

因為它真正影響的，可能不只是 Compliance，而是：
企業怎麼做 Product。

一、第一個改變：Cybersecurity 開始真正走進 Product

過去談 Cybersecurity，很多人第一個想到的可能是 Firewall、SOC、SIEM、EDR、Phishing、Server Vulnerability。
這些當然都很重要。
但 CRA 把視角往另一個方向拉：Product。
問題開始變成：
Product 本身安全嗎？
Product 有哪些 Attack Surface？
Product 裡用了哪些 Components？
Product 被發現 Vulnerability 怎麼辦？
Product 要支援多久？
Security Update 怎麼提供？
Product Change 之後 Risk 有沒有改變？
這跟傳統 Corporate IT Security，其實是很不一樣的視角。
所以我自己一路研究下來，第一個很深的感受就是：
Cybersecurity 正在從 IT Infrastructure，進一步走向 Product Lifecycle。
Security Team 要看的，不再只有公司自己的 Server、Endpoint、Network，而開始一路看到客戶手上的 Product。

二、第二個改變：Security 不再只是 Release 前的檢查

如果 Security 到 Product 快 Release 才進來，然後說：「我們來做一次 Penetration Test。」
結果一測發現 Architecture 本身有問題，這時再回頭修改，成本通常已經很高。
所以 CRA 一路研究下來，我越來越覺得它帶來的思維不是：最後測一下安不安全。
而是：一開始就把 Security 放進 Design。
從 Product Requirement 開始，經過 Risk Assessment、Threat Modeling、Security Requirement、Secure Design、Implementation、Verification、Release，一直到後續 Maintenance。
這就是我自己理解的：Security by Design 真正開始進入 Engineering。
而且這件事一旦真的做進去，受益的其實也不只是 CRA。

三、第三個改變：Vulnerability 不再只是「修 Patch」

以前看到 Vulnerability，很自然會先問：CVSS 幾分？要不要 Patch？SLA 幾天？
但 Product Vulnerability 的問題其實更長。
我們還需要知道哪些 Product 受影響、哪些 Version 受影響、Component 從哪裡來、Supplier 有沒有 Fix、是否已經被 Exploit、是否涉及 CRA Reporting、Customer 是否需要通知，以及 Security Update 最後怎麼送到客戶手上。

所以我現在會覺得：Vulnerability Management 開始變成 Product Lifecycle Management 的一部分。
它不再只是一張 Vulnerability Scan Report，也不只是 Security Team 把 Finding 丟給 R&D。
它開始牽涉 Product、Component、Version、Supplier、Customer、Support Period，甚至 Regulatory Reporting。

四、第四個改變：SBOM 讓 Supply Chain Security 變得更具體

以前談 Supply Chain Security，可能想到 Supplier Questionnaire、Security Clause、Vendor Risk Rating。
但 CRA 讓我越來越常問另一個問題：Product 裡面到底有什麼？
某個 Library 是誰提供的？哪個 Version？哪些 Product 在使用？Supplier 支援多久？Component EOL 了嗎？
如果明天某個 Component 出現重大 Vulnerability，公司能不能快速找到所有受影響 Product？
這時 Supply Chain Security 就不再只是：「這家 Supplier 安不安全？」
而是：「它提供給我的 Component，會怎麼影響我的 Product Security？」
我自己覺得，這是一個很大的思維轉換。
Supplier Risk 不再只停留在 Vendor Level，而開始往 Component Level、Product Level 延伸。

五、第五個改變：R&D 開始成為 Cybersecurity 很重要的角色

這可能是我一路研究 CRA 後很深的一個感受。
Security Team 可以制定 Framework、提供 Methodology、做 Governance，也可以協助 Vulnerability Handling。但真正了解 Product Architecture、Code、Interface、Component 與 Design Decision 的人，還是 R&D。

所以：Product Security 不可能全部 Outsource 給 Security Team。

Security Team 可以教 Threat Modeling 的方法，但真正知道某個 Interface 為什麼存在、Data Flow 怎麼走、某個 Component 能不能換掉的人，通常還是在 Engineering Team。
因此我現在比較喜歡的狀態是：
Security 是 Engineering 的一部分，而 Security Team 提供專業能力、方法與 Governance。
這跟「Security Team 負責 Product Security」其實是兩種不同的 Organization Model。

六、第六個改變：Product Security 開始跟 Product Compliance 接在一起

以前 Cybersecurity 跟 CE Marking，可能是兩個不同的世界。Security Team 做 Security，Product Compliance Team 做 CE。

但 CRA 把這兩件事情接起來了。

Product 做 Cybersecurity Risk Assessment，進一步滿足適用的 Essential Cybersecurity Requirements，建立 Technical Documentation，再進入適用的 Conformity Assessment，最後形成 EU Declaration of Conformity 與 CE Marking。

所以我自己開始很明顯地感覺到：Cybersecurity 已經不只是 Internal Control，而開始直接影響 Product Market Access。
這個改變，我覺得非常重要。

七、第七個改變：Product Cybersecurity 從 Technical Issue 變成 Business Issue

以前某個 Security Control 做得不好，可能是 Audit Finding、Risk，或是一項 Internal Improvement。
但到了 CRA，如果 Product 不符合適用的 Requirement，後面可能牽涉 Conformity、Corrective Action、Market Surveillance，甚至 Product 能不能繼續在 EU Market 提供。
所以 Product Cybersecurity 開始從：Technical Issue
慢慢變成：Business Issue。
這也是為什麼我現在越來越覺得，CRA 不太適合只放在 Security Department 裡處理。
因為到了某個階段，它一定會碰到 Product、R&D、Legal、Procurement、Product Compliance、Sales，甚至 Management。

八、第八個改變：Security Support 開始成為 Product Promise 的一部分

以前 Product Lifecycle 可能比較常談 Warranty、Maintenance、EOL。
但 CRA 讓 Cybersecurity Support Period 變成一個很重要的議題。
Product 賣出去之後，Manufacturer 還需要在適用的 Support Period 內持續處理相關 Vulnerability，因此 Product Decision 也開始需要考慮 Security Maintenance。
例如：
Product 要賣多久？
Security Update 要支援多久？
Supplier Component 能不能支援這麼久？
R&D Resource 怎麼保留？
Legacy Product 怎麼維護？
這些已經不只是 Security Team 可以決定。

如果 Product Team 承諾很長的 Product Lifecycle，但 Supplier Component 很早就停止 Security Support，最後要承擔這個 Gap 的仍然是 Manufacturer。

所以我現在會覺得：Security Support 本身其實也是 Product Promise 的一部分。

九、第九個改變：Compliance 從「時間點」變成「生命週期」

這可能是我自己很喜歡的一個觀察。
傳統 Product Compliance 很容易讓人想到：上市前完成 Test、取得 Certificate、貼 CE，然後 Product Launch。但 CRA 的 Product 上市之後，事情還沒有結束。後面還有 Vulnerability Monitoring、Security Update、Incident、Article 14、Product Change、Support Period、Market Surveillance。

所以 CRA Compliance 並不是單純的：Point-in-time Compliance。
我自己反而會把它理解成：Lifecycle Compliance。

這也會讓 Product Compliance 的角色跟過去不太一樣。因為我們不只是證明 Product 在某一天符合，而是還要思考：Product 在後續生命週期發生變化時，怎麼維持適用要求下的 Conformity？

十、這也讓「CE」對我來說有了不同的感覺

Day 16 我們談過 CE。一開始很容易覺得：「CE 貼上去了，CRA 就完成了。」
但現在回頭看，我自己反而覺得 CE 比較像是在完成適用 Conformity Assessment 後，Manufacturer 對 Product Conformity 所作的一項重要市場合規表示。
而 Product 進入市場之後：Manufacturer 的 Product Cybersecurity Responsibility 並沒有跟著 CE Marking 結束。
所以 CE 不是 CRA Product Lifecycle 的終點。
後面還有很長的一段 Post-market 工作。

十一、第十個改變：Evidence 開始變成 Engineering 的一部分

Day 26 我們談過 Evidence Management，這一段我自己其實滿有感。

因為 「我們有做」跟「我們證明得出來」，真的完全是兩件事情。
Threat Model 做過，但對應哪一版 Product？
SBOM 有，但對應哪一版 Firmware？
Penetration Test 做過，但後來 Architecture 改過嗎？
Risk Assessment 有，但現在 Product Version 還適用嗎？

所以 Product Security 開始需要：Traceability（可追溯性）。
例如 Requirement → Risk → Control → Test → Evidence → Product Version

我自己覺得這件事不只是 Compliance 要求，它其實也會讓 Security Engineering 本身變得更成熟。
因為工程團隊開始可以回答：我們為什麼這樣設計？解決的是哪個 Risk？怎麼證明它有效？又適用於哪個 Product Version？

十二、第十一個改變：Cybersecurity 開始需要真正的 Management Decision

這一路談下來，很多問題最後其實不是 Security Team 可以自己決定的。
例如 Support Period 要多久？High Residual Risk 可不可以接受？Supplier 不願意提供足夠的 Security Support 怎麼辦？Product 要不要 Delay Release？是否進入 EU Market？需要 Third-party Conformity Assessment 時，相關成本與時程怎麼安排？

這些其實都是 Risk + Cost + Market + Engineering 的綜合決策。

所以 Management Sponsorship 對 CRA 而言，我覺得不應只是成立一個 Steering Committee、開會聽報告。
而是 真的有一些 Product Cybersecurity Risk，需要 Management 做 Decision。

這也是 Day 23 我談 KPI / KRI 與 Management Review 時，自己最在意的地方。

十三、第十二個改變：CRA 其實在推動一種「責任移動」

以前 Cybersecurity 很容易被認為是 Security Team 的責任。
但 CRA 某種程度讓 Responsibility 開始往 Product、R&D、Engineering、Supplier Management、Product Compliance、Management 分散。
這不是說 Security Team 不重要。反而我覺得 Security Team 的角色可能變得更重要，只是角色開始從 「Security 自己做」
逐漸變成 「Security 讓整個 Organization 有能力做 Product Security。」

Security Team 不可能自己寫完所有 Secure Code、決定所有 Product Architecture、維護所有 SBOM、管理所有 Supplier Component，再自己做完所有 Product Compliance。
它真正需要建立的是 一套讓不同 Function 都能把 Security 做進自己工作裡的 Framework。

十四、這也改變了我自己對 Security Governance 的理解

以前談 Governance，很容易想到 Policy、Procedure、Audit、KPI。這些當然還是很重要。
但 Product Security Governance，我現在會再多看一些事情：
Engineering Process 有沒有接？
Product Owner 知不知道 Risk？
Supplier Requirement 有沒有進 Contract？
SBOM 能不能跟 Build 接？
PSIRT 能不能跟 R&D 接？
Product Change 能不能 Trigger Security Review？

所以 Governance 對我而言開始不只是 文件存在。
而是 把不同 Function 串起來。

而且我現在越來越覺得，CRA 真正困難的地方，可能就是這些 Interface。

十五、Traceability 可能是 Product Security 很重要的基礎能力

Product 出現問題時，公司能不能追到 Product Version？
能不能追到 Component？
能不能追到 Supplier？
能不能追到 Risk？
能不能追到 Test？
能不能進一步分析 Customer Impact？

所以 Traceability 可能會慢慢變成 Product Security 很重要的基礎能力。
而 SBOM 只是其中一部分。

真正完整的 Traceability，可能是 Product、Version、Component、Supplier、Risk、Security Requirement、Test、Evidence、Vulnerability 彼此之間都能建立關聯。
這也是我從 Day 26 談 Evidence Management，到 Day 27 做 Mock Audit 時，一直很在意的事情。

十六、如果只把 CRA 做成一堆文件，我覺得有點可惜

假設到了 2027 年，公司完成：
CRA Policy
CRA Procedure
CRA Checklist
CRA Form
CRA Training
CRA Audit

全部都 **Completed。**但 R&D 開新 Product 還是不知道什麼時候要做 Threat Modeling，Release 還是不會產 SBOM，PSIRT 收到 Vulnerability 還是不知道找誰分析 Product，Supplier 還是不提供 Component Security Information。那我自己會覺得 CRA 可能只完成了 Compliance Layer。 真正的
Product Security Capability 還沒有完全建立。這也是為什麼 Day 28 我會特別談 Operating Model。

因為 Project Deliverable 完成，跟 Organization Capability 建立，其實是兩件事情。

十七、反過來說，如果能力建立起來，未來可能不只 CRA 受益

這可能是我目前覺得最值得投入的地方。
如果企業真的建立 Product Inventory、Product Risk Assessment、SSDLC、SBOM、PSIRT、Supplier Component Security、Evidence Traceability、Product Security Governance，這些能力其實不只可以支援 CRA。
未來遇到 Customer Security Requirement、Product Certification、Contract Requirement，甚至其他 Product Cybersecurity Regulation，也可能更容易應對。

所以 CRA 專案的投資，如果做得好，最後留下來的不只是 Compliance Evidence，而是 Reusable Capability。
這也是我覺得企業在評估 CRA 投入時，很值得思考的一件事。
我們花的時間到底是在 「準備一套 CRA 文件」；還是在 「建立 Product Security Capability」？
兩者最後產生的長期價值，可能差很多。

十八、這也讓我重新看「法遵」這兩個字

以前 Compliance 有時候容易被理解成：「法規要求什麼，我們就做什麼。」
但做 CRA 到現在，我自己越來越覺得，比較理想的狀態可能是：法規告訴我們哪些事情必須被管理，企業再把 Requirement 轉換成可以持續運作的 Capability。

所以最後真正留下來的，不應該只有 **CRA Checklist。**而應該是 更成熟的 Product Security Management。

如果有一天 CRA Project 已經結束，但 SSDLC、SBOM、PSIRT、Supplier Security、Evidence Traceability 都還自然地運作，我反而會覺得這個 Project 做得比較成功。

十九、如果現在有人問我：「CRA 最難的是哪一條？」

研究到現在，我可能不會馬上回答某一個 Article。因為單一 Requirement 通常都可以慢慢研究。
Article 14 不懂，就研究 Article 14。
Annex I 不懂，就逐項拆 Annex I。
Conformity Assessment 不熟，就去把 Classification、Standard 與 Assessment Route 搞清楚。

但真正難的，我現在反而覺得是 把它們串起來。

Product 要接 R&D，R&D 要接 Security，Security 要接 PSIRT，PSIRT 要接 Product / Compliance，Compliance 要接 Conformity，Procurement 要接 Supplier，Management 又要接 Risk Decision。

這些跨 Function 的 Interface 可能才是 CRA 導入最需要時間磨合的地方。

因為很多 Gap 並不是某個 Team 完全沒有做事情，而是 A 做完之後，B 不知道要接。

二十、所以我現在反而覺得，CRA 是一個「跨部門流程設計題」

表面上，它是一套 Product Cybersecurity Regulation。實際導入之後，卻很像 Organization Design、Process Design、Product Lifecycle Management、Risk Management、Engineering Governance、Regulatory Compliance 一起來。
這也是為什麼 CRA Project 做到後面，可能會發現最常用的工具不一定是 Vulnerability Scanner。
反而可能是：
RACI。
Process Flow。
Product Inventory。
Evidence Matrix。
Roadmap。
Meeting。

我自己覺得這件事滿有意思。明明做的是 Cybersecurity Regulation，最後花很多時間處理的，卻是
人跟人之間、流程跟流程之間，到底怎麼銜接。

二十一、回頭看 Day 1，我自己看 CRA 的角度也變了

一開始，CRA 對我來說是一套新的 EU Cybersecurity Regulation。
所以開始讀 Article、Annex、Timeline。接著開始研究 SBOM、PSIRT、SSDLC、CE、Technical Documentation。
做到現在，我反而比較常想到的是 Product Security Lifecycle。

因為法規條文最後都需要變成 Process，Process 需要 Owner，Owner 需要 Tool，Tool 需要 Evidence，Evidence 又要能回到 Product。最後全部形成一個 Lifecycle。

所以我自己現在再回頭看 CRA，已經不太會只問：「Article 13 要做什麼？」
而會多問一句：「這個 Requirement 最後要放進 Product Lifecycle 的哪一個地方？」

我覺得這是我自己研究 CRA 到 Day 29，思考方式最大的改變之一。

Day 29 小結｜CRA 真正留下來的，也許不應該只是一張 CE

做到 Day 29，如果要我用一句話整理這一路研究 CRA 最大的感受，我現在可能會說：
CRA 表面上是一套 Product Cybersecurity 法規，但它真正推動的，是企業把 Cybersecurity 放進 Product Lifecycle。

從 Product Planning 開始，經過 Design、Development、Supplier、Testing、Release、Market Access，一直到後面的 Vulnerability Handling、Security Update、Product Change 與 EOL。
所以最後真正留下來的，如果只有一張 CE 跟一堆 Compliance Documents，我自己會覺得有點可惜。
如果 CRA 最後讓企業建立 Secure Development、Product Risk Management、SBOM、PSIRT、Supplier Security、Evidence Traceability 與 Product Security Governance，那即使有一天大家不再每天提「CRA」，這些能力還是會繼續存在。

而我自己目前覺得 這可能才是 CRA 對企業真正長期的價值。

它讓 Cybersecurity 從「Security Department 的工作」，慢慢變成「Product Lifecycle 的一部分」；讓 Compliance 從「上市前的一個時間點」，慢慢變成「整個生命週期的持續管理」；也讓 Product Security 從「技術問題」，逐漸變成需要 Engineering、Supply Chain、Compliance 與 Management 一起面對的 Business Issue。
當然，這只是我一路研究及參與 CRA 導入後，慢慢形成的個人心得與解讀。不同產業、不同 Product、不同企業，一定會有不同的感受與作法。
但如果這 30 天最後只能留下一個想法，我自己現在最想留下的可能是：
不要只為 CRA 建一套 Compliance Process，而是趁這個機會，把 Product Security Capability 真正建立起來。

Day 30 預告｜如果明天才開始做 CRA，我現在會怎麼開始？

終於要到 Day 30 了。
回頭看，我們從「CRA 是什麼？」一路談到 Scope、Classification、Risk Assessment、SSDLC、SBOM、PSIRT、Article 14、Supplier Security、Technical Documentation、Conformity Assessment、CE、Market Surveillance、Governance、Roadmap、Readiness、KPI / KRI、Evidence、Mock Audit，再到 Operating Model。

最後一天：我不想再加入新的 Requirement。
我想做的是把前面 29 天全部收回來。

假設：
今天公司才第一次把 CRA 交到我手上。
如果重新開始一次，我第一件事會做什麼？第二件？第三件？
哪些事情要先做？哪些不用一開始就做到很細？哪些事情我現在知道千萬不要等到 2027 年才開始？
還有一個現在的我們特別不能忽略的時間點：2026/9/11。
因為 CRA 全面適用雖然還有時間，但 Article 14 的部分 Reporting Obligations 已經先到。

所以 Day 30，我想把這 30 天真正收斂成一條：
如果明天開始，我會怎麼走的 CRA Implementation Roadmap。

從：First 30 Days → First 90 Days → 2026/9/11 → 2027/12/11 一步一步整理。

最後也想回頭看看：
如果重新做一次 CRA 導入，有哪些事情我會更早做？哪些事情我不會急著做？又有哪些坑，我現在會想辦法先避開？

Day 30，我們來替這 30 天真正收尾。