寫在前面：

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

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

今天談的 Operating Model（營運模式），也不是 CRA 規定企業一定要採取的組織模式，而是我在思考 CRA 專案完成之後，這些工作究竟要由誰持續做、怎麼融入既有流程的一些心得。

---

如果 2027/12/11 到了，CRA 專案是不是就可以結案？

假設到了 CRA 全面適用的時間點，公司該準備的事情差不多都完成了：

Product Inventory 完成。

Classification 完成。

SSDLC 建好了。

SBOM 可以產了。

PSIRT 跑得動。

Supplier Requirement 建立了。

Technical Documentation 也準備好了。

Conformity Assessment 完成。

EU DoC / CE 也處理好了。

大家終於鬆了一口氣，然後 Project Manager 宣布：

CRA Project Closed！

這個畫面聽起來很合理。

但我自己想到這裡，反而覺得有點奇怪。

因為：

Product 並沒有在 2027/12/11 停止變化。

---

一、專案可以結束，但 Product Lifecycle 還在繼續

2027/12/12，可能就出現新的 Vulnerability（漏洞）。

2028/1，Product Release 新版本。

2028/3，Supplier 通知某個 Component EOL（End of Life，生命週期終止）。

2028/6，R&D 增加新的 Communication Interface（通訊介面）。

2029 年，某個 Open Source Component（開源元件）又可能出現新的 Critical CVE。

甚至未來 Market Surveillance Authority（市場監督主管機關）可能要求 Manufacturer 提供相關 Technical Documentation。

所以：

CRA Project 可以 Close，

CRA Obligations 不會跟著 Project Close。

這也是我現在開始覺得，CRA 導入真正最後的一項 Deliverable（交付成果），可能不是 Final Report，也不是一張漂亮的結案簡報。

而是：

Operating Model。

---

二、什麼是我心裡的 Operating Model？

其實沒有很複雜。

我自己會把它理解成：

CRA 不再需要靠 PMO 每週追，組織原本的流程就會自然把事情做掉。

例如 New Product 進來時，Product Process 本來就會做 CRA Applicability Assessment（CRA 適用性評估）。

Product Change 發生時，Change Management Process 本來就會評估 Cybersecurity Impact（資安影響）。

Product Release 時，Engineering / Release Process 本來就會產生或更新 SBOM。

收到 Vulnerability 時，PSIRT 本來就會進行 Product Impact Assessment（產品影響評估），必要時再進一步評估 CRA Article 14 Reporting Obligation（通報義務）。

Supplier Change 發生時，Procurement / R&D 本來就會評估對 Product Security 的影響。

產品上市前，Product Compliance 本來就會確認適用的 Conformity Assessment（符合性評估）與相關文件。

到了這個階段，大家不需要再收到 CRA PMO 的 Mail：

「請記得完成 CRA Requirement。」

因為：

Requirement 已經進入日常流程。

---

三、這可能就是 Project 跟 Process 最大的差別

Project 的管理方式通常會有 Timeline、Milestone、Weekly Meeting、Action Item、Project Manager。

這些在 CRA 導入階段非常重要。

因為一開始很多事情還沒有 Owner、沒有 Procedure、沒有 Tool，也沒有既有 Process 可以承接，所以一定需要有人把事情往前推。

但如果到了 2030 年，公司還需要 CRA PMO 每週寄信追：

「請問這個 Product 的 SBOM 做了嗎？」

「Risk Assessment 更新了嗎？」

「Supplier Evidence 交了嗎？」

我自己可能會覺得：

有些事情還沒有真正制度化。

成熟的狀態，應該慢慢從：

PMO Push（PMO 推動）

轉成：

Process Pull（流程自然驅動）。

也就是事情一發生，既有流程自然知道下一步該做什麼，而不是等 CRA Team 來提醒。

---

四、所以我會開始問：「每一項 CRA 工作最後要回到哪一個既有流程？」

這是我自己在 Project Transition（專案移轉）階段很想做的一件事。

CRA 工作	建議納入的既有流程
CRA Applicability	Product Planning / Product Compliance
Classification	Product Compliance
Product Risk Assessment	Product Development / Product Security
Threat Modeling	SSDLC
Secure Coding / Testing	R&D / QA
SBOM	Build / Release Process
Vulnerability Handling	PSIRT
Article 14 Reporting	PSIRT + Regulatory Reporting
Supplier Security	Procurement / Supplier Management
Technical Documentation	Product Compliance / Product Lifecycle
Conformity Assessment	Product Compliance
Product Change	Engineering Change Management
Post-market Monitoring	PSIRT / Product Support

這不是 CRA 官方的 Responsibility Matrix（責任矩陣）。

只是我自己在思考：

「專案結束之後，這件事情到底要住在哪裡？」

的一種方式。

我覺得如果每一項 CRA Requirement 最後都找不到一個 Permanent Home（永久歸屬），那它很容易在 Project Close 之後慢慢消失。

---

五、第一件要制度化的，我覺得是 Product Intake

新 Product 進入 Development Process 時，第一個問題之一就應該是：

CRA 適不適用？

這件事最好不要依賴某個 CRA Expert 剛好看到 Product，才提醒大家：

「這個可能要評估 CRA。」

而是 Product Initiation / Product Planning（產品立案／規劃）本身就存在 CRA Applicability Check。

例如確認 Product 是否屬於 Product with Digital Elements、是否涉及直接或間接的 Logical or Physical Data Connection（邏輯或實體資料連線）、是否預計進入 EU Market，以及是否存在需要進一步分析的適用或排除情形。

如果結果顯示：

Further Assessment Required（需要進一步評估）

流程自然 Trigger（觸發）：

Product Compliance Review。

這樣 Scope Management 才比較不容易因為人員更換、新產品增加而漏掉。

---

六、第二件：CRA 要進 SSDLC，而不是在 Release 前才出現

如果 Product 快 Release 了，R&D 才突然收到通知：

「不好意思，CRA 要做 Threat Modeling。」

我猜 R&D 應該不會太開心。

因為這時 Architecture 已經定了、Code 也寫得差不多了，甚至 Testing 都快完成了。

所以 CRA Cybersecurity Requirements 越早進入 Development Lifecycle（開發生命週期）越好。

例如：

Planning → CRA Applicability
Requirement → Cybersecurity Requirements
Design → Threat Modeling
Development → Secure Coding / SAST / SCA
Verification → Security Testing
Release → SBOM / Security Evidence

到了這個階段：

CRA 不再是一個 Release Gate 前突然出現的 Compliance Task。

而是：

Product Development 本身的一部分。

---

七、第三件：SBOM 要變成 Release Artifact

Day 10 我們談過 SBOM。

如果每次 Product Release，都要等 CRA PMO 寄信：

「請提供這次 Release 的 SBOM。」

這個模式長期一定很辛苦。

我自己更希望 Product Build / Release Process 自然產生 SBOM，而且跟 Product Version 自動或至少制度化地綁在一起。

也就是：

Binary / Firmware → Build → Version → SBOM

之間有明確關聯。

這樣 PSIRT 後續收到某個 Vulnerability，才能比較快回答一個非常實際的問題：

哪些 Product、哪些 Version 受到影響？

這時 SBOM 才真正從 CRA Deliverable 變成 Product Security Infrastructure（產品資安基礎能力）。

---

八、第四件：PSIRT 要能脫離 CRA Project 獨立生存

Article 14 的部分 Reporting Obligations 自 2026/9/11 開始適用，但 PSIRT（Product Security Incident Response Team，產品資安事件應變團隊）當然不是只為 CRA 存在。

PSIRT 長期需要處理 External Vulnerability Report、Internal Finding、Supplier Vulnerability、CVE、Product Impact Assessment、Remediation、Disclosure（漏洞揭露）與 Customer Communication。

CRA 加進來的，是另一個需要被納入流程的判斷：

Regulatory Reporting Assessment（法規通報評估）。

也就是 PSIRT 收到 Case 之後，除了原本的 Technical Assessment，也需要在適用情況下判斷是否涉及 CRA Reporting Obligation。

所以 CRA Project Close 之後：

PSIRT 還是繼續存在，而且要繼續跑。

我自己反而覺得，這可能是 CRA 導入過程中最值得留下來的 Organization Capability（組織能力）之一。

---

九、第五件：Supplier Security 也要回到 Supplier Lifecycle

Project 階段很容易做一次：

Supplier Survey。

做完、收回來、統計完成：

Completed。

但幾年後 Supplier 換 Component、Component EOL、Supplier 停止 Security Support，甚至 Supplier 本身發現新的 Vulnerability，這些事情都可能直接影響 Product。

所以我自己會希望 Product Security Requirements 能逐漸進入完整的 Supplier Lifecycle，例如：

Supplier Selection → Contract → Qualification → Change Notification → Performance Review → EOL / Termination

也就是：

Supplier Security 不能只做 Onboarding，還要管理 Lifecycle。

這時 Supplier Security 才會從一次性的 Vendor Assessment，逐漸變成 Product Security Supply Chain Management（產品資安供應鏈管理）。

---

十、Product Change Management 可能是 Operating Model 很重要的一環

Product 上市之後一定會改。

Firmware Update、Library Upgrade、Component Replacement、Function Addition、Interface Change，都很常見。

每一次 Change 當然不代表都要重新做整套 CRA。

但至少需要回答：

這次 Change 對 Product Cybersecurity Conformity 有沒有影響？

所以 Day 17 談過的 Substantial Modification Assessment（實質修改評估），我自己會希望最後能跟 Engineering Change Management（工程變更管理）接起來。

也就是 Engineering Change 發生時，流程本身就會問：

是否改變 Attack Surface？

是否產生新的 Cybersecurity Risk？

是否影響既有 Security Requirement？

是否需要重新 Testing？

是否需要更新 SBOM / Technical Documentation？

是否需要重新檢視 Conformity？

而不是 CRA Team 每隔幾個月去問：

「最近 Product 有沒有改？」

---

十一、Technical Documentation 也應該是「活的」

假設 Technical Documentation 在 2027/12/10 完成，然後輸出 PDF 存檔。

2028 年 Product 改了。

2029 年 Component 換了。

2030 年 Risk Assessment 更新了。

但 Technical Documentation 還停留在 2027 年那一版。

那它很快就會跟實際 Product 脫節。

所以我現在比較喜歡用：

Living Technical Documentation（持續維護的技術文件）

來想這件事。

不是說每天都要修改 Technical Documentation，而是 Product Change、Risk Change、Component Change、Security Update 或其他可能影響 Conformity 的事件發生時，有適當的 Trigger 去判斷：

哪些 Documentation / Evidence 需要跟著更新？

這也剛好接回 Day 26 談的 Evidence Management。

---

十二、這時「Trigger」可能比「Schedule」更重要

很多 Management System 習慣：

Annual Review（年度檢視）。

每年檢查一次，當然可以存在。

但 Product Security 的變化不會等到年底。

所以我自己覺得 CRA Operating Model 更需要：

Event-driven Review（事件驅動檢視）。

例如：

Trigger Event	應啟動的活動
New Product	CRA Assessment
New Release	SBOM / Evidence Update
New Component	Supplier / Risk Review
New Vulnerability	Product Impact Assessment
Major Product Change	Security / Conformity Review
Component EOL	Support Obligation Review

也就是 Operating Model 不是：

「每年做一次 CRA Review。」

而是：

事情發生時，正確的 Process 自然被 Trigger。

這對我而言才是真正進入 BAU 的重要特徵。

---

十三、那 CRA PMO 最後要不要消失？

我自己的想法是：

不一定要完全消失，但角色應該改變。

導入期間，PMO 可能負責 Project Plan、Workstream Coordination、Gap Tracking、Meeting、Escalation 與 Deliverable Management。

但進入 BAU（Business as Usual，日常營運）之後，它可能逐漸轉成：

Governance / Oversight（治理／監督）

Regulatory Monitoring（法規監控）

KPI / KRI Monitoring

Major Issue Escalation

Cross-functional Coordination

Management Review

Audit Coordination

也就是從：

追每一件 Task

逐漸轉成：

確認整個 System 還有效。

我覺得這個角色轉換很重要。

否則 CRA PMO 很容易變成一個永遠不能結案的 Project Team。

---

十四、我自己很喜歡用 Three Lines 思維看這件事

這不是 CRA 的要求，只是我自己熟悉的一種 Governance Model（治理模式）。

**First Line（第一線）**可以是 Product、R&D、Engineering、Procurement 等實際負責 Product Lifecycle 的單位，負責把 Security Requirement 真正做進 Product 與相關流程。

**Second Line（第二線）**可能是 Product Security、Security Governance、Compliance 等角色，負責 Framework、Guidance、Monitoring 與 Challenge（獨立檢視／質疑）。

**Third Line（第三線）**則由 Internal Audit（內部稽核）提供較獨立的 Assurance（確信）。

這樣比較不容易變成：

Security Team 自己制定 CRA Rule、自己執行、自己檢查，最後再自己說符合。

對我而言，這也是 CRA 從 Project 走向 Governance 很重要的一個轉變。

---

十五、但 Operating Model 最難的，可能還是 Ownership

Procedure 可以寫，Tool 可以買，Template 可以設計。

真正困難的反而是：

誰長期負責？

例如：

Product Support Period 誰決定？

SBOM Accuracy 誰負責？

Product Cybersecurity Risk 誰接受？

Supplier Component Risk 誰負責處理或 Escalate？

Article 14 Reporting Decision 誰負責？

Technical Documentation 誰維護？

如果這些問題最後全部寫：

CRA PMO。

那 CRA Project 永遠結不了案。

所以我自己會希望每一項重要責任，最後都有：

Permanent Owner（永久責任人／常態權責單位）。

而且這個 Owner 最好原本就存在於 Product Lifecycle 裡，而不是為 CRA 額外創造一個永遠存在的平行組織。

---

十六、Training 也要從「專案教育」變成「角色教育」

Project 階段，大家一起上一堂 CRA Awareness Training 很合理。

但長期我覺得 Training 應該逐漸變成：

Role-based Training（角色導向教育訓練）。

例如 R&D 需要 Secure Development、Threat Modeling、SBOM；PSIRT 需要 Vulnerability Handling 與 Article 14；Procurement 需要 Supplier Security Requirements；Product Team 需要 CRA Applicability 與 Support Period；Compliance 需要 Technical Documentation 與 Conformity Assessment；Management 則需要理解 Product Risk、Decision Authority 與 Accountability（問責）。

這樣未來新人加入，也可以依照 Role 接受相應訓練。

而不是：

等下一次 CRA Project 才重新教一次。

---

十七、另一個不能忘記的問題：CRA 周邊要求還會繼續發展

CRA Regulation 已經公布，但企業實際落地時所依賴的 Harmonised Standards（協調標準）、Guidance（指引）以及其他相關制度與實務，仍可能持續發展。

所以 Operating Model 還需要一項能力：

Regulatory Monitoring（法規監控）。

誰負責追蹤新的 CRA Guidance / Standards？誰做 Impact Assessment（影響評估）？哪些 Product 或 Process 受到影響？誰負責修改？怎麼留下 Evidence？

如果沒有這個機制：

2027 Ready，不代表 2030 還是 Ready。

---

十八、所以我會建立一個簡單的 Regulatory Change Flow

例如：

New CRA Guidance / Standard

↓

Compliance / Security Review

↓

Impact Assessment

↓

Affected Product / Process Identification

↓

Action Owner

↓

Implementation

↓

Evidence

↓

Closure

其實這跟很多既有 Compliance Management 並沒有太大不同。

只是 Scope 從原本可能偏 Corporate / IT Compliance，進一步延伸到：

Product Cybersecurity Compliance。

---

十九、那怎麼知道 CRA 已經成功轉進 BAU？

我自己覺得有一個很有趣的判斷方式。

如果有一天，我不再收到大量：

「CRA Product Inventory 還沒填。」

「CRA SBOM 還沒交。」

「CRA Risk Assessment 請補。」

不是因為大家放棄了，而是因為：

New Product Process 本來就會做 Applicability Assessment。

Release Process 本來就會產 SBOM。

SSDLC 本來就會做 Security Risk / Threat Assessment。

PSIRT 本來就會處理 Product Vulnerability。

Supplier Process 本來就會管理 Component Security。

Product Compliance 本來就會確認 Conformity。

那我會覺得：

CRA Project 真的可以開始退場了。

因為事情已經不再需要靠 Project Team Push。

---

二十、這時 CRA 甚至不一定需要一直叫「CRA」

這是我自己滿喜歡的一個想法。

成熟之後，R&D 不一定會說：

「我要做 CRA Threat Model。」

可能只是：

「這個 Product 要做 Threat Model。」

Engineering 不一定說：

「我要產 CRA SBOM。」

只是：

「這個 Release 要產 SBOM。」

PSIRT 也不一定說：

「我要跑 CRA Vulnerability Process。」

只是：

「這是一個 Product Vulnerability Case。」

也就是法規要求最後被：

內化成正常的 Product Security Practice（產品資安實務）。

我自己覺得，這可能是 Compliance 很理想的一種狀態：

不是每件事情都因為「法規要求」才做，而是它已經變成公司原本就會做的事。

---

二十一、所以 CRA Project 真正的 Exit Criteria，我可能不只看 Deliverable

如果讓我自己定 CRA Project Exit Criteria（專案退出條件），除了 Policy / Procedure Completed、Product Assessment Completed、Technical Documentation Ready、Conformity Plan Ready 之外，我還會想確認：

BAU Owner 已指定。

Process Trigger 已建立。

KPI / KRI 已建立。

Training 已納入角色制度。

Regulatory Monitoring 已建立。

Audit / Review Mechanism 已建立。

Escalation Mechanism 已建立。

換句話說，我最後想問的已經不只是：

「事情做完了嗎？」

而是：

「Project Team 離開後，事情還會繼續做嗎？」

我自己覺得，如果這題的答案還不確定，Project 可能就還沒有真正完成 Transition。

---

Day 28 小結｜真正成熟的 CRA，也許就是有一天大家不再覺得自己「在做 CRA」

做到 Day 28，我自己對 CRA Implementation 的理解，已經從一開始：

「要完成哪些法規要求？」

慢慢變成：

「怎麼讓這些要求長期運作？」

我現在越來越覺得：

Project 的成功，不是讓 Project 永遠存在。

反而是有一天 Project 可以退出，而 Product、R&D、Engineering、Product Security、PSIRT、Procurement、Compliance 各自都知道自己在 Product Lifecycle 裡應該做什麼。

這時 CRA 不再是一張額外的 Checklist。

Product Development 本來就考慮 Cybersecurity Risk，Release 本來就產 SBOM，Vulnerability 本來就進 PSIRT，Product Change 本來就重新看 Security Impact，Supplier Change 本來就考慮 Component Risk，Product Compliance 本來就維護 Technical Documentation 與相關 Evidence。

我自己覺得：

這才比較像 CRA 真正進入企業。

而不是：

「因為歐盟要求，所以我們多做一套流程。」

而更接近：

「我們本來就是這樣管理 Product Cybersecurity。」

如果有一天有人問：

「你們 CRA 怎麼做？」

大家不用先去找 CRA PMO。

Product Team 可以直接說：

「這就是我們的 Product Development Process。」

PSIRT 說：

「這就是我們的 Vulnerability Handling Process。」

Compliance 說：

「這就是我們的 Product Conformity Process。」

我想：

那時候 CRA 才真的從 Compliance Requirement，慢慢變成 Organization Capability（組織能力）。

以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。

CRA 並沒有規定企業一定要建立本文所描述的 Operating Model；實際作法仍應依企業規模、產品特性、組織分工與既有 Product Security / Product Compliance 機制調整。

---

Day 29 預告｜寫了快 30 天，我反而想回頭問：CRA 真正改變企業的是什麼？

前面 28 天，我們已經談了 Scope、Classification、Risk Assessment、SSDLC、SBOM、PSIRT、Supplier Security、Article 14、Technical Documentation、CE、Market Surveillance、Governance、Roadmap、KPI / KRI、Mock Audit，最後又談到 Operating Model。

到了 Day 29：

我反而不太想再介紹新的 Requirement。

我想稍微停下來，回頭看看這一路研究下來，CRA 真正帶給企業的改變到底是什麼？

只是多一個 CE？

多一份 SBOM？

多一套 Vulnerability Reporting Process？

還是它其實正在推動一個更大的變化：

Cybersecurity 不再只是 Corporate IT 或 Security Team 的事情，而開始真正進入 Product Lifecycle、Engineering、Supply Chain、Product Compliance 與 Management Responsibility？

而且如果把前面 28 天全部串起來，我自己開始覺得：

CRA 真正改變的，也許不是企業多做了哪些文件，而是「誰開始需要對 Product Cybersecurity 負責」。

Day 29，我想先把 Article、Annex、Procedure、Template 放到旁邊。

來聊聊：

研究 CRA 到現在，我自己覺得它正在改變企業的幾件事情。

然後 Day 30，我們再一起回到這 30 天的起點：

如果明天真的要開始做 CRA，我現在會從哪裡開始？