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

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

Content of the technical documentation 技術文件之內容

Eight contents that together form the CRA technical file. The regulator's window into what the manufacturer has done. Read correctly, this is not a compliance artefact but the single source of truth that ties design, risk, standards, testing, and conformity into one auditable story. 八項內容合成 CRA 技術檔案。監管者得以窺見製造商所作的窗。讀對後,這不是合規成品而是將設計、風險、標準、測試、符合性綁成一個可稽核故事的單一事實來源。

Items項次 · 8 Applies from適用起始 · 11 Dec 2027 Primary audience主要對象 · Manufacturer · Notified body · Market surveillance authority製造商 · 指定機構 · 市場監督機關 Last reviewed最後校閱 · 2026-04-25 Status狀態 · Working書寫

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

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

Source. Consolidated text from Regulation (EU) 2024/2847 as published in OJ L 2024/2847, 20 November 2024. Translation is unofficial. 來源。條文自《法規 (EU) 2024/2847》整合文本,發布於 OJ L 2024/2847,2024 年 11 月 20 日。中文為非官方翻譯。

Preamble — scope and as-applicable caveat 前言,範圍與適用保留 Preamble

The technical documentation referred to in Article 31 shall contain at least the following information, as applicable to the relevant product with digital elements:

第 31 條所指之技術文件至少應包含下列資訊,依相關具數位元素產品之適用程度:

"As applicable" is doing work — it does not mean items are optional; it means each item scales to the product's nature. A software-only product provides software-relevant content under item 1; a hardware product provides photos and layouts under item 1(c). The whole list must be addressed — absence is itself a compliance statement.

「依適用程度」有其作用,非指項次可選;而指每項次按產品性質調整。純軟體產品於項次 1 下提供軟體相關內容;硬體產品於項次 1(c) 下提供照片與布局。整份清單須被處理,缺失本身即為合規聲明。

Item 1 — general description of the product 項次 1,產品一般描述 § 1

1. a general description of the product with digital elements, including:

1. 具數位元素產品之一般描述,包括:

(a) its intended purpose;

(a) 其預期用途;

(b) versions of software affecting compliance with essential cybersecurity requirements;

(b) 影響基本網路安全要求符合性之軟體版本;

(c) where the product with digital elements is a hardware product, photographs or illustrations showing external features, marking and internal layout;

(c) 具數位元素產品為硬體產品時,顯示外部特徵、標記與內部布局之照片或插圖;

(d) user information and instructions as set out in Annex II;

(d) 附件二所定之使用者資訊與說明;

Item 2 — design, development, production & vulnerability handling 項次 2,設計、開發、生產與弱點處理 § 2

2. a description of the design, development and production of the product with digital elements and vulnerability handling processes, including:

2. 具數位元素產品之設計、開發、生產與弱點處理流程之描述,包括:

(a) necessary information on the design and development of the product with digital elements, including, where applicable, drawings and schemes and a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing;

(a) 具數位元素產品設計與開發之必要資訊,包含於適用時之繪圖與方案,以及系統架構之描述、解釋軟體元件如何互建或互饋並整合進整體處理;

(b) necessary information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for the reporting of the vulnerabilities and a description of the technical solutions chosen for the secure distribution of updates;

(b) 製造商所建立弱點處理流程之必要資訊與規格,包含軟體物料清單、協調弱點揭露政策、提供弱點通報聯絡位址之證據,以及為安全散布更新所選之技術解決方案之描述;

(c) necessary information and specifications of the production and monitoring processes of the product with digital elements and the validation of those processes;

(c) 具數位元素產品之生產與監控流程及該等流程驗證之必要資訊與規格;

Item 3 — cybersecurity risk assessment 項次 3,網路安全風險評估 § 3

3. an assessment of the cybersecurity risks against which the product with digital elements is designed, developed, produced, delivered and maintained pursuant to Article 13, including how the essential cybersecurity requirements set out in Part I of Annex I are applicable;

3. 依第 13 條所設計、開發、生產、交付、維護之具數位元素產品所針對之網路安全風險評估,包括附件一第一部分所定基本網路安全要求如何適用;

Item 4 — support-period determination inputs 項次 4,支援期間決定輸入 § 4

4. relevant information that was taken into account to determine the support period pursuant to Article 13(8) of the product with digital elements;

4. 依第 13(8) 條為具數位元素產品決定支援期間所考量之相關資訊;

Item 5 — standards applied / alternative solutions 項次 5,所採用標準 / 替代方案 § 5

5. a list of the harmonised standards applied in full or in part the references of which have been published in the Official Journal of the European Union, common specifications as set out in Article 27 of this Regulation or European cybersecurity certification schemes adopted pursuant to Regulation (EU) 2019/881 pursuant to Article 27(8) of this Regulation, and, where those harmonised standards, common specifications or European cybersecurity certification schemes have not been applied, descriptions of the solutions adopted to meet the essential cybersecurity requirements set out in Parts I and II of Annex I, including a list of other relevant technical specifications applied. In the event of partly applied harmonised standards, common specifications or European cybersecurity certification schemes, the technical documentation shall specify the parts which have been applied;

5. 全部或部分適用且引用已於《歐盟官方公報》公告之調和標準清單、本法規第 27 條所定共通規範、或依《規章 (EU) 2019/881》採納依本法規第 27(8) 條之歐洲網路安全認證機制,並於該等調和標準、共通規範或歐洲網路安全認證機制未被適用時,描述為符合附件一第一與第二部分所定基本網路安全要求所採方案,含其他所採相關技術規範清單。部分適用調和標準、共通規範或歐洲網路安全認證機制之情形,技術文件應明定已適用之部分;

Items 6 – 8 — test reports, DoC copy, SBOM on request 項次 6 – 8,測試報告、DoC 副本、應請求之 SBOM §§ 6 – 8

6. reports of the tests carried out to verify the conformity of the product with digital elements and of the vulnerability handling processes with the applicable essential cybersecurity requirements as set out in Parts I and II of Annex I;

6. 為驗證具數位元素產品與弱點處理流程符合附件一第一與第二部分所定適用基本網路安全要求所執行之測試報告;

7. a copy of the EU declaration of conformity;

7. 歐盟符合性聲明之副本;

8. where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority provided that it is necessary in order for that authority to be able to check compliance with the essential cybersecurity requirements set out in Annex I.

8. 適用時,依市場監督機關合理請求提供之軟體物料清單,以該機關為能檢查符合附件一所定基本網路安全要求必要為前提。

Note the asymmetry between item 2(b) and item 8. Item 2(b) requires SBOM availability in the file as part of vulnerability handling. Item 8 provides the SBOM to market surveillance on reasoned request. The SBOM must exist and be retrievable; it does not need to be pushed to the authority unsolicited.

留意項次 2(b) 與項次 8 之不對稱。項次 2(b) 要求 SBOM 於檔案中作為弱點處理之一部分可用。項次 8 依合理請求提供 SBOM 給市場監督機關。SBOM 必須存在並可取得;不需主動推送至機關。

Operating conditions (from Article 31) 運作條件(源自第 31 條) Art 31(1) – (5)

Art 31(1): Technical documentation shall be drawn up before the product is placed on the market and be kept up to date. Art 31(2): Updates are required as appropriate, including during the support period. Art 31(3): Where the product is subject to other Union legal acts requiring technical documentation, a single set of technical documentation covering all applicable acts shall be drawn up. Art 31(4): The manufacturer may choose any official EU language(s) for the technical documentation provided to the notified body. Art 31(5): The Commission is empowered to adopt delegated acts to add elements to Annex VII. Retention floor: Art 13(12) and Annex VIII per-module rules require at least 10 years after placing on the market or the support period, whichever is longer.

第 31(1) 條:技術文件應於產品投放市場前製備並保持更新。第 31(2) 條:視情形更新,含支援期間內。第 31(3) 條:產品受其他要求技術文件之聯盟法律行為拘束時,應製備涵蓋所有適用法律行為之單一套技術文件。第 31(4) 條:製造商得選擇任一官方歐盟語言提供予指定機構之技術文件。第 31(5) 條:執委會有權採納授權法案增加附件七要素。保存底線:第 13(12) 條與附件八各 module 規則要求投放市場後至少 10 年或支援期間(取較長者)。

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

The technical file as a single source of truth 技術檔案是合規工作的單一基準

The CRA technical file is not a pile of documents thrown into a folder. It is a structured package whose contents answer specific questions a market surveillance authority, notified body, or court might ask. Reading Annex VII as eight independent line items misses the point — the eight items together form a compliance narrative that begins with "what is this product?" (item 1), passes through "how was it built and how is it maintained?" (items 2, 3, 4), "against which standards?" (item 5), "with what test evidence?" (item 6), ends with the formal commitment (item 7), and keeps a separable engineering artefact (item 8) on standby.

"A CRA technical file must be continuously curated across the entire support period. EMC files freeze; CRA files breathe."

Three practical characteristics distinguish the CRA technical file from earlier CE-marking regimes.

It is alive, not frozen. Article 31(2) requires updates as appropriate — and item 1(b) captures "versions of software affecting compliance", which means any firmware/software release altering the compliance posture triggers a technical-file update. This is unusual in CE marking. An EMC technical file, once produced, is largely stable unless the product is substantially modified. A CRA technical file must be continuously curated across the entire support period. For software products, this means weekly or monthly updates are realistic; for hardware products, updates track firmware releases.

It consolidates across multiple regulations. Article 31(3) requires a single technical file covering all applicable Union acts. A product that is scoped under CRA + RED + Machinery + AI Act needs one technical file, not four. This is workload-positive over time but front-loads the integration effort — establishing the unified file structure the first time is significant work. The practical pattern: most organisations maintain the file as a structured repository (often Git or a document-management system) with sections mapped to each regulation's annex requirements.

The retention floor is long. Article 13(12) plus each Annex VIII module all require at least 10 years after placing on the market, or the support period, whichever is longer. For a product with a 15-year support period, the file must be kept for 15 years (not 10). This is operational discipline, not just archiving — the file must remain retrievable, searchable, and in a format that can still be opened at year 15. Proprietary document formats tied to current versions of vendor software are a quiet time-bomb; standards-based formats (PDF/A, HTML, Markdown, plain text) survive decade-long transitions.

What the eight items buy, viewed from the regulator's side. An auditor landing on the technical file for the first time can answer these questions in order: (1) what product is this, what version, what does it look like, what does the user see? (2) how was it architected, what's in the SBOM, how does vulnerability handling work? (3) what risks did the manufacturer identify and map to Annex I? (4) why is the support period what it is? (5) which standards were applied, and where they weren't, what alternatives? (6) what tests were run with what results? (7) what did the manufacturer formally declare? (8) if the SBOM is needed to go deeper, where is it? That question sequence is the compliance story, and a technical file that cannot answer them in order has a gap.

CRA 技術檔案不是一堆丟進資料夾的文件。它是一套結構化的東西、內容回答市場監督機關、指定機構、或法院可能會問的具體問題。把附件七讀成 8 個獨立項目會抓不到重點,8 項合起來是一個完整的合規敘事:從「這是什麼產品?」(項次 1)、經過「怎麼設計、怎麼維護?」(項次 2、3、4)、「依據哪些標準?」(項次 5)、「有什麼測試證據?」(項次 6)、停在正式承諾(項次 7)、再加一個可以獨立拿出來的工程成品(項次 8)。

「CRA 技術檔案必須在整個 support period 內持續維護。EMC 檔案是凍結的;CRA 檔案是活的。」

三個實務特徵讓 CRA 技術檔案跟過去的 CE 標示制度不一樣。

它是活的、不是凍結的。第 31(2) 條要求技術檔案要視情況更新,項次 1(b) 抓的是「影響合規的軟體版本」、代表任何會改變合規狀態的韌體 / 軟體版本、都會觸發技術檔案更新。這在 CE 標示制度裡是異類。EMC 技術檔案一旦寫好、除非產品被實質修改、基本上是穩定的。CRA 技術檔案則必須在整個 support period 內持續維護。軟體產品每週或每月更新很正常;硬體產品則跟著韌體版本走。

跨多部法規合在一起。第 31(3) 條要求一份技術檔案涵蓋所有適用的聯盟法律。一個同時受 CRA + RED + 機械 + AI Act 四部法規規範的產品、需要一份技術檔案、不是四份。長期看工作量會減少、但前期整合很吃重,第一次建立統一的檔案結構是不小的工作。實務上多數組織用結構化的儲存庫(通常是 Git 或文件管理系統)維護檔案、各區段對應各法規附件的要求。

保存期很長。第 13(12) 條加上附件八各 module 都要求:投入市場後至少 10 年、或 support period(取較長者)。support period 15 年的產品、檔案要保存 15 年(不是 10 年)。這是營運紀律、不只是歸檔,檔案必須一直可以取得、可以搜尋、而且格式在第 15 年還能打開。綁死在某個廠商當前版本軟體的專屬格式、是靜默的定時炸彈;標準格式(PDF/A、HTML、Markdown、純文字)才能熬過十年的工具世代轉換。

從稽核員的角度看 8 項在問什麼。第一次接觸技術檔案的稽核員、可以依序問:(1) 這是什麼產品、哪個版本、長什麼樣、使用者看到什麼?(2) 怎麼架構的、SBOM 包含什麼、弱點處理怎麼運作?(3) 製造商識別了哪些風險、怎麼對應到附件一?(4) 為什麼 support period 這麼長?(5) 採用了哪些標準、沒採用的部分用什麼替代?(6) 做了哪些測試、結果如何?(7) 製造商正式聲明什麼?(8) 如果要深入看 SBOM、在哪裡?這 8 個問題序列就是合規故事,一份不能依序回答這些問題的技術檔案、就是有缺口的。

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

Engineering-system realities for APAC manufacturers APAC 製造商面對的工程系統現實

Annex VII looks similar to technical-file annexes in other EU product regulations. That surface similarity hides meaningful structural differences that affect how APAC engineering organisations have to work. Four realities to internalise.

附件七表面上看起來像其他 EU 產品法規的技術檔案附件。但這個表面相似掩蓋了結構上的實質差異,而那些差異會影響 APAC 工程組織的工作方式。四個現實值得吸收。

1. SBOM is infrastructure, not output 1. SBOM 是基礎建設、不是輸出

Item 2(b) makes SBOM part of the technical file; item 8 requires providing it to market surveillance on reasoned request. To make this workable, the SBOM has to be generated automatically as part of the build pipeline — not hand-assembled when a request arrives. APAC firmware teams that currently rely on manual component-list spreadsheets face a tool-chain investment: SBOM generation via tools like Syft, Black Duck, Snyk, or CycloneDX-enabled build tools needs to be integrated into CI/CD. The file format (SPDX 2.3+ or CycloneDX 1.5+) is not mandated by the CRA but becomes the practical default. Budget €30k–€100k for the first-time tool-chain integration depending on build complexity; ongoing cost is low.

項次 2(b) 把 SBOM 納入技術檔案;項次 8 要求收到合理請求時提供給市場監督機關。要做到這件事可行、SBOM 必須在 build pipeline 中自動產生,不是請求到了才手工拼裝。目前還在用手動元件清單試算表的 APAC 韌體團隊、要面對一筆工具鏈投資:用 Syft、Black Duck、Snyk 或啟用 CycloneDX 的 build tool 產出 SBOM、整合進 CI/CD。檔案格式(SPDX 2.3+ 或 CycloneDX 1.5+)CRA 沒強制但實務上是預設。首次工具鏈整合預算 €30k–€100k、看 build 複雜度而定;持續成本低。

2. Item 3 risk assessment is the document most APAC manufacturers do not yet produce 2. 項次 3 風險評估是多數 APAC 製造商還沒產出的文件

Most EMC / safety / RF technical files do not contain anything analogous to a cybersecurity risk assessment. Item 3 requires mapping identified risks to Annex I Part I essential requirements — a methodology-driven artefact, not a checklist. Candidate methodologies include ISO/IEC 27005, STRIDE-based threat modelling, IEC 62443-3-2 risk assessment (industrial products), and risk-assessment guidance in M/606 and Fraunhofer SIT/ATHENE draft standards. APAC teams without incumbent cybersecurity risk-management practice will need to stand up this capability — typically 3–6 months with external help, longer internally. The document structure itself becomes a point of differentiation: a well-structured risk assessment makes Module B+C and H audits materially easier.

多數 EMC / 安全 / RF 技術檔案裡沒有類似網路安全風險評估的東西。項次 3 要求把識別出的風險對應到附件一第一部分的 essential requirements,這是方法論導向的成品、不是 checklist。候選方法論包括 ISO/IEC 27005、以 STRIDE 為基礎的威脅建模、IEC 62443-3-2 風險評估(工業產品)、M/606 跟 Fraunhofer SIT/ATHENE 草案標準的風險評估指引。沒有既有網路安全風險管理實務的 APAC 團隊、需要從零建這個能力,找外部協助通常 3–6 個月、純內部花的時間更長。文件結構本身會變成差異化點:結構良好的風險評估讓 Module B+C 跟 H 稽核明顯比較容易。

3. Item 4 support-period rationale needs written reasoning 3. 項次 4 support period 理由要有書面論證

Article 13(8) lists criteria (intended use, expected duration of use, typical period for similar products, relevant Union law, available guidance) that the manufacturer considers. Item 4 requires documenting "relevant information that was taken into account". This is a written-reasoning requirement — the manufacturer must explain why they chose 5 years and not 3 or 7. APAC organisations accustomed to making product-lifetime decisions internally without documenting the logic will need to change process: the decision meeting now ends with a memo, not just a calendar date. ADCO is expected to eventually publish statistics on average support periods by product category, creating a benchmark against which justification can be measured.

第 13(8) 條列出製造商要考量的準則(intended use、預期使用期、類似產品的典型期間、相關聯盟法、可用指引)。項次 4 要求記錄「所考量的相關資訊」。這是「書面論證」要求,製造商必須解釋為什麼選 5 年而不是 3 年或 7 年。習慣於內部拍板產品壽命、不記錄邏輯的 APAC 組織必須改流程:決定會議現在要以一份備忘錄結束、而不只是一個行事曆日期。ADCO 預計最終會發布各產品類別的平均 support period 統計、建立一個可以衡量「正當理由」的基準線。

4. Item 5 "where standards have not been applied" is currently the dominant case 4. 項次 5「未適用標準」現在是主流情境

As of early 2026, no hEN for the CRA has been cited in the OJEU. This means every APAC manufacturer building a CRA technical file now must describe its solutions to essential requirements without the shortcut of "applied hEN X in full". The technical file must list applied standards (ISO 27001, IEC 62443, ETSI EN 303 645, etc.) as evidence but cannot claim presumption of conformity through them until hENs are cited. This dramatically increases item 5's length — probably 3–5× the eventual post-citation steady state. Plan technical-file templates for the current "pre-citation" state, and design them to collapse to shorter form once hEN citation arrives.

截至 2026 年初、CRA 還沒有任何 hEN 在 OJEU 上被引用。這代表現在每一家正在建置 CRA 技術檔案的 APAC 製造商、都必須不靠「完整適用 hEN X」這條捷徑、自己描述對 essential requirements 的解法。技術檔案要列已採用的標準(ISO 27001、IEC 62443、ETSI EN 303 645 等)作為證據、但在 hEN 被引用之前、不能透過這些標準主張合規推定。這讓項次 5 的篇幅明顯增加,可能是引用後穩定狀態的 3–5 倍。就目前「引用前」狀態規劃技術檔案模板、並設計成 hEN 引用到位時能縮成短形式。

A practical note on item 1(c) for hardware products. "Photographs or illustrations showing external features, marking and internal layout" has historically been interpreted loosely in EMC/RED files — a datasheet image and a block diagram often sufficed. Post-CRA, market surveillance authorities investigating security incidents (an exploited debug port, an unshielded JTAG interface, an unmarked UART) will want clear visual evidence. Planning: include high-resolution photos of all surfaces, a labeled internal layout identifying debug interfaces, and explicit markings of tamper-evident seals if present. This is additional work relative to EMC practice.

硬體產品項次 1(c) 的實用提示:「顯示外部特徵、標記、內部布局的照片或插圖」過去在 EMC/RED 檔案裡被寬鬆解讀,一張規格書影像加一張方塊圖通常就夠了。CRA 之後、調查安全事件的市場監督機關(被利用的 debug port、未遮蔽的 JTAG 介面、沒標記的 UART)會要清晰的視覺證據。規劃方向:包含所有表面的高解析度照片、把 debug 介面標出來的內部布局圖、以及防拆封條(如果有)的明確標記。比起 EMC 實務、這是額外的工作。

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

Annex VII mapped to parallel technical-file regimes 附件七與其他技術檔案制度的對照

Two layers to keep separate. Other EU product regulations come with their own technical-file annexes — work done for one regulation can sometimes be reused for the CRA. International process standards are a different category — they shape how engineering work is documented but are not themselves legal instruments. 要分清楚兩層。其他歐盟產品法規各自帶有技術檔案附件,為某部法規做過的工作、有時可以拿來重用在 CRA。國際流程標準是不同類別,它們塑造工程記錄方式、但本身不是法律工具。

Layer 1 · Technical-file annexes in peer EU regulations (potential reuse) 層級一・其他歐盟法規的技術檔案附件(可能可重用)

If you have already produced these technical files for other CE-marked products, parts of that work feed directly into Annex VII. 如果你已經為其他 CE 標示產品做過這些技術檔案、部分內容可以直接餵進附件七。

Regulation法規 Technical-file annex技術檔案附件 Key structural differences from CRA Annex VII與 CRA 附件七的主要結構差異
Machinery Regulation (EU) 2023/1230 Annex IV — technical file; Annex III Part A (accompanying information)附件四,技術檔案;附件三 A 部分(隨附資訊) Machinery Annex IV is heavier on drawings, calculations, test reports for safety-specific assessments. CRA Annex VII lighter on drawings, heavier on SBOM and vulnerability handling. Both require risk assessment but different domains.機械附件四在安全特定評估的繪圖、計算、測試報告較重。CRA 附件七繪圖較輕、SBOM 跟弱點處理較重。兩者都要風險評估、但領域不同。
RED Directive 2014/53/EU Annex V — technical documentation附件五,技術文件 RED Annex V is a 7-item list broadly parallel to CRA Annex VII but with radio-performance and interference focus. RED DA 2022/30 adds cybersecurity elements that the CRA will supersede from 11 Dec 2027.RED 附件五是 7 項清單、大致跟 CRA 附件七平行、但焦點在無線電效能跟干擾。RED DA 2022/30 加入網路安全要素、CRA 從 2027/12/11 起接手。
AI Act (EU) 2024/1689 Annex IV — technical documentation附件四,技術文件 AI Act Annex IV has 9 sections covering system description, development inputs, data governance, training data, testing, accuracy/robustness/cybersecurity (Article 15), post-market monitoring. CRA Article 12(1)(c) routes the cybersecurity portion of AI Act Article 15 through CRA compliance — CRA Annex VII effectively feeds AI Act Annex IV's cybersecurity section.AI Act 附件四 9 章涵蓋系統描述、開發輸入、資料治理、訓練資料、測試、準確性 / 穩健性 / 網路安全(第 15 條)、上市後監測。CRA 第 12(1)(c) 條把 AI Act 第 15 條的網路安全部分透過 CRA 合規路由,CRA 附件七實際上餵給 AI Act 附件四的網路安全章節。
Medical Devices Regulation (EU) 2017/745 Annex II — technical documentation; Annex III — post-market surveillance附件二,技術文件;附件三,上市後監視 MDR Annex II is substantially more detailed than CRA Annex VII — clinical evaluation, UDI, device-specific identifiers, etc. Medical devices are explicitly out of CRA scope per Article 2(2)(a)-(b), so MDR and CRA files are separate. Connected medical devices with non-medical accessories may need both files for different product portions.MDR 附件二明顯比 CRA 附件七詳細,臨床評估、UDI、裝置特定識別子等。醫療器材依第 2(2)(a) 到 (b) 條明確排除在 CRA 範圍外、所以 MDR 跟 CRA 檔案是分離的。含非醫療配件的聯網醫材可能要分別做兩份檔案、對應不同產品部分。
EMC Directive 2014/30/EU Annex II — technical documentation附件二,技術文件 EMC Annex II is a 4-item minimum list — much lighter than CRA. The EMC TCF (Technical Construction File) is essentially frozen after placing on market. CRA Annex VII must be continuously updated. The engineering-culture gap between these two regimes is significant for first-time CRA filers.EMC 附件二是 4 項最低清單,比 CRA 輕得多。EMC TCF(Technical Construction File)在投入市場後大致就固定不動。CRA 附件七必須持續更新。兩個制度的工程文化落差對首次 CRA 歸檔者影響很大。

Layer 2 · International process / engineering standards (voluntary, structural input) 層級二・國際流程 / 工程標準(voluntary、結構輸入)

Voluntary international standards. Not laws, not (yet) cited as CRA hENs — but their process language maps onto Annex VII items, so manufacturers already aligned with them have a structural head start when assembling the technical file. voluntary 國際標準。不是法律、目前也還沒被引用為 CRA hEN:但它們的流程語言可以對應到附件七的項次、所以已經對齊它們的製造商在組技術檔案時、會有結構上的先發優勢。

Standard標準 Scope範圍 Mapping to CRA Annex VII與 CRA 附件七的對應
ISO/IEC 15288 + ISO/IEC 12207 System / software lifecycle processes系統 / 軟體生命週期流程 Voluntary lifecycle process standards. Their process language maps well onto Annex VII items 2(a), 2(c), and 3. Manufacturers already 15288/12207-aligned have a structural head start on item 2 — but applying these standards alone is not a CRA legal route.voluntary 生命週期流程標準。它們的流程語言可以對應到附件七項次 2(a)、2(c)、3。已經對齊 15288/12207 的製造商在項次 2 有結構上的先發優勢,但只適用這些標準本身、不是 CRA 法律路徑。
IEC 62443-4-1 prAA:2026 Secure product development lifecycle安全產品開發生命週期 Provides process-level requirements that map onto Annex VII items 2(a) and 2(b). Under revision with CRA-aligned prAA:2026 amendments. Formal CRA hEN status not confirmed — treat as strong evidence input, not as a presumption-of-conformity route.提供可對應附件七項次 2(a) 跟 2(b) 的流程層級要求。以對齊 CRA 的 prAA:2026 修訂中。正式 CRA hEN 地位未確認,當作有力的證據輸入、不是合規推定路徑。