CRA 漏洞通報找 TWCERT？ 該通報哪個歐盟 CSIRT

漏洞遭積極利用時，台灣製造商的第一個直覺，是通報給熟悉的 TWCERT/CC。這個直覺是錯的。CRA 通報不走本國 CERT。收件者是一個歐盟協調 CSIRT，提交入口是 ENISA 單一通報平台。

真正的規則只有一句：通報一次，給一個協調 CSIRT，ENISA 同時收到，再由它轉發給各銷售國。你不必向 27 個國家各通報一次，也不該把通報送到 TWCERT/CC。

但「哪一個歐盟 CSIRT」這個問題，答案會隨你在歐盟的據點與通路而變。在歐盟有據點和沒有據點，走的是完全不同的路徑。判斷順序是先看歐盟據點，再套用 4 層瀑布，最後對照 27 國名單。

唯一的通報規則

向 EU 市場供應的製造商，在知悉漏洞遭積極利用後，向歐盟通報的方式只有一種：透過 ENISA 的單一通報平台 (SRP)，向一個協調 CSIRT 提交，ENISA 在同一時間收到同一份通報。

收件的那個協調 CSIRT，會把通報轉發給你產品有銷售的每一個歐盟國家的 CSIRT。你只動一次手，後續的跨國分發由協調者完成。

時限維持三段式：知悉後 24 小時內提交早期預警、72 小時內提交完整通報、修補措施可用後 14 天內（事件則為 1 個月內）提交最終報告。但「向誰提交」才是台灣業者最常搞錯的一步。

歐盟據點決定路徑

第一個分歧點，是你在歐盟有沒有一個「負責產品資安決策」的據點。

如果你的產品資安決策主要在某個歐盟成員國的據點裡做，那個成員國就是你的主要營業據點。你向該國的協調 CSIRT 通報，後面的四層瀑布完全不啟動。多數純台灣出口商沒有這種據點，所以才需要往下走瀑布。

只有在歐盟沒有主要營業據點時，才依固定順序往下找。順序是嚴格優先的瀑布，由上而下，停在第一個能定出成員國的層級：

1. 授權代表 (AR) 所在國：先看處理你最多產品的授權代表設在哪一國。
2. 最大進口商所在國：沒有授權代表時，看投放你最多產品的進口商在哪一國。
3. 最大經銷商所在國：沒有進口商時，看提供你最多產品的經銷商在哪一國。
4. 使用者最多的國家：以上皆無時，看你的使用者集中在哪一國。

舉一個常見組合。授權代表在德國，最大進口商在荷蘭。你向德國的 BSI（CERT-Bund）通報，不是荷蘭，因為授權代表排在進口商前面，瀑布在第一層就停了。

這裡有一個要先講清楚的限制。「處理最多產品」的計算基準，法規沒有明確界定：是按 SKU 數、出貨數量，還是產品族來算，目前沒有定論。「使用者」的算法同樣未定義。所以你只能用「處理你最多產品的業者」這個概略判準，不要自行發明百分比門檻。多個授權代表並存的情形，也還沒有定論，不要假設只能有一個授權代表。

歐盟 27 國通報對象 CSIRT 對照表

下表列出各國目前最可能擔任 CRA 通報窗口的 CSIRT。狀態欄的意義：已確定（已完成指定）、預期（國家 CSIRT／CVD 協調窗口，轉換立法尚未完成，ENISA 公布官方清單後更新）、未定（分工未定或尚未指定）。

合計：17 國已確定，8 國預期，2 國未定。

最容易報錯對象的陷阱

同一個國家裡常有兩個名字相近的單位，報錯就等於沒報。西班牙、捷克、丹麥與瑞典最容易造成誤送。

• 西班牙：INCIBE-CERT 負責民間與企業，CCN-CERT 負責公部門。CRA 通報窗口採雙軌模式，提交前要確認你的產品歸哪一邊。
• 捷克：GovCERT.CZ（NÚKIB 轄下）是官方窗口，不是民間的 CSIRT.CZ。
• 克羅埃西亞：窗口是 NCSC-HR，不是學術網路下的 CERT.hr／CARNET。
• 羅馬尼亞：窗口是 DNSC，不是舊稱的 CERT-RO。
• 希臘：窗口是 NCSA 轄下的 CSIRT，不是軍方的 Hellenic CSIRT。
• 盧森堡：窗口是 CIRCL，不是 GOVCERT.LU。
• 丹麥：CSIRT 設在國防情報機構 (FE) 之下，與一般民間 CERT 的運作邏輯不同。
• 瑞典：CERT-SE 的主管機關已從 MSB 改名為 MCF，舊文件上的 MSB 指的是同一條線。

本國 CERT 是另一回事

TWCERT/CC（台灣電腦網路危機處理暨協調中心）在 CRA 通報裡沒有任何角色。把漏洞報給 TWCERT/CC，不會被歐盟視為已完成 CRA 通報。

台灣國內規範可能對你另有通報要求，那是平行而額外的義務。國內通報與 CRA 通報互不取代：報了 TWCERT/CC 不代表滿足 CRA，反之亦然。兩條軌道要分開走。台灣製造商的整體通報架構與時限，參閱台灣製造商的 CRA 漏洞通報指南。

授權代表不是通報窗口

「報給授權代表所在國」這句話，常被誤讀成「把報告送給授權代表」。授權代表所在國只決定收件的歐盟協調 CSIRT，不是報告的收件人。

通報只走一個平台：ENISA 的 SRP，不是授權代表的任何平台。授權代表是法律聯絡點與文件保管人，負責保存符合性聲明與技術文件、回應市場監督機關的查詢，不是漏洞通報的中繼站。授權代表所在的國家，只是用來定出哪一個歐盟協調 CSIRT 收件，僅此而已。

通報的內容也常被搞混。你提交的是 24 小時早期預警、72 小時完整通報、以及 14 天或 1 個月的最終報告，不是「送出一份 SBOM」當作通報。SBOM 留在你的技術文件裡，是評估漏洞影響的依據，不是通報本身。

EUVD（歐洲漏洞資料庫）也不是通報管道。EUVD 可用來追蹤漏洞遭利用狀態與緩解資訊，作為監測和優先排序資料源。若已有 EUVD ID，可以在 SRP 表單中作為參考；CRA 通報本身仍是透過 ENISA SRP 提交給一個協調者 CSIRT。

如果問題不是通報窗口，而是 SBOM 命中 CVE 後如何判定產品是否受影響，請看台灣韌體 SBOM 漏洞判定指南。

官方清單尚未公布

ENISA 還沒有公布 CRA 單一通報平台上正式的電子通報窗口清單，並表示將在後續階段提供協調者 CSIRT 資訊。上表列出的 CSIRT，是各國在 NIS2 之下的 CVD 協調窗口，最可能也成為 CRA 的通報窗口，但這是推定，不是官方指定。

提交當下，請以 ENISA SRP 頁面上的正式清單為準。本對照表最後查核時間為 2026 年 6 月，每一列標示 預期 或 未定 的國家，會在官方清單公布後更新。在依賴任何一列之前，先確認該國的轉換立法與窗口指定是否已經定案。

提交前的盤點清單

通報窗口要在事件發生前就定好，不能等到 24 小時時鐘開始倒數才查。三件事先做：

1. 先盤點授權代表、進口商、經銷商在歐盟的分布。 這直接決定你會落到哪一國的協調 CSIRT。等漏洞遭利用時才查通路，時間會在內部釐清裡流失。
2. SRP 開放時先完成組織註冊。 通報是手動提交的，沒有現成 API。註冊與帳號開通要時間，最後一刻才註冊會撞上 24 小時期限。
3. 備妥早期預警的必填欄位。 受影響的成員國清單、是否疑似遭惡意利用等資訊，事先做成範本，事件當下只需填值，不用從零寫起。

CRA Evidence 的顧問服務

決定通報對象，要先把授權代表、進口商、經銷商在歐盟的分布盤清楚，再對照各國協調 CSIRT 的指定狀態。CRA Evidence 的顧問服務涵蓋通路盤點與協調者 CSIRT 順序判定、SBOM 生成輔導、ENISA 通報流程設計，以及第三方認證導入，協助台灣製造商在 2026 年 9 月 11 日前把通報路徑定好。

可預約免費評估，由顧問協助你定出產品線該對應哪一個歐盟通報窗口。也可先用 CRA 適用性確認工具做初步判定。

本文內容僅供參考，不構成法律建議。有關 EU 產品法規的具體合規要求，請諮詢熟悉 EU 法規的法律專業人士。