歐盟 CRA 網路韌性法案是什麼？2026 漏洞通報義務、SBOM 與合規時程全解析
歐盟 CRA 網路韌性法案是什麼？漏洞通報義務、SBOM 與合規時程解析
你的產品有連網功能、有韌體、有軟體，而且賣進歐盟？那麼 2026 年 9 月 11 日這個日期，建議現在就寫進公司行事曆。依 TWCERT/CC 2026 年的公告，歐盟《網路韌性法案》（Cyber Resilience Act，簡稱 CRA）第 14 條的漏洞通報義務，將在那一天正式強制執行。
時限有多緊？製造商發現產品的漏洞被活躍利用後，24 小時內就要發出早期預警。違反的代價也很具體：最高 1,500 萬歐元罰款，或全球年營收的 2.5%，產品還可能直接被要求下架（TWCERT/CC, 2026）。
更麻煩的是，多數人還沒準備好。Linux Foundation Research 與 OpenSSF 在 2026 年 6 月發布的調查顯示，843 名受訪的軟體產業與開源相關人員中，有 66% 表示不熟悉 CRA（iThome, 2026）。這篇文章把 CRA 是什麼、第 14 條通報時程、SBOM 要求、罰則風險、台灣輸歐企業的受影響情境，以及一份可以直接動手的準備檢查清單，一次整理給你。
CRA 是什麼？歐盟網路韌性法案的適用範圍與核心要求
CRA（Cyber Resilience Act，網路韌性法案）是歐盟針對數位產品的資安法規，適用於所有進入歐盟市場、具備數位功能的產品及其製造商（TWCERT/CC, 2026）。它的核心邏輯很簡單：產品要在歐盟賣，資安就是製造商的法定責任，從設計、上市到漏洞處理都要管。
聽起來像是「又一部歐盟法規」？跟針對組織與個資的規範不同，CRA 盯的是產品本身。一台連網攝影機、一套韌體、一支 App、一個嵌在硬體裡的軟體模組，只要具備數位功能、進了歐盟市場，就在它的射程內。
適用範圍：看產品流向，不看公司國籍
這是台灣業者最容易誤判的一點。CRA 的適用認定標準是「產品是否進入歐盟市場」，而不是公司在哪裡註冊。你的公司設在新竹、台北還是台南，都不影響答案；只要產品輸歐，製造商的義務就跟著上身。
什麼算「具備數位功能的產品」？範圍比直覺寬。除了看得到的聯網裝置與軟體，產品裡的韌體、隨附的雲端連線功能、對外的程式介接，都可能構成數位元素。如果你對程式介接的概念還不熟，可以先讀我們的 API 是什麼入門解析，再回頭盤點自家產品。
CRA 的三層核心要求
把法案拆開看，製造商的義務大致落在三層：
- 設計階段：產品出廠前就要符合基本資安要求，不能先賣再補。
- 上市之後：持續處理漏洞、提供安全更新，責任不隨出貨結束。
- 事件當下：漏洞被活躍利用時，依第 14 條的時限通報主管機關。
其中第三層的通報義務，就是 2026 年 9 月 11 日要強制執行的部分，也是目前時間壓力最大的一塊。
CRA 第 14 條漏洞通報義務：24 小時、72 小時、14 天三階段時程
依 TWCERT/CC 2026 年公告，CRA 第 14 條漏洞通報義務於 2026 年 9 月 11 日正式強制執行：製造商發現「活躍漏洞利用」後，24 小時內須發布早期預警、72 小時內補齊詳細漏洞災損評估、可用矯正措施後 14 天內提交最終報告。三個時限環環相扣，錯過第一個，後面全部跟著垮。
具體要交什麼、什麼時候交？直接看表：
| 階段 | 時限 | 要提交的內容 |
|---|---|---|
| 早期預警 | 發現活躍漏洞利用後 24 小時內 | 早期預警通知 |
| 詳細通報 | 72 小時內 | 詳細漏洞災損評估 |
| 最終報告 | 可用矯正措施後 14 天內（重大資安事件放寬至一個月） | 最終報告 |
（資料來源：TWCERT/CC, 2026）
24 小時從「發現」起算，考驗的是偵測與上報鏈
注意起算點：是製造商「發現」活躍漏洞利用的那一刻，不是漏洞誕生的時間。這代表什麼？真正被考驗的不是填表速度，而是你的偵測能力與內部上報鏈。工程師半夜收到異常告警，多久會變成資安窗口手上的通報草稿？如果這條鏈路平常沒演練過，24 小時其實非常短。
我們協助客戶梳理雲端資產的經驗裡，最常見的狀況是：技術團隊知道系統出事，但「該由誰、用什麼格式、向哪個機關通報」沒有人答得出來。流程斷在組織層，而不是技術層。
通報去哪裡？SRP 平台、CSIRT 與 ENISA
通報管道也已經定案：透過歐盟單一通報平台（SRP）提交，通報對象是當地的 CSIRT（電腦安全事件應變小組）以及歐盟網路安全局 ENISA（TWCERT/CC, 2026）。對台灣製造商來說，這意味著通報流程要預先寫進應變手冊——事發當下才開始查「SRP 怎麼用」，時限根本不夠燒。
SBOM 軟體物料清單：CRA 合規的隱性先決條件
TWCERT/CC 在 2026 年的公告中，把 SBOM（Software Bill of Materials，軟體物料清單）定位為 CRA 合規「實務上的隱性先決條件」，並建議採用 CycloneDX 或 SPDX 國際標準格式（TWCERT/CC, 2026）。法條沒有大寫粗體地要求它，但少了它，第 14 條的時限幾乎不可能達成。
為什麼這麼說？回頭看 72 小時那一關。詳細的漏洞災損評估，前提是你知道受影響的元件用在哪些產品、哪些版本。沒有 SBOM 的團隊，事發當下得人工翻程式碼、問供應商、猜相依關係——72 小時連盤點都做不完，談什麼評估？
SBOM 是什麼？先把「料」列出來
把它想成食品包裝上的成分表。一份 SBOM 列出產品裡用到的所有軟體元件：開源套件、第三方函式庫、版本號、相依關係。漏洞公告一出來，你查表就知道自己中不中招，而不是全公司動員大海撈針。
格式選哪個？CycloneDX 與 SPDX 都是 TWCERT/CC 點名的國際標準，與供應鏈上下游交換時相容性最好。實務上的建議是：選定一種、工具鏈自動產出、跟著每次發版更新，而不是一次性手工編完就放著長灰塵。
從 API 與雲端相依開始盤
很多團隊的盲區不在自己寫的程式碼，而在外部服務。你的產品呼叫了哪些雲端服務、串了哪些 AI 模型介接、金鑰存放在哪？在我們替客戶整理 AI API 資產的實務中，光是「列出公司目前用了哪些外部 API、各自誰在管」這一步，常常就要花掉好幾天——帳號分散、帳單分散、文件缺漏，平常沒人覺得是問題，要交清單時全部現形。如果你的團隊同時用多家服務，可以參考 AI API 管理平台的統一管理作法，先把資產收攏到看得見的地方。
不確定自家的軟體元件與 API 相依該怎麼盤？
SBOM 的第一步是把雲端與 AI API 資產攤開來看清楚。CloudInsight 技術團隊長期協助台灣企業梳理多平台雲端與 AI API 採購，可以從資產盤點切入，協助你建立資安合規評估的起點。
CRA 罰則與商業風險：最高 1,500 萬歐元或全球年營收 2.5%
違反 CRA 的罰則上限是 1,500 萬歐元，或全球年營收的 2.5%，兩者取其高；此外產品還可能面臨下架、召回或限制銷售（TWCERT/CC, 2026）。注意「全球年營收」這四個字——計算基礎不是你在歐盟的營收，而是整家公司的全球收入。
罰款數字夠嚇人了，但對多數台灣企業來說，真正致命的可能是後面那半句。
想一想：你的產品被限制在歐盟銷售，會發生什麼事？通路商重新評估合作、品牌客戶啟動替代供應商、後續訂單凍結。罰款是一次性的，市場准入的損失是連鎖性的。對毛利本來就薄的硬體與代工業者，被踢出歐盟市場的代價，遠超過帳面上的罰金。
還有一層比較少被討論的風險：採購端的連帶要求。歐盟客戶為了自身合規，會把資安與文件要求往供應鏈上游推。也就是說，就算你的產品不直接掛你的牌子進歐盟，只要你在那條供應鏈上，CRA 的壓力一樣會透過合約條款找上門。
誰會受 CRA 影響？台灣軟體與聯網產品輸歐情境分析
影響面比多數人以為的大，而且認知缺口驚人。Linux Foundation Research 與 OpenSSF 於 2026 年 6 月發布的報告指出，這份 2026 年初執行的調查訪問了 843 名歐洲、北美與亞太的軟體產業及開源相關人員，其中 66% 表示不熟悉 CRA（iThome, 2026）。連產業內的人都三分之二不熟，一般輸歐企業的準備度可想而知。
台灣業者具體會怎麼被掃到？我們依產品流向拆成三類情境來分析。
情境一：自有品牌的聯網硬體輸歐
最直接的一類。聯網攝影機、智慧家電、網通設備、工控裝置——只要掛自己的品牌進歐盟市場，製造商義務完整落在你頭上：設計階段的資安要求、上市後的更新責任、第 14 條的通報時限，一項都跑不掉。這類業者的功課最重，也最該搶在 2026 年 9 月前把通報流程演練起來。
情境二：ODM、零組件與模組供應商
你不直接出貨歐盟，但你的模組裝在客戶的產品裡進了歐盟？那麼壓力會以「客戶要求」的形式到貨：要 SBOM、要漏洞通報配合條款、要資安文件。我們的觀察是，這類供應鏈合約條款的更新，往往比法規生效日來得更早——品牌客戶不會等到 9 月 11 日才開始要文件。
情境三：軟體與 SaaS 隨產品進入歐盟市場
軟體業者容易低估自己的曝險。CRA 適用的是「具備數位功能的產品」，軟體本身就是典型標的；嵌在硬體裡的軟體模組、隨裝置出貨的 App，同樣算數。如果你的軟體會以任何形式進入歐盟市場，現在就該確認自己在供應鏈上的角色與義務，而不是假設「我們是軟體公司所以沒事」。
對照組織自身的採購面也一樣：當你向外採購雲端與 AI 服務時，對方能不能配合你的合規文件需求，會直接影響你能不能對你的客戶交代。企業端的選商邏輯可以參考 AI API 企業採購指南。
採購雲端與 AI 服務，也是合規文件的一環
供應商能不能交出正規合約、統一發票與在地技術支援，直接影響你的供應鏈文件完整度。CloudInsight 代理 AWS、GCP、Azure 等雲端服務與主流 AI API，以台灣企業合約與中文支援，協助你把採購端整理成可稽核的狀態。
CRA 合規準備檢查清單：企業現在就能做的 7 件事
距離 2026 年 9 月 11 日的強制執行日，時間是用月在算的（TWCERT/CC, 2026）。好消息是，下列七件事不需要等顧問報告出爐就能動手，而且每一件都直接對應第 14 條的某個環節。
- 盤點產品線的歐盟曝險：列出哪些產品（含軟體、韌體、模組）以任何形式進入歐盟市場。先回答「我到底適不適用」，後面的投資才有方向。
- 建立並維護 SBOM：選定 CycloneDX 或 SPDX 格式，用工具鏈自動產出，隨每次發版更新。手工維護的清單三個月就會過期。
- 建立漏洞情報監控：訂閱你所用元件的漏洞公告來源，確保「發現」這個起算點不會比攻擊者晚太多。
- 演練 24／72 小時通報流程：指定通報負責人、寫好通報模板、確認 SRP 平台的提交方式，然後實際跑一次桌面演練。沒演練過的流程，事發當天一定走樣。
- 檢視供應鏈合約條款：上游供應商能不能配合提供 SBOM 與漏洞資訊？下游客戶會要求你什麼？合約先行，文件才跟得上。
- 收緊存取與金鑰管理：漏洞應變的前提是知道誰能動什麼。API 金鑰與帳號權限的治理可以參考 API Key 管理與安全最佳實踐。
- 把資安納入採購評估：新的系統整合與外部服務導入，從選商階段就把合規文件能力列為條件。整合面的實務細節見 API 整合實務指南。
說實話，這份清單裡沒有任何一項是「等法規再明朗一點」才能做的。每一項都是基本功，差別只在於：現在做是從容布局，9 月之後做是事故應變。
根據我們的經驗，企業在這份清單上最容易卡關的不是技術項目，而是第 4 項的「指定負責人」——技術、法務、業務都覺得通報是別人的事，結果時限一到，三個部門面面相覷。先把人定下來，其他事情才會開始轉動。
常見問題 FAQ
關於 CRA 網路韌性法案，台灣企業最常問的五個問題整理如下。核心事實只有一組：2026 年 9 月 11 日起，24 小時早期預警、72 小時災損評估、14 天最終報告（TWCERT/CC, 2026）。
Q: CRA 的漏洞通報義務什麼時候開始強制執行？
A: 依 TWCERT/CC 2026 年公告，CRA 第 14 條漏洞通報義務於 2026 年 9 月 11 日正式強制執行。從那天起，製造商發現產品有被活躍利用的漏洞，就必須在 24 小時內透過歐盟單一通報平台（SRP）發布早期預警。
Q: CRA 的 24 小時通報是從什麼時候起算？
A: 從製造商「發現活躍漏洞利用」的時間點起算：24 小時內發布早期預警，72 小時內補齊詳細漏洞災損評估，可用矯正措施後 14 天內提交最終報告；重大資安事件的最終報告可放寬至一個月（TWCERT/CC, 2026）。
Q: 台灣公司沒有在歐盟設點，也要遵守 CRA 嗎？
A: 只要產品進入歐盟市場就要。CRA 適用於所有進入歐盟市場、具備數位功能的產品及其製造商，認定標準是產品流向而不是公司註冊地（TWCERT/CC, 2026）。台灣的聯網硬體、韌體與軟體業者只要有輸歐，都在適用範圍內。
Q: SBOM 一定要做嗎？要用什麼格式？
A: TWCERT/CC 在 2026 年公告中把 SBOM 描述為 CRA 合規「實務上的隱性先決條件」：沒有元件清單，72 小時內的災損評估幾乎做不出來。格式建議採用 CycloneDX 或 SPDX 國際標準，與供應鏈上下游交換文件時相容性最好。
Q: 違反 CRA 的罰款最高是多少？
A: 最高可罰 1,500 萬歐元，或全球年營收的 2.5%，兩者取其高（TWCERT/CC, 2026）。罰款之外，產品還可能被要求下架、召回或限制銷售；對依賴歐盟通路的企業來說，市場准入的損失往往比罰款本身更嚴重。
結論：把 2026 年 9 月 11 日當成合規倒數的起點
CRA 第 14 條的強制執行日已經釘死在 2026 年 9 月 11 日，時限規格也完全公開：24 小時、72 小時、14 天（TWCERT/CC, 2026）。而 Linux Foundation 與 OpenSSF 的調查告訴我們，66% 的從業者還不熟悉這部法案（iThome, 2026）。換句話說，現在開始準備的企業，起跑線就贏過大多數同業。
要從哪裡下手？三步就好。
第一步，盤點：確認哪些產品、軟體與模組會進入歐盟市場，包含你在別人供應鏈裡的角色。第二步，SBOM：選定 CycloneDX 或 SPDX，把軟體元件與外部服務相依攤成一張清單。第三步，演練：指定通報負責人，把 24／72 小時的流程實際跑一遍。
合規從來不是一次性的專案，而是一條從資產盤點開始的長期工程。但起點很明確——先看清楚自己手上有什麼。
🎯 立即行動
把雲端與 AI API 採購整理成一條可稽核的供應鏈，是 CRA 準備中最快能動手的一步。CloudInsight 提供企業級雲端與 AI API 採購代理：正規合約、統一發票、中文技術支援，協助你把採購端的合規文件一次補齊。
👉 立即諮詢，取得最適合您的方案 👉 加入 LINE 官方帳號，即時獲得技術支援
延伸閱讀
- API Key 管理與安全｜2026 年 AI API Key 最佳實踐完整指南
- AI API 企業採購指南｜2026 年代理商選擇、折扣方案與合規流程全攻略
- AI API 怎麼開發票？2026 年台灣企業合規採購 AI API 完整流程
- AI API 台灣怎麼買？2026 年購買付款完整教學（OpenAI、Claude、Gemini）
- Open API 是什麼？2026 年開放 API 與 OpenAPI 規範完整解析
參考資料
相關文章
軟體供應鏈攻擊是什麼？2026 Miasma 蠕蟲事件全解析與企業防護指南
軟體供應鏈攻擊正在升級：2026 年 6 月 Miasma 蠕蟲 72 秒感染 32 個 Red Hat npm 套件、劫持 Claude Code 等 13 種 AI 開發工具設定檔。本文整理完整事件時間線、傳統防禦失效的原因，以及企業立即可用的自查與憑證防護清單。
資訊安全AI 資安完整解析：AI 帶來的資安威脅與防護策略【2026】
AI Agent、LLM 如何改變資安戰場？本文解析 2026 年 AI 資安威脅（AI Agent 攻擊、Prompt Injection、Deepfake 2.0、MCP 安全風險）、AI 防護技術進展，以及企業該如何因應 Agent 時代的資安挑戰。
資訊安全雲端資安完整指南：威脅、防護措施、最佳實踐【2025】
雲端環境的資安威脅有哪些？本文說明雲端資安的常見風險、責任共擔模型、主要雲端平台的安全功能，以及企業雲端資安最佳實踐。