台灣 AI 伺服器硬體 CRA 實務指南：BMC/NIC/DPU 韌體證據

台灣 AI 伺服器與資料中心硬體廠商面對的 CRA 問題，和一般 ODM 合約問題不同，也和路由器、NAS、防火牆的產品分類不同。

如果你是替 Dell、HPE、EU 品牌或雲端客戶代工白牌伺服器，先看這篇：台灣 ODM 代工廠的 CRA 合約生存指南。那篇文章處理的是 EU 品牌如何把 SBOM、CVD 政策、短時限通報 SLA、韌體支援期寫入供應商合約。

如果你的產品是路由器、NAS、防火牆、工業交換器或工控閘道器，先看這篇：台灣網通/IoT 品牌廠的 CRA 實戰指南。那篇文章處理的是網通與 IoT 產品的 Class I / Class II 分類。

這篇文章只處理一個比較窄、但正在變重要的題目：台灣品牌 AI 伺服器、資料中心硬體、BMC 韌體、NIC、DPU、加速卡韌體，銷往 EU 雲端、電信、企業資料中心時，CRA 證據要怎麼準備。

這篇適合誰？

這篇文章適合下列團隊：

• 台灣品牌 AI 伺服器或資料中心硬體廠，直接銷往 EU 市場
• BMC、NIC、DPU、SmartNIC、加速卡韌體供應商
• 伺服器主機板、管理控制器、儲存控制卡、網路卡供應商
• 供應 EU 雲端服務商、電信商、企業資料中心的台灣硬體廠
• 法務、產品安全、韌體、供應鏈、業務團隊，需要把 CRA 要求轉成客戶可接受的證據包

這篇文章不假設每一台 AI 伺服器都是重要產品。相反地，分類必須從實際投放 EU 市場的產品開始看：賣的是完整伺服器、主機板、BMC 模組、NIC、DPU，還是只交付客戶品牌下的代工產品。

AI 伺服器是否適用？

大多數 AI 伺服器、GPU 伺服器、儲存伺服器、資料中心 appliance 都會落入 CRA 範疇，原因很直接：產品含有硬體、軟體或韌體，且預期會連接到裝置或網路。

CRA 的範疇測試涵蓋直接與間接連線。放在資料中心機櫃內的伺服器，即使不面向公眾網際網路，也通常會連接到管理網路、儲存網路、叢集網路或遠端管理介面。BMC、BIOS/UEFI、NIC 韌體、DPU 韌體、加速卡韌體，都是產品資安風險評估需要納入的部分。

少數例外情況仍然存在。例如完全為國防或國家安全目的開發的產品，可能不在 CRA 範疇內。醫療、汽車型式認可、航空、船舶設備也有各自的排除或特殊規則。但一般商用資料中心硬體，不能只因為它是 B2B 產品就排除 CRA。

實務判斷可以先問 3 個問題：

如果 3 個答案都是「是」，下一步就是分類與證據準備。

分類的關鍵

AI 伺服器分類最容易出錯的地方，是把內部元件的分類直接套到整台伺服器。

一台完整 AI 伺服器通常包含 NIC、BMC、CPU、GPU、管理韌體、BIOS/UEFI、儲存控制器與多個開源元件。這不代表整台伺服器一定是 CRA 重要產品。分類要看你投放市場的產品本身，以及該產品是否對應到重要產品清單中的具體項目。

完整伺服器

完整 AI 伺服器、GPU 伺服器、資料中心運算節點，若主要功能是運算、儲存或加速，通常不應只因為內建 NIC 就直接標成 Class I。

正確做法是：

• 把完整伺服器先當作一般產品評估
• 檢查伺服器本身是否具有路由器、交換器、防火牆、作業系統、網路管理系統等清單功能
• 檢查是否有分開投放市場的硬體或軟體元件，需要各自分類
• 把內建元件作為風險與證據管理對象，而不是直接把整台伺服器升級分類

NIC 與 DPU

分開銷售的 NIC、SmartNIC、DPU、資料中心網路介面，較可能對應到重要產品 Class I 的「實體或虛擬網路介面」。

如果 DPU 還提供封包處理、隔離、加密、遙測、虛擬交換或雲端網路功能，EU 買家通常會要求比一般伺服器更細的證據。這不一定表示所有 DPU 都需要第三方公告機構，但至少會把分類、調和標準適用性、韌體 SBOM、漏洞處理流程列入採購審查。

BMC 與管理韌體

BMC 是 AI 伺服器 CRA 準備中最敏感的部分之一。它通常具有遠端管理、開機控制、電源控制、感測器監控、韌體更新、事件紀錄與管理網路存取功能。

若晶片供應商把安全相關微控制器、微處理器、ASIC 或 FPGA 作為獨立產品投放 EU 市場，該晶片本身可能需要重要產品分類判斷。若產品主打防竄改能力，還要另外檢查 Class II 風險。

但內建在完整伺服器中的 BMC，不應因此直接被當成獨立的 Class I 或 Class II 產品。對整機品牌廠來說，BMC 首先是伺服器的高風險面、SBOM 範圍與漏洞處理範圍；只有在 BMC 模組或安全晶片本身被分開銷售時，才需要進一步做元件層級的分類。

這裡不應用一句話下結論。比較安全的做法，是在技術文件內保留分類理由：BMC 是整台伺服器的內建元件、分開銷售的模組，還是單獨交付給 EU 客戶的產品？這三種情況的答案可能不同。

加速卡韌體

GPU、AI accelerator、FPGA 加速卡、儲存加速卡本身未必自動落入重要產品。真正要看的，是產品功能、韌體控制面、遠端更新能力、是否提供安全相關功能，以及是否分開投放市場。

對加速卡供應商來說，最實際的 CRA 工作通常不是先爭論分類，而是把韌體元件、開源套件、驅動程式、更新簽章、漏洞回報流程整理成 EU 買家可稽核的證據。

角色與責任

同一台伺服器，在不同交易模式下，CRA 身分可能完全不同。

CRA 下的製造商身分，不只看誰實際生產。以自己名稱或商標把產品投放 EU 市場的一方，通常要承擔製造商義務。因此，白牌 ODM 合約與自有品牌銷售要分開處理。

EU 授權代表則是另一個問題。CRA 允許非 EU 製造商以書面授權任命 EU 授權代表，但這不是像部分醫療器材規則那樣的強制前置條件。即使任命授權代表，產品設計、風險評估、支援期、漏洞處理等核心責任仍留在製造商端。

EU 買家會看什麼？

EU 雲端、電信與企業資料中心買家通常不會只問「有沒有 CE 標章」。他們會問：發生 BMC 漏洞時，誰在 24 小時內判斷？誰能產出受影響版本清單？誰能通知 ENISA？誰能推送修補？誰能證明舊版韌體仍在支援期內？

對 AI 伺服器與資料中心硬體，證據包至少應涵蓋下列項目：

SBOM 的法律基礎是 CRA 的漏洞處理要求（附件 I 第二部分第 1 點），不是買家的自訂格式偏好。實務上，CycloneDX 與 SPDX 都可能出現。格式可以隨客戶與工具鏈調整，但元件範圍不能只停在主機作業系統。對伺服器硬體來說，BMC、BIOS/UEFI、NIC/DPU 韌體、更新工具、管理代理程式都要被盤點。

韌體層的 SBOM

AI 伺服器供應鏈的 SBOM 難點，不在於會不會輸出一份檔案，而在於多層韌體與供應商邊界。

一台資料中心伺服器至少可能有這些軟體或韌體層：

• BMC 韌體，例如 OpenBMC 或供應商客製分支
• BIOS/UEFI 與開機相關元件
• NIC、SmartNIC、DPU 韌體
• GPU 或加速卡韌體
• 儲存控制器、RAID/HBA 韌體
• 風扇、電源、感測器、管理控制器韌體
• 主機端管理代理程式與更新工具
• 遠端資料處理服務，如果產品功能依賴雲端管理

每一層都可能含有開源套件、第三方 SDK、二進位 blob、簽章工具、驅動程式與客製 patch。只產出 Linux rootfs 的 SBOM，不足以支撐資料中心硬體的 CRA 證據。

比較實務的作法是把 SBOM 拆成 4 個層級：

這樣做的好處，是遇到 BMC 或網路介面漏洞時，可以快速回答 EU 買家最在意的 3 個問題：哪些型號受影響？哪些韌體版本受影響？修補版本何時可用？

支援期與生命週期

資料中心硬體的生命週期通常長於消費性電子產品。CRA 的支援期不是簡單寫 5 年就結束。產品預期使用時間較長時，支援期需要反映合理使用年限；若預期使用時間短於 5 年，才可能短於 5 年。

對 AI 伺服器與元件供應商，支援期管理要處理 4 件事：

• 產品銷售資料頁是否清楚列出安全更新終止年月
• 同一硬體平台的不同韌體分支是否有不同支援期
• 客製版本、雲端客戶專用分支、長期供貨型號是否另有支援承諾
• 元件供應商停止支援時，整機品牌是否仍能履行對 EU 使用者的承諾

EU 買家通常會把支援期寫進採購合約。台灣供應商要避免只承諾「依原廠政策」或「依專案另議」。對 CRA 來說，製造商需要能證明支援期是如何決定的，且使用者在購買時能清楚看到安全更新終止時間。

通報流程

CRA 的通報義務在 2026 年 9 月 11 日先行適用。對台灣製造商來說，這個日期比 2027 年 12 月 11 日更接近。

通報分成兩條線：

台灣製造商沒有 EU 主要營業據點時，通報會透過單一通報平台送到指定的協調 CSIRT，並同時供 ENISA 存取。協調 CSIRT 的選擇通常要依序看 EU 授權代表、進口商、經銷商或使用者所在會員國。實務上，這意味著銷售通路資料、EU 進口商資料與主要客戶部署地點，不能只放在業務系統裡。

資料中心硬體常見的通報觸發情境包括：

• BMC 遠端管理介面遭積極利用
• NIC 或 DPU 韌體漏洞造成隔離失效
• 韌體更新機制被濫用，導致惡意程式碼被導入產品
• 管理代理程式漏洞影響大量 EU 客戶部署
• 第三方開源元件漏洞已在同型號產品上被利用

內部流程要能在 24 小時內完成初步判斷。這不代表 24 小時內完成修補，而是要能確認漏洞是否遭積極利用、哪些產品可能受影響、誰負責通報、誰負責通知使用者。

技術文件的重點

技術文件不是一份法規作文。對 AI 伺服器與資料中心硬體，技術文件應能回答工程與合規問題：

• 為什麼完整伺服器被判定為一般產品或重要產品？
• NIC、DPU、BMC、加速卡是否分開投放市場？
• 每個韌體層有哪些開源與第三方元件？
• 安全更新如何簽章、驗證、散布、回滾與撤回？
• 漏洞如何從供應商、研究人員、客戶、內部測試流入？
• 支援期如何決定，何時揭示給客戶？
• 發生遭積極利用漏洞時，誰在 24 小時內做決策？

條文引用可以放在文件附錄。主文件應讓 EU 買家、公告機構、進口商或市場監督機關快速理解產品與流程，不需要讀者在每一段都遇到法條編號。

實作路線圖

第一輪不需要追求完美。比較重要的是選定一條高風險產品線，例如 EU 客戶採購中的 AI 伺服器平台或 DPU 模組，先把分類、SBOM、通報、支援期、技術文件跑通。