CN CRA NotebookCRA 閱讀筆記
Working note — actively evolving, may be revised. See /errata for change log. 推進中的筆記,可能持續修改。修訂紀錄見 /errata

Annex I Regulation (EU) 2024/2847 · Annex I 法規 (EU) 2024/2847 · 附件一

The 22 essential requirements 22 項必要要求

Annex I is the substantive heart of the CRA. Part I contains 13 product-level properties (requirements 2(a) through 2(m)); Part II contains 8 process-level obligations on vulnerability handling. Every assessment module, every harmonised standard, and every technical document you will produce ultimately traces back to these 22 requirements. 附件一是 CRA 的實質核心。第一部分列出 13 項產品層級的屬性(要求 2(a) 至 2(m));第二部分列出 8 項流程層級的弱點處理義務。每一個評鑑模組、每一份協調標準、你要產出的每一份技術文件,最終都追溯回這 22 項要求。

Requirements要求數 · 13 + 8 = 22 Applies from適用起始 · 11 Dec 2027 Primary audience主要對象 · Manufacturers製造商 Last reviewed最後校閱 · 2026-04-24 Status狀態 · Working書寫

Block 1 · Official text 區塊 1 · 官方條文

What the Regulation actually says 條文實際怎麼寫

Source. Consolidated text from Regulation (EU) 2024/2847, Annex I, as published in OJ L 2024/2847, 20 November 2024. Translations below are condensed and unofficial; refer to EUR-Lex for binding text in all 24 EU languages. 來源。條文自《法規 (EU) 2024/2847》附件一,發布於 OJ L 2024/2847,2024 年 11 月 20 日。以下中文為濃縮非官方翻譯;強制適用的條文請依 EUR-Lex 公告之 24 種歐盟官方語言版本。

Part I · Overarching principle (requirement 1) 第一部分 · 總則原則(要求 1) ¶ 1

(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

(1) 具數位元素產品之設計、開發與生產,應依風險確保適當之網路安全水準。

Part I · Product properties (requirements 2(a)–2(f)) 第一部分 · 產品屬性(要求 2(a)–2(f)) ¶ 2(a) – 2(f)

2(a) Made available on the market without known exploitable vulnerabilities.

2(a) 投放市場時不含已知可利用之弱點。

2(b) Made available with a secure by default configuration, including the possibility to reset the product to its original state.

2(b) 以安全預設組態投放市場,包含可將產品重設為原始狀態之功能。

2(c) Ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates installed within an appropriate timeframe enabled as a default setting.

2(c) 確保可透過安全更新處理弱點;於適用時,包含預設啟用之自動安全更新於適當時程內完成。

2(d) Ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access.

2(d) 透過適當控制機制(含但不限於認證、身分或存取管理系統)確保免於未經授權之存取,並回報可能之未經授權存取。

2(e) Protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms.

2(e) 保護儲存、傳輸或以其他方式處理之資料(個人資料或其他)之機密性,例如以先進機制對靜態或傳輸中之相關資料加密。

2(f) Protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions.

2(f) 保護儲存、傳輸或以其他方式處理之資料(個人資料或其他)、命令、程式、組態之完整性,使免於未經使用者授權之操作或修改;並回報遭破壞之情形。

Part I · Product properties (requirements 2(g)–2(m)) 第一部分 · 產品屬性(要求 2(g)–2(m)) ¶ 2(g) – 2(m)

2(g) Process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation).

2(g) 僅處理與產品預期用途相當、相關、且限於必要之資料(個人資料或其他),資料最小化。

2(h) Protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks.

2(h) 保護產品基本與核心功能之可用性,含事件發生後;包括對阻斷服務攻擊之韌性與緩解措施。

2(i) Minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks.

2(i) 最小化產品本身或連接裝置對其他裝置或網路所提供服務之可用性之負面影響。

2(j) Be designed, developed and produced to limit attack surfaces, including external interfaces.

2(j) 設計、開發、生產應限制攻擊面,含外部介面。

2(k) Be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques.

2(k) 設計、開發、生產應透過適當之利用緩解機制與技術,降低事件之影響。

2(l) Provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user.

2(l) 透過記錄及監控相關內部活動(含資料、服務或功能之存取或修改)提供安全相關資訊,並提供使用者退出機制。

2(m) Provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.

2(m) 提供使用者安全且簡便地永久刪除所有資料與設定之可能;於該資料可轉移至其他產品或系統時,確保以安全方式為之。

Part II · Vulnerability handling (requirements 1–8) 第二部分 · 弱點處理(要求 1–8) Part II

(1) Identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.

(1) 辨識並記載具數位元素產品中包含之弱點與元件,包括以常用且機器可讀之格式,產製至少涵蓋產品頂層相依關係之軟體物料清單(SBOM)。

(2) In relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates.

(2) 依產品所面對之風險,及時處理並修正弱點,含提供安全更新;於技術可行時,新安全更新應與功能更新分開提供。

(3) Apply effective and regular tests and reviews of the security of the product with digital elements.

(3) 對具數位元素產品之安全進行有效且定期之測試與審查。

(4) Once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts, their severity and clear and accessible information helping users to remediate the vulnerabilities.

(4) 安全更新提供後,分享並公開披露已修復弱點之資訊,包括弱點描述、使用者識別受影響產品之資訊、影響及嚴重性、以及協助使用者修補之明確易讀資訊。

(5) Put in place and enforce a policy on coordinated vulnerability disclosure.

(5) 建立並執行協調揭露政策(CVD policy)。

(6) Take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements.

(6) 採取措施以促進就產品及其第三方元件之潛在弱點資訊分享,含提供弱點通報之聯絡地址。

(7) Provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner.

(7) 提供安全派送產品更新之機制,以確保弱點及時修復或緩解;於適用時(安全更新),以自動方式為之。

(8) Ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.

(8) 確保於安全更新可供處理已辨識安全問題時,無遲延派送,且除製造商與商業使用者就客製化產品另有約定外,免費提供,並伴隨相關建議訊息,含使用者可能需採取之行動資訊。

Block 2 · Plain language 區塊 2 · 白話解讀

What this actually means 這其實在說什麼

The structural trick: product vs process

Part I and Part II are not two lists of "more security stuff." They operate on different objects. Part I describes properties of the product — what it must do, what it must prevent, what it must provide. Part II describes properties of your organisation — what you must do throughout the product's support period. This distinction matters more than it sounds: risk assessment methodologies that cover Part I (STRIDE, LINDDUN, IEC 62443-4-2) often say nothing about Part II, and vice versa. Don't assume your existing framework covers both.

The "based on the risks" clause is the whole hinge

Requirement 1 says products shall ensure "an appropriate level of cybersecurity based on the risks." Every 2(a)–2(m) item is conditioned by this. You are not required to implement every cryptographic control or every attack-surface reduction — you are required to implement them where the risk assessment shows they are relevant. That turns your risk assessment into the load-bearing document. If it is sloppy, vague, or copy-pasted from a template, every downstream essential-requirement claim collapses.

Part II(1) SBOM: "top-level dependencies" is thinner than you think

The SBOM requirement demands "at the very least the top-level dependencies." This is narrower than the US executive-order SBOM debate. CRA does not mandate full transitive dependency trees. It does mandate machine-readable format, which in practice means SPDX, CycloneDX, or equivalent — not PDFs, not Excel. And it applies continuously throughout the support period; a snapshot at release is insufficient.

Part II(8) "free of charge" is a fight that has already happened

Requirement 8 establishes that security updates must be free of charge — unless a manufacturer and business user have otherwise agreed in relation to a tailor-made product. Consumer products: security updates are always free. B2B contracts: you can contract around it, but only if the product is tailor-made and both parties agreed explicitly. "Tailor-made" is not a licence term you sneak in — it means the product was actually designed to the buyer's specifications.

兩部分在說兩件不同的事

附件一第一部分跟第二部分,不是兩張「再多寫幾條安全規範」的清單。它們作用在不同的對象。第一部分講產品屬性:產品本身必須做什麼、必須擋住什麼、必須提供什麼。第二部分講組織屬性:你在 support period 裡必須持續做什麼。這個區分比聽起來重要,因為涵蓋第一部分的風險評估方法(STRIDE、LINDDUN、IEC 62443-4-2)通常對第二部分隻字未提,反過來也一樣。別假設既有的合規框架兩邊都涵蓋。

「跟風險程度相稱」這句話的份量

要求 1 寫得很關鍵:產品應確保「跟風險程度相稱的網路安全水準」。下面 2(a) 到 2(m) 每一項都被這個條件框住。你不必實作每一個密碼控制、每一個攻擊面削減,你必須實作風險評估說相關的那些。這把你的風險評估變成承重文件。寫得馬虎、含糊、或從範本複製貼上,下游每一個 essential requirement 的合規主張都會崩塌。

SBOM 範圍比美國的窄,但更剛性

SBOM 要求「至少涵蓋 top-level dependencies」。這個範圍比美國行政命令在討論的 SBOM 窄。CRA 不要求完整的遞迴依賴樹。它要求的是 machine-readable 格式,實務上指 SPDX、CycloneDX 或同等格式,不是 PDF、不是 Excel。而且整個 support period 內都要持續適用,發布時拍一張快照不算數。

免費安全更新有狹窄的例外

要求 8 把安全更新訂死了:必須免費,除非製造商跟商業使用者就客製化產品另有約定。消費型產品,安全更新永遠免費。B2B 合約可以排除,但前提是產品確實是客製的、雙方明確同意。「客製化」不是你偷偷塞在 EULA 裡的條款,意思是產品實際上是依買方規格設計的。

Block 3 · APAC perspective 區塊 3 · APAC 觀點

How this lands in Taiwan, Japan, and Korea 這一條在台日韓怎麼落地

Taiwan: CNS 15936 gives you the shell, not the risk engine 台灣:CNS 15936 給你外殼,但沒給風險引擎

Taiwan's CNS 15936 series (IoT security) and SEMI E187 (semiconductor) cover several Part I requirements — notably 2(a), 2(b), 2(c), and 2(d). What they do not cover is the "based on the risks" framing that ties every requirement back to a documented risk assessment. Manufacturers who have CNS 15936 certification often assume that certification implies Annex I conformity. It does not. You still need the product-specific risk assessment artefact described in Article 13(2), and you still need to map each 2(a)–2(m) claim back to it.

台灣 CNS 15936 系列(IoT 安全)跟 SEMI E187(半導體)涵蓋附件一第一部分的部分要求,特別是 2(a)、2(b)、2(c)、2(d)。它們沒涵蓋的是「跟風險程度相稱」這個框架,把每一項要求繫回一份書面的風險評估。已經拿到 CNS 15936 認證的台灣製造商,常以為等於符合附件一。不是。你還是需要第 13(2) 條規定的「產品特定的風險評估」這份成品,而且還是要把每個 2(a) 到 2(m) 的主張都對回到這份成品上。

Japan: JC-STAR Level ★★★ is closest, but still a subset 日本:JC-STAR ★★★ 最接近,但仍是子集

JC-STAR (the IoT security labelling scheme run by METI + IPA) at Level ★★★ covers roughly 70% of Annex I Part I and most of Part II's vulnerability handling requirements. The gaps are specific: 2(g) data minimisation (JC-STAR touches it but not at CRA depth), 2(l) logging with opt-out (Japanese regulators have been softer on this), and the Part II(1) machine-readable SBOM requirement. Japanese manufacturers with ★★★ can expect a meaningful head start, but cannot treat the two as equivalent.

JC-STAR(METI 跟 IPA 共同推的 IoT 安全標示計畫)在 ★★★ 等級涵蓋附件一第一部分約 70%、加上第二部分弱點處理的大部分要求。具體的落差有三個:2(g) 資料最小化(JC-STAR 有碰到但深度不到 CRA)、2(l) 含 opt-out 機制的記錄(日本監管比較寬)、以及第二部分 (1) 的 machine-readable SBOM 要求。拿到 ★★★ 的日本製造商,實質上有不小的先發優勢,但不能把兩者畫等號。

Korea: K-ISMS-P vs Annex I is a categorical mismatch 韓國:K-ISMS-P 跟附件一是不同類別的東西

K-ISMS-P is an organisational ISMS certification — same family as ISO 27001. TTA IoT is a voluntary certification scheme. Neither is a law, and neither matches the legal force of the CRA. Annex I Part I is what the CRA imposes on products through statute — they are simply not measuring the same thing. Korean exporters holding K-ISMS-P and hoping it helps with CRA should expect it to help with Part II (process-level vulnerability handling overlaps with K-ISMS-P controls) but not with Part I. TTA IoT sits closer to Part I than K-ISMS-P does, but it remains a certification, not a statute — it cannot satisfy CRA Article 13(2)'s formal risk-assessment obligation on your behalf.

K-ISMS-P 是組織層級的資訊安全管理系統認證、跟 ISO 27001 同一族;TTA IoT 是 voluntary certification,兩者都不是法律、都不對應 CRA 的法律強度。附件一第一部分是 CRA 透過法律對產品課的要求,量的東西本來就不一樣。持有 K-ISMS-P 的韓國出口商,期待它對 CRA 合規有幫助時:可以期待對第二部分有用(流程層級弱點處理跟 K-ISMS-P 的控制有重疊),但第一部分對不上。TTA IoT 在第一部分上比 K-ISMS-P 接近一點,但仍是認證制度、不是法律,它沒辦法替你滿足 CRA 第 13(2) 條的 formal 風險評估義務。

The SBOM pivot APAC manufacturers keep missing APAC 製造商一直忽略的 SBOM 轉向

The most common gap I see in APAC readiness programmes is SBOM generation treated as a release-time deliverable, not a living artefact. Part II(1) requires SBOMs to be maintained throughout the support period and used for ongoing vulnerability correlation. That means SBOM generation needs to be part of CI/CD, not a Friday-afternoon PDF export before CE marking. Tools exist (Syft, CycloneDX CLI, SPDX tools) and they are mostly open source. The barrier is workflow integration, not tooling cost.

APAC 準備度計畫裡我最常看到的落差是:SBOM 被當成「發布時的交付物」,而不是活文件。附件一第二部分 (1) 要求 SBOM 在 support period 內持續維護、用於持續性的弱點關聯分析。這代表 SBOM 產出必須融入 CI/CD,不能是 CE 標示前週五下午臨時匯出的 PDF。工具都有現成的(Syft、CycloneDX CLI、SPDX tools),大部分還是開源。瓶頸是 workflow 整合,不是工具成本。

Block 4 · Cross-regulation map 區塊 4 · 跨法規對照

Which standards give you presumption of conformity 哪些標準給你符合性推定

Harmonised European standards under the CRA are still in development (the M/606 work programme is active; no hEN has been cited in the OJEU yet as of April 2026). Until then, these four reference frameworks carry the most weight for demonstrating Annex I conformity. CRA 的歐洲 harmonised standard 還在開發中(M/606 工作計畫進行中;截至 2026 年 4 月,OJEU 還沒引用任何一份 hEN)。在這之前,下面四個參考框架對證明附件一合規最具分量。

IEC 62443-4-2

IACS component security capabilities

IACS 元件安全能力

IEC 62443-4-2 maps cleanly onto Part I requirements 2(d)–2(l). For industrial and IoT products, this is the closest existing mature standard. Its "Security Level 2" baseline matches typical CRA expectations; SL3/SL4 exceed them. Already in many APAC manufacturers' quality systems.

IEC 62443-4-2 清楚對應到第一部分 2(d) 到 2(l)。對工業跟 IoT 產品來說,這是現有最成熟的近似標準。它的 SL2 基線符合 CRA 典型預期;SL3/SL4 則超過。許多 APAC 製造商已經把它放進品質系統裡。

ETSI EN 303 645

Consumer IoT baseline

消費者 IoT 基線

For consumer IoT (Class I categories 16–19), ETSI EN 303 645 is the natural reference. It covers 2(a), 2(b), 2(c), 2(d), 2(e), 2(f), 2(g), and 2(m). It does not cover Part II's vulnerability-handling processes — you need ISO/IEC 30111 + ISO/IEC 29147 alongside.

對消費者 IoT(Class I 第 16 到 19 類),ETSI EN 303 645 是最自然的參考。涵蓋 2(a)、2(b)、2(c)、2(d)、2(e)、2(f)、2(g)、2(m)。不涵蓋第二部分的弱點處理流程,必須搭配 ISO/IEC 30111 + ISO/IEC 29147。

NIST SSDF (SP 800-218)

Secure software development framework

安全軟體開發框架

NIST SSDF (SP 800-218) addresses the secure-development-lifecycle dimension that crosses Part I and Part II. Useful for software-only products and for manufacturers already aligned with US federal procurement expectations. Does not substitute for Annex I conformity claims — use as supporting evidence.

NIST SSDF (SP 800-218) 處理橫跨第一、第二部分的安全開發生命週期面向。對純軟體產品、以及已經對齊美國聯邦採購預期的製造商有用。不能取代附件一合規主張,當作輔助證據用。

prEN 40000-1-2 (draft)

Risk management for products with digital elements

具數位元素產品的風險管理

The CEN-CENELEC JTC 13 draft prEN 40000-1-2 is the emerging horizontal standard for CRA risk management. It will, once published, be the primary route to presumption of conformity for Article 13(2)'s risk assessment requirement. Not yet citable in OJEU; track the M/606 work programme for status updates.

CEN-CENELEC JTC 13 草案 prEN 40000-1-2 是 CRA 風險管理新興的橫向標準。一旦公布,會成為第 13(2) 條風險評估要求合規推定的主要路徑。還不能在 OJEU 引用;狀態更新追 M/606 工作計畫。