準備EN 40000與CRA合規，製造商需要建立能連結產品版本、風險判斷與處理紀錄的證據。重點包括風險評估、軟體物料清單（SBOM）、漏洞處理、修補驗證及必要的通報紀錄，並在產品變動後持續更新。
對產品安全、韌體研發與品質團隊而言，關鍵問題是：這份資料對應哪個產品版本？哪些要求已經驗證？哪些風險仍待處理？本文整理EN 40000系列的分工，以及製造商可先建立的合規證據與工作流程。
EN 40000與CRA有什麼關係？
CRA是歐盟《網路韌性法案》（Cyber Resilience Act），訂定適用產品的資安義務；本文聚焦的EN 40000-1系列屬於支援CRA標準化工作的橫向標準，涵蓋術語、資安原則、漏洞處理與通用安全要求。製造商應先確認產品適用範圍與分類，再選擇相應的評估程序及技術方法。
理解兩者關係時，必須分清楚標準草案、正式發布的標準，以及已於《歐盟官方公報》引用的協調標準。草案可供準備工作參考；正式發布本身，也不代表已對CRA產生推定符合性。只有符合相關引用條件，且在標準涵蓋的要求範圍內，才能主張相應效果。
CRA主要義務將自2027年12月11日起適用；製造商針對遭積極利用的漏洞及影響產品安全的嚴重事件之通報義務，已自2026年9月11日起適用。標準化進度與法規義務需分別追蹤，不能因標準仍在制定，就忽略已適用的通報責任。
EN 40000各分冊的重點
EN 40000的分冊依不同主題分工，不能直接按「一般產品」與「高風險產品」解讀編號。對合規團隊而言，可先掌握共同術語、風險與生命週期原則、漏洞處理，以及通用安全控制四個方向。
| 分冊 | 主題方向 | 企業準備重點 |
|---|---|---|
| 40000-1-1 | 術語與共同定義。 | 統一產品、風險及漏洞管理文件中的用語。 |
| 40000-1-2 | 資安韌性原則、產品風險管理與生命週期活動。 | 連結風險評估、設計決策與開發維護流程。 |
| 40000-1-3 | 漏洞處理。 | 整理漏洞接收、分析、修補與協調揭露的執行紀錄。 |
| 40000-1-4 | 通用安全要求與安全控制。 | 依產品情境選擇控制措施，保留測試及驗證依據。 |
產品是否屬於CRA的重要或關鍵產品，應依產品功能與法規分類判斷，並另外核對相關產品標準。不能因為看到40000-1-2，就推定它僅適用於高風險產品。
製造商應準備的五類合規證據
製造商可以將CRA準備工作整理為五類證據：風險與設計、元件組成、漏洞處理、修補與支援，以及通報紀錄。以下是依產品資安義務整理的實務清單，不應解讀為未定稿標準的完整條文或固定測試項目。
1. 風險評估與安全設計依據
風險評估需要說明產品用途、預期使用環境、攻擊面，以及選擇安全措施的理由。對每項重要風險，團隊應能指出採取了什麼控制、如何測試，以及仍有哪些限制。
建議將風險項目連結到設計文件、測試結果與負責人，並保留版本。產品功能或部署情境改變後，才能判斷哪些結論需要重新確認。
2. 與交付版本一致的SBOM與元件資料
軟體物料清單（Software Bill of Materials，SBOM）應支持產品元件的識別與追蹤。CRA附件I第II部分要求識別、記錄漏洞與元件，包括以常用且機器可讀的格式建立SBOM，至少涵蓋產品的頂層相依項目。
在實務上，應將SBOM對應到實際發布版本，檢查供應商資料與交付韌體是否一致。新版本改變元件組成時，需更新清單；只有漏洞資訊變動時，則應更新相關風險與處置紀錄，不能把所有變動都混成同一份資料。
3. 漏洞接收、監控與協調揭露紀錄
企業需要建立可執行的漏洞處理流程，涵蓋接收內外部通報、確認受影響產品、協調供應商，以及安排修正與揭露。對外聯絡窗口和內部處理責任應相互銜接。
可保留漏洞工單、元件比對結果、供應商回覆、影響判斷與揭露決策。這些紀錄有助於說明團隊如何處理發現，而不只是證明曾發布一份漏洞揭露政策。
4. 修補驗證與支援期間安排
發現漏洞後，應結合技術嚴重性、產品暴露情況與實際影響安排處理，保存修補決策、測試結果與發布紀錄。單一分數可以協助排序，但不能取代產品情境判斷。
CRA的支援期間原則上至少五年，且需反映產品預期使用時間；若產品預期使用時間少於五年，支援期間可對應該時間。對預期使用更久的產品，也不能直接把五年當作足夠的固定上限。相關判斷依據應納入技術文件。
5. 分階段通報與時間紀錄
CRA的通報流程不只是一份「24小時內完成的報告」。對遭積極利用的漏洞，原則上需在知悉後24小時內提交早期預警、72小時內提交通報，並在矯正措施可用後14天內提交最終報告；各階段均須避免無故延遲。
影響產品安全的嚴重事件也有相應通報義務，但最終報告時點與漏洞情境不同。團隊應透過單一通報平台向指定CSIRT與ENISA完成適用通報，保存知悉時間、內部升級、提交內容與後續補充紀錄。
沒有原始碼，如何建立韌體證據？
使用第三方韌體時，可以結合供應商SBOM、版本與修補聲明、韌體二進位分析，以及必要測試建立證據。無法取得原始碼，仍需掌握交付內容與風險；二進位分析則是補足資料缺口的重要方法之一。
例如，產品整合通訊模組後，可先向供應商索取與交付版本一致的元件資料，再分析可取得的韌體映像，交叉檢查元件、版本與已知漏洞。對加密、封裝或辨識不明的內容，應記錄分析限制並追蹤補件。
建議保存分析工具版本、掃描範圍、韌體識別資訊、元件判讀結果及未解決項目。二進位分析能提供技術線索，但不能保證找出所有元件，也不能單獨取代完整的符合性評估。
將證據管理納入產品發布流程
較有效的準備方式，是讓每個發布版本都有可追查的證據，並明確定義重審條件。以下四個步驟可作為研發、產品安全與品質團隊的共同工作框架。
- 界定範圍：確認產品、版本、預期用途、CRA分類及評估責任，建立適用要求清單。
- 整理證據：彙整風險評估、SBOM、韌體分析、測試與供應商資料，記錄來源及對應版本。
- 處理缺口：將未確認元件、待修漏洞與缺少文件的要求轉成工作項目，指定負責人和驗證方式。
- 持續重審：在新版本、重大功能變更或相關漏洞資訊更新時，重新確認受影響的判定，保存決策與處置紀錄。
這樣的流程有助於避免常見落差：清單屬於舊版本、修補已有結果卻未更新紀錄，或產品發布後才發現沒有可執行的漏洞通報程序。
ONEKEY如何支援合規資料管理？
ONEKEY可支援韌體分析、元件與SBOM管理及漏洞調查，讓團隊以產品資料檢查技術風險。平台中的Compliance Wizard則可協助逐項查看支援規範的評估建議、補充人工判定，以及整理支援材料。
對應的條款建議可連結CVE與安全問題；重新分析或相關問題狀態改變後，受影響的條款也可標示為待重新確認。這些能力能協助整理合規資料，但實際支援的規範、版本與分析範圍仍需確認，不應直接推定已涵蓋所有EN 40000分冊。
功能與應用方式可參考 宏虹ONEKEY Compliance Wizard合規管理介紹 。企業仍需負責適用性判斷、組織流程及最終符合性評估。
ONEKEY合規管理常見問題
ONEKEY可以直接判定產品符合CRA嗎？
ONEKEY可提供韌體分析結果、漏洞資訊與合規評估建議，協助團隊整理證據及找出缺口。產品適用要求、風險接受與最終符合性判斷，仍需由企業及相關評估單位確認。
已有SBOM與漏洞掃描工具，還需要Compliance Wizard嗎？
可先檢查現有流程能否將分析結果連結到合規要求，並保留人工判定與佐證資料。若仍需人工彙整，或產品更新後難以確認哪些項目需要重審，可進一步評估Compliance Wizard。
評估ONEKEY前，需要準備哪些資料？
建議先選定一款產品，準備可提供的韌體檔案、產品版本、既有SBOM，以及希望評估的法規或標準。若資料尚未齊備，可先列出缺項，與宏虹討論分析範圍與Demo需求。
