九月十一日，漏洞時鐘開始走：歐盟 CRA 的 24／72 小時如何改寫台灣硬體出口

CRA 第十四條把通報拆成至少三個節點。第一個節點是早期預警：製造商在知悉遭主動利用漏洞或嚴重事故後，無不當延遲且最遲二十四小時，透過單一通報平台送件。第二個節點是七十二小時通知：企業補上更完整的一般資訊、初步評估與可用的緩解措施。第三個節點是最終報告：漏洞以修正措施可用日為起點，最遲十四日；嚴重事故則以七十二小時通知為基準，最遲一個月。^[1][2]

這三只時鐘的制度意義不同。二十四小時是讓主管機關知道「可能有一個跨市場事件正在發生」；七十二小時是讓協調單位能初步判斷範圍與風險；最終報告才要求更完整的原因、影響、修正或緩解。把三者混成一張完美報告，最常見的後果不是品質更好，而是企業為了等鑑識結論，先錯過第一個法定節點。

ENISA 的八月三日 FAQ 更直白地說，通報程序從製造商「知悉」事件時開始。平台欄位也刻意分層：二十四小時階段需要通報類型、製造商、產品與標題等最低資訊；七十二小時階段才要求漏洞或事故的一般性描述、初步評估與措施；最終階段再補完整內容。^[4][5] 這種設計承認資安事件最初必然不完整，但不接受企業因為資訊不完整而完全沉默。

對台灣企業而言，第一個治理問題不是「工程師多久能修完」，而是「哪一刻算組織已經知道」。客服收到可信的在野利用證據、SOC 看到惡意流量、開源元件維護者公告攻擊、品牌客戶轉來研究人員的重現資料，可能落在不同法人與系統。法規沒有替每家跨國集團畫出內部歸責圖。企業若沒有預先定義事件接收、可信度升級與法務通知路徑，就會在真正的二十四小時內爭論誰先知道。

因此，最保守也最可操作的做法，是把第一個可信訊號記為內部 T0：保存原始訊息、時區、接收人、產品與初步理由；技術團隊可以繼續驗證，但不能覆寫原始時間。T0 不自動等於 CRA 法律上的知悉，也不自動等於必須通報；它只是讓後續判斷有可稽核的起點。是否已達法定門檻，仍由法律製造商依事實與法律意見判斷。

企業最容易出現兩種相反錯誤。一種是看到任何 CVE 就啟動二十四小時法定通報，造成大量噪音；另一種是覺得漏洞還在第三方元件、自己尚未確認客戶被打，就一概不處理。CRA 的門檻位於兩者之間。

「遭主動利用的漏洞」不是單純存在弱點，也不是風險評分很高，而是有可靠證據顯示惡意行為者已在未經許可下利用它。^[1] 因此，弱點掃描命中、研究人員提出概念驗證、供應商發布修補，與已觀察到惡意利用，是不同證據狀態。工程處置可能都要開始，但 CRA 強制通報判斷不能只靠嚴重度分數取代「主動利用」證據。

嚴重事故則是另一條路徑。法規關心事故是否已經或可能嚴重影響產品保護資料與功能的能力，以及是否已導致或可能導致惡意程式進入產品或使用者系統。^[1][4] 也就是說，沒有一個對外公布的 CVE，不代表事故不可能達到門檻；反過來，一個高分 CVE 也不必然等於已發生嚴重事故。

台灣供應商最好把內部事件表分成兩欄。第一欄記技術狀態：弱點存在、可重現、是否已被利用、影響產品與版本、目前緩解。第二欄記法律狀態：疑似哪一種 CRA 事件、證據是否達門檻、由誰判定、何時重評。兩欄共用同一事件編號，但不能彼此取代。這樣既不會因法律意見尚未完成而停止封鎖惡意流量，也不會因工程團隊緊急修補就誤稱已完成法定通報。

CRA 把義務放在「製造商」身上，但產業口語中的製造商，常指實際生產或組裝者。兩者不是同一概念。歐盟制度下，產品以誰的名稱或商標上市、誰控制設計與合規，才是判定核心。進口商或經銷商若以自己的名稱或商標提供產品，或對產品作實質修改，也可能承擔製造商義務。^[1][10]

因此，同一台網路設備可能有三種情境。第一，台灣自有品牌直接輸歐，台灣公司可能就是非歐盟製造商，並透過授權代表、進口商等安排履行歐盟義務。第二，台灣 ODM 按歐洲品牌規格生產、由對方商標上市，歐洲品牌較可能是法律製造商，台灣廠是關鍵資訊供應者。第三，歐盟進口商換牌或實質修改產品，其法律角色可能升級。每個情境的通報責任、協調 CSIRT 與資料交付路徑都不同，不能用一份通用流程涵蓋。

CRA 第十四條也規定協調 CSIRT 的認定。原則上看製造商的主要設立地，也就是產品資安決策主要作成之處；若製造商沒有在歐盟設立，則依授權代表、進口商、經銷商，乃至產品使用者所在會員國的順序處理。^[1][4] 這不是一個只填公司註冊地址的行政欄位，而是牽涉誰控制產品資安決策與哪個歐盟節點承接義務。

台灣企業現在最值得做的，不是問「我們是不是製造商」一次，而是逐產品線畫法律角色表：上市名稱、商標所有人、設計變更權、軟體更新控制者、歐盟授權代表、進口商、主要市場與通報決策人。若答案散落在業務、法務與專案經理的信箱，真正事件發生時就不可能在幾小時內完成角色判斷。

CRA 沒有明文要求台灣 ODM 必須在四小時內回報品牌客戶。然而，品牌商若要在法定二十四小時內完成事件分級、內部核准、翻譯與 SRP 送件，不可能把整整二十四小時都留給上游。因此，品牌採購合約把供應商通知期縮到四、八或十二小時，是高度可預期的商業推論，不是已確認的法規事實。

這種「時鐘壓縮」會重新分配成本。過去售後資安常以工作日、補丁週期與客訴優先級運作；現在需要全年候命聯絡人、跨時區升級路徑、日誌保存、產品版次查詢、第三方元件聯絡與法律保密機制。大型 ODM 尚可建立二十四小時 PSIRT，小型模組商、韌體外包商與開源元件供應者卻可能沒有同等資源。品牌若只在合約寫一個極短時限，卻不共同定義資料格式、嚴重度、測試環境與費用，供應鏈可能交付更多不完整警報，而不是更快的可靠證據。

合理的合約附件應至少回答：什麼事件必須立即通知？誰可以代表雙方接收？遇到假日與人員離職如何備援？第一包資料最低包含什麼？敏感利用資訊用哪種加密管道傳送？若第三方元件造成多品牌同時受影響，由誰協調？修補、外部鑑識與緊急測試成本如何分攤？未回答這些問題，單獨把時限縮短只會製造責任轉嫁。

一台數位產品通常不是單一公司的程式。晶片 SDK、開源函式庫、無線模組、雲端代理、行動應用與更新服務可能由不同團隊維護。當某個共用元件遭主動利用，品牌商必須知道哪些產品、韌體與歐盟市場真的受到影響；台灣整合商則需要從元件版本反查客戶型號。

如果企業只有採購料號，沒有軟體物料清單與實際出貨版次，就會出現三種延遲：先花時間確認有沒有使用該元件，再花時間辨認哪些版本已更新，最後才找得到品牌窗口。這些工作以前可以在補丁週期內慢慢整理，如今會吃掉法定時鐘。

可用的產品—元件帳不必一開始追求完美。最低限度包括產品商業名稱、內部料號、韌體版本、關鍵第三方元件與版本、維護責任人、支援終止日、歐盟銷售會員國與法律製造商。當外部通報只有元件名稱與攻擊跡象時，團隊能在數小時內反查可能受影響範圍，再逐步縮小，而不是從零詢問每個專案。

ENISA FAQ 表示，第三方元件中的遭利用漏洞是否要求每個整合產品製造商通報，仍要回到執委會實施 FAQ 的具體判斷。^[4][9] 這提醒企業不要把上游已通報當成自己的免責證明，也不要在沒有產品影響分析時機械式重複送件。共同元件需要共享技術事實，但每個法律製造商仍須判斷自己的產品與市場義務。

企業擔心把未修補漏洞送進跨國平台後擴散，並非毫無根據。CRA 的設計是由單一平台同時送到協調 CSIRT 與 ENISA，再由協調 CSIRT 向產品所在會員國的相關 CSIRT 及必要的市場監管機關分送。^[1][2][4] 分送範圍可能不小，資料品質與敏感度標記必須慎重。

另一方面，這不是公開漏洞資料庫的自動貼文。法規要求主管機關保護機密、商業秘密與安全敏感資訊；在立即分送會造成更大資安風險的特殊情況，制度也設有延遲或限制分送的條件。^[1][4] ENISA 在修補後可能把漏洞資訊帶入歐洲漏洞資料庫，與二十四小時預警的受控處理仍是不同階段。

正確做法不是把所有技術細節塞進第一封，也不是因怕外洩而不留痕跡。二十四小時資料包只放辨識事件與產品所需的最低資料，清楚標示尚未確認之處、敏感性與立即緩解；利用鏈、金鑰、客戶識別等細節依平台欄位與法律判斷分級提交。企業內部也應限制原始證據存取，保留誰看過、誰下載與誰批准傳送的紀錄。

台灣企業可以用四本帳把制度落地。

第一本是「法律角色帳」。它回答每一產品由誰以何種商標在歐盟上市、誰可能是 CRA 製造商、協調 CSIRT 的連結點與誰有送件權。第二本是「產品元件帳」，把產品、韌體、元件、版本、支援期與銷售會員國串在一起。第三本是「事件時鐘帳」，保留原始 T0、每次升級、決策與對外傳送的時間戳。第四本是「通報決策帳」，明列證據支持遭主動利用或嚴重事故的理由、仍未知的事實、法律判斷者與下一次重評時間。

四本帳必須共用同一事件編號。否則 SOC 的告警、工程 Jira、品牌客戶郵件與法務意見會變成四個互不相識的案件。事件狀態也不要只有「是／否通報」兩格，可以使用「觀察中、技術確認中、疑似達門檻、決定通報、決定不報但待重評、已送二十四小時、已補七十二小時、最終報告完成」。每個狀態都有責任人與下一期限。

一個最低可用的二十四小時包，應能回答：誰在何時收到什麼可靠訊號；可能涉及哪個產品與版本；為何懷疑遭主動利用或構成嚴重事故；產品在哪些歐盟市場提供；目前採取何種封鎖、關閉功能或客戶緩解；哪些內容仍未知；下一個更新時間。這些資料不是最終真相，但足以讓法律製造商保住第一個節點。

七十二小時包再補上較穩定的一般性漏洞或事故描述、攻擊或利用方式、初步影響、受影響版本、已採取與使用者可採取的措施。最終報告才完整交代嚴重度、影響、根因與修正。每次更新都保留版本差異，不能用新結論覆蓋早期判斷，否則事後無法解釋當時為何作出特定決定。^[4][5]

第一個情境是研究人員通知台灣 ODM：某韌體元件有可用攻擊，但尚未看到在野利用。此時工程處置與品牌通知可以啟動，卻不能只因有概念驗證就斷言 CRA 強制通報已觸發。紀錄證據、確認產品、監測利用訊號，並把法律狀態設為待重評。

第二個情境是品牌客戶轉來可信的惡意利用紀錄，涉及已在德國與法國販售的型號。這時內部 T0、產品—元件反查、證據保存與法律升級應同時啟動。即使根因未明，法律製造商也要評估二十四小時預警；ODM 不應等到補丁完成才回覆。

第三個情境是雲端服務事故讓多款設備失去驗證能力，但未確認有漏洞利用。團隊不能因「沒有 CVE」就排除 CRA；必須另依嚴重事故判準檢視可用性、真實性、完整性、機密性與惡意程式風險。這正是兩條通報路徑必須分開的原因。

演練時不要預先告訴參與者完整答案。讓客服先收到模糊訊息、工程稍後取得日誌、品牌法務位於不同時區，再觀察四件事：多久建立同一事件編號、多久找到法律製造商、多久產出最低資料包、誰有權決定送件。演練失敗通常不是工程師不夠快，而是名單、權限與資料關係不存在。

距離適用日愈近，愈不該把時間花在一份過度宏大的合規簡報。第一週先盤點輸歐產品與法律角色，確認品牌、授權代表、進口商及緊急窗口。第二週建立最低產品—元件表與 T0 表單，選一個最常見產品線做桌上演練。第三週把供應商合約、保密傳輸與假日值班補起來，並準備 EU Login 等基本帳戶條件。

ENISA 截至八月三日表示，SRP 專用公開網址會在上線前公布，現階段沒有提供 API；代表名義的驗證由協調 CSIRT 處理，且初次驗證不應妨礙提交。^[4][6][7] 因此，企業可以先準備帳戶、代表證明與欄位資料，但不能假裝平台整合已完成。自動化需求高的品牌，也要先保留人工送件與雙人覆核方案。

多數 CRA 主要產品義務到二〇二七年十二月十一日才全面適用，並不表示二〇二六年的通報只是預演。^[1][2] 第十四條已是獨立的法定義務；違反第十三、十四條等核心規定，一般最高行政罰可達一千五百萬歐元或全球前一年度營業額百分之二點五，以較高者為準。^[1] 但法規另定，微型與小型企業未在二十四小時內送出第十四條的早期預警，不適用這項行政罰；這不等於免除其通報義務或其他違規責任。^[1] 企業當然不應只為罰款治理，但罰則說明歐盟把通報能力視為產品市場責任，而非可有可無的客服服務。

截至二〇二六年八月二十四日，至少還有三項不宜寫死。第一，SRP 正式入口與完整協調 CSIRT 名單仍待公布；ENISA 文件本身會更新。^[3][4] 第二，跨國集團內哪一個節點的資訊足以構成製造商「知悉」，要看組織設計與具體事實，本文不能替個案下法律結論。第三，品牌商將把多少時間、費用與責任轉嫁給供應商，取決於合約談判，而不是 CRA 自動規定。

因此，真正成熟的準備不是假裝所有未知都已解答，而是讓未知有主人、有下一個查核時間、有暫行處置。事件可以標為「產品範圍未知」，但要指定誰在兩小時內查產品帳；可以標為「是否主動利用未知」，但要指定誰向研究人員與威脅情報來源取證；可以標為「法律製造商待確認」，但要先通知所有可能責任人，不能讓時鐘在組織縫隙中消失。

CRA 的二十四小時，不是單純把資安團隊催得更快。它把過去分散在售後、法務、品牌與代工體系的知識，壓縮到同一條可稽核時間線。對台灣供應鏈而言，最有價值的能力也不只是更快修補，而是能在資訊不完整、責任跨法人、漏洞仍敏感的時候，準確說出三件事：目前知道什麼、為什麼這樣判斷、下一個期限由誰負責。

九月十一日真正開始走的，是組織時鐘。產品清冊、角色表、保密管道與決策紀錄若今天不存在，事件發生後再買一套平台，也補不回已經流失的二十四小時。