ENISA 於 2026 年 7 月 發布 《SME 網路韌性成熟度評估模型》，透過五大面向、25 題自評與三種成熟度等級，協助企業盤點 EU CRA 產品網路安全準備度與改善優先順序。
企業開始準備 EU CRA 時，經常遇到兩個問題：
我們目前到底做到什麼程度？
哪些事情應該先處理？
為協助中小企業，ENISA 於 2026 年 7 月 發布《SME 網路韌性成熟度評估模型》，提供一套簡單的評估方法，協助企業了解目前的成熟度、找出不足之處，進一步規劃改善順序。
下載 EU CRA SME 網路韌性成熟評鑑模型說明文件
下載 EU CRA 成熟模型工具(Excel)
這份成熟度模型是什麼？
簡單來說，就是一套協助企業進行 EU CRA 準備度盤點的自評工具。
這套工具，將EU CRA 相關的產品網路安全要求整理成五大面向，共 25 道自評問題，用來協助企業：
- 找出目前產品網路安全流程的缺口
- 根據風險決定改善優先順序
- 有系統地準備 EU CRA
- 建立後續改善路線圖
- 定期重新評估並追蹤進度
這套模型主要評估企業對於產品的資安管理能力。
因此，它並不是一般的企業資訊安全成熟度評估，也不是用來全面檢查 ISO/IEC 27001 所關注的組織資訊安全管理制度。評估重點是：企業能否在產品的整個生命週期中，持續管理產品相關的網路安全風險。
適用對象：以中小企業為主，但不限於中小企業
這套模型主要提供給從事具數位元素之產品的：製造商、進口商與經銷商。
不過，這套模型並不限於中小企業。其他規模的企業，以及參與產品生命週期的系統整合商或服務提供者，也可以將其作為產品資安自評及改善的參考工具。
評估進行的步驟及注意事項
《SME 網路韌性成熟度評估模型》是透過五大面向 + 各項評估問題，協助企業檢視目前的產品資安政策、流程與實際作法。
評估前準備：下載官方工具
開始評估前，可先從 ENISA 官方網站下載 EU CRA 成熟模型工具(Excel)；
使用官方工具的好處，是填完每一道問題後，Excel 會自動計算各面向及整體成熟度，不需要自行另外整理分數。
筆者建議：開始評估前，先完成基本的產品範圍判斷。
1. 哪些產品屬於 EU CRA 所稱的「具數位元素之產品」？
2. 屬於一般產品、重要產品或關鍵產品？
3. 該產品應採用哪一種符合性評估程序？
不同產品類別，適用不同的法規要求與符合性評估方式。
這套成熟度模型不會因為產品屬於一般、重要或關鍵產品，而自動調整題目或評分標準。另外，如果公司有多種差異很大的產品，也不建議全部混在一起評估。可先選定特定產品、產品系列或事業單位，避免評估結果過於模糊，無法反映實際情況。
步驟一：依實際執行情形及客觀證據評分
《SME 網路韌性成熟度評估模型》共分為五大面向，每個面向包含五道問題，合計 25 道自評問題。
每一道問題，依造 「成熟等級」： Level 1 至 Level 5 ，進行評分。
不同問題的詳細成熟度定義會稍有不同，以下先用較簡單的方式說明五個等級的概念；實際評分時，仍應參考工具中各道問題所提供的詳細定義。
| 等級 | 概略描述 |
|---|---|
| 1 | 尚未建立，或僅有零星、臨時性的作法 |
| 2 | 主要採取非正式或被動處理，且依賴個人經驗 |
| 3 | 已建立相關文件或基本流程，但執行仍不一致 |
| 4 | 流程已正式建立，並能夠持續且一致地執行 |
| 5 | 流程受到監控、定期審查，並持續改善 |
筆者建議：評分時，不要只看「有沒有文件」
進行自我評估時，不要只確認是否有程序書、政策或表單，還要進一步確認：
* 是否有明確的負責人
* 是否真的有執行
* 是否在不同產品或團隊中一致落實
* 是否保留執行紀錄
* 是否定期檢查並改善
舉個例子來說：公司雖然已經建立漏洞管理程序，但實際上只有少數工程師知道，不同產品團隊的做法也不一致，便不適合直接給予較高的成熟度分數。
步驟二：彙整評估結果
完成五大面向、共 25 道自評問題後，應先計算每個面向的平均分數，再計算五個面向的平均分數。
如果使用 ENISA 提供的官方 Excel 工具，系統會自動完成計算，並呈現各面向與整體成熟度結果。
最終的「整體成熟度」可分為三種：
| 整體分數 | 成熟度 | 基本狀態 |
|---|---|---|
| 1.0–2.5 | 基礎 | 多數活動尚未建立、採臨時處理或依賴個人 |
| 2.6–3.9 | 中階 | 已建立部分文件與流程，但尚未一致落實 |
| 4.0–5.0 | 進階 | 流程已正式建立、一致執行並持續改善 |
值得注意：成熟等級高，不代表已經符合 EU CRA!!!
ENISA 特別提醒，使用此工具進行評估，儘管成熟等級達到「進階」，也不等於已經完成 EU CRA 合規。
成熟度評估結果 ≠ EU CRA 合規
這個工具的評估結果，無法取代正式的產品符合性評估、網路安全風險評估、技術文件、EU 符合性聲明、漏洞與事故通報義務、其他 EU CRA 法定要求。
步驟三：根據結果規劃改善行動
評估完成後，最後是將評估結果轉換成具體的改善計畫。
ENISA 官方工具的最後一個工作表 “Checklist”，其用途是在完成自評後，規劃後續改善路線圖。
建議使用方式如下：
1. 從目前的成熟度開始
找到工作表”Pivots”，找到各面向及整體的成熟度。
2. 優先處理分數最低的面向
在工作表”Pivots”中，優先針對分數較低的面向進行改善（尤其是低於 2.5 分的面向）。
例如：請參考下圖，整體成熟度雖然是3（屬於「中階」），但「治理與文件管理」面向仍低於 2.5 分，便可先參考基礎成熟度中與漏洞管理相關的改善項目。
3. 找到高風險的子項目，挑選適當的改善行動
在工作表”Pivots”中，面向的細部問題，找到差距比較大的，對應在工作表”Checklist”中，找到對應的改善行動。
筆者備註：不建議一次將 Checklist 中的所有項目都納入改善計畫；不建議一次將 Checklist 中的所有項目都納入改善計畫。
4. 定期重新評估及追蹤改善結果
追蹤改善行動的執行進度，並於適當時機再重新評估成熟度。
筆者備註：例如：每半年一次，或在產品、組織及流程發生重大變化後。
ENISA 評估的五大面向
一、治理與文件管理
第一個面向，主要目的是確認企業是否已建立基本的產品網路安全治理架構。
主要評估內容包括：
| Ref. | 評估問題 |
|---|---|
| 1.1 | 是否已建立並核准產品資安政策？ Do you have written and approved product security policies? |
| 1.2 | 是否已明確定義產品資安活動的角色與責任？ (例如: 產品開發、漏洞管理及安全更新、等工作的負責人) Are roles and responsibilities clearly defined for product security activities (e.g. development, vulnerability management, updates)? |
| 1.3 | 是否維護產品層級的技術文件？ (文件內容應涵蓋已實施的安全功能、網路安全風險評估、設計決策及更新程序) Do you maintain product-level technical documentation describing implemented security features, risk assessments, design decisions and update procedures? |
| 1.4 | 是否建立定期審查產品資安及相關文件品質的流程？ Is there a process to regularly review product security and the quality of related documentation? |
| 1.5 | 是否了解 EU CRA 相關主管機關與法規程序？ (包括負責執行 EU CRA 的市場監督機關、產品適用的符合性評估程序，以及必要時如何與相關主管機關聯繫) Are you aware of the Market Surveillance Authority responsible for enforcing the CRA, the conformity assessment procedure applicable to your products, and how to interact with relevant authorities if needed? |
筆者備註：
問題 1.1 所提及的「產品資安政策」，不應只理解為單一份政策文件。
通常還需要依政策內容，進一步建立相對應的二、三、四階文件，例如：管理程序、作業指導書、表單、範本及執行紀錄，才能將政策要求真正落實到產品開發、漏洞管理、安全更新及後續維護等活動中。
坊間有一種說法認為：
「準備 EU CRA 不需要建立政策或流程」
「導入 EU CRA ，只需要買工具就好」
這樣的理解並不正確。
關於工具與正式流程之間的關係，可進一步參考筆者於 LinkedIn 發布的：
【EU CRA 問與答】#018：公司已經導入漏洞掃描工具，沒有正式流程可以嗎？
筆者備註：
問題 1.5 雖然只簡單提到企業應「了解」相關主管機關與法規程序，看起來著墨不多，但實際上涉及 EU CRA 下漏洞與資安事故的通報義務。
企業除了要知道哪些情況可能屬於主動利用漏洞（AE）或嚴重資安事故（CI），以及應向哪些單位通報之外，還需要建立相對應的內部處理流程
換句話說，問題 1.5 所提及的「了解」，不能只停留在知道主管機關名稱或閱讀法規條文，而應進一步落實為明確的責任分工、判斷標準、處理流程及演練機制。
二、風險管理、安全設計與安全預設
第二個面向，企業是否從產品設計與開發初期，就開始管理網路安全風險，並將風險評估結果實際帶入產品設計、組態設定、元件選擇、測試及後續維護。
評估問題包括：
| Ref. | 評估問題 |
|---|---|
| 2.1 | 是否執行產品網路安全風險評估，並將結果用於產品決策？ (風險評估的結果將用於，產品設計、開發、組態設定及元件管理、等…活動) Do you perform cybersecurity risk assessments and use the results to guide product design, development, configuration and component management decisions? |
| 2.2 | 產品是否從開發初期即導入「安全設計」？ Are products designed using security-by-design principles from the outset? |
| 2.3 | 產品交付時是否採用「安全預設」 的組態與設定？ Are products delivered with secure-by-default configurations and settings? |
| 2.4 | 產品發布或更新前，是否執行安全檢查及測試？ (同時也應評估自動化工具被導入及實際使用的程度) Do you perform security checks and testing before releasing or updating a product, and to what extent are automated tools used? |
| 2.5 | 當風險改變或出現新威脅時，是否重新審查並更新相關內容？ (包括風險評估、產品組態及第三方元件) When risks change or new threats emerge, are risk assessments, configurations and third-party components reviewed and updated? |
筆者備註：
問題 2.1 所提及的網路安全風險評估，是針對特定產品及其生命週期進行的評估，與一般企業導入 ISO/IEC 27001 時，以組織資訊資產及營運風險為主的風險評鑑，關注重點並不完全相同。
此外，這項評估也不能只等同於一般的「威脅建模」。威脅建模可以作為辨識威脅與攻擊情境的方法之一，但完整的產品風險評估，還應包含風險判斷、風險處理，以及後續的監控與審查。
實務上，可參考目前仍處於草案階段的 prEN 40000-1-2：Principles for cyber resilience。該草案涵蓋產品情境、資產與資安目標、威脅辨識、風險估算與評價、風險處理，以及後續監控與審查等內容。（由於目前仍是草案，文章中建議使用 prEN 40000-1-2，而不是直接寫成已正式發布的 EN 40000-1-2）
筆者備註：
問題 2.2 的重點，在於產品資安要求應從開發初期就導入，而不是等到產品快完成、準備上市或接受查驗時，才回頭補做相關文件。
筆者在拜訪企業時，經常被問：「以前沒有做的文件，現在可不可以回補？」
這種作法風險很高，也不建議將其視為正常的 EU CRA 準備方式。
三、漏洞與修補管理
第三個面向，主要是確認企業是否具備接收、分析、追蹤及修補產品漏洞的完整能力。
評估問題包括：
| Ref. | 評估問題 |
|---|---|
| 3.1 | 是否建立漏洞接收與追蹤流程？ (能夠接收、確認、記錄及追蹤由客戶、資安研究人員或內部人員所回報的漏洞) Do you have a process to receive, acknowledge, record and track vulnerabilities reported by customers, researchers or internal staff? |
| 3.2 | 是否建立安全更新管理流程？ (包括針對仍在支援期間內的產品，建立安全更新的開發、測試、交付及客戶溝通程序) Do you have a defined process for creating, testing, delivering and communicating security updates to customers for supported products? |
| 3.3 | 是否維護並實際使用 SBOM？ (將 SBOM 用於漏洞識別、第三方元件及相依性管理) Do you maintain and use a SBOM to support vulnerability and dependency management? |
| 3.4 | 是否根據風險與潛在影響，決定漏洞處理及安全更新的優先順序？ Are vulnerabilities and updates prioritized based on risk, potential impact? |
| 3.5 | 是否驗證安全更新確實解決已回報的漏洞，並保留驗證證據？ Do you verify that security updates effectively resolve reported vulnerabilities and maintain evidence of this verification? |
筆者備註：
問題 3.3 所提及的概念非常重要。
EU CRA 並不只要求企業「建立 SBOM」，更重要的是，能否實際運用 SBOM，支援漏洞監控、第三方元件管理及相依性分析。
例如：當外部發布新的漏洞資訊時，企業應能透過 SBOM 進一步確認：
* 產品是否使用受影響的元件；
* 哪些產品、型號或版本可能受到影響；
* 該元件與其他元件之間是否存在相依關係；
* 是否需要進一步評估、修補或更新。
因此，SBOM 不只是產品開發完成後產出的一份文件，而應同時被運用在兩個階段：
* 產品開發過程中：協助管理第三方元件、版本及相依性，並支援元件選擇與風險評估。
* 產品上市後：持續比對漏洞情資，確認受影響的產品與版本，並支援後續的處理及更新。
四、產品生命週期管理
第四個面向，主要是確認企業是否在產品上市及投入使用後，持續管理產品資安風險。
評估問題包括：
| Ref. | 評估問題 |
|---|---|
| 4.1 | 是否建立產品營運階段的資安管理方式？ Is there a defined approach to managing product security during the operational phase? |
| 4.2 | 是否主動管理產品生命週期？ (包括：定義產品支援期間、更新責任、產品EOL，以及與客戶的溝通) Is the product lifecycle management actively managed, including defined support periods, update responsibilities, end-of-life arrangements and communication with customers? |
| 4.3 | 是否依經驗來持續改善產品？ (經驗包括：產品實際運作、資安事件檢討結果及客戶意見) Is experience from product operation, post-incident reviews and customer input used to improve products over time? |
| 4.4 | 是否建立結構化且經測試的方式，來處理產品資安問題？ Is there a structured and tested way to address identified product security issues? |
| 4.5 | 產品在營運期間是否有持續監控？ (監控是為了識別新的產品資安風險、漏洞及新興威脅) Are products monitored during operation to identify security risks, vulnerabilities and emerging threats? |
五、意識、能力與技能
第五個面向，主要是確認企業是否具備設計、開發及維護安全產品所需的人員能力。
評估問題包括：
| Ref. | 評估問題 |
|---|---|
| 5.1 | 企業是否具備足夠的產品資安專業能力？ (專業能力包含：安全地設計、開發及維護產品) (另外，當內部資源不足時，是否適當使用外部專業資源) Are sufficient skills available to design, develop and maintain products in a secure way, including through external expertise where internal capacity is limited? |
| 5.2 | 相關人員是否接受與其職務相符的資安訓練？ (訓練內容包括：產品風險管理、漏洞管理及「安全設計」) Do relevant staff receive appropriate training on cybersecurity practices relevant to their roles, including product risk management, vulnerability management, and security-by-design? |
| 5.3 | 企業是否建立資安文化？ (包括鼓勵人員主動回報問題，以及提升對產品資安風險的認知) Does the organisation promote a culture of responsible product development, open reporting and awareness of product risks? |
| 5.4 | 是否持續關注外部產品資安資訊？ (例如：漏洞公告、資安警示及其他產品安全資訊) Do you follow relevant external product security information (e.g. advisories, alerts)? |
| 5.5 | 是否評估並驗證團隊具備維護安全產品所需的技能與能力？ (包括風險評估、產品組態及第三方元件) Do you assess and validate that your team has the required skills and competence to maintain secure products? |
筆者備註：
問題 5.1 與 5.2 所提及的資安專業能力及資安訓練，不只是安排一般性的資安宣導，而是要確認相關人員是否具備其職務所需要的產品資安知識與實務能力。
不同職務所需具備的能力也不盡相同，例如產品管理、研發、測試、漏洞管理、法規及客戶支援人員，應依其角色接受相對應的訓練。
關於企業面對 EU CRA 時，人員應具備哪些資安能力，可進一步參考筆者於 LinkedIn 發布的：
【EU CRA 問與答】 #024 面對 EU CRA，公司人員需要具備哪些資安能力？
筆者備註：
問題 5.3 所提及的「資安文化」，不只是員工是否知道資安的重要性，也可以進一步反映在企業的管理制度中。
舉個例子：企業可將產品網路安全或資安要求，納入政策文件及年度目標，並進一步轉化為部門或相關人員的 KPI，再透過實際執行紀錄與監控結果，確認相關目標是否真正落實。
筆者備註：
問題 5.5 所提及的「評估並驗證團隊具備維護安全產品所需的技能與能力」，重點不只是確認人員曾經參加課程，而是要能提出相對應的評估與驗證證據。
因此，單純提供課程參與證明或出席紀錄，通常只能證明人員曾經接受訓練，未必能充分證明其已具備所需能力。較具體的能力證據可以包括：課程考試或測驗結果、專業能力證書、等。
進一步討論：國內證書能否作為 EU CRA 的能力證據？
概念上，EU CRA 並沒有規定只能使用特定國家或特定機構所核發的證書。因此，國內訓練機構或專業單位核發的證書，仍可作為能力證據之一。
不過，當證書的適用性或可信度受到挑戰時，企業可能需要進一步說明：
* 課程內容是否與人員職務及 EU CRA 相關工作相符
* 使用的教材及參考標準
* 授課單位及授課講師的專業背景
* 考試或能力評估的方式
* 通過標準及評分紀錄
* 證書的有效期限或能力維持方式
若相關資料只有中文，在提供給歐盟客戶、符合性評估機構或其他外部單位查驗時，也可能需要準備英文版本或翻譯資料。
因此，國內證書並不是不能使用，而是要能說明這張證書實際證明了哪些能力，以及這些能力如何對應人員的工作職責。
若希望降低後續說明與舉證的負擔，可以優先考慮具國際知名度、課程內容與評量方式較透明的訓練或認證。不過，國際證書本身也不代表一定足夠，仍應確認其內容是否真正符合人員在 EU CRA 下所需要執行的工作。
簡單總結
ENISA 的《SME 網路韌性成熟度評估模型》，透過五大面向、25 道自評問題，協助企業了解目前的產品資安成熟度，並找出需要優先改善的缺口。
搭配官方 Excel 工具，企業可以自動彙整各面向及整體分數，再透過 Checklist 將評估結果轉換成具體的改善行動。
需要特別注意的是，成熟度高不代表已經符合 EU CRA。這套模型比較適合用來盤點現況、建立改善路線圖及追蹤進度，不能取代正式的風險評估、技術文件、符合性評估及其他法定義務。
對企業而言，最重要的不是追求高分，而是依照實際執行情形誠實評估，先改善低分及高風險項目，再定期重新檢查與持續提升。
