2026年6月6日 星期六

歐盟2022/2557關鍵實體韌性指令初探(五之一)


適合出口型產業界、韌性能力、驗證業、實驗室、網路安全及工程師、企業管理者或法規政策研究人員,具備大學教育背景但對歐盟法規基本概念的亞洲讀者閱讀。

此文僅供個人參考與資訊喚回,尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊,經由整合篩選與文字調整。法規內容可能隨時間修訂,具體符合決策宜諮詢歐盟專業法律、顧問或驗證機構。文中提及之市場資料係基於公開報告及邏輯估算,實際數值可能隨時變動。參考法規資訊截至20263月,後續修訂請查閱歐盟CRA官方網站和EUR-Lex資料庫。

© All Rights reserved 版權聲明。CC BY-SA 40

目錄

標題

1

執行摘要

2

歐盟立法策略與法律體系

3

指令的範圍

4

關鍵詞彙與專有名詞定義(含範例)

5

關鍵條文詳解(§4-§9

6

實施規則、時程與排除情形

7

歐盟韌性立法生態與相關法規

8

技術規格、稽核與標準(ISO 22301等)

9

決策者指引、保障機制與第三方稽核

10

經濟影響預測、勞動市場趨勢(至2031

11

人員資格與經驗要求

12

陷阱、新興風險與主要議題

13

罰則與真實案例討論

14

改進建議與其他重要主題

15

國際比較(美國/瑞士/日本/英國/中國)

16

給決策者的實務操作指南

17

結論

18

文獻參考

1. 執行官摘要 (Executive Summary)

歐盟指令(EU) 2022/2557(關鍵實體韌性,Critical Entities Resilience Directive),以下簡稱CER指令,是歐盟在COVID-19後疫情時代與地緣政治動盪(如俄烏戰爭)後,為了強化其「生存韌性」而推出的核心法規。於2022年12月14日在歐盟公報頒布,2023年1月3日起實施。

對於亞洲地區的從業者(例如:跨國企業經營者或法務專員)而言,最核心的理解點在於:CER指令並非單純的「生存韌性安全管理準則」,而是一種「國家生存韌性安全等級」的監督架構。它旨在確保當自然災害、恐怖攻擊或網路攻擊發生時,歐盟內維持社會運作的「關鍵實體」(Critical Entities)能夠快速復原,避免連鎖效應(Cascading Effect)導致整個歐盟經濟架構崩潰。該指令類似中國的《關鍵信息基礎設施安全保護條例》或日本的《重要基礎設施保護法》,但歐盟強調的是國家與社會的「韌性」(resilience)而非純單純基於被動式防禦心態。此文係初步探討該指令的結構、涵義及作用,以供亞洲地區企業參考借鏡,未來可能出現該等狀況時,及時做出相應措施。
 

2.歐盟立法策略 (European Legislation Strategy) 與法律體系

2.1 為什麼現在推出 CER?

在 2022 年之前,歐盟的關鍵基礎設施保護(CIP)主要依賴各國的自願性協議或分散的國家法律。然而,三波衝擊讓歐盟意識到「碎片化」的危險,歐盟曾經在2008年的舊指令(Council Directive 2008/114/EC)已不足以應付當前複合型風險:
  1. COVID-19 疫情:揭露了國際性、區域性到國家級醫療供應鏈的脆弱性。
  2. 地緣政治衝突:源於俄烏戰爭(2022)曝露的能源/交通脆弱性,能源供應(天然氣)成為政治武器,顯示出對單一來源依賴的危險。
  3. 數位化轉型:實體基礎設施(如電力網路)與網路資訊安全系統(Cyber systems)高度融合,潛在的「混合威脅」(hybrid threats,如網路+物理攻擊)視為首要風險,單一點的失效會導致大面積經濟實體崩潰。

2.2 立法策略:從「保護」轉向「韌性」(From Protection to Resilience)
歐盟的策略發生了根本性轉變:

  • 傳統保護 (Protection): 建立高牆,防止災害進入(例如:加強圍牆、安裝防火牆)。
  • 韌性 (Resilience): 承認「災害終將發生」,重點在於發生後如何「快速恢復」(Recover) 並「適應」(Adapt)。

2.3 「指令」(Directive) 與 「條例」(Regulation) 的區別
這是亞洲讀者最容易混淆的地方。
  • CER 是「指令 (Directive)」:強調「最低和諧標準」(minimum harmonisation),並不直接對企業生效,且允許會員國添加該國特殊條款。且歐盟各成員國(如德國、法國等27個成員國)須在限定時間內,將其內容「轉譯」成各成員國的國家法律。
  • 策略核心:基於歐盟的立場,維持核心策略的一致性,如:風險導向(risk-based)、比例原則(proportionality)、公私合作(public-private partnership),兼顧各國發揮特長。
  • 實務影響:這意味著雖然歐盟法規的大架構為一致的文本,但考慮成員國的需求與法律傳統,呈現在指令的執行階段或實施細節上,德國的 CER 法規可能與法國的版本略有不同。 

3. CER 指令的範圍

根據 CER 指令第 2 條,「關鍵實體」公共或私人實體由各成員國加以評鑑後正式認定。成員國必須在 2026 年 7 月 17 日前,根據以下三項累計準則來識別其領土內的關鍵實體:
  • 該實體提供一項或多項關鍵服務(指對維持重要社會功能、經濟活動、公共健康與安全或環境至關重要的服務)。
  • 該實體在該成員國領土內運作,且其關鍵基礎設施位於該國領土內。
  • 一旦發生事故,將對上述關鍵服務的提供產生重大干擾效應。在判斷「重大干擾」時,會考量受影響的用戶數量、干擾持續時間、受影響的地理區域以及該實體在市場上的重要性等因素。
此外,若一個關鍵實體向六個或更多成員國提供相同或類似的關鍵服務,則會被定義為「具有特殊歐洲意義的關鍵實體」(Critical entities of particular European significance),並受額外的監督與諮詢機制規範。
CER 指令的涵蓋適用範圍極廣,不再侷限於傳統的「交通、水電、能源」。它涵蓋以下關鍵部門:
  1. 能源:包括電力(如發電、配電、輸電及市場營運)、區域供熱與供冷、原油(管道與設施營運)、天然氣及氫氣的生產、存儲、輸送等實體。
  2. 運輸:涵蓋航空(航空運送人、機場管理、空中交通管制)、鐵路、水路(客運、貨運、港口管理)及道路運輸,亦包括公共運輸。
  3. 銀行與金融:主要是指歐盟法律定義下的信用機構(Credit institutions,包括支付系統、清算中心、核心銀行。
  4. 健康與醫療:包括醫療服務提供者、歐盟參考實驗室、藥品研發機構、藥品與關鍵醫療器械製造商及藥品分銷授權持有人,如:醫院、藥品生產與分銷、公共衛生監控。
  5. 飲用水與廢水:飲用及生活用水的供水系統,與負責收集、處置或處理城市廢水、生活廢水或工業廢水的企業。
  6. 數位基礎設施(Digital infrastructure):包括互聯網交換點(IXP)提供商、DNS 服務提供商、頂級域名(TLD)註冊機構、雲計算服務提供商、數據中心服務提供商、內容分發網絡(CDN)、信託服務提供商及公共電子通信網絡/服務提供商,服務事項包括雲端服務、資料中心、骨幹網路等。
  7. 公共管理(Public administration):指由成員國根據國家法律定義的中央政府公共管理機構(不包括國防、國家安全、公共安全或執法等領域),包括政府核心運作、緊急應變系統。
  8. 太空(Space):由成員國或私人方擁有、管理和營運,用於支持提供太空服務的地面基礎設施營運商,包括衛星導航、太空通訊。
  9. 食品生產、加工與分銷(Production, processing and distribution of food): 僅限於專門從事物流、批發分銷以及具有顯著市場份額的大規模工業生產與加工的食品企業,包括關鍵食品供應鏈與儲存。
CER排除軍事/國防體系(§3(2)),由國防部負責相關事宜。
【重要提醒】: 即使您是一家非歐盟公司,但如果您在歐盟內經營上述服務,或您的產品是歐盟關鍵實體的「關鍵供應商」,您仍會受到間接影響(透過供應鏈壓力傳導)。

歐盟CER指令現況示意圖:(2025年底)

4. 關鍵詞彙與專有名詞定義 (Keywords & Definitions)

為了讓非法律背景讀者快速進入狀態,以下是本指令的核心術語表:

術語 (Term)

法律定義簡述

實務解釋與例子

關鍵實體 (Critical Entity), §2(1)

經成員國認定,一旦失效將對其社會、經濟或環境造成重大影響的實體。

例子:港口經營者、醫院集團一家掌控全國 30% 電力供應的私營電網公司,或一家經營核心港口的物流公司。

重大破壞性效應 (Significant Disruptive Effect), §7

指實體功能失效後,導致基本服務中斷,影響範圍達到國家或跨國等級。

例子: 某銀行清算系統崩潰,導致全歐盟跨境交易停止 48 小時,引發金融恐慌。

荷蘭鹿特丹港三天停擺,可能導致歐洲供應鏈成本上升15-20%

韌性措施 (Resilience Measures), §2(12)

《韌性》指實體在面對風險時,能預防、抵抗、吸收、適應並快速恢復的能力;相關措施乃實體或組織為了降低風險、提高恢復能力而採取的技術手段。

例子: 為關鍵伺服器建立地理分散的備援中心 (DR Site);建立跨國供應鏈替代方案。

主管機關 (Competent Authority)

由各成員國指定,負責監督、稽核與處罰 CER 執行情況的政府部門。

例子:德國的聯邦內政部 (BMI) 或特定部門。

風險評鑑Risk Assessment, §5

會員國每4年評鑑威脅/脆弱性

系統性分析所有可能風險(自然、人為、技術、供應鏈),並評鑑其發生機率與衝擊程度。

調和標準Harmonised Standards

ISO 22301業務持續管理)

符合調和標準,即適用推定符合性假設

(未完,見續篇)

2026年6月5日 星期五

歐盟《網路韌性法》初探(八之八)

EU Cyber Resilience Act(CRA)

Regulation (EU) 2024/2847 + Corrigendum B / C1 / C2 / C3

(續前篇)

適合產業界、驗證業、資訊安全、網路安全及軟//韌體工程師、企業管理者或法規政策研究人員,具備大學教育背景但對歐盟法規未盡熟悉的亞洲讀者閱讀。

此文僅供個人參考與資訊喚回,尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊,經由整合篩選與文字調整。法規內容可能隨時間修訂,具體符合決策宜諮詢歐盟專業法律及資安顧問或驗證機構。文中提及之市場資料係基於公開報告及邏輯估算,實際數值可能隨時變動。參考法規資訊截至20263月,後續修訂請查閱歐盟CRA官方網站和EUR-Lex資料庫。

© All Rights reserved。 版權聲明。CC BY-SA 40


第十八章 風險評估、陷阱、改善建議與實際案例

18.1 已知漏洞、新興風險與主要陷阱

(一)技術層面的常見陷阱

     預設密碼未更改:最簡單卻最常見的違規,直接觸犯 CRA 附錄I Part I 要求。2021 Mirai 殭屍網路攻擊即源於此

     未追蹤的開源元件:Log4ShellCVE-2021-44228)漏洞影響數以千計使用 Log4j 函式庫的產品,許多製造商甚至不知道自己的產品含有此元件

     SBOM 不完整:採購的商業 SDK 或硬體模組供應商未提供 SBOM,導致整合後的 SBOM 出現空白。

     OTA 更新無法驗證簽章:更新機制未做程式碼簽章驗證,使產品易受惡意更新攻擊。

     支援期間計算錯誤:製造商宣稱「5 年支援」,但從首次販售日起計算,而非最後一次市場投入,導致期間被低估。

     完全豁免的限制條款:在20271111日之前已經最終交付給終端使用者的PDE產品,豁免CRA符合性要求,但排除以下情況之一 即使已經生產好放在倉庫的產品,如果在該日期後才放入歐盟市場,還是需要完全符合CRA

a.    任何在該日期之後繼續販賣的產品,不論當初生產的日期;

b.    任何在該日期之後推送的任何軟體更新;

c.     任何在該日期之後新啟用的功能。

     搭便車迷思:「軟體漏洞是從第三方程式庫取得的,所以不是製造商的責任」;當製造商將外來程式放到自己的產品裡面,製造商就負全部的產品責任,原始開發者並不是產品安全責任的首要承受對象。

     時間段迷思:「該項軟體漏洞在當年出貨的時候還沒有人發現,既然當時已經出貨,客戶也收下來,所以製造商沒有責任做後續的更新或發出補丁」。CRA條例的立法原則係嚴格責任制,不論製造商當時是否知道漏洞的存在,只要PDE產品仍在生命周期內,製造商負起後續的更新或做出矯正措施的責任。

(二)法規合規陷阱

     「通過 ISO 27001 認證就夠了」的誤解:ISO 27001 認證是組織層級的管理系統,尚無法取代產品層級的 CRA 符合性評鑑的管理制度及技術文件要求。

     進口商不知自身法律責任:亞洲製造商在歐盟無設立據點時,其歐盟進口商承擔大部分法律責任,但多數進口商對此認識不足。

     重大修改觸發重新評估:產品韌體版本更新(Patching)若引入新的網路功能,或涉及核心架構,可能被認定為「重大修改」,需重新執行符合性評鑑。

     EU DoC 內容不正確:EU 符合性聲明若引用錯誤的調和標準或遺漏必要資訊,構成直接違規。

     證書迷思:「誤以為「基本級 (Basic)PDE產品的自我聲明在所有應用場景都有同等效力」。實務上,在 B2B 場景或企業招標公告中,業主通常要求「重要」或「關鍵」等級的PDE產品。

     供應商迷思:「身為零組件供應商,僅負責供貨,下游製造商才需要負責符合性問題」;條例第11條亦規定零組件供應商負連帶責任,主管機關可以越過下游製造商追溯到上游供應商而直接課處罰鍰。

     大盤商迷思:「身為大盤商,將產品只賣給企業級客戶,所以不適用CRA條例」;大盤商雖然不是直接面對消費者,但放入歐盟市場的PDE產品,便適用CRA條例,而且商業和工業產品適用比消費型產品更嚴格的要求。

     結束營業迷思:「本企業已經結束該項PDE產品業務,永久離開該產業,所以不用繼續提供軟體更新或補丁」。CRA條例的立法原則係嚴格責任制,製造商的支援義務不會因為停止營業或者停產PDE產品而終止。

18.2 風險評估方法論

CRA 要求製造商對PDE產品進行「網路資訊安全風險評鑑」,以下是建議的操作架構:

l   資產識別(Asset Identification):列出產品中所有值得保護的資產,包含資料、功能、通訊介面;

l   威脅建模(Threat Modeling):採用 STRIDESpoofing/ Tampering/ Repudiation/ Information Disclosure/DoS/Elevation)或 PASTA 方法論,系統化識別潛在威脅;

l   漏洞分析(Vulnerability Analysis):結合 SBOM 比對 NVDNational Vulnerability Database),識別已知 CVE

l   風險評分(Risk Scoring):採用 CVSSCommon Vulnerability Scoring System)量化漏洞嚴重性;

l   風險減緩(Risk Mitigation):針對高風險項目制定具體緩解措施或接受風險的理由;

l   殘餘風險評估(Residual Risk Assessment):確認採取措施後殘餘風險可被接受。

 

18.3 附錄I 的改善行動建議

Part I — 設計及開發要求的具體落實

     建立安全開發生命週期(SDL):採用 OWASP SAMM BSIMM 架構衡量現有成熟度,再制定改善路線圖

     採用「零信任架構」(Zero Trust Architecture):假設內部網路同樣不安全,所有存取均需驗證

     強化身份驗證:禁用預設密碼,要求初次使用時設定強密碼或採用無密碼認證(FIDO2

     實施最小化資料收集:只收集產品功能所需最少量的個人資料(與 GDPR §5 協同)

     定期進行第三方滲透測試:至少每年一次,覆蓋新版本發布前後

Part II — 漏洞處理改善

     建立安全資訊中心(Security Advisory Page):在官方網站發布 CVE 公告及對應更新連結

     採用自動化掃描工具:將 SAST/DAST/SCA 整合進 CI/CD 管道,確保每次程式碼提交都經過安全掃描

     設定 SLA 處理時程:依 CVSS 評分設定漏洞修補期限(如 CVSS 9.0+ 7 天內發布修補) 

18.4 真實案例研究

案例一:Log4j事件 2021

事件概述:Log4j(Log4Shell) 是由 Apache 軟體基金會開發的 Java 日誌架構,廣泛應用於全球數百萬個應用程式中。屬於「遠端代碼執行 (RCE)」漏洞(CVE-2021-44228)。攻擊者只需向受影響的伺服器發送一串特殊的字串(如透過 Header 或登入欄位),利用 Java 命名和目錄介面 (JNDI) 缺陷,即可誘使伺服器下載並執行惡意程式碼。CVSS 評分達到最高分 10.0,屬於致命性風險等級。谷歌公司Google 估計超過 35,000 Java 套件受到衝擊,佔當時 Maven Central 套件庫的 8% 以上。全球頂尖雲端商(AWS, Microsoft, iCloud)、企業軟體及工業控制系統無一倖免。雖然具體的經濟損失難以精確量化,但數以萬計的企業需緊急停機維護。美國網路資訊安全審查委員會 (CSRB) 指出,Log4j 將是一個「長達十年的問題」,因為它深埋在許多遺留系統(Legacy Systems)中,其修補的人力成本估計達數十億美元。

CRA 啟示:CRA架構下,每一個把Log4j包含在PDE產品裡面的製造商都會負起連帶責任。Apache基金會本身則係符合開源豁免的條款,而免遭CRA處罰。依照CRA條例,軟體開發商或將受影響軟體整合進PDE產品的廠商(包括大型商業開發者)必須履行下列義務:

措施

行動事項

24小時早期預警

 

製造商一旦察覺漏洞被「積極利用」(Actively Exploited),必須在 24 小時內向 ENISA 與該國 CSIRT 提交初步通報

72小時強制通報

72 小時內提供詳細的技術分析、風險評估與緩解建議

軟體材料清單 (SBOM) 的強制調閱

CRA 要求製造商必須維護 SBOM。企業必須清楚知道其產品中使用了哪些開源組件(如 Log4j

2021 年,許多企業甚至不知道自己使用了 Log4j,但在 CRA 架構下,這已構成違犯CRA條例的必要條件

立即修補與安全性更新

製造商必須在漏洞發現後立即開發補丁,並透過自動更新機制推播給用戶。

如果無法修補,必須提供明確的停用建議


相對地,CRA條例要求歐盟執行委員會與各成員國監管機構採取的干預措施:

措施

行動事項

建立單一通報平台 (SRP)

ENISA 運行的平台將彙整所有 Log4j 的攻擊數據,並即時向全歐盟的關鍵基礎設施(如電力、醫療)發布預警

市場監督與產品召回

若某廠商未能及時提供 Log4j 的修補程式,或隱瞞漏洞不報,國家監管機構有權要求該產品從歐盟市場撤回 (Withdrawal) 召回 (Recall)

高額罰鍰 (fines)

對於未履行漏洞處理義務的廠商,CRA 規定了最高 1,500 萬歐元 全球年營業額 2.5% 的行政罰鍰(以較高者為準)


案例二:SolarWinds 供應鏈攻擊(2020-2021

事件概述:俄羅斯 APT 組織在 SolarWinds Orion 的合法動態連結庫建置流程中植入惡意程式碼(SUNBURST)後門程式,由於該檔案擁有 SolarWinds 的官方數位簽章,因此能避開幾乎所有傳統安全軟體的偵測。透過合法的軟體更新機制散布至全球 18,000 個組織,包括美國多個聯邦政府機構(財政部、商務部、國土安全部、國務院、能源部及國家核安全管理局)以及財富 500 強中的多間科技巨頭(如 Microsoft, Intel, Cisco)。軟體攻擊雖然早在 2019 年就開始佈署,歷經約一年的潛伏期,從2020 3 月起透過正常的軟體更新管道分發,直到 2020 12 月才由資安公司 FireEye 揭發。駭客長期潛伏在受害機構的電子郵件系統與內部網路中,竊取了海量高度機敏數據。調查與修復成本估計達 數十億美元。SolarWinds 自身的股價一度跌掉 40% 以上,並面臨多起集體訴訟。此次攻擊暴露了軟體供應鏈的系統性漏洞。

CRA 啟示:此案例直接推動了 SBOM 及安全開發生命週期的立法強制化。CRA SBOM 要求、建置環境安全要求(附錄I Part I 3 點)及 OTA 更新完整性要求,正是針對此類攻擊的具體回應。該類網路管理軟體 (Network Management Systems) 會被列為 「重要產品 (Important Products) - II 類」 「關鍵產品 (Critical Products)」,不能僅靠廠商自我評估。CRA條例要求必須由第三方驗證及公告機構 (Notified Body) 進行強制性的符合性評鑑,審查其開發流程是否具備防篡改機制。CRA條例進一步 規定製造商必須確保「產品生命週期的安全性」。這意味著 SolarWinds 有法律義務證明其建置系統 (Build System) 的完整性。當SolarWinds現其產品被植入後門且正被積極利用,必須以24小時/72小時的限定期間內通報歐盟主管機關,若在 CRA條例管制下,一旦證明廠商因管理疏忽導致未能察覺大規模攻擊,將面臨最高 1,500 萬歐元或全球營收 2.5% 的罰款,配合及時發行補丁程式、追蹤修復進度,甚至嚴重時停止銷售、召回。

案例三:Hikvision 攝影機漏洞(CVE-2021-36260

事件概述:中國監控攝影機製造商 Hikvision 的網頁伺服器元件存在嚴重的命令注入漏洞(CVSS 9.8),允許未授權的遠端完全控制。此漏洞在 2021 年被公開後被廣泛利用,多國政府(含美國、英國)將 Hikvision 設備列為安全隱患並實施限制。

CRA 啟示: CRA 已生效,此漏洞的通報義務(24h)、修補義務及技術文件不足的問題,將可能導致 Hikvision 在歐盟遭受高額罰款,並被市場監督機關限制銷售。此案亦說明連網監控設備(IPC)在 CRA 下屬於需特別關注的高風險類別。

案例四:ASUS 路由器漏洞事件(2023

事件概述:2023 年,ASUS 多款路由器被發現存在多個高危漏洞(含 CVE-2023-28702CVE-2023-28703 等),允許未經授權的遠端執行程式碼。ASUS 雖最終發布修補程式,但因通報及修補時程問題受到多國資安機構關注。美國 CISA 發出公告,荷蘭 NCSC 亦發出建議停用特定版本的警告。

CRA 啟示: CRA 已生效,ASUS 將面臨:(1) 漏洞通報義務——24h ENISA 通報;(2) 技術文件不足導致的合規風險;(3) 若被認定為 Class I 路由器,可能觸發更嚴格的符合性評鑑要求。此案例凸顯 SBOM 追蹤及主動漏洞監控的重要性。


案例五:特斯拉自動駕駛召回 2024

這個案例確認了CRA條例一個非常重要的原則:【軟體更新】措施,本身就屬於新的PDE產品放入市場的行為。也就是說即使PDE產品已經出貨很多年,只要企業(經濟營運者)推送新的軟體更新,就要重新確認整個PDE產品符合所有適用CRA條例的要求。(見附圖)



附錄 文獻參考(Literature References

A. 主要法規文本

     Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 20.11.2024. EUR-Lex: http://data.europa.eu/eli/reg/2024/2847/oj

     Corrigendum to Regulation (EU) 2024/2847 (C3). OJ L, 2025/90555, 2.7.2025. EUR-Lex: http://data.europa.eu/eli/reg/2024/2847/corrigendum/2025-07-02/oj

     Commission Implementing Regulation (EU) 2025/2392 — Technical Description of Important and Critical Products. OJ L, 1.12.2025.

     Commission Delegated Regulation (EU) 2025/1535 — Exclusion for Certain Products under Regulation 168/2013. OJ L, 29.7.2025.

     Regulation (EU) 2019/881 — Cybersecurity Act (ENISA Regulation). EUR-Lex.

     Directive (EU) 2022/2555 — NIS2 Directive. EUR-Lex.

     Regulation (EU) 2016/679 — GDPR. EUR-Lex.

     Regulation (EU) 2024/1689 — AI Act. EUR-Lex.

B. 官方指引與技術文件

     European Commission. (2024). Cyber Resilience Act — Summary of the Legislative Text. https://digital-strategy.ec.europa.eu

     European Commission. (2024, December 3). CRA Frequently Asked Questions (Technical FAQs). 66 pages.

     BSI (Bundesamt für Sicherheit in der Informationstechnik). (2024). Technical Guideline TR-03183 — Cyber Resilience Requirements for Manufacturers and Products.

     ENISA. (2024). ENISA Foresight Cybersecurity Threats for 2030.

     CEN/CENELEC/ETSI Mandate M/606 — Standardisation Request for CRA. (3 February 2025).

C. 調和標準(已發布或預期)

     ETSI EN 303 645 v2.1.1. (2020). Cyber Security for Consumer Internet of Things: Baseline Requirements. Sophia Antipolis: ETSI.

     ISO/IEC 27001:2022. Information Security Management Systems — Requirements. ISO.

     ISO/IEC 27002:2022. Information Security, Cybersecurity and Privacy Protection — Information Security Controls. ISO.

     EN ISO/IEC 29147:2020. Information Technology — Security Techniques — Vulnerability Disclosure. ISO.

     EN ISO/IEC 30111:2020. Information Technology — Security Techniques — Vulnerability Handling Processes. ISO.

     ISO/IEC 27404:2025. Internet of Things (IoT) Security — Baseline Security Requirements. ISO.

     IEC 62443 Series. Industrial Communication Networks — IT Security for Networks and Systems. IEC.

D. 市場研究

     Mordor Intelligence. (2026, January). Cybersecurity Market Size & Growth Trends Report 2031. https://www.mordorintelligence.com

     ISC2. (2024). ISC2 Cybersecurity Workforce Study. https://www.isc2.org

     CBI (Centre for the Promotion of Imports). (2024). The European Market Potential for Cybersecurity Products and Services. https://www.cbi.eu

     ENISA. (2024). ENISA Threat Landscape 2024. European Union Agency for Cybersecurity.

     ENISA. (2026). ENISA Threat Landscape 2025. European Union Agency for Cybersecurity.

E. 學術文獻

     Bradford, A. (2020). The Brussels Effect: How the European Union Rules the World. Oxford University Press.

     Timmers, P. (2022). 'Cybersecurity in the European Union: Regulatory Challenges and the Path Forward.' Journal of Cybersecurity and Privacy, 2(3), 451-468.

     OECD. (2024). Building a Skilled Cyber Security Workforce in Europe. OECD Publishing. https://doi.org/10.1787/3673cd60-en

F. 重要網路資源

     EUR-Lex(歐盟法律資料庫):https://eur-lex.europa.eu

     ENISA 官方網站https://www.enisa.europa.eu

     歐盟數位策略官方頁面https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

     BSI TR-03183 技術指引https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html

     歐盟網路韌性法追蹤網站https://www.european-cyber-resilience-act.com

     Secure by Design Handbookhttps://www.securebydesignhandbook.com

(本篇完)