法規 (EU) 2024/2847 的獨立指南 · 狀態：已生效
本頁為自動（AI）翻譯，未經人工審閱。
了解 CRA・通報

CRA 事件與漏洞通報

自 2026 年 9 月 11 日起，製造商必須依第 14 條通報主動被利用漏洞與嚴重事件。本頁說明應通報什麼、24 小時、72 小時與最終報告的期限、由誰接收，以及 ENISA 的單一通報平台在上線後實際如何運作；並包括平台至今仍未提供的功能。

約 19 分鐘閱讀Art. 14 · 16 · 18自 2026 年 9 月 11 日起適用審閱於 2026 年 9 月 11 日

01須通報什麼

相關法規的 Art. 14 網路韌性法 為含數位元素的產品製造商設立兩項通報義務。其範圍比乍看之下更窄：例行程式錯誤與一般修補程式並不在範圍內。 Art. 14

  • 主動被利用漏洞；指你的產品中的漏洞，且有可靠證據顯示惡意行為者已在未經擁有者許可的情況下於系統中加以利用。若你在漏洞遭利用前即發現並修補，則透過你既有的 漏洞處理流程，而非本通報管道。
  • 嚴重事件；指對產品保護資料或功能之可用性、真實性、完整性或機密性的能力造成負面影響，或可能造成負面影響的事件。嚴重性判斷標準見第 14(5) 條。

這些義務並不限於商業製造商。 開放原始碼軟體維護者 在其涉及含數位元素的產品之範圍內，負有自身的通報義務。 Art. 24(3)

測試標準

若您產品中的安全弱點正遭主動利用，或安全事件已對其造成嚴重影響，Art. 14 的計時即開始。其他情況均屬日常漏洞處理範疇。

通報義務不溯及既往

若某項漏洞遭主動利用一事，你在通報義務開始適用之日，即 2026 年 9 月 11 日之前即已知悉，則毋須通報。該義務繫於你 獲悉之時，因此僅涵蓋你自該日起所獲悉者，不再往前追溯。

但它確實及於你已經售出的產品

這一點最容易讓人誤解，值得說得精確一些。 第 69(2) 條 訂定一般過渡規則：於 2027 年 12 月 11 日 之前投放市場的產品，僅在自該日起經 重大修改 時，才受本規則規範。單獨閱讀，這似乎意味著你既有的產品目錄不受影響。

第 69(3) 條 接著又將第 14 條直接排除於該規則之外。依明示減損規定，通報義務適用於 所有 於 2027 年 12 月 11 日之前投放市場、且屬本規則適用範圍的含數位元素的產品，無論其是否曾經修改。

因此這兩項規則沿著不同的軸線運作。你在 2025 年售出的產品也許永遠不需要依 CRA 進行 CE 標示，但若該產品中的漏洞遭主動利用，且你在 2026 年 9 月 11 日當日或之後獲悉，即應通報。你的 既有安裝基礎屬於通報範圍 ，即使其不在產品要求的適用範圍內亦然。執委會在其《CRA 實施常見問答》第 5.3 節中也得出相同結論。 Art. 69(2)–(3)

02三個截止期限

每份報告分三個階段進行，計時起點為您 獲悉 遭利用之漏洞或嚴重事件時起算。時間窗相當緊迫，因此事前準備至關重要。 Art. 14(2)–(4)

  • 24 小時內早期預警。 首次通報已發生主動被利用漏洞或嚴重事件；就事件而言，並須說明是否懷疑係由非法或惡意行為所致。
  • 72 小時內漏洞／事件通知。 較完整的說明：漏洞與利用手法的一般性質、初步評估，以及已採取的矯正或緩解措施，加上使用者可採取的措施。
  • 最終報告最終報告。 就 漏洞而言，不遲於 14 天 ，自矯正或緩解措施可供取得時起算。就 嚴重事件而言，須於 一個月 內，自 72 小時通報起算。該報告載明完整說明、嚴重性、影響及所採行的補救措施。

請注意最後一列的不對稱：漏洞的計時由修補措施的存在觸發，事件的計時則由先前的通報觸發。兩者機制不同，值得在你的作業手冊中分別載明。

03生效時間

通報義務是 CRA 最早生效的主要部分。雖然大多數條款自 2027 年 12 月 11 日起適用，Art. 14 自 2026 年 9 月 11 日；即該法生效後 21 個月。ENISA 於同一日開放了單一通報平台。 Art. 71

狀態 · 2026 年 9 月 11 日

平台已上線，其所服務的義務也隨之生效。ENISA 公布的網址為 portal.cra-srp.enisa.europa.eu，你在該處選擇 Assigned Representative 角色，並以已啟用多因素驗證的 EU Login 帳號登入。此網址公布於 ENISA 於 2026 年 9 月 10 日、即開放前一日所做的常見問答更新中。

ENISA marked the launch by publishing an AR User Manual and a set of platform terms and conditions, version 1.0 of 10 September 2026, and by adding four questions to the FAQ: how to connect, when the obligations start, what to do if you are not a manufacturer, and how to report a security problem in the platform itself. The AR User Tutorial Video, promised for launch, went live within days, and the SRP Factsheet followed in nine further EU languages. The platform interface itself still runs in English only, with other languages deferred to a later phase.

有四件事並未隨平台一同到位，本頁大部分內容都是圍繞著它們而寫：第 15 條的自願通報仍然付之闕如且未附日期；仍然沒有 API；72 小時計時器仍自你遞交早期預警起算，而非自你獲悉的時點起算；而用來記錄你何時獲悉主動被利用漏洞的欄位，仍保留至後續版本。支撐漏洞處理的調和標準同樣尚未發布，在執委會 2026 年 7 月就標準化請求 M/606 提出的修正草案將 2026 年的期限往後推兩個月之後，目前預計在 2026 年 10 月 30 日前後出現，且尚未在官方公報中引用。

為何這是首個重要截止日期

與 CE 標示不同，CE 標示是在產品投放市場前完成一次即可，而通報則是一項自 2026 年 9 月起生效、其後隨時可能被觸發的持續性義務。做好準備不是一次性的專案。現在就建立內部的偵測與通報流程；無論工具是否完備，該義務自 2026 年 9 月 11 日起適用。

04通報對象

通報對象為 ENISA 及向 指定為協調員的 CSIRT，透過單一入口，而非分別向各國主管機關遞交。該入口即 單一通報平台，由 ENISA 依第 16 條建立、管理與維護。 Art. 14 · 16

你所對應的 CSIRT 取決於你在歐盟境內的 主要營業所 ；若你並未在歐盟設立，則取決於你的 授權代表所在地。接收的 CSIRT 會將通報轉發給產品可取得之會員國的 CSIRT，並視需要轉發給市場監督機關。 Art. 14(7) · 18

協調者名單已於 2026 年 9 月 4 日公布

直到 2026 年 9 月 4 日 之前，本頁上最實際的問題——究竟哪一個國家團隊真正接收你的申報——都沒有公開的答案。ENISA 現已發布一份 獲指定為協調者的 CSIRT 名單 ，為全部 27 個會員國各提供一或多個聯絡網址，並於 2026 年 9 月 10 日重新標註日期，因此在依賴先前取得的副本之前，請再次核對你所在的那一列。愛爾蘭指向一個專為 CRA 設立的 NCSC 頁面；西班牙則提供兩條各自獨立的 INCIBE 路徑，一條處理事件，一條處理漏洞協調。

該名單告訴你各會員國的協調者是誰，卻沒有告訴你哪一個是你的；而且第 14(7) 條的判準比多數組織所以為的更窄。你的 主要營業所 ，是指關於你含數位元素產品之網路安全的決定 主要作成所在的會員國；該地可能是一處開發據點，而非登記辦事處或規模最大的商業據點。若無法確定，則退而以你在歐盟境內員工人數最多的會員國為準。若完全未在歐盟設立，順序為：你的授權代表為最多產品行事的會員國，其次是將最多產品投放市場的進口商，再次是提供最多產品的經銷商，最後是使用者最多的會員國。由於這會固定日後每一次申報的收件對象，請事先在法律意見的協助下確定，並寫下判斷理由。

雙方都有支援管道。 ENISA 設有服務台，並特別關注中小企業；而 獲指定為協調者的 CSIRT 亦須就第 14 條義務提供服務台支援。ENISA 也會將已修補的漏洞匯入 歐洲漏洞資料庫，並每兩年發布一份技術趨勢報告，第一份應於通報義務開始後 24 個月內提出。 Art. 17(6)

已通報漏洞的轉發可由 CSIRT 暫停，但你不能

接收的 CSIRT 得基於正當的網路安全理由，在嚴格必要的期間內延遲或保留後續轉發；例如某漏洞正處於協調揭露程序之中。執委會已在 授權法規 (EU) 2026/881中訂明相關條件，該法規的通過日期為 2025 年 12 月 11 日。CSIRT 保留通報時，必須立即告知 ENISA，並提出理由及預計轉發的時間。

此外，在 特別 例外的情形下，你可以在 72 小時通報中勾選 第 16(2) 條 所列的其中一項狹義條件：該利用行為僅限於你的 CSIRT 所屬會員國、進一步轉發將牴觸該會員國的重大利益，或轉發將造成迫在眉睫的高度網路安全風險。若你這麼做，在 CSIRT 釋出完整通報之前，ENISA 只會收到有限資訊（已提出通報一事、關於產品的一般資訊、利用手法的一般性質，以及已提出安全理由一事）。

PEC 僅適用於漏洞，而且是一項請求，不是開關

2026 年 9 月 9 日 ENISA 發布了專門說明特別例外情形（PEC）的指引頁面，解決了先前資料留下的適用範圍疑問。可以援引 PEC 的情形， 僅限於主動被利用漏洞的 72 小時通報。就 嚴重事件而言並無對應機制，平台也未在事件通報上提供任何 PEC 控制項。

在操作上，它是 72 小時表單底部的一個切換開關，開啟後會顯示三項延後理由以及一欄選填的自由文字說明。該說明並非裝飾：ENISA 表示，它有助於 CDaC 判斷是否接受該筆以 PEC 提交的通報。因此援引 PEC 是請求施加限制，而不是逕行施加限制，該筆紀錄只是進入 72h Submitted under PEC 狀態，等候協調者決定。撰寫說明時，請設想它會被一位必須在保密與儘快告知其他會員國之間權衡的人閱讀，因為確實會如此。

關鍵的區別

這兩種機制都不會暫停 你的 計時。你不能延遲 遞交；24 小時、72 小時與最終報告的時間窗均自獲悉時起算。你能做的是標示敏感性，藉此限制 誰能看到內容。是否保留轉發的決定權，屬於接收的 CSIRT。

05在平台上註冊

ENISA 重新標註為 2026 年 9 月 10 日的註冊指引，以及重新標註為 2026 年 9 月 9 日的介面指引，展示了實際畫面。註冊已於 2026 年 9 月 11 日隨平台一同開放，因此這已是一套你可以實際走過的流程，而不只是閱讀而已。儘管如此，ENISA 仍基於下述理由請你不要預先註冊，這反而使事先熟悉流程更有價值，而非更無價值：你第一次走這套流程時，很可能正有一個 24 小時的時鐘在跑。

在需要之前先指派兩個人

平台為每一家製造商提供 兩 種使用者帳號，而你今天就可以決定由誰擔任。 主要 代表先行註冊，並在平台上建立該製造商的資料。該人員接著邀請一位 次要 代表，該代表對同一家製造商擔任備援角色，並可代其遞交。兩者都是你公司內的具名人員。由於遞交需人工完成，若僅有一位指定通報人，而該人正在休假、就寢或已離職，將構成實質的營運風險，因此第二個名額應視為必要而非可有可無。

EU Login 就是登入憑證，兩個人今天就能建立

平台帳號透過 EU Login進行認證，這是歐盟執委會跨其線上系統使用的共用登入服務。請分別為主要代表與次要代表各建立一個，網址為 ecas.ec.europa.eu，並使用一年後仍然存在的公務電子郵件地址。多因素驗證為強制規定：ENISA 要求在首次存取平台前於 EU Login 帳號啟用 MFA，因此若你的人員已持有一般的 EU Login 帳號，請他們現在就開啟 MFA，而不要等到事件發生時。EU Login 帳號屬於個人，ENISA 並未在其之上另行運作企業認證。執委會在其 可信數位身分 頁面中說明了 EU Login 是什麼，以及它如何融入其更廣泛的身分框架。

註冊流程

首次進入平台時，你要選擇自己的角色，從下拉選單中選取你的 指定 CSIRT ，透過 EU Login 進行認證，閱讀並接受法律協議，確認系統預填的個人資料（名字、姓氏、電子郵件、法定名稱），然後輸入製造商的名稱、地址與其他資訊。若遺漏任一必填的製造商欄位，流程將無法繼續。完成後，你的帳號狀態為「Active」，並取得 「AR Primary User」 角色，你會收到一封確認郵件，製造商實體也會在平台中建立。

該 次要 代表則透過來自主要代表的 電子郵件邀請 加入，確認預填的個人與製造商資料，並就同一家製造商登錄為 「AR Backup User」 角色。該邀請的有效期為 7 天，逾期後該筆紀錄會標示為「Invitation Expired」，必須重新發送。請在設定主要代表的同一時段一併設定備援；在事件處理過程中才發現邀請已失效，是可以避免的麻煩。

CSIRT 會以人工方式查核你的代表，但這不會妨礙你遞交

必須有人確認某位人員確實可以代表某家製造商通報，而這項查核由獲指定為協調者的 CSIRT 負責，ENISA 現在將其縮寫為 CDaC。這是人工步驟，各 CSIRT 的程序不盡相同，且各自決定其作法。關鍵在於，它發生於 你首次進入平台之後 ，並與你的通報 同時 進行。在其 2026 年 8 月 3 日 的更新中，ENISA 明確指出：CDaC 的驗證 並非履行 CRA 通報義務的前提條件，也不影響你遞交通報的能力。未經驗證的帳號仍可在 24 小時時間窗內遞交。

這也是為什麼 ENISA 建議，只有在你確實需要遞交時才進行註冊並啟動驗證，而不是讓整個市場預先註冊、使 CSIRT 淹沒在推測性的查核之中。你可以事先完成的準備，是 EU Login 帳號以及決定由誰擔任這兩個角色，而非平台註冊本身。

但未經驗證的帳號上限為 20 則通報

當代表透過 Association Management將其帳號連結至某家製造商時，該關聯建立時的狀態為 Unverified ，並會向 CDaC 送出驗證請求。 2026 年 8 月 14 日 的介面指引將上限訂為 10 則通報。而重寫於 2026 年 9 月 4 日 的常見問答將其加倍：未經驗證的代表 就同一家製造商最多可遞交 20 則通報 ，此後驗證即成為強制要求；而重新標註為 2026 年 9 月 9 日 的介面指引現在也寫著 20。

兩項陳述可以並存：驗證並非你首次遞交的門檻，但也不能無限期拖延。ENISA 並未說明第 21 次嘗試會發生什麼，也未說明該上限計算的是事件數還是個別遞交數。若你在 8 月把「10」抄進內部程序，請更正為 20。20 對單一產品的公司而言相當寬裕，但對跨多個法律實體遞交的集團而言仍屬有限；若你屬於後者，請主動與你的協調 CSIRT 展開對話，而不要等到事件逼著你去做。

一個帳號可以持有多家製造商

同一份指引也說明了這兩個席位的日常管理。主要代表以電子郵件地址邀請備援，這會建立一筆紀錄，其標示為 「Pending Invitation」 ，在接受之前不具任何角色。次要代表可以請求升為主要代表，該請求會送交 CDaC 審查。ENISA 已於 2026 年 9 月 17 日將此正式化，將常見問答第 9 題標註為「[已更新]」，並說明次要 AR「不具備與主要 AR 相同的行政權限，但可主張擔任主要 AR 角色，惟須經指定 CSIRT 審核並核准」。任一方都可以移除關聯，該關聯隨後會標示為 「Deleted」。此外，單一帳號可以同時持有與 多家製造商的關聯，各筆關聯均透過 Association Management 新增，並各自分別驗證。

最後這一點對於擁有多家製造法律實體的集團，以及依第 18 條為設立於歐盟境外之製造商行事的公司，格外重要。這也是下方的名稱陷阱最容易造成困擾之處。

一個值得及早釐清的名詞陷阱

ENISA 的指引是針對「Assigned Representatives」（AR）撰寫的，其中分為主要使用者與備援使用者。那是一種 平台帳號角色。它並 不 是 授權代表 （依 CRA 第 18 條以書面委任所指定者）。你可以有前者而沒有後者。請在內部程序中將兩者區分清楚，否則你可能會為了一項法律上的指派而爭論不休，而你真正需要的只是第二組登入帳號。

06遞交報告

通報作業從儀表板開始。你建立一筆通報，然後在各階段補充同一筆紀錄，而非分別遞交三件東西。每個階段有各自的頁籤，且都可以先存為草稿。儀表板可依通報 ID、製造商或標題搜尋，依標題或最後更新排序，並可依會員國、遞交類型或 Action Required 標記進行篩選。

你的備援看不到你的草稿

重新標註為 2026 年 9 月 9 日的介面指引寫得很明確：主要代表可看到與製造商相關聯的每一則通報，但次要代表只能看到自己遞交的通報與自己建立的草稿，無法檢視同一家製造商的另一位代表所遞交的通報。草稿屬於其作者私有，不會在公司內部共用。

設想後果。有人開始撰寫 24 小時早期預警、存成草稿，然後失聯；備援打開儀表板卻什麼也找不到，而 24 小時的時間窗自獲悉起一直在跑。請在 平台之外 草擬文字，寫在事件處理團隊已經共用的文件中，再用平台謄寫。

  • 早期預警從儀表板建立新的通報，填妥必填欄位，並選擇既有製造商或新增一家。遞交後即可供你的指定 CSIRT 存取，並自動送交 ENISA。電子郵件與提示的確認訊息會發送給 CSIRT、ENISA，以及為該製造商登錄的 每一位 代表，而不只是遞交的那個人。
  • 72 小時須先有早期預警才能使用。開啟同一筆通報並填妥 72 小時頁籤。ENISA 會自動收到， 除非 你援引第 16(2) 條的條件；此時該筆紀錄會被標記為「72h Submitted under PEC」，且在 CSIRT 釋出之前，ENISA 可見的內容受到限制。
  • 最終報告須先有前兩個階段才能使用。除非援引了第 16(2) 條的條件，否則 ENISA 會自動收到。
要傳達到其他會員國，每個階段都需人工操作

ENISA 於 2026 年 8 月 3 日 的指引指出，其他相關 CSIRT 要收到早期預警、72 小時通報與最終報告，都必須等到 人工轉發之後 ，而轉發是由獲指定為協調者的 CSIRT 執行。7 月 31 日的版本只就最終報告如此表述。你的義務沒有任何改變，CDaC 依第 16(2) 條仍必須 毫不延遲地轉發；但值得知道的是，在你的通報與你產品銷售的其他市場之間，隔著某一個國家 CSIRT 的一位承辦人員。

何時必須提供哪些內容

ENISA 已公布各階段的必填欄位。該表格有助於修正一項普遍的誤解：24 小時的早期預警是一則 警示，而不是一份調查報告。

  • 24 小時時；通報類型與層級、製造商或管理者名稱、產品，以及標題。就事件而言，還需說明是否懷疑涉及非法或惡意行為。產品可取得的會員國僅在你已掌握該資訊時才須填寫。
  • 72 小時時；漏洞與利用手法的一般性質、已採取的矯正或緩解措施，以及使用者可採取的措施。就事件而言，還需說明偵測時間與發生時間，加上初步評估。敏感性於此階段標示。
  • 最終報告時；完整說明、嚴重性與影響、矯正措施可供取得的日期，以及安全更新的細節。就事件而言，還需說明可能的根本原因與持續進行的緩解措施。

仍值得填寫的選填欄位包括 CVE ID 以及 EUVD ID，兩者自第一階段起即可填入。

每個欄位都有字數上限，其中一個非常短

ENISA 的 SRP 詞彙表，於 2026 年 9 月 5 日的 1.1 版首次載明各欄位大小，現為 2026 年 9 月 10 日的 1.3 版，是公布每個輸入框大小的 ENISA 文件。請依這些上限撰寫你的內部範本，而不是在凌晨兩點才發現它們：

  • 4000 字元 ：適用於敘述性欄位，即摘要、關於漏洞或事件的一般資訊、使用者可採取的矯正措施、嚴重性與影響的完整說明、初步評估，以及就事件而言已採取及進行中的緩解措施。
  • 2000 字元 ：適用於你已採取的矯正或緩解措施，以及最終報告中安全更新或矯正措施的細節。
  • 800 字元 ：適用於 72 小時漏洞通報中附於 PEC 請求的自由文字理由。
  • 255 字元 ：適用於標題、產品名稱、產品版本範圍、元件名稱、攻擊向量、敏感性理由，以及可能的根本原因。
  • 100 字元 ：適用於利用該漏洞的惡意行為者。這大約只有一行，因此請規劃指名該行為者或指向某項指標參照，而不是描述整場攻擊行動。

詞彙表也確認了一項小小的便利： 產品可供應的會員國 欄位會預先填入你自己的協調 CSIRT，其他市場則由你自行新增。

編輯，以及無法回頭的時點

已遞交的通報可以更新，平台會自動向你的 CSIRT、ENISA，以及任何已透過轉發收到該通報的 CSIRT 發送一則提示與一封電子郵件。但有兩項限制：已 結案 的通報無法更新；而且該紀錄會在 最終報告遞交後即無法編輯.

留意提示頁籤，週末也不例外

每個帳號都有一個 提示 頁籤，以顏色區分：未讀提示為淺藍色，開啟後轉為灰色，而紅色提示只在發生異常情況時才出現。ENISA 舉的例子是指定 CSIRT 將一份遞交判定為無效。因此遞交並非往來的終點，也不會因為一則通報被退回而改變任何第 14 條的期限。負責盯著該頁籤的人必須在下班時間也盯著，這也是應在兩個席位後方設置受監控團隊信箱、而非兩個個人信箱的另一項理由。

平台的 72 小時計時器並非自獲悉時起算

常見問答揭露了畫面上的倒數計時實際如何運作，而它們並不追蹤法定期限。ENISA 更新常見問答的日期為 2026 年 9 月 10 日，即開放前一日，而這則答覆維持原狀，因此此處所述的行為就是實際上線的行為。在目前版本中， 72 小時計時器 顯示的到期時間為 你遞交 24 小時報告後的 48 小時，而不是你獲悉後的 72 小時。ENISA 明白表示，因此一筆通報可能顯示為 逾期 ，即使自獲悉起尚未經過 72 小時；並表示該邏輯將在後續版本改為自「date and time when you became aware」欄位起算，漏洞與事件皆然。

最終報告的計時器又有不同。就 嚴重事件 而言，計時器顯示的是 72 小時通報之後一個月。至於 主動被利用漏洞 ，則 完全沒有計時器，因為期限取決於修正措施何時可供取得，而平台無從得知。

自行計時

ENISA 明確表示，這些計時器只是為了讓你看得見，並 不取代 第 14 條的義務。請自獲悉的那一刻開始計時，並記入你的事件紀錄。依法律所期望的那樣儘快提出早期預警，反而會讓畫面上的計時器比法定期限 更嚴格 。畫面上的「逾期」標示並不構成不合規的認定，綠色的計時器也不是抗辯理由。

上線時平台不會記錄你何時獲悉

2026 年 9 月 5 日 ENISA 已將其逐欄位的 SRP 詞彙表更新為 1.1 版。其中兩則註腳比這一頁上的任何內容都更重要。就主動被利用漏洞而言， Date/time when you become aware 欄位附註說明它 將於平台的下一個版本提供。就嚴重事件而言，該註腳表示在目前版本中，對應欄位的名稱為 Date/time the incident was detected.

與上述計時器邏輯並置，這就把一個圓圈畫完了。常見問答曾說，一旦獲悉欄位到位，72 小時計時器就會修正；詞彙表則說該欄位會在後續版本才出現。兩者在開放前都沒有任何變動：ENISA 於 2026 年 9 月 10 日 再次將詞彙表修訂為 1.3 版，並讓兩則註腳保持原樣。因此自第一天起，平台對漏洞完全不會擷取任何獲悉時間戳記，對事件則擷取偵測的時點，而那並不是獲悉的時點。

偵測不等於獲悉，而這個差異要由你來舉證

依執委會 2026 年 7 月 27 日 的指引，當初步評估使你獲得 合理程度的確定性 ，認定你產品中的漏洞正遭利用或已發生嚴重事件時，你即為獲悉。偵測通常更早發生，有時早得多。由於平台記錄的是偵測時點而非評估時點，它所保存的紀錄並不是第 14 條起算的時點。請自行保存一份加註時間的紀錄，記下初步評估何時作成結論、由誰作出判斷。若市場監督機關日後詢問早期預警為何在該時點送出，你的證據是那份紀錄，而不是平台。

平台無法使用時，時鐘依然在跑

ENISA 於 2026 年 9 月 4 日新增了一則關於服務中斷的問答。若 SRP 暫時無法使用，請等到恢復後再遞交。若期間確有立即聯繫的必要，你可以直接聯絡你的指定 CSIRT，但服務恢復後，通報仍必須透過平台提出。

有一點值得明說，因為 ENISA 沒有說：CRA 中沒有任何規定會在服務中斷期間暫停 24 小時、72 小時、14 天或一個月的時間窗。請為中斷情形以及你所做的任何直接聯繫加註時間戳記，並與你的獲悉時間戳記一併保存。

目前沒有 API

ENISA 表示， 初始版本不會提供應用程式介面，並表示 API 功能可能於未來階段納入考量。你可以在內部將偵測、分級與草擬自動化，但遞交本身仍是由人在瀏覽器表單上完成。請刻意規劃這個交接環節，並確保在下班時間與週末都有不只一個人能夠執行。

自願通報並未隨平台一同到位

平台最終將受理關於漏洞、網路威脅、事件與虛驚事件的自願通報，來源不限於製造商，任何自然人或法人皆可提出。2026 年 7 月 31 日的常見問答曾表示此功能將於 2026 年 9 月 11 日之後啟用。實際上並未啟用。已開放的平台僅受理第 14 條與第 24 條的強制通報，第 15 條的自願通報則移至沒有日期的未來階段。

ENISA 現在明確說明了這對其他所有人的後果。若你不是製造商，而想通報漏洞或其他安全問題，請直接聯繫相關的國家 CSIRT，因為改由平台提出的遞交可能會被標記為「無效」。法律上要求的東西並無缺漏，但沒有低風險的演練機會；而原本打算將未遭利用的漏洞導入 SRP 的揭露流程，仍然無處可送。

07你今天可以做的事

守住 24 小時的時限是營運問題，而不是文書問題。既然平台已經開放，下列清單就不再是為未來事件所做的準備；義務已經在跑，此處任何你尚未完成的事項都是曝險，而不是計畫。

  • 建立你的 EU Login 帳號，並開啟 MFA。 為主要通報人與至少一位備援各建立一個。只需幾分鐘，網址為 ecas.ec.europa.eu，而平台不會讓任何未使用多因素驗證的人進入，因此啟用它是這項工作的一部分，而不是錦上添花。
  • 確認你的指定 CSIRT。 ENISA 已發布 協調者名單 ，涵蓋全部 27 個會員國，發布日期為 2026 年 9 月 4 日，因此這現在是一項你可以完成的工作。請套用第 14(7) 條的主要營業所判準，選出你的那一列，並寫下判斷理由。
  • 在內部建立 24 小時表單。 製作一份對應 ENISA 早期預警必填欄位的簡短範本，讓你第一次正式遞交時只需謄寫，而不必臨場撰寫。請放在兩位代表都能開啟的地方，因為平台上的草稿只有建立者本人看得到。
  • 指定負責人員，包含下班時間。 決定由誰判斷應予通報、由誰草擬、由誰遞交。由於沒有 API，最後一步必然是一位具名的人坐在鍵盤前。
  • 維持精確的 SBOM。 你無法通報一個你根本不知道自己出貨過的元件。請維護軟體物料清單，並隨版本變動保持更新。
  • 持續監控。 將你的元件與已知漏洞來源比對，讓遭主動利用的缺陷能在數小時內浮現，而不是數週。我們的 SBOM 與漏洞分析器 會將你的物料清單與 NVD 及歐盟漏洞資料庫（EUVD）進行比對追蹤。
  • 確認實際適用範圍。 72 小時階段會要求填寫產品類型以及附件 III 或 IV 的類別，因此請在需要之前先確定分類。 分類工具 可以回答這個問題，而 符合性矩陣 將通報與其所屬的更廣泛 Annex I 漏洞處理義務相連結。
  • 決定下班時間由誰查看提示頁籤。 指定 CSIRT 可以將一份遞交判定為無效，而告知此事的提示只會出現在平台上，未必進到你的收件匣。請在兩個代表席位後方設置一個受監控的信箱。
  • 不要依賴平台的倒數計時。 請自行記錄你的獲悉時間戳記。畫面上的 72 小時計時器是從 24 小時報告遞交起算，而非從獲悉起算，因此可能在法定期限尚未屆至前就把一筆通報標示為逾期。
  • Read the AR User Manual, and watch the tutorial video. ENISA published the manual at launch and added the AR User Tutorial Video within days, so between the two, plus the guidance pages, you have the fullest available description of the live platform.
  • 遞交前先確認你選對了協調員。 ENISA 現在提醒，若選錯了指定為協調員的 CSIRT，通報可能被判定為無效，屆時你必須在時鐘持續走動的情況下，重新向正確的對象遞交。
開啟漏洞分析器 →CRA 解析 →

08追蹤原始出處

本頁反映的是 2026 年 9 月 11 日、即平台開放當日的情況。情況仍會持續變動，而 ENISA 傾向悄悄修改頁面，而不是公告每一項變更。上線前一週，常見問答於 2026 年 9 月 4 日重寫、於 2026 年 9 月 10 日再次更新，協調員名單於 2026 年 9 月 4 日出現並於 2026 年 9 月 10 日重新標註日期，詞彙表於 2026 年 9 月 5 日達到 1.1 版、於 2026 年 9 月 10 日達到 1.3 版，關於特別例外情況的指引於 2026 年 9 月 9 日發布，AR User Manual 與平台條款及條件則於 2026 年 9 月 10 日公布。自上線以來，常見問答已於 2026 年 9 月 12 日再次更新（AR 使用者教學影片上線，SRP 資訊單張新增九種語言版本），並於 2026 年 9 月 17 日再度更新，當時第 9 題被標註為「[已更新]」，以記載次要 AR 可在指定 CSIRT 審核後主張擔任主要 AR 角色。 關於支援問題，ENISA 在主要入口頁面公布了服務台地址：cra-srp-helpdesk [at] enisa.europa.eu。以上為第一手來源；上文所述皆為我們對這些來源的解讀。

「最後更新」標記不是可靠的版本依據

我們先前建議，凡是抄入內部程序的內容都應一併記下該標記。這項建議需要一項但書。 在 2026 年 9 月 7 日至 9 日期間 之間，ENISA 大幅重寫了 AR Notification submission and update 頁面，卻仍讓頁面上的標記維持為 3/08/2026：用語全面改為 CDaC 並刪去了對國家端點資料層的提及，提交確認現在會送達該製造商的 每一位 Assigned Representative，而不只是提交者；並且明白指出，早期預警要送達其他相關 CSIRT，必須先經 人工 轉發。若某份指引頁面對你的程序很重要，請自行保留一份註明日期的內文副本，而不要相信 ENISA 印在頁面上的日期。

上線當天再次印證了這一點。2026 年 9 月 11 日上午，AR 介面功能頁面仍標示 14/08/2026，未驗證上限也仍是 10；到了下午，頁面已標示為 2026 年 9 月 9 日並寫著 20，而沒有任何公告。主要入口頁面將 PEC 指引列為 2026 年 9 月 10 日更新，但頁面本身標示的是 2026 年 9 月 9 日；詞彙表也以同樣悄然的方式從 1.1 版變為 1.3 版。當 ENISA 的兩個頁面彼此不一致時，請以常見問答為兩者中較新的一方。

就具拘束力的條文而言，第 14 至 17 條規範整個通報體系，第 16 條則設立該平台；請在我們的 法規閱讀器中閱讀。里程碑日期則追蹤於 最新進展 頁面。

09常見問題

我須依 CRA 通報什麼，以及需多快通報？

影響你產品安全性的主動被利用漏洞與嚴重事件。獲悉後 24 小時內提出早期預警，72 小時內提出較完整的通報，並在漏洞的矯正措施可供取得後 14 天內、或嚴重事件的 72 小時通報後一個月內提出最終報告。 Art. 14

通報義務何時開始？

2026 年 9 月 11 日；即本法令生效後 21 個月，遠早於 2027 年 12 月 11 日的全面適用日。

我應向誰通報？

ENISA 以及獲指定為協調者的國家 CSIRT，透過依第 16 條設立的單一通報平台。你對應的 CSIRT 取決於你在歐盟境內的主要營業所；若你並未在歐盟設立，則取決於你的授權代表所在地。

協調 CSIRT 的名單是否已公布？

是，自 2026 年 9 月 4 日起已公布。ENISA 公布了全部 27 個會員國的聯絡窗口。該名單指出各會員國的協調者是誰；至於哪一個是你的，仍取決於第 14(7) 條的主要營業所判準，而該判準的關鍵在於關於你產品網路安全的決定主要在何處作成。

我是否必須通報每個錯誤或漏洞？

否。僅主動被利用的漏洞及嚴重事件需要通報。您在漏洞被利用前發現並修復的漏洞，透過您的一般漏洞處理流程管理。

ENISA 的單一通報平台是否已上線？

是。它已於 2026 年 9 月 11 日、也就是第 14 條義務開始適用的同一天開放，網址為 portal.cra-srp.enisa.europa.eu。請選擇 Assigned Representative 角色，並以已啟用多因素驗證的 EU Login 帳號登入。ENISA 於 2026 年 9 月 10 日、即開放前一日，在其常見問答中公布了此網址。

已開放的平台還缺少什麼？

有四件事值得納入規劃。第 15 條的自願通報付之闕如，且沒有日期。沒有 API，因此遞交就是由一個人在瀏覽器表單中填寫。72 小時計時器自你遞交早期預警起算，而非自獲悉起算，因此可能在法定期限尚未屆滿前就把一筆遞交顯示為逾期。而記錄你何時獲悉主動被利用漏洞的欄位，則保留至後續版本。此外平台目前僅有英文版。

當我需要遞交時平台故障，該怎麼辦？

ENISA 於 2026 年 9 月 4 日新增的答覆是：等待平台恢復後再遞交。若期間確有立即聯繫的必要，你可以直接聯絡你的指定 CSIRT，但通報事後仍必須透過平台提出。請注意，CRA 中沒有任何規定會在服務中斷期間暫停你的期限，因此請為中斷情形與任何直接聯繫加註時間戳記。

平台的倒數計時與我的法定期限一致嗎？

並不完全一致。在目前版本中，72 小時計時器顯示的到期時間，是你遞交 24 小時報告後的 48 小時，而不是你獲悉後的 72 小時，因此一筆通報可能在法定期限尚未屆至前就顯示為逾期。ENISA 表示該邏輯將在後續版本中變更，並表示這些計時器並不取代第 14 條的義務。請自行計時，並自獲悉時起算。

平台會記錄我何時獲悉嗎？

上線時不會。2026 年 9 月 10 日的 SRP 詞彙表 1.3 版指出，主動被利用漏洞的獲悉欄位要到後續版本才會出現；至於嚴重事件，目前的欄位記錄的是偵測的時點。偵測通常早於獲悉，而執委會 2026 年 7 月的指引將獲悉繫於初步評估達到合理確定性。請自行記錄該評估何時作成結論。

我可以就嚴重事件援引 PEC 嗎？

不可以。ENISA 2026 年 9 月 9 日的指引指出，特別例外情形僅適用於主動被利用漏洞的 72 小時通報。嚴重事件通報並無 PEC 控制項。另請注意，援引 PEC 是一項請求：由協調 CSIRT 決定是否接受，並以你提供的選填說明作為判斷依據。

每個欄位可以多長？

詞彙表公布了上限：敘述性欄位 4000 字元，已採取的措施與安全更新細節 2000 字元，PEC 理由 800 字元，標題、產品、元件、攻擊向量與根本原因 255 字元，惡意行為者則僅 100 字元。請依這些大小建立你的內部範本。

我應該立刻在平台上註冊嗎？

ENISA 表示不必，並建議只在你確實需要遞交時才註冊，而不要預先註冊。你現在應該做的，是建立平台所使用的 EU Login 帳號，並啟用多因素驗證，分別供主要通報人與備援人員使用。協調 CSIRT 會在你首次存取之後、而非之前驗證你的帳號；ENISA 並確認此項驗證並非履行通報義務的前提，也不會阻擋遞交。

在我的 CSIRT 完成驗證之前，遞交次數有上限嗎？

有，而且數字改變了。ENISA 2026 年 8 月 14 日的介面指引訂為 10 則通報；2026 年 9 月 4 日重寫的常見問答與重新標註為 2026 年 9 月 9 日的介面指引均表示，未經驗證的代表就同一家製造商最多可遞交 20 則通報，此後驗證即成為強制要求。驗證並非你首次遞交的門檻，但也不能無限期拖延。

我的備援通報人能看到我開始撰寫的草稿嗎？

不能。儀表板只顯示登入中的代表所建立的草稿，因此一份寫到一半的早期預警對你的備援是看不見的。請在平台之外、於事件處理團隊共用的文件中草擬，再用平台謄寫。

我可以透過 API 遞交報告嗎？

不行。ENISA 表示現階段不會提供應用程式介面。你可以將內部的偵測與草擬自動化，但遞交仍是由人在瀏覽器表單上完成。

24 小時的早期預警實際上必須包含什麼？

比多數人想像的要少。必填欄位為通報類型與層級、製造商或管理者名稱、產品、標題，以及就事件而言是否懷疑涉及非法或惡意行為。實質分析要到 72 小時才需提出，而不是第一天。

目前是否已有標準通報格式或範本？

資料欄位已經公布。ENISA 的常見問答載明 24 小時、72 小時與最終報告各階段的必填項目，因此你今天就能建立相對應的內部範本。執委會仍可能透過實施法案進一步規定格式與程序。

如果揭露有風險，我可以延後通報嗎？

遞交不行。24 小時、72 小時與最終報告的時間窗均自獲悉時起算，沒有任何機制會使其暫停。你可以標示敏感性：依第 16(2) 條，你可以勾選狹義條件，在 CSIRT 釋出完整通報之前限制 ENISA 所能看到的內容。是否延後後續轉發的決定權，依 2025 年 12 月 11 日通過的授權法規 (EU) 2026/881，屬於接收的 CSIRT。

2026 年 9 月之前我已知悉的利用行為，需要通報嗎？

不需要。該義務自你獲悉時起適用，並不及於你在 2026 年 9 月 11 日之前即已知悉遭主動利用的漏洞。

通報義務是否適用於我多年前投放市場的產品？

適用。第 69(2) 條規定，2027 年 12 月 11 日之前投放市場的產品，僅在自該日起經重大修改時才受本規則規範；但第 69(3) 條就第 14 條明示減損：通報義務適用於所有於 2027 年 12 月 11 日之前投放市場、且屬適用範圍內的產品，無論是否經過修改。因此一項產品可能不受 CRA 產品要求規範，卻仍屬通報範圍。 Art. 69(2)–(3)

這些規定是否適用於開源專案？

依第 24(3) 條，開源軟體管理者在其涉及含數位元素的產品之範圍內，負有通報義務。執委會 2026 年 7 月 27 日的指引對開源有更詳細的說明。

如果我是小公司，可以到哪裡取得協助？

ENISA 設有服務台並特別關注中小企業，而獲指定為協調者的 CSIRT 亦須就第 14 條義務提供服務台支援。ENISA 公布了一個服務台地址 cra-srp-helpdesk [at] enisa.europa.eu, for questions not answered by the FAQ or the guidance pages. The AR User Manual was published at launch, and the tutorial video followed within days.

繼續閱讀

相關參考

§CRA 解析

以簡明語言說明適用範圍、類別、義務及完整時程。

→§SBOM 與漏洞分析器

將您的元件與 NVD 及 EUVD 進行比對，以在 24 小時內完成通報。

→§執委會指引

執委會依第 26 條發布的指引如何解讀通報與漏洞處理義務。

→§目前的進展現況

平台、標準與授權法案目前實際進展到哪裡。

→§法規全文

法規 (EU) 2024/2847 具拘束力條文中的第 14 至 17 條。

→§常見問答

針對常見利害關係人問題的簡要解答，附參考來源。

→