歐盟 CRA（Cyber Resilience Act）通報要求：第 14 條與 SRP

Julian Meroi · 發布日期 2026年10月6日 · 最近校閱 2026年10月6日

誰必須通報？自何時起？

屬 CRA 適用範圍之產品的製造商，自 2026 年 9 月 11 日起即須遵循第 14 條。這也包括於 2027 年 12 月 11 日前投放市場的產品：第 69 條第 3 項明文將通報義務適用於這些較早投放市場的產品。因此，在套用本程序之前，必須先確認產品是否屬於適用範圍，以及製造商的角色。第 71 條第 2 項、第 69 條第 3 項、第 2 條。

通報義務以「知悉」為觸發點。依歐盟執委會指引，製造商若在 2026 年 9 月 11 日前即已知悉漏洞遭積極利用，無須追溯通報。若製造商於該日或之後才知悉遭積極利用的情形，即使漏洞本身早已為人所知，通報義務仍然適用。產品支援期間結束後，通報義務仍持續存在。附件 I 第二部分的漏洞處理要求原則上自 2027 年 12 月 11 日起適用；對於在該日前投放市場的產品，除非自該日起受實質修改，否則不適用，且這些要求隨產品支援期間結束而終止。第 69 條第 2 項、歐盟執委會指引，第 210 段及第 217 段、ENISA SRP 常見問題，§13。

本指南以製造商為對象。開源軟體管理者另有第 24 條第 3 項的通報規定，自 2027 年 12 月 11 日起適用。組織應就相關活動評估自身角色。第 24 條第 3 項、第 71 條第 2 項。

哪些事件會觸發 CRA 通報？

遭積極利用的漏洞

第 3 條第 (42) 款要求有可靠證據顯示，惡意行為者未經系統所有人許可，已在系統中利用該漏洞。第 14 條第 1 項要求製造商在知悉其產品所含的遭積極利用的漏洞時加以通報。漏洞評分、已存在 CVE 編號或尚無修補程式，本身都不足以構成此定義。第 3 條第 (42) 款、第 14 條第 1 項。

歐盟執委會服務部門的常見問題集 §5.2 說明：在善意測試中發現的零時差漏洞，若無惡意利用的證據，不會僅因此觸發強制性漏洞通報。應依法律定義評估實際事實。執委會常見問題集，§5.2。

對於整合的組件，歐盟執委會指引第 218 段處理的是：該漏洞是否存在於製造商的產品中，以及是否已在該產品中遭到利用。指引區分兩種情形：組件漏洞無法在該產品中被利用，或尚未在該產品中被利用。應針對受影響的產品與版本記錄此項評估；不要僅憑供應商公告，就認定每一個下游產品都已遭利用。對該製造商而言不須通報的組件漏洞，仍可依第 15 條自願通報。自 2027 年 12 月 11 日起，對於屬該等義務範圍的產品，第 13 條第 6 項亦要求製造商將在整合組件中發現的漏洞，通報予製造或維護該組件的個人或實體，並依附件 I 第二部分加以處理。若遭積極利用的漏洞源自本身已投放市場的組件，該組件的製造商亦須通報。歐盟執委會指引，第 218 段、執委會常見問題集，§5.4、第 13 條第 6 項。

影響產品安全的重大資安事件

第 14 條第 5 項規定了兩項擇一適用的重大性判斷標準。事件若有下列情形之一，即屬重大：

• 對產品保護敏感或重要資料或功能之可用性、真實性、完整性或機密性的能力，造成或可能造成負面影響；或
• 已導致或可能導致惡意程式碼被植入或執行於產品中，或該產品使用者的網路與資訊系統中。

這些標準涵蓋潛在影響。通報評估應同時考量兩項標準。第 14 條第 3 項及第 5 項。

通報期限與應提供的資訊

製造商何時算是「知悉」？

早期預警通報與 72 小時通報自知悉時起算。最終報告則各有其觸發點：漏洞以矯正或緩解措施可供取得為準，重大資安事件以提交事件通報為準。歐盟執委會指引認為，製造商在對可疑事件或第三方通報進行初步評估後，若有合理程度的確定性認為其產品中的漏洞正遭積極利用，或重大資安事件已危及其產品的安全，即屬知悉。指引期待該初步評估應立即且迅速進行，尤其是在風險可能重大時。記錄事件首次被偵測的時間以及評估完成的時間，可說明知悉時間是如何認定的。歐盟執委會指引，第 211 至 214 段。

早期預警通報與後續通報都必須不無故遲延提交。24 小時與 72 小時是自知悉相關事件起算的最長期限。第二個期限並非自提交早期預警通報時才開始起算。第 14 條第 2 項第 (a) 目至第 (b) 目及第 4 項第 (a) 目至第 (b) 目。

除相關資訊已提供者外，後續通報與最終報告皆須提交。漏洞最終報告必須包括漏洞的描述、嚴重性與影響；可取得的惡意行為者相關資訊；以及已提供之安全更新或其他矯正措施的細節。事件最終報告必須包括詳細描述、嚴重性與影響、可能的威脅類型或根本原因，以及已採行與進行中的緩解措施。必要時，收受通報的經指定為協調者之 CSIRT 得要求提交狀態更新的期中報告。第 14 條第 2 項、第 4 項及第 6 項。

緩解措施可在永久修補程式就緒前，即開始起算漏洞最終報告的期限。事件的期限是一個月，而不是固定的 30 天。這些都源自第 14 條第 2 項第 (c) 目及第 4 項第 (c) 目的文字。

通報應向哪個機關提交？

透過 CRA 單一通報平臺 提交，並使用適當的經指定為協調者之 CSIRT 的電子通報端點。第 14 條要求同時通報予該 CSIRT 及 ENISA；第 16 條則建立了該平臺。第 16 條第 2 項規定了在例外情況下限制通報的傳遞。這些規定涉及通報的分享，並未普遍延長製造商依第 14 條提交通報的期限。第 14 條第 1 項、第 3 項、第 7 項、第 16 條。

製造商在歐盟設有主要營業所者，使用該主要營業所所在的會員國。第 14 條第 7 項以產品網路安全相關決策主要作成地來界定主要營業所；無法認定該會員國時，則以製造商在歐盟境內員工人數最多的營業所為準。

製造商在歐盟沒有主要營業所者，應依其所掌握的資訊，按下列順序認定：

1. 代表該製造商就其最多數量產品行事之授權代表設立所在的會員國。
2. 將該製造商最多數量產品投放市場之進口商設立所在的會員國。
3. 於市場上提供該製造商最多數量產品之經銷商設立所在的會員國。
4. 該製造商產品使用者人數最多的會員國。

依第四項標準，後續通報得提交予首次通報的同一經指定為協調者之 CSIRT。第 14 條第 7 項。

經指定為協調者之 CSIRT 由製造商在平臺上自行選擇。ENISA 提醒，提交給錯誤 CSIRT 的通報可能被判定無效，必須重新提交給正確的 CSIRT，因此應在事件發生前就記錄 CSIRT 的認定評估。ENISA SRP 常見問題，§18。

預先準備平臺存取，並另行保存期限紀錄

以下操作細節已於 2026 年 10 月 6 日依 ENISA 於 10 月 3 日更新的常見問題核對：

• Assigned Representative（AR）使用個人的 EU Login 帳號，並須啟用多重要素驗證（MFA）。ENISA 建議在需要提交通報時才開始 SRP 註冊；EU Login 帳號可事先建立（§9）。
• 每個製造商有一位 Primary Assigned Representative，以及最多 20 位 Secondary Assigned Representative。任何一位都能接續處理已提交的通報，但草稿只有建立者本人看得到。CSIRT 對 AR 與製造商關聯的驗證與通報同步進行；尚未驗證的關聯在驗證成為必要之前，最多可提交 20 件通報（§9）。
• 平臺上的 Assigned Representative 角色，不同於第 18 條所定的授權代表。
• 72 小時倒數計時目前以提交早期預警通報後 48 小時計算。法定期限應自知悉時起算（§26）。
• 平臺中斷期間，ENISA 建議待服務恢復後再提交；若在此期間有必要直接聯繫 CSIRT，也不能取代在 SRP 上的提交（§25）。
• 平臺尚未提供第 15 條的自願通報功能（§27）。

這些平臺操作說明並未修改第 14 條。ENISA SRP 常見問題，§§9、25 至 27、第 18 條。

告知受影響的使用者

向主管機關通報與告知使用者是兩項不同的義務。第 14 條第 8 項要求製造商將漏洞或事件告知受影響的使用者，並於適當時告知所有使用者；於必要時，並應告知使用者可採行的風險緩解與矯正措施。該項也提到於適當時以結構化、機器可讀的格式提供資訊。該項並未規定一體適用的 24 小時使用者告知期限。製造商未及時告知使用者者，受通報的 CSIRT 於相稱且必要時，得向使用者提供該等資訊。第 14 條第 8 項。

依歐盟執委會指引，告知使用者應以風險為基礎，並不要求公開或不加區別地揭露。詳細資訊可限於相關的使用者或客戶，尤其是公開技術細節可能助長漏洞利用時。此外，自 2027 年 12 月 11 日起，對於屬其適用範圍的產品，附件 I 第二部分第 (4) 點要求製造商在安全更新提供後，公開揭露已修補漏洞的資訊。在有正當理由的情形下，若公開的安全風險大於效益，製造商得延後公開揭露，直到使用者有機會套用修補程式為止。歐盟執委會指引，第 220 至 221 段、附件 I 第二部分。

實作範例：內部通報紀錄

以下是依據第 14 條與執委會常見問題集 §5.1 提出的實作範例。此內部紀錄格式及其欄位名稱並非 CRA 所強制規定。通報中依法應提供的資訊，仍以第 14 條為準。

執委會常見問題集 §5.1 舉例說明了製造商可能知悉的管道。這並不表示監控所列的每一個管道都是第 14 條的要求。內部核准流程應有助於及時提交。執委會常見問題集，§5.1。

期限計算範例

假設製造商於 10 月 6 日 10:00（UTC）知悉一項遭積極利用的漏洞。自該時點直接起算的保守內部目標為：早期預警通報 10 月 7 日 10:00（UTC），漏洞通報 10 月 9 日 10:00（UTC）。兩者仍須不無故遲延提交。若緩解措施於 10 月 8 日 10:00（UTC）可供取得，最終報告的內部目標為 10 月 22 日 10:00（UTC），因為該期限自措施可供取得時起算，而非自知悉時起算。規劃時不應假設週末或國定假日會暫停 24 小時與 72 小時的期限。本範例適用第 14 條第 2 項；紀錄格式與作業流程僅為實作建議。

導入協助

Meroi Security 可協助界定通報責任、制定升級處理程序，並以產品資安情境加以演練。歡迎參閱我們的 CRA 合規服務，或閱讀 第 14 條及其實務說明。

如需錄影說明該通報什麼、何時通報、向哪裡通報，請觀看我們 2026 年 2 月的 CRA 通報義務線上研討會。該場研討會錄製於通報義務開始適用之前；本指南則反映審閱日期當時最新的歐盟執委會與 ENISA 指引。