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

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

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

如果你要把 SBOM CVE 轉成受影響、未受影響、已修補或調查中判定，請看台灣韌體 SBOM 漏洞判定指南。

如果你的產品是路由器、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 買家可稽核的證據。

元件分類的技術界線

前面的分類判斷，現在有一份更硬的依據。自 2025 年 12 月 21 日起，歐盟為重要與關鍵產品的每一個類別，補上了具約束力的技術描述。你可以拿每個元件對照對應類別的技術描述，而不是憑印象猜。搭配「內建一個重要元件，不會自動把整台伺服器拉進第三方評估」這條規則，逐一元件的界線就能畫得比較清楚。

這條界線的法律依據，是 CRA 第 7 條第 1 項（內建重要元件不會牽動整機的第三方評估）與 CRA 第 7 條第 4 項要求的技術描述實施法規。該實施法規為 2025 年 11 月通過、2025 年 12 月 21 日生效的歐盟實施規則 2025/2392（Commission Implementing Regulation (EU) 2025/2392），為附件 III 的重要產品類別與附件 IV 的關鍵產品類別提供具約束力的技術描述。

BMC 不在清單上，不代表它落在 CRA 範疇之外。內建 BMC 仍是整台伺服器的高風險面、SBOM 範圍與漏洞處理範圍。清單分類決定的是要不要第三方評估，不是要不要納管。

角色與責任

同一台伺服器，在不同交易模式下，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 個問題：哪些型號受影響？哪些韌體版本受影響？修補版本何時可用？

韌體證明鏈

SBOM 回答的是「裡面有哪些元件」。EU 買家接下來會問另一個問題：開機時實際載入的韌體，是不是你宣稱的那一份版本？這兩個問題不同，需要不同的證據。

資料中心硬體有一組成熟的產業機制可以回答第二個問題。它們不是 CRA 指定的工具，而是你可以選用的證據來源：

• 晶片信任根（silicon root of trust）：以硬體為錨點，在第一段韌體執行前先驗證其完整性
• 量測開機（measured boot，例如 OpenBMC 的實作）：把每一層韌體的版本量測值寫入硬體暫存器，形成可事後查驗的紀錄
• DMTF SPDM：讓 NIC、DPU、加速卡、BMC 之間互相驗證身分，並交換韌體量測值，供主機端核對

這組機制對 CRA 有兩個實際用途。第一，它為基本資安要求提供可查驗的證據，例如完整性保護、安全更新與竄改偵測。第二，它把多層韌體 SBOM 接回現場：EU 買家可以拿 SBOM 上的韌體版本，對照量測開機留下的量測值，確認清單描述的就是實際運作的韌體。

這裡要講清楚一件事。CRA 沒有規定你一定要用 SPDM、量測開機或任何特定信任根。法律要求的是達到基本資安要求並能提出證據。晶片信任根、量測開機與 SPDM 是把「我們有做」變成「這是可驗證的證據」的方法，不是法律義務本身。

支援期與生命週期

資料中心硬體的生命週期通常長於消費性電子產品。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 小時內完成修補，而是要能確認漏洞是否遭積極利用、哪些產品可能受影響、誰負責通報、誰負責通知使用者。

到 2026 年年中，ENISA 的單一通報平台還沒有正式上線。這不會延後你的通報義務，但代表在平台完全就緒前，你需要一套過渡辦法：先確認協調 CSIRT 的窗口、備妥通報內容範本、保留人工送件路徑，避免在 2026 年 9 月 11 日之後才發現流程卡在平台狀態上。

技術文件的重點

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

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

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

還有一點會影響你的自我評估規劃。到 2026 年年中，歐盟官方公報還沒有列出任何 CRA 調和標準。這代表第 27 條的符合性推定目前還不能用，你無法靠「符合某條調和標準」直接推定達到基本資安要求。技術文件要自己把每項基本資安要求對應到具體的設計與測試證據，不能先假設之後有標準可以套。

實作路線圖

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

CRA Evidence 的顧問服務

CRA Evidence 專注在把 AI 伺服器與資料中心硬體的 CRA 要求，轉成 EU 買家可稽核的證據，而不是一份法規摘要。

顧問範圍包含：完整伺服器與 BMC、NIC、DPU、加速卡的逐項分類判定；多層韌體 SBOM 的範圍界定與生成輔導；韌體證明鏈與基本資安要求的證據對應；漏洞通報流程與 24 小時判斷演練設計；以及技術文件與供應商合約條款的缺口盤點。

如果你已經收到 EU 客戶的 CRA 問卷或 SBOM 要求，可以先用一條高風險產品線做盤點。想先確認產品是否落入 CRA 範疇，可以用 CRA 適用性快速檢查。需要外部協助時，預約免費評估。