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

如果星期五下午收到 Vulnerability，24 小時是不是就開始倒數？
Day 9 談 PSIRT 時，我們已經碰到 CRA Article 14。對我來說，Article 14 是 CRA 裡很需要提早準備的一段，原因很簡單：它不是等到 2027 年 12 月 CRA 全面適用時才開始。
CRA Article 14 的 Reporting Obligations 從 2026 年 9 月 11 日開始適用。Manufacturer 對符合條件的 Actively Exploited Vulnerability（遭主動利用的漏洞），以及 Severe Incident having an impact on the security of the Product with Digital Elements（對具數位元素產品安全造成影響的嚴重事件），需要依規定進行通報。
所以現在如果正在準備 CRA，我自己會把 Article 14 放在相對前面。很多 CRA 的制度、流程與 Technical Documentation 還可以持續往 2027 年準備，但 Article 14 已經是一個很快就會真正碰到的時間點。

一、先分清楚：不是所有 Vulnerability 都要 24 小時通報
剛開始接觸 Article 14 時，我覺得第一個很容易產生的誤解，就是看到「Vulnerability」與「24 hours」，很自然地把它理解成只要公司發現產品漏洞，就必須在 24 小時內向 EU 通報。
但 Article 14 對 Vulnerability 使用的詞其實是 Actively Exploited Vulnerability，而不是所有 Vulnerabilities。
所以 Product 有 CVE，不等於一定觸發 Article 14；收到 Security Researcher 的 Vulnerability Report，也不代表一定需要通報；即使 CVSS 是 9.8，我自己也不會只看這個分數，就直接判斷它已經構成 CRA Reporting Obligation。
真正需要回答的問題是：這個 Vulnerability 是否符合 CRA 所稱的 Actively Exploited Vulnerability？
因此在實務上，我自己會把 Vulnerability Severity Assessment 與 CRA Reporting Assessment 稍微分開。前者是在判斷漏洞本身的 Severity、Exploitability 與 Impact，後者則是在判斷目前掌握的事實是否已經觸發 CRA Article 14 的法規通報條件。兩者彼此相關，但我認為不能完全畫上等號。

二、那什麼叫 Actively Exploited Vulnerability？
CRA Article 3 對 Actively Exploited Vulnerability 有正式定義。以我自己的理解來簡化，就是 Manufacturer 或其他相關方已經有可靠證據顯示，Malicious Actor 確實利用了 Product 中的 Vulnerability。
我自己在看這個定義時，會特別注意 Reliable Evidence，以及 Malicious Actor has exploited the vulnerability 這兩個概念。
換句話說，「這個 Vulnerability 理論上可以被 Exploit」與「已經有可靠證據顯示 Malicious Actor 利用了這個 Vulnerability」，在 Article 14 的判斷上，我認為可能還是不太一樣。
這也讓我開始覺得，未來 PSIRT 收到 Vulnerability Report 時，除了 CVSS、Affected Version、Exploitability 與 Impact 之外，可能還需要多確認一件事情：目前有沒有 Active Exploitation 的 Evidence？
因為這個答案可能會影響另一條 CRA Regulatory Reporting Process 是否需要開始啟動。

三、真正麻煩的問題：24 小時到底從什麼時候開始？
Article 14 有一句很關鍵的文字：
within 24 hours of the manufacturer becoming aware of it
也就是說，Reporting Clock 與 Manufacturer becoming aware 有關。
看到這裡，我第一個想到的反而是一個很實際的情境。假設星期五下午 17:00，公司的 Security Mailbox 收到一封 Vulnerability Report，而且 Security Researcher 在信裡還附上疑似已遭 Malicious Actor 利用的 Evidence，那 24 小時是不是已經開始倒數？
還是要等星期一早上 PSIRT 上班、完成初步確認之後，才算 Manufacturer aware？
對這個問題，我自己不會很武斷地下結論。因為「becoming aware」在實際事件中如何認定，可能還需要依 European Commission、ENISA 後續 Guidance、事件事實與企業實際流程進一步判斷。
但如果從 Risk Management 的角度來設計流程，我自己不太敢建立一個假設：「因為週末沒有人看信，所以星期一才算知道。」
如果整個 Article 14 Reporting Process 是建立在這個前提上，我覺得風險可能有點高。

四、所以 Vulnerability Intake 不能只是建立一個 Email Address
以前談 Vulnerability Disclosure 時，我可能會先想到在官網放一個 Security Contact，例如 Security Mailbox，讓 Security Researcher 或 Customer 找得到通報窗口。
但研究 Article 14 之後，我開始覺得「有一個 Mailbox」其實只是第一步。
真正需要思考的是，這個 Mailbox 收到訊息之後，有沒有人會即時知道？如果星期五晚上收到怎麼辦？Holiday 呢？海外 Site 收到 Vulnerability Report 時又怎麼處理？第一個看到的人知不知道什麼情況需要 Escalate？如果原本指定的主管或 Product Security Contact 聯絡不到，流程還能不能繼續？
這不代表所有公司都需要因此建立一套 24×7 的大型 SOC，但至少如果 Article 14 有 24 小時的 Reporting Requirement，那這個時間限制就應該反映在 Vulnerability Intake、On-call、Escalation 與 Decision Authority 的流程設計裡。
對我來說，這可能比「公司有沒有建立 Security Mailbox」更接近真正的 Article 14 Readiness。

五、24 小時不是要求把所有 Investigation 做完
另一個我覺得很重要的地方，是不要把 24 小時理解成「24 小時內所有事情都必須調查完成」。
對 Actively Exploited Vulnerability，CRA Article 14(2)(a) 要求 Manufacturer 在沒有不當延遲的情況下，最遲於 24 小時內提出 Early Warning Notification。其中在適用情況下，也包括 Manufacturer 所知道 Product 已 Made Available 的 Member States 等資訊。
所以我自己會把這個階段理解成：先讓主管機關知道有這件事情。
它並不是要求 R&D 在 24 小時內完成 Root Cause Analysis，也不是要求 PSIRT 在一天內完成所有 Forensics、Patch Development、Regression Test 與 Customer Communication。
這個差異對實際流程設計很重要。因為如果公司內部認為「Technical Investigation 還沒有完成，所以現在不能報」，反而可能讓 24 小時的 Reporting Clock 變得非常危險。

六、到了 72 小時，資訊要比 Early Warning 更完整
Early Warning 之後，下一個重要時間點就是 72 小時。
對 Actively Exploited Vulnerability，Article 14(2)(b) 要求進一步提出 Vulnerability Notification，包括 Product 的一般資訊、Exploit 與 Vulnerability 的一般性質、已採取的 Corrective / Mitigating Measures、User 可以採取的相關措施，以及在適用情況下 Manufacturer 對通報資訊敏感程度的判斷。
我自己特別注意到法規在這裡使用了 as available 這樣的文字。
所以我目前會理解成，72 小時階段提供的資訊應該比 24 小時 Early Warning 更完整，但不一定代表所有 Technical Investigation 都已經結束。
這也是為什麼我覺得 Article 14 很考驗跨部門協作。因為在這 72 小時裡，PSIRT 可能正在分析 Vulnerability，R&D 正在確認 Affected Version，Product Team 正在確認 EU Market Information，Legal / Compliance 則同時需要確認 Reporting Content。這些事情很可能不是一件做完再換下一件，而是必須同時往前跑。

七、Final Report 的「14 天」其實很容易記錯
Article 14 的幾個時間要求裡，我自己覺得最容易被簡化成口訣，然後不小心記錯的，就是 Final Report。
對 Actively Exploited Vulnerability 而言，並不是單純從 Awareness 開始一路計算「24 小時、72 小時、14 天」。前面是 24 小時 Early Warning，接著是 72 小時 Vulnerability Notification，但 Final Report 的時間點則與 Corrective or Mitigating Measure available 有關，是在相關措施 available 後，最遲 14 天內提出。
Final Report 的內容會進一步包括 Vulnerability Description、Severity / Impact、若有相關資訊則包含 Malicious Actor，以及 Security Update 或其他 Corrective Measures。
所以我自己在寫 SOP 時，反而會特別把這個 Trigger 標示清楚。因為最後這個 14 天，與前面的 24 小時、72 小時並不是完全相同的起算邏輯。如果大家只是記成「24h、72h、14 days」，真正發生 Vulnerability 時反而很容易算錯。

八、Severe Incident 也是 24h / 72h，但 Final Report 又不一樣
Article 14 不只有 Actively Exploited Vulnerability，還有另一條 Severe Incident having an impact on the security of the Product with Digital Elements 的通報路徑。
這兩種情況前面的 Reporting Timeline 看起來很像，都有 24 小時 Early Warning 與 72 小時 Main Notification，但到了 Final Report，兩者的要求就不一樣。
對 Actively Exploited Vulnerability 而言，Final Report 是在 Corrective or Mitigating Measure available 後最遲 14 天內提出；但如果是 Severe Incident，前面同樣要進行 24 小時 Early Warning，接著在 72 小時內提出 Incident Notification，而 Final Report 則是在 72-hour Incident Notification 提交後一個月內完成。
所以我自己在整理 Article 14 SOP 時，會特別把這兩條 Timeline 分清楚。雖然大家很容易把 Article 14 記成「24 小時、72 小時、最後再交 Final Report」，但實際上 Actively Exploited Vulnerability 與 Severe Incident 的 Final Report 不只有期限不同，起算的 Trigger 也不一樣。

九、公司原本的 Incident Severity A/B/C，不一定等於 CRA 的判斷
談到 Severe Incident，另一個我自己在導入時會注意的問題，就是公司通常早就有自己的 Information Security Incident Classification，例如 A、B、C 級，或 Critical、High、Medium、Low。
但 CRA Article 14(5) 本身也有判斷條件。例如 Incident 已經或可能對 Product 保護 Sensitive / Important Data 或 Function 的 Availability、Authenticity、Integrity、Confidentiality 造成負面影響，或者已經或可能導致 Malicious Code 被引入或執行於 Product 或 User 的 Network and Information Systems。
所以我自己不會直接認為「公司判定 A 級事件，就一定等於 CRA Severe Incident」，也不會認為「公司判定 B 級，所以一定不用向 EU 通報」。
比較實際的做法，我認為可能是保留公司既有的 Incident Severity Matrix，但另外再 Mapping CRA Article 14 Criteria。這樣既不用把原來的 Incident Management System 全部推翻，又可以在事件發生時多做一層 CRA Reporting Assessment。

十、通報不是自己寄 Email 給每一個 Member State
接下來就是另一個很實務的問題：到底要報給誰？
CRA Article 14 涉及 CSIRT designated as coordinator 與 ENISA，而實際通報機制則透過 Article 16 所建立的 Single Reporting Platform（SRP）。
European Commission 目前對這個機制的說明，是希望 Manufacturer 透過 Single Reporting Platform 進行通報，再由相關機制將資訊提供給 ENISA 與相關 Member State CSIRTs。
所以我自己不會把 Article 14 的 Reporting Process 理解成「公司準備很多封 Email，再分別寄給不同 EU Member States」。
真正需要準備的，反而是誰負責操作 SRP、誰有 Authority 可以 Submit、需要準備哪些資料，以及緊急情況下 Backup Person 是誰。

十一、那 Coordinator CSIRT 到底是哪一國？
這一題對非 EU Manufacturer 特別重要，因為第一個直覺很可能是：「產品主要賣哪一國，就報哪一國。」
但 Article 14(7) 對 Coordinator CSIRT 有自己的判定順序。
以我目前的理解來簡化，會先看 Manufacturer 在 Union 的 Main Establishment；如果 Manufacturer 沒有 Establishment in the Union，則還需要依 CRA 所規定的條件，例如 Authorised Representative 等進一步判斷。如果依前面的條件仍然無法確定，再依 Product Made Available 的 Member State 等相關規則處理。
所以我自己不會只因為「產品有賣到德國」，就直接認定 Coordinator CSIRT 一定是德國。這一段我會傾向在 Article 14 真正生效以前，先和 Legal / Compliance 把公司的適用情境確認清楚。

十二、有 Authorised Representative，不代表 Manufacturer 的責任就不見了
對非 EU Manufacturer 來說，另一個很自然會想到的問題就是：既然有 Authorised Representative（AR），那 Article 14 可不可以全部交給 AR 處理？
我目前的理解是，Article 14 的 Reporting Obligation 主體仍然是 Manufacturer。至於實際操作上是否由 AR 協助進行通報、SRP Account 如何安排、誰被授權 Submit，以及雙方在事件發生時如何交換資訊，這些都可以事先設計。
但我自己會把兩件事情分開看：「誰負有法規責任」與「誰實際協助完成通報」並不一定是同一個概念。
所以如果公司未來確實希望由 AR 協助 Article 14 Reporting，我會傾向事前把相關 Authority、Mandate、Contact Point 與 Escalation Process 都確認清楚，而不是等到 Vulnerability 真的發生，而且 Reporting Clock 已經開始倒數，才開始討論 AR 到底能不能代為操作。

十三、Single Reporting Platform 也要真的操作得起來
因為我們現在已經來到 2026 年，所以 Article 14 不再只是紙上的制度設計問題，實際 Reporting Platform 的準備狀態也開始變得很重要。
European Commission 目前說明，ENISA 負責建立 CRA Single Reporting Platform，並預計於 2026 年 9 月 11 日正式 Operational，正式上線以前也會有 Testing Period。
所以即使公司的 Article 14 SOP 已經完成，我自己還是會保留一段 Reporting Platform Operation，持續確認後續 Account、Role、Authority、Submission Flow、Testing 等實際操作資訊。
因為 SOP 裡寫「由指定人員向 SRP 提交通報」是一回事，到了事件發生時才發現指定人員沒有 Account、沒有權限，或者 Backup Person 根本不知道怎麼操作，就是另外一回事了。

十四、我現在會把 Article 14 拆成兩條同時進行的流程
做到這裡，我自己越來越傾向不要把 Article 14 當成一條從頭跑到尾的單一路徑，而是拆成 Technical Flow 與 Regulatory Flow 兩條同時進行的流程。
Technical Flow 處理的是 Vulnerability 本身，從收到 Report 後進行 Validation，確認 Affected Product、Exploitability 與 Impact，再進一步處理 Fix 或 Mitigation；Regulatory Flow 則是在同一時間確認 Product 是否屬於 CRA Scope、目前情況是否符合 Actively Exploited Vulnerability 或 Severe Incident、是否已經觸發 Reporting Obligation，以及後續 24 小時、72 小時與 Final Report 應該如何處理。
我覺得這兩條線最重要的地方，就是不一定要等 Technical Flow 做完，Regulatory Flow 才開始。
如果公司一定要等 R&D 完成 Root Cause Analysis，才開始問「這件事情到底需不需要 Article 14 Reporting」，那 24 小時可能很快就會變得非常緊。

十五、所以 Article 14 最難的，可能根本不是填表
研究到這裡，我自己反而越來越覺得 Article 14 最困難的地方，可能不是 Reporting Form 到底要填哪些欄位，而是公司能不能在資訊還不完整的時候快速做出決定。
例如誰有權認定 Manufacturer 已經 aware、誰負責判斷 Active Exploitation Evidence、誰決定是否觸發 Article 14、Product 到底有沒有進入 EU Market、這些 Market Information 要去哪裡找，以及星期六收到 Vulnerability 時誰負責 Escalation。再往後一點，還會碰到原本負責的人休假時誰可以代理、誰有 SRP 操作權限，以及 Legal、Product、R&D 與 PSIRT 要怎麼在很短的時間內取得足夠資訊做出判斷。
這些問題其實都發生在「填表」之前，而且等 Vulnerability 真正發生後才開始討論，可能已經太晚。
所以如果現在要準備 Article 14 Readiness，我自己反而會很想先做一次 Tabletop Exercise（桌上演練），看看原本設計的流程實際跑起來到底會發生什麼事情。

十六、我可能真的會挑星期五下午來演練
例如我可能設計一個情境：星期五 17:30，Security Researcher 通知公司某項 Product 存在 Vulnerability，同時提供疑似已被 Malicious Actor Exploit 的 Evidence。
接下來先不急著看 SOP 寫了什麼，而是直接看團隊怎麼反應。第一個收到訊息的人知不知道該找誰？誰負責確認 Affected Product？R&D 多久能加入分析？誰判斷 Active Exploitation Evidence？Product Team 能不能快速確認 EU Market Information？最後又是誰有 Authority 決定是否觸發 Article 14 Reporting？
然後我會再故意加一個條件：現在是星期五晚上，而且星期六主管聯絡不到。
這時候流程還能不能繼續？24 小時內有沒有人可以做出決定？有人可以操作 SRP 嗎？如果原本指定的 Submitter 剛好休假，有沒有 Backup？
我覺得這種演練可能比大家坐在會議室裡，把 SOP 從第一頁讀到最後一頁，更容易找到真正的 Process Gap。因為文件裡寫一句「應立即通報主管」很簡單，但星期六真的找不到主管時，流程還跑不跑得下去，才是 Article 14 Readiness 真正會遇到的問題。

Day 10 小結｜24 小時真正考驗的，可能是公司的決策速度
研究 Article 14 到這裡，我自己最大的感受是：CRA Reporting 不只是 PSIRT 的技術問題。
它其實同時牽涉 Product、R&D、Product Security、Legal / Compliance、Management，以及 EU Market Information。更麻煩的是，這些角色不是等前一個人把事情全部做完才輪到下一個，而是很可能必須在資訊仍然不完整的情況下，同時開始動起來。
所以我現在反而不會把「24 小時」理解成「24 小時完成 Investigation」，而比較像是：公司必須具備在資訊仍不完整時，快速判斷、Escalation、決策與通報的能力。
這也是為什麼我自己會把 Article 14 Readiness 放在很多其他 CRA 工作之前。因為 CRA 雖然要到 2027 年 12 月才全面適用，但 Article 14 的 Reporting Obligations 2026 年 9 月 11 日就要開始。
當然，以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。尤其是 becoming aware、Active Exploitation 的判定、Coordinator CSIRT，以及實際 SRP Operation 等涉及實際法規適用與操作的議題，我自己仍會持續依 European Commission、ENISA 後續 Guidance 與實際運作方式調整理解與作法。

Day 11 預告｜通報只是其中一段：CRA 的 Vulnerability Disclosure 到底要做到什麼？
Article 14 解決的是：什麼情況需要向 EU 通報。
但 Product Vulnerability Handling 還有另外一個很實際的問題：要不要告訴 Customer？
如果真的發現 Product Vulnerability，什麼時候可以公開？Security Researcher 應該透過什麼方式聯絡 Manufacturer？是不是每一個 Vulnerability 都一定要申請 CVE？如果不是，那 CVE、Security Advisory 與 CRA Reporting 之間到底是什麼關係？
另外，CRA Annex I 又為什麼要求 Manufacturer 建立 Coordinated Vulnerability Disclosure Policy（協調式漏洞揭露政策）？這是不是代表每家公司都要建立一個公開的 Vulnerability Disclosure Website？
Day 11，我們繼續來聊 CVD、Security Advisory、CVE，以及 CRA 下的 Vulnerability Disclosure。