---
title: CRA 評估目標（AO）拆分與各 AO 的建議證據
subtitle: 一條控制項包多件事的拆成可各自判定、各自收證據的評估目標；每個 AO 底下寫交什麼檔、檔裡要看到什麼、證據從哪來
eyebrow: FR-135 CRA 合規框架 · AI 依法條與 ENISA 子要求拆分，待顧問確認 · 2026-10-12
lede: CRA 框架 5 個群組 40 條控制項，其中 23 條拆成 65 個評估目標（AO），每個 AO 一句英文、可以獨立判定「有／沒有」，底下掛自己的建議證據。準備期依 AO 各開一筆收證據工作，做事的人點 AO 就看得到要交什麼。
---

## 使用前須知

- **狀態：AI 依法條與 ENISA 子要求拆分，待顧問確認。** 拆點是我們對法條的詮釋，不是官方內容；決策者裁定不等顧問、先讓流程跑起來，顧問日後有真實案件再調整。
- **依據**：AO 句與建議證據依法條原文自寫（Annex I、II：`docs/reference/CRA/annex-I-II-original-text.md`；Article 13、14：`docs/reference/CRA/article-13-14-original-text.md`）。ENISA／JRC 對照報告（JRC137340）只拿來參考「拆在哪裡」，報告與 EN 40000 的文字都不抄進框架。各 AO 的 Basis 欄只留在本檔，不進框架，客戶看不到。
- **五個群組**：Annex I Part I、Annex I Part II、Annex II，加上第 13、14 條兩組——「上市前之符合性證明」（風險評估、技術文件、符合性評估、聲明與 CE）與「上市後之持續義務」（支援期、通報、文件保存與主管機關、矯正與停業、改版持續符合）。這兩組的法源在第 13、14、28～32 條，附件一、二沒有對應的點。
- **編號規則**：`part_id` 是 `<控制項代號>_obj.<N>`，N 從 3 起（1 是條文 `_smt`、2 是控制項層建議證據 `_gdn`），`sort_order` 與 N 相同。AO 句首的 `[a]`、`[b]`… 是畫面與證據分類器看的字母，分類器從句首解析，**句首格式不能改**。
- **建議證據掛在各 AO 底下**：每個 AO 有一筆子段落 `<AO part_id>_gdn`（`name=guidance`、`parent_id` 指向 AO），內容是三段式。有 AO 的控制項，控制項層建議證據只剩一句「See assessment objectives [a]–[x].」；沒 AO 的 17 條，控制項層就是三段式（見 `cra-suggested-evidence.md`）。
- **參考來源**：每條控制項層建議證據 `_gdn` 最後一段「References」，分法條（EUR-Lex 條文錨點）、執行法規與指引、實務範例三類，來源清單在 `scripts/cra_ao_content_ext.py` 的 `REFERENCES`。
- **三段式**：`Deliverable`＝交什麼檔或紀錄；`Must show`＝審閱者要在裡面看到什麼；`Evidence`＝從哪來——`upload`（客戶自有檔上傳）、`system — <頁面>`（客戶在系統其他頁填完就有，不該再上傳）、`template — <範本>`（系統給範本，客戶填完產出）。標 `(Phase N)` 的系統落點是之後才上線的功能，在那之前先上傳。標 `system` 的 AO 由 seed 006 在 props 標上 `evidence-source`，規劃頁與稽核判定頁直接連到那個系統物件、顯示填了沒；每筆證據都是系統內的，畫面不收程序書。報告模組（Phase 3）還沒有系統物件，仍是上傳。
- **改內容改 `scripts/cra_ao_content.py`，再跑 `python scripts/gen_cra_ao_restructure.py`**：同時重產本檔、`cra-suggested-evidence.md` 的建議證據段與 jedi-oscal-v2 `migrations/005-cra-2024-ao-restructure.sql`、`006-cra-2024-ao-evidence-source.sql`。不要直接改 md 或 seed。
- **生效範圍**：只對之後新建的資源庫與專案有效（建資源庫時整份複製框架 catalog，AO 的收證據流程範本也在那時建）。既有的資源庫與專案吃不到，要重建。
- **搬移不刪除**：從 CRA.I.1 搬到 CRA.ART.13.RA 的三個 AO 在 seed 裡是改掛（換控制項與 part_id），不是刪掉重建。
- **EN 40000-1-4 出版後要替換。** CRA 調和標準預估 2027 年出版，屆時以框架新版本替換，舊專案沿用舊版。

## 總覽

| 群組 | 控制項 | AO 數 | 拆成哪幾件事 |
|---|---|---:|---|
| Annex I Part I | CRA.I.1 | 2 | 安全開發流程有執行紀錄／每個風險都有處理並對到控制項 |
| Annex I Part I | CRA.I.2.b | 3 | 預設安全設定／初始帳密唯一或首次強制變更／可重設回原始狀態 |
| Annex I Part I | CRA.I.2.c | 5 | 能用安全更新修漏洞／自動更新預設開啟且有期限／退出機制／通知使用者／可暫時延後 |
| Annex I Part I | CRA.I.2.d | 3 | 存取控制機制已設計實作／授權測試證明不能越權／偵測並回報可能的未授權存取 |
| Annex I Part I | CRA.I.2.f | 2 | 資料、指令、程式、設定受完整性保護／偵測並回報損毀 |
| Annex I Part I | CRA.I.2.h | 2 | 列出基本功能且抗 DoS 措施已測試／事件後維持或恢復 |
| Annex I Part I | CRA.I.2.j | 2 | 網路與軟體介面已限縮／含硬體者實體介面已停用或防竄改 |
| Annex I Part I | CRA.I.2.l | 4 | 記錄內部活動／紀錄防竄改／監控方式已定義並執行／使用者可退出 |
| Annex I Part I | CRA.I.2.m | 2 | 使用者可永久刪除資料與設定／資料可轉移時安全轉移 |
| Annex I Part II | CRA.II.1 | 2 | 每個發布版本有 SBOM／找出並記錄產品所含漏洞 |
| Annex I Part II | CRA.II.2 | 3 | 依風險分級並訂修補期限／期限內修補（含第三方元件）／安全更新與功能更新分開 |
| Annex I Part II | CRA.II.4 | 3 | 修補後公開已修漏洞／公開內容五要素／延後公開有理由 |
| Annex I Part II | CRA.II.8 | 3 | 不延遲發送／免費（客製例外另約）／附通告寫明使用者要做什麼 |
| Annex II | CRA.A2.8 | 6 | 使用說明 (a)～(f) 六節各一份 |
| Article 13 — before placing on the market | CRA.ART.13.RA | 3 | 風險評估有文件且涵蓋用途、可預見使用、使用條件／逐條判定適用與如何實作／支援期內更新 |
| Articles 13 and 14 — after placing on the market | CRA.ART.13.SP | 3 | 支援期至少五年並記錄依據／結束年月在購買時清楚告知／安全更新保存十年 |
| Articles 13 and 14 — after placing on the market | CRA.ART.14.RP | 3 | 通報程序與三個時限／重大事件判定標準／通報紀錄 |
| Article 13 — before placing on the market | CRA.ART.13.TD | 3 | 上市前備妥且涵蓋附件七／未採標準時說明替代做法／支援期內持續更新 |
| Article 13 — before placing on the market | CRA.ART.13.CA | 2 | 依分級選對程序並記錄理由／上市前完成並留紀錄 |
| Article 13 — before placing on the market | CRA.ART.13.DOC | 3 | 依附件五製作並簽署聲明／上市前打 CE／聲明隨變更更新 |
| Articles 13 and 14 — after placing on the market | CRA.ART.13.REC | 2 | 技術文件與聲明保存十年或支援期／主管機關要求的應對程序 |
| Articles 13 and 14 — after placing on the market | CRA.ART.13.CORR | 2 | 不符合時矯正、下架或召回／停業前通知 |
| Articles 13 and 14 — after placing on the market | CRA.ART.13.SER | 2 | 每次發版檢查符合性／實質修改的判定與後續處理 |
| **合計** | **23 條** | **65** | |

## Annex I Part I

### CRA.I.1 Risk-Based Cybersecurity by Design

拆分說明：Part I (1) 只要求「依風險做到適當水準」。風險評估文件、逐條適用判定、評估更新的法源在 Article 13，已搬到新群組 CRA.ART.13.RA；本條留「安全開發流程有執行」與「每個風險都有處理並對到控制項」兩件。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.1_obj.3 | [a] a secure development process is defined, and records show it was followed for the released version (design review, code review, security testing). | Part I (1) "designed, developed and produced in such a way"; Art. 13(2) "take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases"; ENISA 3.1.1 |
| CRA.I.1_obj.4 | [b] each identified cybersecurity risk has a recorded treatment and is mapped to the Part I (2) requirements that address it. | Part I (1) "based on the risks"; Art. 13(2) "take the outcome of that assessment into account" |

**[a] Suggested evidence**

- **Deliverable**: Secure development records for the released version: one design review record, one code review record and one security test record.
  - **Must show**: the product version they apply to; date; reviewer or tester; findings and how each was closed. The development procedure itself belongs in the Document Pool, not here.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Risk treatment table.
  - **Must show**: every identified risk with its treatment (mitigate, accept, transfer or avoid), the control measures applied and the Part I (2) requirement(s) each measure addresses; no risk left without a treatment.
  - **Evidence**: system — Risk Assessment tab (Phase 2); until available: upload the table

### CRA.I.2.b Secure-by-Default Configuration & Reset

拆分說明：預設設定、初始帳密、重設三件事證據不同（設定清單、帳密產生方式、重設測試）。客製化產品的例外併在 [a]，因為它取代的就是預設設定本身。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.2.b_obj.3 | [a] the product is made available with a secure by default configuration, or a different configuration agreed with the business user for a tailor-made product is documented. | Part I (2)(b) "with a secure by default configuration, unless otherwise agreed … tailor-made product"; ENISA 3.1.3 |
| CRA.I.2.b_obj.4 | [b] where the product ships with initial credentials, they are unique per device or installation and randomly generated, or must be changed at first use; otherwise marked not applicable. | Part I (2)(b) "secure by default configuration"; ENISA 3.1.3 (initial credentials; the regulation does not name credentials) |
| CRA.I.2.b_obj.5 | [c] the product can be reset to its original state. | Part I (2)(b) "including the possibility to reset the product to its original state"; ENISA 3.1.3 |

**[a] Suggested evidence**

- **Deliverable**: Factory default configuration list.
  - **Must show**: every security-relevant setting, its default value and why that value is secure.
  - **Evidence**: upload
- **Deliverable**: For a tailor-made product: the agreement with the business user on a different configuration.
  - **Must show**: the parties; the settings that differ from the secure default; signature and date.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Description of how initial credentials are generated, or a screenshot of the forced change at first login.
  - **Must show**: that each device or installation gets a different, randomly generated credential, or that the product refuses to continue until the credential is changed.
  - **Evidence**: upload

**[c] Suggested evidence**

- **Deliverable**: Reset procedure and a test record of a reset.
  - **Must show**: the steps a user follows; that after the reset the settings match the factory default list in [a]; test date and product version.
  - **Evidence**: upload

### CRA.I.2.c Security Updates & Automatic Updating

拆分說明：法條一句列了五件事：能用安全更新修漏洞、自動更新預設開啟且有期限、退出機制、通知使用者、可延後。截圖與設計文件各不相同，拆五個 AO。支援期承諾屬 Article 13(8)，在 CRA.ART.13.SP。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.2.c_obj.3 | [a] vulnerabilities can be addressed through security updates, verified for integrity and authenticity before installation. | Part I (2)(c) "ensure that vulnerabilities can be addressed through security updates"; ENISA 3.1.13 |
| CRA.I.2.c_obj.4 | [b] where applicable, automatic security updates are enabled by default and installed within a stated timeframe. | Part I (2)(c) "where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting" |
| CRA.I.2.c_obj.5 | [c] a clear and easy-to-use opt-out mechanism for automatic updates is available. | Part I (2)(c) "with a clear and easy-to-use opt-out mechanism" |
| CRA.I.2.c_obj.6 | [d] users are notified of available updates. | Part I (2)(c) "through the notification of available updates to users" |
| CRA.I.2.c_obj.7 | [e] users can temporarily postpone updates. | Part I (2)(c) "and the option to temporarily postpone them" |

**[a] Suggested evidence**

- **Deliverable**: Update mechanism design.
  - **Must show**: how an update is obtained; how its signature or hash is checked before installation; what happens when the check or installation fails.
  - **Evidence**: upload
- **Deliverable**: Security Update and Decommissioning Procedure, update section.
  - **Must show**: who builds, signs and releases an update and how users receive it.
  - **Evidence**: template — Security Update and Decommissioning Procedure

**[b] Suggested evidence**

- **Deliverable**: Screenshot of the factory default update setting, and the document page stating the installation timeframe.
  - **Must show**: automatic security updates switched on out of the box; the stated timeframe (e.g. within 24 hours of availability).
  - **Evidence**: upload

**[c] Suggested evidence**

- **Deliverable**: Screenshot of the opt-out setting.
  - **Must show**: where the setting is and that one action turns automatic updates off.
  - **Evidence**: upload

**[d] Suggested evidence**

- **Deliverable**: Example of an update notification.
  - **Must show**: the message a user receives (in-product prompt, email or notice page) naming the update and how to install it.
  - **Evidence**: upload

**[e] Suggested evidence**

- **Deliverable**: Screenshot of the postpone option.
  - **Must show**: that the user can delay an update and for how long.
  - **Evidence**: upload

### CRA.I.2.d Protection from Unauthorised Access

拆分說明：「有機制」是設計文件、「各角色真的不能越權」是授權測試，兩種證據分開判；「回報可能的未授權存取」是正式版新增的第三件事。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.2.d_obj.3 | [a] control mechanisms against unauthorised access (authentication, identity or access management) are designed and implemented. | Part I (2)(d) "by appropriate control mechanisms, including but not limited to authentication, identity or access management systems"; ENISA 3.1.4 |
| CRA.I.2.d_obj.4 | [b] authorisation testing shows that each role cannot access administrative or configuration functions, or personal or protected data, beyond its permissions. | Part I (2)(d) "ensure protection from unauthorised access"; ENISA 3.1.4 |
| CRA.I.2.d_obj.5 | [c] possible unauthorised access is detected and reported. | Part I (2)(d) "and report on possible unauthorised access" |

**[a] Suggested evidence**

- **Deliverable**: Authentication and authorisation design.
  - **Must show**: login methods; identity and access management; role-permission matrix; lockout and multi-factor settings.
  - **Evidence**: upload
- **Deliverable**: Where the product includes hardware: measures against unauthorised physical access required by the risk assessment (not applicable to software-only products).
  - **Must show**: the physical measure and the risk it addresses.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Authorisation test report.
  - **Must show**: for each role, the administrative functions and protected data tried; expected and actual result; test date and product version.
  - **Evidence**: upload

**[c] Suggested evidence**

- **Deliverable**: Detection rules and an example report of possible unauthorised access.
  - **Must show**: the events that raise an alert; who or what receives the report; one example alert or event record.
  - **Evidence**: upload

### CRA.I.2.f Integrity of Data, Programs & Configuration

拆分說明：完整性保護與「回報損毀」是兩件事，證據分開（保護設計與測試 vs. 告警範例），與 I.2.d 拆出「回報」同理。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.2.f_obj.3 | [a] stored, transmitted or processed data, commands, programs and configuration are protected against modification not authorised by the user. | Part I (2)(f) "protect the integrity of stored, transmitted or otherwise processed data … commands, programs and configuration against any manipulation or modification not authorised by the user"; ENISA 3.1.6 |
| CRA.I.2.f_obj.4 | [b] corruptions are detected and reported. | Part I (2)(f) "and report on corruptions" |

**[a] Suggested evidence**

- **Deliverable**: Integrity protection design.
  - **Must show**: for stored data, data in transit, commands, programs and configuration: the mechanism used (hash, signature, message authentication code, authenticated command channel).
  - **Evidence**: upload
- **Deliverable**: Test record of the integrity checks.
  - **Must show**: a tampered program, configuration or message is rejected; test date and product version.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Example of a corruption report.
  - **Must show**: the alert, log entry or user notification produced when tampering or corruption is detected.
  - **Evidence**: upload

### CRA.I.2.h Availability of Essential & Basic Functions

拆分說明：平時可用（含抗 DoS）與事件後維持是兩種證據（防護設定與測試 vs. 復原演練紀錄）。哪些算基本功能的清單是兩者共同前提，放在 [a]。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.2.h_obj.3 | [a] the essential and basic functions are listed, and denial-of-service resilience and mitigation measures protecting them are in place and tested. | Part I (2)(h) "protect the availability of essential and basic functions … including through resilience and mitigation measures against denial-of-service attacks"; ENISA 3.1.8 |
| CRA.I.2.h_obj.4 | [b] the essential and basic functions remain available, or are restored, after an incident. | Part I (2)(h) "also after an incident"; ENISA 3.1.8 |

**[a] Suggested evidence**

- **Deliverable**: List of essential and basic functions with the denial-of-service measures that protect each.
  - **Must show**: each function; measures such as rate limits, request size and connection limits, timeouts, load balancing.
  - **Evidence**: upload
- **Deliverable**: Load, stress or rate-limit test record.
  - **Must show**: the function tested; load applied; that it stayed available; test date and product version.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Recovery drill record.
  - **Must show**: the incident simulated; the functions restored; time to restore; date.
  - **Evidence**: upload

### CRA.I.2.j Attack Surface Limitation

拆分說明：網路與軟體介面（清冊＋埠掃描，軟體團隊產出）與實體介面（硬體設計與拆機測試，硬體團隊產出）證據與負責人都不同；軟硬體客戶都用同一份框架，合在一條時硬體產品只能填單一狀態、看不出缺哪一半。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.2.j_obj.3 | [a] network ports, APIs and administrative interfaces are limited to those needed, each with a documented reason, and every endpoint callable without authentication is documented with its reason and protected. | Part I (2)(j) "limit attack surfaces, including external interfaces"; ENISA 3.1.10 |
| CRA.I.2.j_obj.4 | [b] where the product includes hardware, physical interfaces (debug, serial, USB and similar ports) are disabled, closed off or protected against tampering as required by the cybersecurity risk assessment; otherwise marked not applicable. | Part I (2)(j) "designed, developed and produced to limit attack surfaces"; ENISA 3.1.10 |

**[a] Suggested evidence**

- **Deliverable**: External interface inventory.
  - **Must show**: every network port, API and administrative interface; why each is needed; the endpoints callable without authentication, why, and how they are protected.
  - **Evidence**: upload
- **Deliverable**: Port scan result of a default installation.
  - **Must show**: only the ports in the inventory are open; scan date and product version.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Physical interface inventory with the protection applied to each.
  - **Must show**: every physical port and debug interface; whether it is disabled, closed off or protected, and how; the risk each measure addresses.
  - **Evidence**: upload
- **Deliverable**: Physical interface or tamper test record.
  - **Must show**: the interfaces tested; that disabled interfaces give no access; test date and hardware revision.
  - **Evidence**: upload

### CRA.I.2.l Recording & Monitoring of Internal Activity

拆分說明：記錄、紀錄保護、監控、退出機制四件事證據不同。[b] 紀錄防竄改法條未明文，依 ENISA 3.1.12 保留。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.2.l_obj.3 | [a] relevant internal activity, including access to or modification of data, services or functions, is recorded. | Part I (2)(l) "recording … relevant internal activity, including the access to or modification of data, services or functions"; ENISA 3.1.12 |
| CRA.I.2.l_obj.4 | [b] the records are protected against unauthorised modification or deletion. | ENISA 3.1.12 (the regulation does not state this explicitly); Part I (2)(l) "provide security related information" |
| CRA.I.2.l_obj.5 | [c] the way recorded activity is monitored (alert rules or review frequency) is defined, and records show it is carried out. | Part I (2)(l) "recording and monitoring relevant internal activity" |
| CRA.I.2.l_obj.6 | [d] an opt-out mechanism for recording and monitoring is available to the user. | Part I (2)(l) "with an opt-out mechanism for the user" |

**[a] Suggested evidence**

- **Deliverable**: List of recorded events and sample log entries.
  - **Must show**: the events recorded (logins, permission changes, configuration changes, data access and modification); one sample entry each for access to and modification of data, a service and a function.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Log protection settings.
  - **Must show**: who can read, change or delete the logs; the tamper protection used (append-only storage, forwarding to a separate system, signatures).
  - **Evidence**: upload

**[c] Suggested evidence**

- **Deliverable**: Monitoring rules and execution records.
  - **Must show**: the alert rules or the review frequency; who monitors; records of recent reviews or alerts handled. The alerts used for CRA.I.2.d [c] may be reused.
  - **Evidence**: upload

**[d] Suggested evidence**

- **Deliverable**: Screenshot of the opt-out setting.
  - **Must show**: where the user switches recording and monitoring off, and what stops being recorded.
  - **Evidence**: upload

### CRA.I.2.m Secure Data Removal & Transfer

拆分說明：永久刪除與安全轉移是兩件事，轉移是條件式（資料可轉移時才適用）。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.I.2.m_obj.3 | [a] users can securely and easily remove all data and settings on a permanent basis. | Part I (2)(m) "provide the possibility for users to securely and easily remove on a permanent basis all data and settings" |
| CRA.I.2.m_obj.4 | [b] where data can be transferred to other products or systems, the transfer is done in a secure manner; otherwise marked not applicable. | Part I (2)(m) "where such data can be transferred to other products or systems, ensure that this is done in a secure manner" |

**[a] Suggested evidence**

- **Deliverable**: Removal procedure and a test record.
  - **Must show**: the steps a user follows; that after removal the data cannot be recovered; test date and product version.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Data export or transfer design.
  - **Must show**: how transferred data is protected (encryption, authentication of the receiving side).
  - **Evidence**: upload

## Annex I Part II

### CRA.II.1 Vulnerability & Component Identification (SBOM)

拆分說明：SBOM 與漏洞清單是兩份不同產出（原始碼掃描也分開產出），拆兩個 AO。第三方元件的盡職調查（Art. 13(5)）併在 [b] 證據。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.II.1_obj.3 | [a] a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies, is drawn up for each released version. | Part II (1) "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"; ENISA 3.2.1 |
| CRA.II.1_obj.4 | [b] vulnerabilities contained in the product are identified and documented. | Part II (1) "identify and document vulnerabilities and components contained in products"; Art. 13(5) |

**[a] Suggested evidence**

- **Deliverable**: SBOM of the released version (SPDX or CycloneDX).
  - **Must show**: product version it describes; generation date; at least the top-level dependencies with their versions.
  - **Evidence**: system — Source Scan results (FR-134); until linked as evidence: upload the exported file
- **Deliverable**: SBOM files shipped with the product, where Source Scan does not cover them (e.g. container image layers, the product's own release SBOM).
  - **Must show**: the same SBOM files delivered to users; one per component or image, with the product version.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Vulnerability list of the released version, including third-party and open-source components.
  - **Must show**: each vulnerability; affected component and version; severity; status.
  - **Evidence**: system — Source Scan results (FR-134); until linked as evidence: upload the exported file
- **Deliverable**: Third-party component selection records.
  - **Must show**: how components (including open-source) are chosen and checked before integration: source, maintenance status, known vulnerabilities.
  - **Evidence**: upload

### CRA.II.2 Timely Vulnerability Remediation

拆分說明：依風險排優先（程序與期限）、在期限內修補（執行紀錄）、安全更新與功能更新分開（發布做法），三種證據不同。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.II.2_obj.3 | [a] vulnerabilities are rated and prioritised according to the risks they pose, with remediation deadlines defined per severity level. | Part II (2) "in relation to the risks posed"; ENISA 3.2.2 (deadlines per severity are practice) |
| CRA.II.2_obj.4 | [b] vulnerabilities, including those in third-party components, are remediated within the deadlines defined in [a], including by providing security updates; overdue cases have a recorded reason. | Part II (2) "address and remediate vulnerabilities without delay, including by providing security updates"; Art. 13(6) |
| CRA.II.2_obj.5 | [c] security updates are provided separately from functionality updates, or a justification is recorded where this is not technically feasible. | Part II (2) "where technically feasible, new security updates shall be provided separately from functionality updates" |

**[a] Suggested evidence**

- **Deliverable**: Vulnerability handling procedure.
  - **Must show**: the severity rating method (e.g. CVSS); the remediation deadline for each severity level; the sources monitored (vulnerability alerts from CERTs and CVE databases, dependency advisories).
  - **Evidence**: template — Security Update and Decommissioning Procedure

**[b] Suggested evidence**

- **Deliverable**: Vulnerability tracking records.
  - **Must show**: for each vulnerability: discovery date, severity, deadline, fix date, release version; the reason for each one fixed after its deadline; third-party component fixes included.
  - **Evidence**: upload

**[c] Suggested evidence**

- **Deliverable**: Release records.
  - **Must show**: security-only releases listed apart from feature releases, or the recorded reason why they cannot be separated.
  - **Evidence**: upload

### CRA.II.4 Public Disclosure of Fixed Vulnerabilities

拆分說明：修補後公開、公開內容五要素、延後公開的例外（條件式），證據各不相同。與 II.8 共用同一份安全通告，II.4 看公開內容、II.8 看隨更新發給使用者。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.II.4_obj.3 | [a] once a security update is available, information about the fixed vulnerabilities is publicly disclosed. | Part II (4) "once a security update has been made available, share and publicly disclose information about fixed vulnerabilities"; ENISA 3.2.4 |
| CRA.II.4_obj.4 | [b] the disclosure includes a description, affected product identification, impact, severity and remediation guidance. | Part II (4) "including a description of the vulnerabilities, information allowing users to identify the product … affected, the impacts …, their severity and clear and accessible information helping users to remediate" |
| CRA.II.4_obj.5 | [c] where disclosure is delayed, the justification is recorded and disclosure follows once users could apply the patch. | Part II (4) "in duly justified cases … may delay making public information … until after users have been given the possibility to apply the relevant patch" |

**[a] Suggested evidence**

- **Deliverable**: Published security advisories.
  - **Must show**: at least one advisory actually published; for each fixed vulnerability, the advisory date on or after the update release date.
  - **Evidence**: upload the published security advisories (at least one, with the vulnerabilities fixed and the versions)

**[b] Suggested evidence**

- **Deliverable**: One published security advisory.
  - **Must show**: description; affected product and versions; impact; severity; how users remediate; CVE identifier where one exists.
  - **Evidence**: template — Security Advisory

**[c] Suggested evidence**

- **Deliverable**: Record of each delayed disclosure.
  - **Must show**: why publication risks outweighed the benefits; the update release date; the final publication date. If no disclosure has been delayed, state so.
  - **Evidence**: upload

### CRA.II.8 Timely, Free Security Updates with Advisories

拆分說明：不延遲發送、免費（客製例外）、附通告三件事證據不同。通告與 II.4 共用同一份，本條看「隨更新給使用者、寫明使用者要做什麼」。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.II.8_obj.3 | [a] available security updates are disseminated without delay. | Part II (8) "they are disseminated without delay" |
| CRA.II.8_obj.4 | [b] security updates are provided free of charge, or other terms agreed with the business user for a tailor-made product are documented. | Part II (8) "unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product …, free of charge" |
| CRA.II.8_obj.5 | [c] security updates are accompanied by advisory messages stating the action users should take. | Part II (8) "accompanied by advisory messages providing users with the relevant information, including on potential action to be taken" |

**[a] Suggested evidence**

- **Deliverable**: Release timeliness records.
  - **Must show**: for each security update: fix completion date and the date it reached users.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Terms or policy stating that security updates are free of charge; for a tailor-made product, the agreement with the business user.
  - **Must show**: the clause on security update cost.
  - **Evidence**: template — Support Period Statement

**[c] Suggested evidence**

- **Deliverable**: Advisory message sent with one security update.
  - **Must show**: what was fixed; how to apply the update; any action the user must take. The advisory used for CRA.II.4 [b] may be reused.
  - **Evidence**: template — Security Advisory

## Annex II

### CRA.A2.8 Detailed Secure-Use Instructions

拆分說明：法條自己列了 (a)～(f) 六項，每項是使用者資訊裡獨立的一節。(f) 只在產品會被整合進其他產品時適用。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.A2.8_obj.3 | [a] instructions are provided on the measures needed during initial commissioning and throughout the product lifetime to ensure its secure use. | Annex II (8)(a) |
| CRA.A2.8_obj.4 | [b] instructions are provided on how changes to the product can affect the security of data. | Annex II (8)(b) |
| CRA.A2.8_obj.5 | [c] instructions are provided on how security-relevant updates can be installed. | Annex II (8)(c) |
| CRA.A2.8_obj.6 | [d] instructions are provided on the secure decommissioning of the product, including how user data can be securely removed. | Annex II (8)(d) |
| CRA.A2.8_obj.7 | [e] instructions are provided on how the default setting enabling automatic installation of security updates can be turned off. | Annex II (8)(e) |
| CRA.A2.8_obj.8 | [f] where the product is intended for integration into other products, the information the integrator needs to comply with Annex I and Annex VII is provided; otherwise marked not applicable. | Annex II (8)(f) |

**[a] Suggested evidence**

- **Deliverable**: The section of the user information (Annex II), or the URL, on secure commissioning and use.
  - **Must show**: the steps a user takes at first setup and during use to keep the product secure.
  - **Evidence**: template — Information and Instructions to the User

**[b] Suggested evidence**

- **Deliverable**: The section of the user information (Annex II), or the URL, on changes and data security.
  - **Must show**: which user changes (configuration, add-ons, integrations) can weaken data security and how.
  - **Evidence**: upload

**[c] Suggested evidence**

- **Deliverable**: The section of the user information (Annex II), or the URL, on installing updates.
  - **Must show**: the steps to install a security update.
  - **Evidence**: template — Security Update and Decommissioning Procedure

**[d] Suggested evidence**

- **Deliverable**: The section of the user information (Annex II), or the URL, on decommissioning.
  - **Must show**: the steps to take the product out of service and remove user data. The removal function itself is CRA.I.2.m [a].
  - **Evidence**: template — Security Update and Decommissioning Procedure

**[e] Suggested evidence**

- **Deliverable**: The section of the user information (Annex II), or the URL, on turning off automatic updates.
  - **Must show**: the steps to turn off automatic installation. The setting itself is CRA.I.2.c [c].
  - **Evidence**: template — Information and Instructions to the User

**[f] Suggested evidence**

- **Deliverable**: The integrator information, or the URL.
  - **Must show**: the information an integrator needs to meet Annex I and the Annex VII documentation requirements.
  - **Evidence**: upload

## Article 13 — before placing on the market

### CRA.ART.13.RA Cybersecurity Risk Assessment

Legal basis: Article 13(2)(3)(4)(7)

拆分說明：風險評估要有文件、逐條判定 Part I (2) 適用與如何實作、支援期內更新，法源都在 Article 13，從 CRA.I.1 搬來。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.13.RA_obj.3 | [a] a cybersecurity risk assessment is documented, covering the intended purpose, reasonably foreseeable use and the conditions of use (such as the operational environment and the assets to be protected), with a version and an assessment date. | Art. 13(2)(3)(4); ENISA 3.1.1（由 CRA.I.1_obj.3 搬來） |
| CRA.ART.13.RA_obj.4 | [b] for each requirement in Annex I Part I (2)(a)–(m), the assessment states whether it applies and, if so, how it is implemented; a justification is recorded for each requirement that does not apply. | Art. 13(3) "whether and, if so in what manner … are applicable … and how those requirements are implemented"; Art. 13(4) "clear justification"（由 CRA.I.1_obj.5 搬來） |
| CRA.ART.13.RA_obj.5 | [c] the assessment is updated during the support period, at least for each release and each relevant change in threats or vulnerabilities. | Art. 13(3) "updated as appropriate during a support period"; Art. 13(7)（由 CRA.I.1_obj.6 搬來） |

**[a] Suggested evidence**

- **Deliverable**: Cybersecurity risk assessment.
  - **Must show**: intended purpose; reasonably foreseeable use; conditions of use (operational environment, assets to protect); threats; impact and likelihood; treatment; residual risk; version and assessment date.
  - **Evidence**: system — Risk Assessment tab (Phase 2); purpose, misuse and environment: system — Assessed target, CRA fields

**[b] Suggested evidence**

- **Deliverable**: Applicability and implementation statement for Part I (2)(a)–(m).
  - **Must show**: for each of the 13 requirements: applies or not; if it applies, how it is implemented; if not, the justification.
  - **Evidence**: system — Applicability status and justification on each control (Planning page)

**[c] Suggested evidence**

- **Deliverable**: Risk assessment revision history.
  - **Must show**: each revision with its date and trigger (release, new vulnerability, change in threats); the latest revision is dated after the latest release.
  - **Evidence**: system — Risk Assessment tab (Phase 2); until available: upload the revision history

### CRA.ART.13.TD Technical Documentation

Legal basis: Article 13(12), Article 31, Annex VII

拆分說明：「有沒有、齊不齊」對附件七清單；未全採調和標準時的替代做法說明單獨拆，因為調和標準尚未公告，所有製造商都會走這一支，最常被挑；持續更新的證據是修訂紀錄，形狀不同。附件七第 8 點（SBOM 應主管機關要求提供）併在 ART.13.REC [b]。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.13.TD_obj.3 | [a] technical documentation is drawn up before the product is placed on the market and contains each element listed in Annex VII, points 1 to 7. | Art. 13(12); Art. 31(1)(2); Annex VII points 1–7 |
| CRA.ART.13.TD_obj.4 | [b] where harmonised standards, common specifications or European cybersecurity certification schemes are not applied or applied only in part, the documentation describes the solutions adopted to meet each essential requirement of Annex I Parts I and II. | Annex VII point 5 |
| CRA.ART.13.TD_obj.5 | [c] the technical documentation is updated during the support period, at least for each release that affects compliance with the essential requirements. | Art. 31(2) "continuously updated, where appropriate, at least during the support period" |

**[a] Suggested evidence**

- **Deliverable**: Technical documentation table of contents.
  - **Must show**: each element of Annex VII points 1 to 7 mapped to a section or annex: general description and intended purpose; software versions affecting compliance; Annex II user information; system architecture; vulnerability handling processes, SBOM, CVD policy, vulnerability contact and secure update distribution; production and monitoring processes; risk assessment; support period basis; standards applied; test reports; EU declaration of conformity.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: List of applied standards and description of alternative solutions.
  - **Must show**: each standard, specification or certification scheme applied and the parts applied; for each Annex I requirement not covered, how it is met.
  - **Evidence**: system — Applicability status and justification on each control (Planning page); export as the description of solutions

**[c] Suggested evidence**

- **Deliverable**: Technical documentation revision history.
  - **Must show**: each revision with its date, product version and trigger; the latest revision is dated after the latest release that affects compliance.
  - **Evidence**: upload

### CRA.ART.13.CA Conformity Assessment Procedure

Legal basis: Article 13(12), Article 32, Annex VIII

拆分說明：選對程序（看產品分級）和真的做完（看紀錄）是兩回事；分級錯了，後面全錯。分級判斷在受評標的已有欄位，[a] 直接連過去。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.13.CA_obj.3 | [a] the conformity assessment procedure is selected according to the product's classification (default, important class I or II, critical), and the reason for the selection is recorded. | Art. 32(1)–(4); Art. 7, 8; Annex III, IV |
| CRA.ART.13.CA_obj.4 | [b] the selected procedure is carried out before the product is placed on the market and its outcome is recorded; where a notified body is involved, its name, number and certificate are recorded. | Art. 13(12); Annex VIII |

**[a] Suggested evidence**

- **Deliverable**: Product classification and choice of procedure.
  - **Must show**: the product classification and its reasoning; the procedure chosen under Article 32; for an important class I product assessed by internal control, that harmonised standards were applied in full.
  - **Evidence**: system — Assessed target, CRA fields (product class and reason)

**[b] Suggested evidence**

- **Deliverable**: Conformity assessment record.
  - **Must show**: for internal control (module A): scope, date, assessor and the conclusion for each Annex I requirement (the audit result of this framework project can serve as the record); for notified body procedures: the certificate or examination report.
  - **Evidence**: upload

### CRA.ART.13.DOC EU Declaration of Conformity and CE Marking

Legal basis: Article 13(12)(20), Articles 28 and 30, Annexes V and VI

拆分說明：聲明本身（附件五內容、簽署、語言）、CE 標誌、日後更新是三件事，證據各不同。A2.6 只管使用者找不找得到聲明，本條管聲明本身。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.13.DOC_obj.3 | [a] an EU declaration of conformity following the structure of Annex V is drawn up, signed on behalf of the manufacturer, and made available in the languages required by the Member States where the product is made available. | Art. 28(1)(2)(4); Annex V |
| CRA.ART.13.DOC_obj.4 | [b] the CE marking is affixed before the product is placed on the market, on the product, its packaging, the declaration of conformity or, for software, the accompanying website. | Art. 30(1)(3) |
| CRA.ART.13.DOC_obj.5 | [c] the declaration of conformity is updated when the product, the standards applied or the conformity assessment change. | Art. 28(2) "Such a declaration shall be updated as appropriate" |

**[a] Suggested evidence**

- **Deliverable**: Signed EU declaration of conformity.
  - **Must show**: Annex V items 1 to 8: product name, type and identification; name and address of the manufacturer or its authorised representative; statement of sole responsibility; object of the declaration; statement of conformity; standards or specifications applied; notified body, where applicable; place and date of issue, name, function and signature. List of language versions.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Screenshot of where the CE marking is shown.
  - **Must show**: the CE marking on the declaration, product, packaging or website; for a website, that the section is reachable directly.
  - **Evidence**: upload

**[c] Suggested evidence**

- **Deliverable**: Declaration revision history.
  - **Must show**: each version of the declaration with its date and the reason for revision.
  - **Evidence**: upload

## Articles 13 and 14 — after placing on the market

### CRA.ART.13.SP Support Period

Legal basis: Article 13(8)(9)(19)

拆分說明：支援期至少五年、結束日至少到年月且購買時告知、每個安全更新保存十年，原框架沒有落點，新開一條。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.13.SP_obj.3 | [a] the support period is at least five years, or matches the expected use time where shorter, and the information used to determine it is recorded. | Art. 13(8) |
| CRA.ART.13.SP_obj.4 | [b] the end date (at least month and year) is clearly stated at the time of purchase. | Art. 13(19) |
| CRA.ART.13.SP_obj.5 | [c] each security update remains available for at least 10 years after it is issued or for the rest of the support period, whichever is longer. | Art. 13(9) |

**[a] Suggested evidence**

- **Deliverable**: Support period and the reasons for its length.
  - **Must show**: the end date; the expected use time; the factors considered (user expectations, nature of the product, support periods of integrated components).
  - **Evidence**: system — Assessed target, CRA fields

**[b] Suggested evidence**

- **Deliverable**: Support Period Statement, and a screenshot of where it is shown at purchase.
  - **Must show**: the end month and year, visible on the product page, packaging or order flow before purchase.
  - **Evidence**: template — Support Period Statement

**[c] Suggested evidence**

- **Deliverable**: Update retention policy and the archive location.
  - **Must show**: where past security updates are kept; the retention period; a past update still downloadable.
  - **Evidence**: upload

### CRA.ART.14.RP Reporting of Exploited Vulnerabilities and Severe Incidents

Legal basis: Article 14(1)–(5)

拆分說明：被利用的漏洞與重大事件要在 24 小時／72 小時／最終報告期限內通報 CSIRT 與 ENISA，原框架沒有，新開一條。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.14.RP_obj.3 | [a] a procedure is in place to notify actively exploited vulnerabilities and severe incidents to the coordinating CSIRT and ENISA via the single reporting platform, within 24 hours (early warning), 72 hours (notification) and the final-report deadline. | Art. 14(1)(2)(3)(4) |
| CRA.ART.14.RP_obj.4 | [b] criteria for classifying an incident as severe are defined. | Art. 14(5) |
| CRA.ART.14.RP_obj.5 | [c] notification records are kept. | Art. 14(2)(4) |

**[a] Suggested evidence**

- **Deliverable**: Notification procedure.
  - **Must show**: who decides to notify; the three deadlines (24 hours, 72 hours, final report within 14 days of a fix for vulnerabilities or one month for incidents); the content of each notification; the reporting platform.
  - **Evidence**: upload the notification procedure document

**[b] Suggested evidence**

- **Deliverable**: Severity criteria.
  - **Must show**: the conditions that make an incident severe: impact on availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or introduction or execution of malicious code.
  - **Evidence**: upload the severity criteria document

**[c] Suggested evidence**

- **Deliverable**: Notification records.
  - **Must show**: for each notified case: dates of awareness, early warning, notification and final report; what was sent. If nothing has been notified yet, state so.
  - **Evidence**: upload the notification records

### CRA.ART.13.REC Record Keeping and Requests from Authorities

Legal basis: Article 13(13)(22), Article 18

拆分說明：保存（有沒有存、存多久）與應對（主管機關來要時怎麼給）證據不同。授權代表是「得指定」，其委任範圍（第 18 條第 3 項）正是保存與應對，併在 [b]，不另立經濟運營者控制項。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.13.REC_obj.3 | [a] the technical documentation and the EU declaration of conformity are retained for at least 10 years after the product is placed on the market or for the support period, whichever is longer, with the storage location and responsible person recorded. | Art. 13(13); Annex VIII Part I point 4.2 |
| CRA.ART.13.REC_obj.4 | [b] a procedure is in place to answer a reasoned request from a market surveillance authority, including providing the documentation and, where requested, the software bill of materials in a language the authority can understand; where an authorised representative is appointed, the written mandate covers these tasks. | Art. 13(22); Art. 18(3); Annex VII point 8 |

**[a] Suggested evidence**

- **Deliverable**: Document retention policy.
  - **Must show**: the documents kept; where they are stored; how the retention period is counted; who is responsible.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Procedure for requests from authorities, and the authorised representative mandate if one is appointed.
  - **Must show**: who receives the request; response time; documents provided; languages available; that the mandate covers the tasks in Article 18(3)(a) to (c). If no request has been received, state so.
  - **Evidence**: upload

### CRA.ART.13.CORR Corrective Action and Cessation of Operations

Legal basis: Article 13(21)(23)

拆分說明：兩件不同的事件觸發型義務：發現不符合時的矯正，與停業前的通知。事件未發生時，紀錄部分填不適用，程序本身仍要有。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.13.CORR_obj.3 | [a] a procedure defines how non-conformity of the product or the manufacturer's processes is identified, decided and corrected, including when to withdraw or recall the product, and corrective actions taken are recorded. | Art. 13(21) |
| CRA.ART.13.CORR_obj.4 | [b] a procedure is in place to inform market surveillance authorities and users before the manufacturer ceases operations. | Art. 13(23) |

**[a] Suggested evidence**

- **Deliverable**: Non-conformity procedure and corrective action records.
  - **Must show**: sources of non-conformity (internal audit, vulnerability, authority, customer report); who decides; criteria for correction, withdrawal or recall; whom to notify; date and content of each corrective action. If none has occurred, state so.
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Cessation notice procedure.
  - **Must show**: who is notified (authorities, users); by what means; when (before cessation takes effect).
  - **Evidence**: upload

### CRA.ART.13.SER Continued Conformity of Releases

Legal basis: Article 13(14), Article 3(30)

拆分說明：每版例行檢查與實質修改判定是兩件事：前者每次發版都做，後者觸發重新評估、重新聲明、支援期重新判斷（與 ART.13.SP 連動）。

| part_id | Assessment objective | Basis |
|---|---|---|
| CRA.ART.13.SER_obj.3 | [a] each release is checked for changes affecting conformity (design, development or production process, standards applied), and the outcome is recorded. | Art. 13(14) |
| CRA.ART.13.SER_obj.4 | [b] criteria for a substantial modification are defined; when a release is a substantial modification, the conformity assessment, the declaration of conformity and the support period are revisited. | Art. 3(30); Art. 13(14); Art. 69(2) |

**[a] Suggested evidence**

- **Deliverable**: Release conformity check record.
  - **Must show**: for each release: version, date, summary of changes, whether compliance with Annex I is affected, who checked. Can be the same record as the per-release secure development record (CRA.I.1 [a]).
  - **Evidence**: upload

**[b] Suggested evidence**

- **Deliverable**: Substantial modification criteria and decisions.
  - **Must show**: the criteria (affects compliance with Annex I Part I, or changes the intended purpose); the decision for each release; for a substantial modification, how the assessment, declaration and support period were handled.
  - **Evidence**: upload