若貴公司的產品依 IEC 62443-4-1 開發，或元件已依 IEC 62443-4-2 評估，您很可能已保有產品設計、測試與維護的詳細紀錄。其中部分紀錄可支持您的歐盟網路韌性法案（CRA）工作。真正的課題在於確認：哪些紀錄適用於哪一項產品與版本、這些紀錄實際證明了什麼，以及哪些 CRA 義務需要另行評估。
本頁將特定的 IEC 62443 要求對應到特定的 CRA 條文，說明各項要求可作為何種證據，也清楚指出其不足之處。
適用對象與前提
貴公司製造工業自動化硬體、軟體或韌體，並將具數位元素的產品投放歐盟市場，無論公司設立於何處。貴公司的開發組織依 IEC 62443-4-1 運作，部分元件已依 IEC 62443-4-2 評估。本頁假設相關流程確實運作，且所涉產品版本確有紀錄。證書或載明該標準的政策，只是審查的起點。
有兩件事並非這兩項標準所能決定：
- CRA 是否適用，以及適用於誰。 CRA 適用於在歐盟市場上供應、且其預期用途或可合理預見之使用方式包含與裝置或網路之直接或間接的邏輯或實體資料連線的具數位元素的產品（第 2 條）。第 3 條 定義產品（包括其遠端資料處理解決方案）與製造商。第 2 條的排除規定需另行檢視。IEC 62443-4-1 適用於產品的開發者與維護者，而非其整合者或使用者（第 1 節，第 11 頁）。貴公司是否為特定產品的 CRA 製造商，是另一個法律問題。
- 產品屬於哪一類別，這決定符合性評估途徑（第 7 條、第 8 條 與 第 32 條，以及附件 III 與附件 IV）。類別取決於產品的核心功能。IEC 62443 的安全等級描述的是抵禦精密程度遞增之威脅的能力（IEC 62443-4-2，3.3 節，第 26 頁），並非 CRA 類別。依第 7 條第 1 項，整合具備附件 III 所列類別核心功能的元件，並不因此使最終產品適用重要產品的符合性評估程序。
本頁對照的版本
- IEC 62443-4-1:2018，第 1.0 版，2018 年 1 月：安全產品開發生命週期要求。
- IEC 62443-4-2:2019，第 1.0 版，2019 年 2 月：工業自動化與控制系統（IACS）元件的技術安全要求。CENELEC 未經修改即將其採納為 EN IEC 62443-4-2:2019。勘誤 1（2022 年）僅修正法文版本。
- 下文頁碼為 IEC 文本的印刷頁碼。
- 這兩部分均援引其他文件，尤其是 IEC 62443-3-3：4-2 的要求即由其衍生，且其中數項要求指向該文件。本頁未對照這些被援引的要求。
- 第 (EU) 2024/2847 號法規，即 CRA，以《歐盟官方公報》公布之版本為準。
先確認評估的範圍
在重複使用任何 IEC 62443 結果之前，請寫下它實際涵蓋的範圍：
- 標準部分與版本；若經驗證，則包括驗證機制及其版本。
- IEC 62443-4-1：受評估的組織及其文件化流程。 流程評估描述的是產品「應如何」開發；產品紀錄才能顯示特定版本是否確實如此。IEC 62443-4-1 也定義了成熟度等級（Maturity Level），用以描述要求落實的程度（4.2 節，第 19 頁）。請記錄評估所載的等級。
- IEC 62443-4-2：元件、其版本及元件類型。 元件類型包括軟體應用、嵌入式設備、主機設備與網路設備。一個元件可能同時符合多種定義，此時應符合每一種類型的要求（3.3 節，第 26 頁）。請記錄各項基礎要求（FR）所達到的安全能力等級（SL-C）。
- 假設存在的外部補償措施。 若某項 4-2 要求須借助元件外部的補償措施（compensating countermeasure）才能達成，元件文件必須加以說明（4.3 節，CCSC 2，第 27 頁）。IEC 62443-4-1 SG-2 記錄預期由環境提供的縱深防禦措施（12.3.1，第 45 頁）。
最後一點對 CRA 很重要。歐盟執委會的指引說明，網路安全風險評估涵蓋源自產品外部的風險，而 CRA 並不要求製造商控制外部環境。製造商應識別此類風險，並透過產品本身的設計加以緩解，必要時並透過提供使用者資訊與說明為之（C(2026) 5252，第 168 段，第 59 頁）。因此，「工廠網路會提供防火牆」這類假設，是網路安全風險評估的輸入，而產品層級如何處理該風險，需要有自己的證據。
多數 4-2 要求是以能力的形式表述：元件「應提供能力」去做某件事。具備能力，並不代表產品出貨或組態時就是如此。交付組態的證據，來自您的產品紀錄。
IEC 62443-4-1 證據可提供的支持
以下各組列出 4-1 要求、證據可對應的 CRA 條文，以及該要求未能涵蓋之處。請將每一項連結都視為「潛在」的重複使用：它仍取決於所涉產品、版本、流程是否確實執行，以及其產出的品質。
安全情境與威脅模型
IEC 62443-4-1： SR-1（6.2.1，第 27 頁）、SR-2（6.3.1，第 27–28 頁）。
文件化的產品安全情境，可對應 第 13 條第 2 項與第 3 項；涵蓋資料流、信任邊界、介面、實體與除錯埠、外部相依項目，以及威脅之嚴重性與緩解措施的威脅模型亦同。兩者均應納入 附件 VII 第 3 點 所定的技術文件。SR-2 另要求已發布產品的威脅模型至少每年審查一次，並於出現新威脅時視需要更新，即使設計並未變更。
檢查重點：
- 最低內容。 第 13 條第 3 項規定網路安全風險評估的最低內容：預期用途、可合理預見之使用方式、使用條件（例如運作環境及所欲保護之資產），並考量產品的預期使用期間。
- 適用性。 評估也必須載明附件 I 第一部分第 (2) 款各項要求是否適用、如何適用及如何實施，以及如何適用第一部分第 (1) 款與第二部分的漏洞處理要求。某項要求不適用時，第 13 條第 4 項要求在技術文件中提出明確理由。
- 方法與範圍。 歐盟執委會的常見問題集確認並未強制特定方法（第 4.1.2 節，第 27 頁），且評估必須涵蓋整個產品，包括屬適用範圍的遠端資料處理（第 4.1.1 節，第 26 頁）。IEC 威脅模型可作為該網路安全風險評估的一部分。整體評估是否涵蓋整個產品及第 13 條第 3 項的內容，仍需另行確認。
- 審查週期。 每年審查的間隔來自 IEC。CRA 要求網路安全風險評估予以文件化，並於支援期間內視情況更新（第 13 條第 3 項）。
安全設計與實作
IEC 62443-4-1： SD-1（7.2.1，第 30 頁）、SD-2（7.3.1，第 31 頁）、SI-1（8.3.1，第 33 頁）、SI-2（8.4.1，第 34 頁）。
這類證據可對應 附件 I 第一部分第 (1) 款、第一部分第 (2) 款第 (j) 目（限縮攻擊面，包括外部介面），以及第 (k) 目（利用緩解機制）。它也支持 附件 VII 第 2 點第 (a) 目 所述的設計與系統架構說明。其內容包括：
- 每一個介面的特性描述，涵蓋外部或內部存取、信任邊界、使用者與資產、包括輸入驗證在內的防護措施，以及所使用的第三方產品；
- 依據威脅模型配置的多層防禦；
- 實作審查，包括對所有原始碼變更與新程式碼進行靜態程式碼分析（static code analysis），且該語言有可用工具時以工具執行；
- 持續維護的安全編碼標準。
檢查重點：SI-1 與 SI-2 適用於產品自身的元件。外部提供的元件改由 SM-9 規範（8.2 節，第 33 頁）。靜態分析與工具要求來自 IEC 62443-4-1；附件 I 並未指定任何分析方法或工具。設計與審查紀錄僅能就其所描述的版本支持 CRA 要求。
外部提供的元件與軟體材料清單
IEC 62443-4-1： SM-9（5.11.1，第 24 頁）、SM-10（5.12.1，第 24 頁）、DM-4（10.5.1，第 40 頁）。
SM-9 要求以流程識別並管理所有外部提供元件的安全風險，其補充指引同時討論開源與商用元件。SM-10 要求由第三方供應商客製開發、且符合其條件的元件，遵循符合 4-1 的生命週期流程。兩者的紀錄均可對應 第 13 條第 5 項 對整合組件之善良管理人注意義務；該義務明文涵蓋非於商業活動過程中於市場上供應的自由與開源軟體組件。
三個檢查重點：
- 軟體材料清單本身。 附件 I 第二部分第 (1) 款 要求識別並記錄漏洞與組件，包括以通用且機器可讀之格式製作軟體材料清單，至少涵蓋最上層相依套件。IEC 62443-4-1 在補充指引中建議建立第三方元件清冊（5.11.2，第 24 頁），但未指定軟體材料清單的格式或深度。IEC 62443-4-2 CR 7.8（11.10，第 62 頁）是支援控制系統元件清冊的能力，並非軟體材料清單。
- 向上游通報。 DM-4 要求在所有情況下，於所含第三方原始碼中發現問題時告知第三方。第 13 條第 6 項 要求製造商將在任何整合組件中發現的漏洞，通報製造或維護該組件的個人或實體；若已開發修補方式，並應將相關程式碼或文件（於適當時以機器可讀格式）分享予對方。請確認紀錄涵蓋這兩個步驟，以及未隨附原始碼交付的組件。
- 公開。 CRA 並不要求公開軟體材料清單。附件 VII 第 2 點第 (b) 目 將其納入技術文件，附件 VII 第 8 點涵蓋經市場監督機關附具理由之要求而提供的情形；若您決定向使用者提供，則適用 附件 II 第 9 點。
驗證與確認測試
IEC 62443-4-1： SVV-1（9.2.1，第 35 頁）、SVV-2（9.3.1，第 35 頁）、SVV-3（9.4.1，第 36 頁）、SVV-4（9.5.1，第 36 頁）、表 3（第 37 頁）。
這類測試證據可對應 附件 I 第二部分第 (3) 款，該款要求對產品安全性施以有效且定期的測試與審查；也可對應 附件 VII 第 6 點，該點要求提供為查核符合性所執行測試的報告。其內容包括：
- 安全要求測試，包括錯誤情境與無效輸入；
- 威脅緩解測試，包括嘗試破解每一項緩解措施；
- 漏洞測試，包括濫用案例測試（abuse case testing）、攻擊面分析、已知漏洞掃描，以及就編譯型軟體進行軟體組成分析（software composition analysis）；
- 滲透測試。
檢查重點：
- 附件 VII 第 6 點的兩個面向。 附件 VII 第 6 點涵蓋產品以及漏洞處理流程的符合性。只測試產品功能的報告，未能回應後者。
- 定期測試。 第二部分的要求於整個支援期間內適用（第 13 條第 8 項；歐盟執委會常見問題集第 4.1.3 節，第 27 頁）。上市前的報告只反映單一時點。請規劃在支援期間內反覆進行測試與審查。
- 掃描的限度。 已知漏洞掃描結果乾淨，只是附件 I 第一部分第 (2) 款第 (a) 目「於市場上供應時不含已知可利用之漏洞」的一項輸入，本身並不足以證明符合。
- 測試條件與獨立性。 SVV-3 的部分活動僅於有可用工具時適用。表 3 依測試類型規定測試人員的獨立性：靜態程式碼分析與軟體組成分析無需獨立；濫用案例、攻擊面與已知漏洞測試須由獨立人員執行；SVV-1 與 SVV-2 須由獨立部門執行；滲透測試須由獨立部門或組織執行。請記錄實際適用的條件與獨立性。
缺陷管理與揭露
IEC 62443-4-1： DM-1（10.2.1，第 38 頁）、DM-2（10.3.1，第 38 頁）、DM-3（10.4.1，第 39 頁）、DM-4（10.5.1，第 40 頁）、DM-5（10.6.1，第 41 頁）、SM-11（5.13.1，第 25 頁）。
這是重疊最密集的部分。相關紀錄涵蓋：
- 接收來自測試人員、元件供應商、開發人員與使用者（包括研究人員）的問題；
- 及時調查；
- 影響評估，包括嚴重性、受影響的產品與版本，以及根本原因；
- 如何處理各項問題的決定；
- 將可通報的問題告知使用者。
這些紀錄可對應 第 13 條第 7 項與第 8 項，也可對應附件 I 第二部分第 (1)、(2) 及 (4) 至 (6) 款，以及附件 VII 第 2 點第 (b) 目的漏洞處理說明。
CRA 增加的具體要求：
-
處置決定。 DM-4 允許在說明理由與風險後延後修補，或在殘餘風險低於您所設定的可接受程度時不予修補。SM-11 要求產品在其安全相關問題獲得處理並追蹤至結案前不得發布。依 CRA，具數位元素的產品應依網路安全風險評估並於適用時，於市場上供應時不含已知可利用之漏洞（附件 I 第一部分第 (2) 款第 (a) 目）；漏洞也應就其所生風險不遲延地處理並修補（第二部分第 (2) 款）。DM-4 紀錄記載的是一項決定；該決定是否符合這些要求，須就每一項產品評估。
-
揭露。 DM-5 涵蓋您指定為可通報的問題，其註記並指出及時性取決於市場因素。第二部分第 (4) 款要求於安全更新可供取得後，分享並公開揭露已修補漏洞的相關資訊，包括漏洞之描述、如何辨識受影響產品、影響、嚴重性，以及有助於使用者修補的資訊。於有正當理由之情形，製造商認為公開所生之網路安全風險大於安全效益者，得延後公開相關資訊，惟僅得延後至使用者已有機會套用相關修補程式為止。請據此檢視您的可通報性判準。
-
政策與聯絡窗口。 第二部分第 (5) 款要求協調式漏洞揭露政策，第 (6) 款要求提供通報漏洞的聯絡地址。第 13 條第 17 項要求指定單一聯絡窗口。請逐項明確確認相關證據。
-
法定通報。 沒有任何 4-1 要求規定 CRA 的通報對象或期限，這些來自 第 14 條：
- 早期預警通報與通報自製造商知悉時起算：兩者均應不無故遲延為之，且早期預警通報至遲於 24 小時內、通報至遲於 72 小時內提出。遭積極利用之漏洞（第 14 條第 2 項第 (a) 目與第 (b) 目）及影響產品安全的重大資安事件（第 14 條第 4 項第 (a) 目與第 (b) 目）均適用這兩個階段。
- 最終報告的起算點不同。 遭積極利用之漏洞的最終報告，至遲於矯正或緩解措施可供取得後 14 日內提出（第 14 條第 2 項第 (c) 目）。重大資安事件的最終報告，於提交事件通報後一個月內提出（第 14 條第 4 項第 (c) 目）。
- 已提供之資訊。 相關資訊已提供者，無須再提出通報與最終報告。
- 通報管道。 通報透過依 第 16 條 建立的單一通報平臺，提交予經指定為協調者之 CSIRT，並同時供 ENISA 取用。
- 使用者。 知悉上述任一情形後，製造商並應告知受影響之使用者，並於適當時告知所有使用者；於必要時，包括使用者可採行的緩解與矯正措施（第 14 條第 8 項）。
- 貴公司的供應商判準並不界定這些觸發條件。
-
由哪一個會員國受理通報。 由第 14 條第 7 項決定。製造商於歐盟有主要營業所者，向該會員國經指定為協調者之 CSIRT 通報。主要營業所為就其產品網路安全相關決策主要作成地之會員國；無法認定時，為其於歐盟境內員工人數最多之營業所所在會員國。製造商於歐盟無主要營業所者，應依其所掌握之資訊，按下列固定順序認定：
- 代表該製造商就其最多數量產品行事之授權代表設立所在之會員國；
- 無此情形者，將其最多數量產品投放市場之進口商設立所在之會員國；
- 再其次，於市場上提供其最多數量產品之經銷商設立所在之會員國；
- 最後，其產品使用者人數最多之會員國。
請事先確認適用於貴公司的是哪一項規則，以及其指向哪一個會員國。
-
通報義務已經適用。 第 14 條自 2026 年 9 月 11 日起適用（第 71 條第 2 項）。第 69 條第 3 項 將其延伸適用於 2027 年 12 月 11 日前投放市場、屬適用範圍的產品。
安全更新管理
IEC 62443-4-1： SUM-1（11.2.1，第 42 頁）、SUM-2（11.3.1，第 42–43 頁）、SUM-3（11.4.1，第 43 頁）、SUM-4（11.5.1，第 43 頁）、SUM-5（11.6.1，第 44 頁）。
4-1 的更新紀錄涵蓋：
- 確認更新可處理預定的漏洞且不會造成迴歸問題，包括來自元件供應商的修補程式；
- 每一項更新的使用者文件：受影響版本、手動與自動安裝、重新開機等影響、如何確認已安裝，以及不套用的風險；
- 相依元件與作業系統更新的文件；
- 以使用者可驗證真實性的方式交付；
- 文件化的交付時程政策。
這些紀錄可對應 附件 I 第二部分第 (2)、(7) 及 (8) 款、附件 II 第 8 點第 (c) 目（如何安裝安全相關之更新），以及附件 VII 第 2 點第 (b) 目為安全散布更新所選定技術解決方案之說明。SUM-1 指出，確認程序應（should）確認更新不牴觸運作、安全或法律上的限制。這在標準中屬建議事項，與強制項目分開列出。
檢查重點：
- 時程。 SUM-5 的時程由貴公司自身政策訂定。CRA 要求就漏洞所生風險不遲延地修補（第二部分第 (2) 款），並要求可用的安全更新不遲延地散布（第二部分第 (8) 款）。
- 更新交付。 第二部分第 (2) 款要求於技術上可行時，新的安全更新與功能性更新分開提供。第二部分第 (8) 款要求安全更新免費提供並隨附建議訊息，但製造商與商業使用者就客製化產品另有約定者不在此限。IEC 62443-4-1 並未處理收費問題。
- 更新行為。 附件 I 第一部分第 (2) 款第 (c) 目要求漏洞得透過安全更新加以處理。於適用時，包括預設啟用、於適當期間內安裝的自動安全更新，並提供清楚且易於使用的退出機制、向使用者通知可用之更新，以及暫時延後更新的選項。SUM-2 記錄手動與自動安裝，但未處理上述行為，因此請直接檢查產品本身。
- 元件能力。 IEC 62443-4-2 要求嵌入式設備、主機設備與網路設備支援更新。於安裝前驗證更新真實性與完整性的需求增強，自 SL-C 2 起適用（EDR 3.10，13.5，第 66 頁；HDR 3.10，14.5，第 71–72 頁；NDR 3.10，15.7，第 78–79 頁）。4-2 並無專為軟體應用撰寫的更新支援要求：CR 3.10 指向各元件類型的專屬條款（7.12，第 52 頁），而軟體應用條款（第 12 節）並無 SAR 3.10。這並不表示軟體應用可免除更新處理。4-2 要求每一種元件類型均依 IEC 62443-4-1 的流程開發與支援（4.5 節，CCSC 4，第 27 頁），而這些流程包括上述 SUM 要求。
使用者安全指引
IEC 62443-4-1： SG-1 至 SG-7（12.2.1 至 12.8.1，第 44–47 頁）。
4-1 的使用者文件涵蓋：
- 產品的縱深防禦策略，以及預期由環境提供的措施；
- 強化指引，包括可組態值與預設值；
- 產品停止使用的指引，包括安全移除所儲存的資料；
- 安全操作指引；
- 使用者帳號與預設帳號指引；
- 追蹤手冊錯誤與遺漏的流程。
這些資料是 附件 II 所要求之使用者資訊與說明的輸入，技術文件亦應納入（附件 VII 第 1 點第 (d) 目）。尤其與下列項目相關：
- 附件 II 第 4 點：預期用途、安全環境與安全性質；
- 附件 II 第 5 點：可能導致重大網路安全風險的情況；
- 附件 II 第 8 點第 (a) 目：確保安全使用的措施；
- 附件 II 第 8 點第 (d) 目：安全除役，包括安全移除使用者資料。
檢查重點：
- 附件 II 的其他項目。 附件 II 也要求：
- 製造商名稱與聯絡資訊（第 1 點）；
- 漏洞通報的單一聯絡窗口，以及可查得協調式漏洞揭露政策之處（第 2 點）；
- 產品的唯一識別資訊（第 3 點）；
- 於適用時，可取得歐盟符合性聲明之網址（第 6 點）；
- 技術安全支援之類型及支援期間結束日期（第 7 點）；
- 如何關閉自動安全更新（第 8 點第 (e) 目）；
- 提供整合者的資訊（第 8 點第 (f) 目）。
- 文件並不等於能力。 描述一項能力，並不能證明該能力存在。
流程紀錄
IEC 62443-4-1： SM-1（5.2.1，第 21 頁）、SM-12（5.14.1，第 25 頁）。
文件化且落實的開發、維護與支援流程，以及顯示所有適用安全流程均於發布前完成的紀錄，可對應 附件 VII 第 2 點 的流程說明，以及附件 VII 第 6 點的測試報告。
檢查重點：
- 產品專屬的文件。 技術文件係針對特定產品。它必須包含適用的附件 VII 要素，於投放市場前製作，並至少於支援期間內視情況持續更新（第 31 條）。附件 VII 規定最低內容，並未規定文件結構。一種可行做法（CRA 並未規定）是建立索引，將每一項適用的附件 VII 要素對應到所涉產品版本的證據。
- 與符合性聲明分開。 流程紀錄並不是歐盟符合性聲明；後者依 附件 V 的範本製作（第 28 條第 2 項）。
IEC 62443-4-2 證據可提供的支持
下表為精選的證據對應，並非任一文件的完整對照。「等級」欄列出基本要求與各項需求增強所適用的安全能力等級。
| IEC 62443-4-2 要求 | 等級 | 對應的 CRA 條文 | 檢查重點 |
|---|---|---|---|
| CR 3.4，軟體與資訊完整性（software and information integrity）（7.6，第 48 頁）：對軟體、組態及其他資訊執行或支援完整性檢查，並記錄與回報結果，或整合至可執行此類檢查的系統 | 基本要求 SL-C 1–4；真實性（RE 1）SL-C 2–4；完整性遭破壞時自動通知（RE 2）SL-C 3–4 | 附件 I 第一部分第 (2) 款第 (f) 目：資料、指令、程式與組態之完整性，並就毀損情形提出報告 | 檢查是在產品內執行，還是仰賴周邊系統；是否涵蓋產品處理的所有資料與指令 |
| CR 4.1，資訊機密性（information confidentiality）（8.3，第 52–53 頁）：保護支援明確讀取授權之靜態資訊；支援 IEC 62443-3-3 SR 4.1 所定的傳輸中資訊保護 | SL-C 1–4，無需求增強 | 附件 I 第一部分第 (2) 款第 (e) 目：所儲存、傳輸或以其他方式處理之資料（不論是否為個人資料）之機密性 | 明確讀取授權範圍以外的資料；傳輸中的部分仰賴系統及 3-3，本頁未對照 |
| CR 4.2，資訊留存（information persistence）（8.4，第 53–54 頁）：元件停止服務或除役時，清除支援明確讀取授權之資訊 | SL-C 1 未選用；基本要求 SL-C 2；共用記憶體與清除驗證之需求增強 SL-C 3–4 | 附件 I 第一部分第 (2) 款第 (m) 目：安全且簡便地永久移除所有資料與設定，並於資料可移轉時以安全方式移轉；附件 II 第 8 點第 (d) 目 | 以 SL-C 1 評估的元件於此並無要求；CRA 條文涵蓋所有資料與設定、移除的簡便性以及移轉 |
| CR 7.1，阻斷服務防護（denial of service protection）（11.3，第 59 頁）：於阻斷服務事件導致降級模式運作時維持必要功能 | 基本要求 SL-C 1–4；洪泛緩解（RE 1）SL-C 2–4 | 附件 I 第一部分第 (2) 款第 (h) 目：必要與基本功能之可用性，包括於事件發生後 | 基本功能與事件後的行為；第 (i) 目（對其他裝置或網路的影響）為另一項要求 |
| CR 7.6，網路與安全組態設定（network and security configuration settings）（11.8，第 61 頁）：可依建議設定組態，並提供存取目前部署設定的介面 | 基本要求 SL-C 1–4；機器可讀的設定報告（RE 1）SL-C 3–4 | 附件 I 第一部分第 (2) 款第 (b) 目：預設安全之組態，並提供將產品重設回原始狀態之可能 | 預設採用建議設定在標準中屬指引（should）；請檢查出貨預設值、重設行為，以及與商業使用者就客製化產品之約定 |
| CR 7.7，最小功能（least functionality）（11.9，第 61 頁）：限制不必要之功能、連接埠、協定與服務的能力 | SL-C 1–4，無需求增強 | 附件 I 第一部分第 (2) 款第 (j) 目：限縮攻擊面，包括外部介面 | 預設停用基準以外的功能在標準中屬指引（should）；請檢查產品出貨時的狀態 |
| EDR 3.10、HDR 3.10、NDR 3.10，更新支援（support for updates）（13.5，第 66 頁；14.5，第 71–72 頁；15.7，第 78–79 頁） | 基本要求 SL-C 1–4；更新真實性與完整性（RE 1）SL-C 2–4 | 附件 I 第一部分第 (2) 款第 (c) 目；第二部分第 (7) 款 | 自動更新、通知、延後及散布機制須另行檢查；軟體應用並無元件專屬的更新要求，但仍透過 CCSC 4（4.5 節，第 27 頁）適用 4-1 的更新管理 |
4-2 評估涵蓋的是單一元件。CRA 產品可能結合多個元件、軟體與遠端資料處理解決方案（第 3 條第 (1) 款）。歐盟執委會的指引就協調標準提出類似觀點：產品的範圍可能大於標準的範圍，製造商應檢查該標準是否涵蓋產品的所有風險（C(2026) 5252，第 150 段，第 52 頁）。
評估既有資料
以下範例為假設情境，用以說明決定能否重複使用的關鍵問題。它不是客戶案例，不是稽核結果，也不代表任何公司的實際紀錄內容。
一家製造商向歐盟的機械製造商與工廠營運者銷售可程式邏輯控制器（PLC）。執行韌體 3.2 版的該控制器，已以嵌入式設備身分依 IEC 62443-4-2 評估，各項基礎要求均達 SL-C 2。該製造商的開發流程已依 IEC 62443-4-1 評估，其工程軟體另行銷售。就本例而言，假設製造商自行進行的分類審查認定該控制器不具備附件 III 或附件 IV 所列類別的核心功能。此結論屬於本例的設定，並非對控制器的一般性判斷。
| 資料 | 對應條文 | 決定能否重複使用的問題 | 可能需補充的工作 |
|---|---|---|---|
| 4-2 評估報告，搭載韌體 3.2 的控制器 | 上表所列的附件 I 第一部分第 (2) 款各目；附件 VII 第 6 點 | 此版本測試了哪些要求？假設了哪些控制器外部的補償措施（4.3 節）？ | 對照第一部分第 (2) 款的每一目，包括上表未列者；將假設的外部補償措施作為網路安全風險評估的輸入 |
| 產品威脅模型 | 第 13 條第 2 項與第 3 項；附件 VII 第 3 點 | 是否記錄可合理預見之使用方式與預期使用期間，並涵蓋整個產品（包括任何遠端資料處理）？ | 補充第一部分第 (2) 款逐項的適用性說明；不適用者附具理由（第 13 條第 4 項） |
| 缺陷管理紀錄（DM-1 至 DM-5） | 第 13 條第 7 項；附件 I 第二部分第 (1)、(2) 及 (4) 至 (6) 款 | 處置紀錄是否顯示不遲延地修補，以及於更新可取得後公開揭露已修補漏洞？ | 建立第 14 條通報與第 14 條第 8 項使用者告知流程；增加第 13 條第 6 項的上游通報途徑 |
| 修補程式管理文件（SUM-1 至 SUM-5） | 附件 I 第二部分第 (7) 與 (8) 款；附件 II 第 8 點第 (c) 目 | 安全更新是否不遲延、免費並隨附建議訊息交付？於技術上可行時是否與功能性更新分開？ | 訂定支援期間及其結束日期；依第 13 條第 9 項使每一項安全更新維持可取得 |
另行銷售的工程軟體本身即為產品（第 3 條第 (1) 款包括分別投放市場的軟體），需要另行審查。以行動表彙整結果是可行的做法：資料、CRA 條文、重複使用的決定、缺漏工作、負責人。這些欄位屬實作建議，CRA 並未規定。
仍需確認或完成的網路韌性法案（CRA）工作
以下各點是 CRA 評估必須涵蓋之處，不論您的 IEC 62443 紀錄已包含哪些內容。其中數項，您的紀錄可能確有工程與測試證據；確認這一點正是評估的目的。
- 範圍與角色。 涉及哪些產品與版本，以及您是否為製造商（第 2 條與第 3 條）。
- 分類與符合性評估途徑。 一般產品，或重要類別 I、重要類別 II、關鍵類別，以及隨之適用的程序（第 7 條、第 8 條與第 32 條，以及附件 III 與附件 IV）。
- 產品要求本身。 依網路安全風險評估，逐項檢視 附件 I 第一部分第 (2) 款 的每一目，並以各目全文及其限定條件為依據。
- 漏洞處理。 附件 I 第二部分的每一款，於支援期間內適用。
- 通報。 第 14 條與第 16 條，已經適用。
- 支援期間與更新可取得性。 第 13 條第 8 項 要求支援期間至少 5 年，但產品預期使用期間較短者不在此限。支援期間應反映預期使用期間，決定時所考量的資訊應納入技術文件（附件 VII 第 4 點）。第 13 條第 19 項要求於購買時清楚載明支援期間結束日期。依第 13 條第 9 項，於支援期間內提供的每一項安全更新，於發布後至少維持可取得 10 年，或維持至支援期間結束為止，以較長者為準。
- 使用者資訊。 附件 II 全部內容。
- 符合性證據。 技術文件、符合性評估程序、歐盟符合性聲明與 CE 標誌（第 13 條第 12 項與第 13 項、第 28 條、第 30 條、第 31 條與第 32 條，以及附件 V 與附件 VII）。第 13 條第 13 項要求於產品投放市場後至少 10 年，或於支援期間內（以較長者為準），保存技術文件與歐盟符合性聲明，以供市場監督機關查閱。
可行的推動順序
現在就開始，並與其他工作同步進行： 建立第 14 條的通報能力。該義務已經適用，無法等待以下步驟完成。具體而言，包括指定有權提交通報的人員、於單一通報平臺完成註冊，並確認貴公司依第 14 條第 7 項所適用的會員國。
接著：
- 確定範圍：產品、法律實體，以及將評估的版本。
- 進行產品分類並決定符合性評估途徑。
- 蒐集您打算重複使用的每一項 IEC 62443 評估的範圍紀錄：部分、版本、驗證機制、元件、版本、類型、等級及假設的外部補償措施。
- 依網路安全風險評估，逐項進行附件 I 第一部分第 (2) 款的適用性檢視。
- 依上述各組對照既有證據，並將每一項標示為可重複使用、需補充後可重複使用，或不適用。
- 補足適用性檢視所發現的缺漏。
- 依附件 VII 彙整技術文件並持續更新。