多數企業還把 CRA 當作一次性認證在準備——用產品上市時程回推測試排程，測完了、拿到報告，就當作合規到位。但 Article 14 考驗的從來不是「有沒有做過測試」，而是「事件發生的那一刻，組織內部接不接得住」。這也是這篇文章要談的重點：不是條文本身有多複雜，而是條文背後藏著一個多數企業還沒問過自己的問題。
談 CRA，多數人第一個記住的日期是 2027 年 12 月 11 日，也就是全面適用那天。不過 2026 年 9 月 11 日，就有一條帶著明確罰則的義務要先上路：Regulation (EU) 2024/2847（Cyber Resilience Act）Article 14——製造商的通報義務（Reporting obligations of manufacturers），自 2026 年 9 月 11 日起生效。
對企業經營層而言，這代表 Article 14 不是留給資安或法務團隊自行消化的技術細節，而是可能直接反應在財報風險揭露與董事會議程上的合規事項。
依 Article 64(2)，違反 Annex I 必要要求以及 Article 13、14 義務者，屬 CRA 罰則的最高級距，最高可處 15,000,000 歐元，或（若違規者為企業）前一會計年度全球年營業額的 2.5%，兩者取其高。
不論產品於哪一年上市、是否曾經改版，只要落在 CRA 適用範圍內，9 月 11 日之後，通報義務即對所有在歐盟市場流通的產品同步生效。就算你不打算為你的舊產品重新認證，但只要還在歐盟市場流通且被發現正遭受攻擊，一樣還是得在 24 小時內完成通報。
Article 14 鎖定兩種情境觸發，且各自設有門檻，並非任何弱點都須通報。
第一種是積極被利用的弱點（actively exploited vulnerability）。
(Art. 14(1)) A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.
關鍵在「actively exploited」。依 Article 3(42) 的法律定義，須有可靠證據顯示惡意行為者已在未經系統所有者授權的情況下，於系統中實際利用該弱點——僅是理論上可能遭攻擊並不構成。一個被掃描工具標為高風險、但尚未被實際攻擊的 CVE，通常還不會啟動 Article 14 的通報時限。須待出現實際遭利用的證據，無論由製造商自身監控偵測到、客戶回報，或外部研究人員揭露，計時方才起算。
第二種是影響產品資安的嚴重事故（severe incident）。
(Art. 14(3)) A manufacturer shall notify any severe incident having an impact on the security of the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.
「嚴重」的認定門檻見 Article 14(5)，符合下列任一即屬嚴重：
(Art. 14(5)) (a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or (b) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements.
此處判斷的並非弱點本身的技術嚴重程度，而在於是否已對資料或功能的可用性、真實性、完整性或機密性造成實際或潛在的負面影響，或已導致惡意程式碼被植入或執行。這一類的重點是「已經發生」，而非「可能存在漏洞」。
以資安團隊熟悉的說法來解釋，弱點較接近「可能被攻擊」，事故則是「已遭攻擊」。CRA 將這兩個階段分別管理，且通報節奏亦各自不同。
至於通報主體，始終是製造商，不因產品被歸類為 Default、Important 或 Critical 而有豁免。此點於企業內部溝通時尤須強調，因不少資安團隊會直覺認為自家產品風險不高、應無須理會；但 Article 14 是否觸發，取決於弱點或事故本身的性質，與產品分類無關。
Article 14 的時限規定，是整部 CRA 中少數將時間點寫得相當明確之處，卻也最常被簡化到失真。坊間流傳的版本常將「弱點」與「事故」兩條軌道混為一談，但官方條文其實將兩者清楚分開，連起算基準都不相同。
弱點軌（積極被利用的弱點）：
事故軌（嚴重資安事故）：
兩條軌道的前兩個時間點一致，差異在最終報告的起算基準：弱點軌的 14 天，自修正或緩解措施「可用」之日起算；事故軌的一個月，則自 72 小時通報「提交」之日起算。兩者皆與客戶端最終取得更新的時間無關。此處特別容易出錯，因企業內部常將「更新已發送給客戶」視為流程的結案節點，但 Article 14 的計時方式並非如此。事先釐清此點，方能避免最終報告逾期送出。
須留意的豁免範圍：依 Article 64(10)(a)，微型與小型企業僅就「未能遵守 24 小時早期預警期限」一項不予罰款；通報義務本身、72 小時通報與最終報告，對其仍完整適用。此豁免僅限罰款、且僅限 24 小時該項，義務並未豁免。
另有一項無彈性空間的規定：所有通報均須透過 ENISA 依 Article 16 建立的單一通報平台（Single Reporting Platform，SRP）提交，並同步送達製造商主要營業地所在會員國指定的協調者 CSIRT。電子郵件、電話等非正式管道，均不構成法規認可的通報方式。
熟記時限並不困難，困難的是組織內部須在「知悉」的當下，同時啟動多條作業線：技術須確認證據、法遵與公關須擬定對外用語、業務或客服可能須同步準備客戶溝通，而這些都須壓縮進 24 小時內，產出第一份對外文件。多數企業現行的資安事件應變流程，是為了盡快修復而設計，鮮少為了在極短時間內產出一份符合法規格式的官方通報而設計。這正是 9 月 11 日這一關讓許多製造商難以及時因應的原因。
接下來真正的問題是，內部流程該如何搭建，才能在事件真正發生時承接這些時限。這部分將於下一篇說明，從 SOP 的骨架開始拆解。
歡迎參加 9 月 18 日（五）台北實體研討會，直接向來自西班牙的 CRA 專家提問，進一步說明 2027 合規規劃佈局及導入所需的時間與成本估算。報名連結：實體研討會報名連結
Q：CRA Article 14 何時生效？
2026 年 9 月 11 日，早於 CRA 全面適用 2027 年 12 月 11 日。它適用於所有在歐盟市場流通的產品，無論是何時上市。
Q：Article 14 所要求的兩種通報情況是什麼？
一是有明確證據顯示其弱點已被積極利用（actively exploited vulnerability）；二是已對產品資安造成實際或潛在影響的嚴重事故（severe incident），例如影響資料的可用性、真實性、完整性或機密性。
Q：Article 14 的通報時限是多久？
這兩類都必須在 24 小時內提交早期警示、72 小時內提交具體通報。弱點類的最終報告必須在修正或緩解措施可用之日起 14 天內提交；事故類，需於 72 小時通報提交日起一個月內完成。
Q：CRA 通報要透過哪些管道？
須通過 ENISA 依 Article 16 設立的單一通報平台（SRP），同時交付給製造商主要營業地會員國指定的協調 CSIRT。非正式管道如電子郵件和電話不予認可。
本文所引法規條文與時間點，均以下列官方文件為準：
文／安合規律 × Applus+ Laboratories 顧問團隊
＊本文為法規解讀性質，非法律意見。個案之最終認定，仍應以歐盟官方文件與主管機關解釋為準。
