工業機器人與協作型機器人是否為 CRA 重要產品？

如何分類工業機器人或協作型機器人釋出版本？

從銷售方案 (offer) 出發，而非從手臂硬體出發。同一支 6 軸手臂以零組件方式賣給系統整合商，與作為完整協作型工作單元賣給小型工坊，在 CRA 下是不同的產品。路線取決於：買方為什麼付費、隨附哪一款控制器與教導器，以及製造商是否同時提供艦隊雲、安全配置與 OTA 更新通道。

上方圖示承載路線選擇。下方矩陣承載邊界備忘錄：一旦變體確定，這些就是製造商針對該變體應能填入的證據列。

選路工具是寫邊界備忘錄之前的輔助，不是替代品。備忘錄仍需明確列出：手臂型號、負載與作業範圍、控制器機櫃、教導器、程式設計環境、安全配置範圍、艦隊雲、OTA 服務與預定用途。針對完整協作型工作單元，請列出買方仰賴的協作運轉模式：速度與距離監測、功率與力限制、引導示教或安全評等監視停止。

接著檢視是否有另一項列名功能才是產品的真正核心。CRA 是以產品的核心功能是否符合列名類別來判定「重要」；單純嵌入一個控制器並不足以把機器人推進重要類別。如果銷售方案的本質其實是防火牆閘道、VPN 設備、網路管理系統、SIEM 連接器，或以防竄改晶片為核心建構的強化型控制器，請先就該核心功能進行分類，並把手臂視為周邊裝置。

零組件銷售不要硬套到完整工作單元的類別。賣給系統整合商的機器人手臂，仍然是含數位元件的產品，仍需具備安全設計證據、更新通道、漏洞處理流程、支援期間聲明，以及面向整合商的書面說明。路線維持標準路線；責任則與整合商分擔。

分類備忘錄應回答四個問題：

1. 本次釋出是以機器人手臂、完整協作型工作單元，或嵌入另一台機器內的機器人形式銷售？
2. 機器人的運動是否為產品的核心功能，或另一項列名功能（防火牆、VPN、網路管理、安全相關微控制器）才是真正的主角？
3. 為了預期功能提供了哪些數位元件：手臂韌體、安全配置、教導器、程式設計環境、OTA 服務、艦隊雲與漏洞處理流程？
4. 哪些系統不在製造商的銷售方案之內：客戶的工作單元邏輯、客戶安全 PLC、廠區網路、第三方視覺軟體、客戶 MES 或 SCADA？

機器人產品邊界內應包含哪些項目？

對機器人製造商而言，合規邊界很少只有手臂本身。它應隨上市產品以及預期動作與安全功能所需的數位元件而設定。

通常屬於機器人製造商邊界內：手臂韌體、關節控制器韌體、控制器機櫃作業環境、安全控制器韌體、教導器、程式設計環境、OTA 服務與漏洞處理流程。

通常屬於邊界外，除非製造商把它們作為銷售方案的一部分一起賣：客戶工作單元邏輯、客戶撰寫的安全配置、廠區網路、第三方末端工具、第三方視覺軟體、客戶 MES 或 SCADA，以及客戶安全 PLC。

應採用哪一種適合性評估路線？

機器人檔案中應放入哪些架構檢查點？

機器人釋出檔案應依實際機台而設，而非套用通用的 OT 檢核清單。賣給整合商的獨立手臂、賣給中小企業的力限協作工作單元、嵌入包裝產線的機器人，以及含視覺的潔淨室機器人，可以共用一份分類討論，但所需的工程紀錄各不相同。

1. 運動授權路徑。 列出所有可變更運動、參數或安全配置的路徑：教導器、工程站、廠商雲、廠商服務通道、USB 傳輸、來自工作單元控制器的現場匯流排，以及任何遠端協助通道。
2. 本地曝險。 在試車與每次更新後，掃描控制器上可達的服務。釋出檔案應呈現哪些服務可達、哪些需要驗證，以及哪些預設關閉。
3. 客戶系統。 客戶工作單元邏輯、客戶安全 PLC、廠區網路、第三方視覺軟體、MES 或 SCADA，除非由製造商銷售，否則皆視為機器人製造商產品之外。
4. 更新授權。 將更新授權視為雙向交換：控制器查詢或接收更新中繼資料，更新服務針對該控制器變體與安全韌體版本回傳簽章韌體封裝。簽章更新、降級拒絕、機台影響、復原與回滾紀錄皆應與釋出版本一同留存。
5. 供應商輸入。 為伺服微控制器、編碼器、安全微控制器、現場匯流排堆疊、視覺模組、即時作業系統與程式設計執行環境，各自指派負責人、版本、通告監看與釋出決定。
6. 服務存取。 服務通道、診斷與遠端協助連線不應變成第二條運動授權路徑。保留通道關閉、遮蔽與稽核樣本紀錄。
7. 上市後迴圈。 漏洞通報、重大事件、供應商通告與場域故障應更新威脅清單、殘留風險紀錄、釋出檔案與下一個釋出閘門。

下方的工作單元圖刻意比範例更廣。請在縮減至實際出貨變體前，把它當作產品家族邊界檢查工具：6 軸手臂、協作型機器人、潔淨室變體、堆棧變體，以及與末端工具一起銷售的機器人，各需不同的證據集合。

符合此佈局的真實 OEM 控制器包括 ABB OmniCore、KUKA KR C5 (KSS) 與運行 iiQKA.OS 的 KUKA 控制器、FANUC R-30iB Plus、Yaskawa YRC1000、Universal Robots PolyScope X。上述分工在所有產品上都共用：製造商產品檔涵蓋手臂、控制器與裝置端軟體邊界；客戶工作單元邏輯、廠區 LAN 與客戶自有工具則在邊界外，除非製造商也銷售該層。

如何建立機器人風險評估？

請把這個範例當作理解所需深度的依據，而非可直接貼入釋出檔案的文字。機器人製造商仍需針對自家的手臂、關節驅動、控制器、安全控制器、教導器、程式設計執行環境、艦隊雲、供應商、銷售主張、支援期間與釋出流程進行評估。

我們要評估的是哪一個產品？

範例產品（非真實裝置）：ExampleCo CR-12，12 公斤負載、1300 公釐作業範圍的 6 軸鉸接式工業機器人手臂，附選配力限協作模式。出貨內容包含手臂、一台控制器機櫃、一支教導器、選配 2D 視覺感測器、一套程式設計環境、簽章 OTA 更新與製造商艦隊雲連接器。銷售對象為中小製造業的完整工作單元，並以零組件方式賣給系統整合商作為更大機台之用。

本範例的產品邊界包含：手臂、關節驅動、控制器機櫃、安全控制器、教導器、程式設計執行環境、OTA 服務、廠商雲連接器、漏洞通報窗口與支援結束揭露。不包含：客戶工作單元邏輯、客戶安全 PLC、廠區網路、第三方 MES 或 SCADA、第三方末端工具、圍籬與光柵安裝，以及任何 AGV 或 AMR 底盤。

本產品供受訓的操作員與整合商於室內工業環境使用。不適用於醫療或外科機器人、服務型機器人、教育型機器人，或任何消費性用途。

寫威脅表前，先測試三條通常會驅動機器人風險評估的路徑：程式載入與教導器授權、安全與資安的邊界，以及整合商交接。下列圖示把這個範例轉成工程問題，而非通用威脅清單。

產品檔紀錄：五個階段紀錄加上 N1–N5 五項反向測試結果，構成製造商的授權變動時序。把它們留在產品檔中，審查者可看出每一次轉手時運動或安全授權由誰持有。

擁有權與程式載入是兩項分開的檢查。即使控制器具備簽章更新，若維護後服務通道仍未關閉，或客戶轉手後舊工程站仍能寫入，仍可能失敗。

圍籬工業機器人與協作型機器人的攻擊面有何不同？

本頁將兩者歸入同一個 CRA 類別，因為兩者本質相同：在資安韌性層面屬於工業機器人，而非智慧家庭產品。但風險樣貌不同，威脅清單應反映這項差異。

對範例 ExampleCo CR-12 而言，圍籬配置強調工程站授權、復原插槽完整性與汰役時憑證輪替。協作型配置則把視覺輸入驗證、校正資料完整性、距離監測竄改測試與每位操作員的教導器角色儲存當作一等公民。

我們要保護的是哪些資產？

風險評估從資產起步，因為機器人的威脅並非單一面向。失去運動完整性、安全配置遭破壞、工程通道遭接管，三者所需的控制與釋出紀錄都不同。

主要的信任邊界在哪裡？

本範例中製造商至少應建模五個環境。重點不是把每條線都畫出來，而是要區分出攻擊者機會會改變的位置：機櫃內部、教導器連線、廠區網路、製造商後端，以及工程站。

安全堆疊與資安堆疊並非同一個專案。它們會在特定點共用證據；檔案要說明清楚每一條條款由誰負責。

應先評估哪些威脅？

本範例先列出十四項產品專屬威脅。重點不在於窮舉，而是展示製造商應能展現的可追溯深度。

接著單獨檢視整合商交接：對於組成的工作單元，誰算製造商？哪些紀錄必須隨之移交？

初步風險應如何排序？

採用釋出閘門位階，讓每一項風險不致都拿到同一種裁定：

哪些設計控制能改變風險樣貌？

控制表應可追溯回 R 編號，但不應讀來像通用安全開發檢核表。對每一項控制，製造商應能對該釋出版本展示證明該控制存在的測試、設計註記或營運紀錄。

套用控制後仍存的殘留風險？

套用控制後，製造商應重跑評估，而非把威脅標為完成。本範例中，供應商漏洞路徑、整合商交接與長產品壽命，在支援期間仍須持續管理。殘留風險可被接受的前提，是製造商可證明：監看、分流、簽章更新交付、整合商通知與矯正措施流程確實在運作。

艦隊雲通告應如何路由？

上方的風險評估針對單一機器人機櫃。通告路由則跨上百台。當製造商艦隊雲服務多家整合商與多個營運場域時，問題不是「雲端是否安全」，而是「24 小時漏洞警示觸發時，整個鏈條中誰會聽見？誰核准每個場域的更新視窗？」

釋出紀錄。 一份艦隊雲路由地圖，針對連接器清單上的每位整合商與營運者，列出 24 小時漏洞警示的聯絡人、維護視窗擁有者、回滾權責與仍開啟的殘留通告。沒有這份地圖，期限會跑向沒有收件人的位址。

釋出前要過哪些驗證閘門？

避免使用籠統的「已完成資安審查」閘門。請採用一份釋出閘門清單，對每一項可能停止機器人出貨的決定，記載失效模式、設計控制與證明文物。

機器人從概念到支援由誰負責？

主導責任會隨機器人從產品定義走向上線支援而轉移。請使用此鏈道，在產品變動的每一階段指派一位負責人、一份維護中的紀錄與一個審視閘門。

擁有權規則：這是主導鏈，而非完整責任矩陣。產品變動時，每位主導負責人維護一份紀錄；支援所得的發現會回流到下一個變體的邊界備忘錄與威脅清單。

在架構工作前凍結邊界，在實作前凍結設計意圖，在驗證前凍結候選版本，在釋出前凍結決定，並在支援期間使釋出版本持續運作。新進通報、供應商通告、事件結果與回歸結果，會重啟下一份邊界備忘錄、威脅清單與元件登錄。

檔案中應放哪些證據紀錄？

檔案應讓審查者能從產品識別一路追到資安控制。下列每一列應指向一份維護中的紀錄，而非一堆散落的截圖。

機器人 SBOM 中應放入什麼？

CRA 要求一份機器可讀的 SBOM，識別產品的元件並至少涵蓋頂層相依，但目前尚未指定固定格式。在執委會 (Commission) 補充細節前，機器人製造商通常選擇 CycloneDX 或 SPDX。SBOM 機制的跨產品細節置於專門的 SBOM 指南；本節聚焦機器人專屬的樹狀結構。

機器人釋出版本通常出貨多項各有更新週期的數位元件，而非單一二進位檔。兩種實作模式皆能滿足 CRA 最低要求：一份產品層級的 SBOM，含分元件區段（運動 CPU、安全控制器、即時作業系統與教導器韌體各版本皆釘住），或對每一出貨的數位元件各自維護一份 SBOM，每次釋出時更新。兩種模式皆可接受，前提是 SBOM 為機器可讀且涵蓋頂層相依。

SBOM 紀錄： 一份以 CycloneDX 或 SPDX 製作的機器可讀 SBOM，至少涵蓋頂層相依。建議的機器人製造商模式：產品層級單一 SBOM 含分元件區段，或對每一出貨數位元件各維護一份 SBOM 並於釋出時更新。可在建置系統能夠產生時補上更深層的傳遞相依。將 SBOM 與元件通告監看紀錄（證據對照中的「元件清單」列）相互配對，審查者方能看出已知漏洞落在哪一個程式庫，哪一次釋出將其關閉。

釋出簽核要檢查什麼？

機器人在投放歐盟市場前，簽核應結清下方 SVG 標示為 Q1 至 Q4 的同四份紀錄夾。完整檔案清單在上方的證據對照中；本表只列出四個會阻止釋出的問題。

簽核閘門：若任一紀錄缺漏，即不予簽核釋出。

符合性聲明紀錄： 範本與必填欄位請參照主要的 歐盟符合性聲明指南。針對機器人釋出，產品識別應釘住手臂、控制器機櫃、教導器、韌體分支、隨附選項與支援期間參考。若同一聲明同時涵蓋機械法規，請在聲明中標示該路線，並使機器人技術檔案與機械安全檔案保持對齊。

機器人如何交接給進口商、經銷商、整合商與營運者？

釋出檔案應讓機器人製造商交付給進口商、經銷商、作為製造商的整合商與終端使用者的交接可被測試。對機器人與協作型機器人而言，弱點通常不在 CE 標章本身，而在出貨、手冊、艦隊雲、OTA 服務與整合商交接是否仍與所評估的釋出版本一致。

交接閘門：當包裹、可追溯性、支援聲明、艦隊雲、更新通道、角色身份或已知漏洞與所評估的釋出版本不一致時，不得將機器人由出貨推進至上架。

下列各欄是精簡版：何時驗證、何時暫停、何時需要重新進行角色分析。跨產品的角色觸發細節（製造商、進口商、經銷商、授權代表、開源軟體管家）置於 CRA 適用對象指南。