CRA 評估目標（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].」加參考來源。
• 參考來源：每條控制項層建議證據 _gdn 最後一段「References」，分法條（EUR-Lex 條文錨點）、執行法規與指引、實務範例三類，來源清單在 scripts/cra_ao_content_ext.py 的 REFERENCES。
• 三段式：Deliverable＝交什麼檔或紀錄；Must show＝審閱者要在裡面看到什麼；Evidence＝從哪來——upload（客戶自有檔上傳）、system — <頁面>（客戶在系統其他頁填完就有，不該再上傳）、template — <範本>（系統給範本，客戶填完產出）。標 (Phase N) 的系統落點是之後才上線的功能，在那之前先上傳。標 system 的 AO 由 seed 006／014 在 props 標上 evidence-source，規劃頁與稽核判定頁直接連到那個系統物件、顯示填了沒；每條 AO 仍有任務，完成時上傳該頁匯出或截圖。報告模組（Phase 3）還沒有系統物件，仍是上傳。
• 改內容改 scripts/cra_ao_content.py，再跑 python scripts/gen_cra_ao_restructure.py：同時重產本檔、cra-suggested-evidence.md 的建議證據段與 jedi-oscal-v2 migrations/014-cra-2024-fill-missing-ao.sql（005／006 已出貨，給路徑才重產）。不要直接改 md 或 seed。
• 生效範圍：只對之後新建的資源庫與專案有效（建資源庫時整份複製框架 catalog，AO 的收證據流程範本也在那時建）。既有的資源庫與專案吃不到，要重建。
• 搬移不刪除：從 CRA.I.1 搬到 CRA.ART.13.RA 的三個 AO 在 seed 裡是改掛（換控制項與 part_id），不是刪掉重建。
• EN 40000-1-4 出版後要替換。 CRA 調和標準預估 2027 年出版，屆時以框架新版本替換，舊專案沿用舊版。

CRA.I.1 Risk-Based Cybersecurity by Design

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

[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.a No Known Exploitable Vulnerabilities

拆分說明：「上市時沒有已知可利用漏洞」要看三件事：有沒有做過評估（掃描報告）、評估出來的東西怎麼處理（發布核准紀錄）、有做滲透測試時發現有沒有追到結案。三份證據不同，拆三個 AO。

[a] Suggested evidence

• Deliverable: Pre-release vulnerability scan reports for the released version (source code, third-party dependencies, container images).
  • Must show: product version scanned; scan date; tool name and version; every finding with its severity and status.
  • Evidence: system — Source Scan results (FR-134); until linked as evidence: upload the exported file; container image scans (e.g. Trivy, Grype): upload

[b] Suggested evidence

• Deliverable: Release gate record.
  • Must show: the decision to release; the list of vulnerabilities still open at release, each with the reason it is not exploitable or how it is mitigated; who approved and when.
  • Evidence: upload

[c] Suggested evidence

• Deliverable: Penetration test or independent security assessment report, where one was performed.
  • Must show: scope and version tested; test dates; findings and their remediation status.
  • Evidence: upload

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

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

[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。

[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

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

[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.e Data Confidentiality

拆分說明：法條點名「靜態與傳輸中加密」，ENISA 另列金鑰管理。演算法清冊、TLS 掃描、金鑰設計三種證據各看一件事，拆三個 AO。

[a] Suggested evidence

• Deliverable: Cryptography inventory for data at rest and in transit.
  • Must show: each algorithm and key length; where it is used; the deprecation list it was checked against (name and version, e.g. ECCG agreed cryptographic mechanisms or NIST SP 800-131A).
  • Evidence: upload

[b] Suggested evidence

• Deliverable: Encryption test result, such as a TLS configuration scan.
  • Must show: target, date and tool; no weak protocol or cipher accepted.
  • Evidence: upload

[c] Suggested evidence

• Deliverable: Encryption and key management design.
  • Must show: which stored data is encrypted and how; how keys are generated, stored and rotated; TLS versions and cipher suites enabled by default; certificate issuance and validation.
  • Evidence: upload

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

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

[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.g Data Minimisation

拆分說明：資料最小化分「收什麼」與「留多久」兩件事：資料清冊看收集範圍，保存與刪除規則看留存期間，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Data inventory.
  • Must show: each data item the product collects or processes; its purpose; why it is necessary for the intended purpose; where it is sent.
  • Evidence: upload

[b] Suggested evidence

• Deliverable: Retention and deletion rules.
  • Must show: how long each data item is kept and how it is deleted when no longer needed.
  • Evidence: upload

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

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

[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.i Limiting Impact on Other Devices & Networks

拆分說明：降低對其他設備與網路的衝擊，ENISA 拆成「只連必要目的地」與「不淹沒對方」兩類子要求，證據分別是連線清冊與重試／逾時設定，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Outbound connection inventory.
  • Must show: each destination, purpose and frequency; that the product connects only where needed.
  • Evidence: upload

[b] Suggested evidence

• Deliverable: Retry, timeout and back-off settings.
  • Must show: the values that stop the product from flooding busy or unresponsive services, and any bandwidth or request-rate cap.
  • Evidence: upload

CRA.I.2.j Attack Surface Limitation

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

[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.k Exploitation Mitigation & Incident Impact Reduction

拆分說明：降低事件衝擊分架構層（攻破一處拿不到全部）與技術層（降權、記憶體保護、沙箱等緩解技術），證據是架構圖與緩解技術清單，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Architecture diagram with isolation boundaries.
  • Must show: network segments, containers, sandboxes and privilege separation; what an attacker who compromises one part still cannot reach.
  • Evidence: upload

[b] Suggested evidence

• Deliverable: List of exploitation mitigation techniques applied.
  • Must show: e.g. for software: running without root privileges, dropped capabilities, memory protections, sandboxing; for hardware: secure boot, firmware privilege separation, memory isolation; where each is applied.
  • Evidence: upload

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

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

[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

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

[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

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

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

[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

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

[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.3 Regular Security Testing & Review

拆分說明：「有效且定期」要分開看：有沒有計畫、有沒有照計畫做、有沒有自動化。三種證據不同，拆三個 AO。

[a] Suggested evidence

• Deliverable: Security test plan.
  • Must show: test types, frequency and scope; high-risk components covered first.
  • Evidence: upload

[b] Suggested evidence

• Deliverable: Recent security test reports.
  • Must show: execution dates that follow the planned frequency; product version tested; findings.
  • Evidence: upload

[c] Suggested evidence

• Deliverable: Automated security test configuration and run records, where tests run on each build or release.
  • Must show: the pipeline step that runs the tests and recent run results.
  • Evidence: upload

CRA.II.4 Public Disclosure of Fixed Vulnerabilities

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

[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.5 Coordinated Vulnerability Disclosure Policy

拆分說明：法條要求「訂定並執行」，政策文件與執行紀錄是兩份證據，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Coordinated vulnerability disclosure policy.
  • Must show: intake channels; response time commitments; how reporters are kept informed; disclosure timeline. Its public URL is taken from the assessed target.
  • Evidence: template — CVD Policy; URL: system — Assessed target, public links

[b] Suggested evidence

• Deliverable: Records showing the policy is enforced.
  • Must show: for each report received: receipt, response, fix and disclosure dates. If no external report has been received yet, a record of an internal exercise that ran a simulated report through the process.
  • Evidence: upload

CRA.II.6 Vulnerability Information Sharing & Reporting Contact

拆分說明：法條一句兩件事：提供通報聯絡處、促進含第三方元件在內的漏洞資訊分享（Art. 13(6) 要通報元件維護者）。聯絡窗口在系統內、分享紀錄要上傳，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Vulnerability reporting contact address.
  • Must show: the published email address, web form or PSIRT contact, and where it is published.
  • Evidence: system — SSP parties, vulnerability-contact role

[b] Suggested evidence

• Deliverable: Records of measures taken to share vulnerability information.
  • Must show: how reports are passed on, including notifications to maintainers of third-party and open-source components about vulnerabilities found in their components (Art. 13(6)) and any fix shared with them.
  • Evidence: upload

CRA.II.7 Secure Update Distribution

拆分說明：安全派送分產品端（驗簽章）與發行端（官方管道、誰能發布、公布雜湊），證據不同，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Update signing and verification design.
  • Must show: the code-signing certificate used; how the product verifies the signature and publisher before installing.
  • Evidence: upload

[b] Suggested evidence

• Deliverable: Distribution channel description.
  • Must show: official download sites or registries; who can publish to them; published hashes and how users verify them. Automatic installation on the product side is covered by CRA.I.2.c.
  • Evidence: upload

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

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

[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

CRA.A2.1 Manufacturer Identity & Contact Details

拆分說明：第 1 項列了身分（名稱、商號、商標）與聯絡方式（地址、電子聯絡、網站）兩類資訊，拆兩個 AO；證據都是系統內製造商角色加使用者資訊範本。

[a] Suggested evidence

• Deliverable: Manufacturer identity and contact details.
  • Must show: name or registered trade name or trademark; postal address; email or other digital contact; website where available.
  • Evidence: system — SSP parties, manufacturer role
• Deliverable: The page of the user information (Annex II) showing these details.
  • Must show: the same details as recorded in the system, in a language users and market surveillance authorities understand.
  • Evidence: template — Information and Instructions to the User

[b] Suggested evidence

• Deliverable: Manufacturer identity and contact details.
  • Must show: name or registered trade name or trademark; postal address; email or other digital contact; website where available.
  • Evidence: system — SSP parties, manufacturer role
• Deliverable: The page of the user information (Annex II) showing these details.
  • Must show: the same details as recorded in the system, in a language users and market surveillance authorities understand.
  • Evidence: template — Information and Instructions to the User

CRA.A2.2 Vulnerability Reporting Contact & CVD Policy

拆分說明：第 2 項列了通報窗口與揭露政策位置兩件事，前者在系統內參與單位、後者在受評標的公開網址，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Single point of contact for vulnerabilities.
  • Must show: the contact for reporting and receiving vulnerability information.
  • Evidence: system — SSP parties, vulnerability-contact role
• Deliverable: The page of the user information (Annex II) showing the contact.
  • Must show: the same contact as recorded in the system; at least one means of contact that is not an automated tool (Art. 13(17)).
  • Evidence: template — Information and Instructions to the User

[b] Suggested evidence

• Deliverable: Location of the coordinated vulnerability disclosure policy.
  • Must show: where the CVD policy can be found (a web address or an accompanying document).
  • Evidence: system — Assessed target, public links
• Deliverable: The page of the user information (Annex II) showing where the policy can be found.
  • Must show: the same policy location as recorded in the system.
  • Evidence: template — Information and Instructions to the User

CRA.A2.3 Product Identification

拆分說明：第 3 項只要求一件事（產品識別），一個 AO。

[a] Suggested evidence

• Deliverable: Product identification.
  • Must show: product name, type and any additional identifier (model, version, batch or serial number).
  • Evidence: system — Assessed target, CRA fields
• Deliverable: Proof the identification is provided with the product.
  • Must show: the user information page, label or about screen showing the same identification.
  • Evidence: template — Information and Instructions to the User

CRA.A2.4 Intended Purpose & Security Properties

拆分說明：第 4 項列了預定目的與安全環境（系統內有欄位）、基本功能與安全特性（只在使用者資訊）兩類，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Intended purpose and operating environment.
  • Must show: intended purpose; security environment provided by the manufacturer.
  • Evidence: system — Assessed target, CRA fields
• Deliverable: The section of the user information (Annex II) on intended purpose and security environment.
  • Must show: the same intended purpose and security environment as recorded in the system.
  • Evidence: template — Information and Instructions to the User

[b] Suggested evidence

• Deliverable: The section of the user information (Annex II) on essential functionalities and security properties.
  • Must show: the product's essential functionalities; its security properties.
  • Evidence: template — Information and Instructions to the User

CRA.A2.5 Foreseeable Significant Cybersecurity Risks

拆分說明：第 5 項只要求一件事（列出風險情境），一個 AO；內容要與風險評估一致。

[a] Suggested evidence

• Deliverable: Known or foreseeable circumstances leading to significant cybersecurity risks.
  • Must show: circumstances under intended use and reasonably foreseeable misuse, taken from the risk assessment.
  • Evidence: system — Risk Assessment tab (Phase 2); foreseeable misuse: system — Assessed target, CRA fields
• Deliverable: The section of the user information (Annex II) listing them.
  • Must show: the same circumstances, written for users.
  • Evidence: template — Information and Instructions to the User

CRA.A2.6 Access to the EU Declaration of Conformity

拆分說明：第 6 項只要求一件事（聲明取得方式），一個 AO；聲明本身在 CRA.ART.13.DOC 評。

[a] Suggested evidence

• Deliverable: How users can access the EU declaration of conformity.
  • Must show: either that a full copy of the declaration is provided with the product (then this item is not applicable once delivered), or the exact internet address of the full declaration where a simplified declaration is provided (Art. 13(20)). The declaration itself is assessed in CRA.ART.13.DOC.
  • Evidence: system — Assessed target, public links (EU declaration of conformity)

CRA.A2.7 Security Support Type & End Date

拆分說明：第 7 項列了支援類型與支援期結束日兩件事，拆兩個 AO；證據都是受評標的欄位加支援期聲明範本。

[a] Suggested evidence

• Deliverable: Type of technical security support and support period end date.
  • Must show: the type of support offered; the end date of the support period.
  • Evidence: system — Assessed target, CRA fields
• Deliverable: The section of the user information (Annex II) stating them.
  • Must show: the same support type and end date as recorded in the system.
  • Evidence: template — Support Period Statement

[b] Suggested evidence

• Deliverable: Type of technical security support and support period end date.
  • Must show: the type of support offered; the end date of the support period.
  • Evidence: system — Assessed target, CRA fields
• Deliverable: The section of the user information (Annex II) stating them.
  • Must show: the same support type and end date as recorded in the system.
  • Evidence: template — Support Period Statement

CRA.A2.8 Detailed Secure-Use Instructions

拆分說明：法條自己列了 (a)～(f) 六項，每項是使用者資訊裡獨立的一節。(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

CRA.A2.9 SBOM Access Information

拆分說明：第 9 項只要求一件事（SBOM 取得資訊，選擇性），一個 AO。

[a] Suggested evidence

• Deliverable: Where the SBOM can be accessed, if the manufacturer makes it available to users.
  • Must show: the location or request method; or a record of the decision not to make it available (this item is optional).
  • Evidence: system — Assessed target, CRA fields

CRA.A7.1 General Description of the Product

Legal basis: Annex VII (1)

拆分說明：四小點證據來源不同：用途與版本系統已有欄位；硬體照片只有硬體產品要（軟體產品標不適用）；使用者資訊本身由附件二整群驗，這裡只驗技術文件有收一份。

[a] Suggested evidence

• Deliverable: General description section of the technical documentation.
  • Must show: product name and type; what it does; intended purpose and operational environment; matches the assessed target's CRA fields.
  • Evidence: system — Assessed target, CRA fields (intended purpose, operational environment)

[b] Suggested evidence

• Deliverable: List of software versions covered by the documentation.
  • Must show: each version with release date and support end date; the versions in the documentation match the Versions sub-table.
  • Evidence: system — Information system, Versions sub-table (Phase 2)

[c] Suggested evidence

• Deliverable: Product photographs or illustrations.
  • Must show: external view; CE and other markings; internal layout. For software-only products, mark not applicable with a short reason.
  • Evidence: upload

[d] Suggested evidence

• Deliverable: Copy of the user information included in the technical documentation.
  • Must show: the same version as the one supplied with the product; content assessed under the Annex II controls (CRA.A2.1–A2.9), not re-assessed here.
  • Evidence: template — Information and Instructions to the User

CRA.A7.2 Design, Development, Production and Vulnerability Handling

Legal basis: Annex VII (2)

拆分說明：三小點是三份不同的東西：架構說明系統裡沒有落點要上傳；漏洞處理流程的各項本體由附件一第二部分各條驗，這裡只驗技術文件有一節把它們串起來；生產與監控流程是本框架唯一沒有其他控制項在收的。

[a] Suggested evidence

• Deliverable: Architecture and design description.
  • Must show: architecture diagram; main components and their interfaces; data flows; trust boundaries; how the design addresses the Annex I Part I requirements.
  • Evidence: upload

[b] Suggested evidence

• Deliverable: Vulnerability handling section of the technical documentation.
  • Must show: one section that references each item: SBOM (CRA.II.1), CVD policy (CRA.II.5), reporting contact (CRA.II.6), secure update distribution (CRA.II.7). The items themselves are assessed under those controls.
  • Evidence: upload

[c] Suggested evidence

• Deliverable: Production and monitoring process description and validation record.
  • Must show: build and release pipeline; production controls (for hardware: manufacturing and provisioning); how deployed products are monitored; how and when these processes were validated, with results.
  • Evidence: upload

CRA.A7.3 Cybersecurity Risk Assessment in the Technical Documentation

Legal basis: Annex VII (3), Article 13(2)(3)

拆分說明：風險評估本身由 CRA.ART.13.RA 驗（有沒有做、涵蓋什麼、有沒有更新）；這裡只驗技術文件收錄的是那份最新版，兩者證據都在系統內。

[a] Suggested evidence

• Deliverable: Risk assessment and applicability statement included in the technical documentation.
  • Must show: the version included is the current one; each Annex I Part I requirement has an applicability status and justification. Assessed in substance under CRA.ART.13.RA.
  • Evidence: system — Risk Assessment tab (Phase 2); system — Applicability status and justification on each control (Planning page)

CRA.A7.4 Support Period Determination

Legal basis: Annex VII (4), Article 13(8)

拆分說明：支援期長度與告知由 CRA.ART.13.SP 驗；這裡只驗技術文件寫了「為什麼是這個長度」的考量依據，依據欄位系統裡已有。

[a] Suggested evidence

• Deliverable: Support period determination section.
  • Must show: the support end date; the factors considered under Article 13(8); consistent with the support end date and reason recorded for the assessed target.
  • Evidence: system — Assessed target, CRA fields (support end date and reason)

CRA.A7.5 Standards Applied and Alternative Solutions

Legal basis: Annex VII (5), Article 27

拆分說明：清單與替代做法是兩件事。CRA 調和標準尚未公告，幾乎所有製造商都要寫替代做法，最常被挑，單獨一個 AO。原本放在 CRA.ART.13.TD [b]，搬過來。

[a] Suggested evidence

• Deliverable: List of standards and specifications applied.
  • Must show: each standard, specification or scheme with its reference and edition; applied in full or in part; for partial application, the clauses applied.
  • Evidence: system — Risk Assessment tab (Phase 2) (reference standards)

[b] Suggested evidence

• Deliverable: Description of the solutions adopted.
  • Must show: for each Annex I requirement not covered by an applied standard, how it is met; may be produced from the implementation description of each control.
  • Evidence: system — Applicability status and justification on each control (Planning page)

CRA.A7.6 Conformity Test Reports

Legal basis: Annex VII (6)

拆分說明：測試計畫與執行頻率由 CRA.II.3 驗；這裡驗的是「證明符合」這個目的：技術文件收錄的報告要涵蓋附件一兩部分、且是送出版本的。產品測試與流程驗證是不同的報告，拆兩個 AO。

[a] Suggested evidence

• Deliverable: Vulnerability scan results of the version placed on the market.
  • Must show: product version scanned; scan date; findings with severity and status.
  • Evidence: system — Source Scan results (FR-134); until linked as evidence: upload the exported file
• Deliverable: Penetration test and other product conformity test reports.
  • Must show: product version tested; test date; tests performed (e.g. penetration test, configuration review); results mapped to the Annex I Part I requirements; open findings and their treatment.
  • Evidence: upload

[b] Suggested evidence

• Deliverable: Vulnerability handling process verification report.
  • Must show: how each Annex I Part II process was verified (e.g. internal audit, CVD exercise, update signing test); date; result. The audit result of this framework project can serve as the report.
  • Evidence: upload

CRA.A7.7 Copy of the EU Declaration of Conformity

Legal basis: Annex VII (7)

拆分說明：聲明本身（附件五內容、簽署、更新）由 CRA.ART.13.DOC 驗；這裡只驗技術文件收的是現行有效的那一版。

[a] Suggested evidence

• Deliverable: Copy of the EU declaration of conformity in the technical documentation.
  • Must show: the same version as the latest signed declaration; content assessed under CRA.ART.13.DOC.
  • Evidence: upload

CRA.A7.8 Software Bill of Materials on Request

Legal basis: Annex VII (8), Article 13(22)

拆分說明：SBOM 的產出由 CRA.II.1 驗；這裡驗的是「應主管機關要求時拿得出來」：每個版本的 SBOM 有保存、找得到。原本併在 CRA.ART.13.REC [b]，搬過來，REC 只留應對程序。

[a] Suggested evidence

• Deliverable: SBOM retention.
  • Must show: where the SBOM of each released version is stored; that the SBOM of the version on the market can be retrieved; who provides it on request.
  • Evidence: system — Source Scan results (FR-134); until linked as evidence: upload the exported file

CRA.ART.13.RA Cybersecurity Risk Assessment

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

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

[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

拆分說明：本條只管技術文件這件事本身：上市前有沒有、編排找不找得到、有沒有持續更新。附件七每一點的內容由附件七群組（CRA.A7.1～A7.8）各自判定，不在這裡重複。

[a] Suggested evidence

• Deliverable: Technical documentation with its issue date.
  • Must show: issue date earlier than the date the product was placed on the market; the product version it covers.
  • Evidence: upload

[b] Suggested evidence

• Deliverable: Technical documentation table of contents.
  • Must show: each Annex VII point mapped to a section or annex; languages available. The content of each point is assessed under CRA.A7.1–A7.8.
  • Evidence: upload (the Annex VII technical documentation exported from the system can be used)

[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] 直接連過去。

[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 只管使用者找不找得到聲明，本條管聲明本身。

[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

CRA.ART.13.SP Support Period

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

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

[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，原框架沒有，新開一條。

[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]，不另立經濟運營者控制項。

[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. SBOM on request is assessed under CRA.A7.8.
  • Evidence: upload

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

Legal basis: Article 13(21)(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 連動）。

[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