The CRA is law. Now what? CRA 生效，該怎麼做？
The CRA itself says almost nothing about how a manufacturer actually complies. The implementation detail sits in two follow-on documents — one with legal force, one still in draft. This page works through them topic by topic, starting where APAC manufacturers hit the wall first. CRA 條文本身，幾乎沒告訴製造商實際的合規做法。把施行細節補上的是兩份後續文件：一份具備法律效力，一份還在草案。這裡從 APAC 製造商最先撞到牆的地方開始，以主題討論的方式展開討論。
The two source documents兩份原始文件
Technical descriptions of the categories of important and critical products with digital elements under CRA Annex III & IV. Adopted under Article 7(4) of the CRA. This is the document that decides whether your product needs a Notified Body or not. CRA 附件三、附件四之下，important 跟 critical 產品類別的技術描述。依 CRA 第 7 條第 4 項通過。這份文件直接決定你的產品要不要走 Notified Body。
The Commission’s Article 26 guidance on how to apply the CRA. Feedback period closed 31 March 2026. Not legally enforceable — only the Court of Justice of the EU can authoritatively interpret the CRA — but it is the closest thing to an instruction manual that exists. 執委會依 CRA 第 26 條發布的適用指引。徵詢期已於 2026-03-31 結束。沒有強制適用力，只有歐盟法院能對 CRA 作權威解釋，但這是目前最接近一本說明書的東西。
The RDPS three-part test, and why most APAC SaaS still fails one of them. 你的雲端到底算不算 RDPS？三個問題就能判斷。
Whether a cloud component lives inside or outside your product’s CRA conformity scope is decided by three questions. The Commission lays them out clearly. The catch: APAC manufacturers either fail the second question and lose the cloud feature, or pass the third unintentionally and pull a SaaS vendor into their conformity assessment by accident. 一個雲端元件要不要納入產品的 CRA 範圍，三個問題就決定了。執委會講得很清楚，問題是 APAC 製造商常常第二題就答錯、把雲端功能搞掉；或是不小心答對第三題、把 SaaS 廠商一起拖下水。
All twenty-six important and critical product categories, drawn as one map. CRA 把產品分成 26 類。你的產品落在哪一類？
Class I has 19 categories. Class II has 4. Annex IV (Critical) has 3 more. The technical descriptions are scattered across an Implementing Regulation that almost no one reads end to end. Here’s the consolidated picture, with the borderline cases that actually trip APAC manufacturers up. Class I 有 19 類、Class II 有 4 類、附件四 Critical 還有 3 類。這些技術描述散在一份幾乎沒人讀完的執行法規裡。這篇把整張圖拼起來，順便標出 APAC 製造商最容易踩錯的那幾條邊界。
Where does “core functionality” sit when a product does five things? 產品做五件事，哪一件才是 core functionality？
A SOAR has SIEM functions. A router has firewall functions. An OS has browser functions. None of these is automatically classified by the embedded function — the rule is the product’s own core functionality. This decides whether you go through a Notified Body or not. SOAR 有 SIEM 功能。Router 有 firewall 功能。OS 有 browser 功能。但這些都不會讓產品被「升等」到那個類別去；真正決定分類的是產品本身的 core functionality。這個判斷直接決定你要不要走 Notified Body。
The four questions a software update must answer before you ship. 這次更新算不算 substantial modification？四題自己問。
Not every update is a substantial modification. The Commission's logic distills into four questions, with worked examples. Get this wrong and you trigger a fresh conformity assessment for a routine patch — or worse, ship a substantial modification thinking it was routine. 不是每次更新都算 substantial modification。執委會的判斷邏輯可以拆成四個問題、加上一堆示例。判斷錯一次，你不是把例行 patch 拖去重新走 conformity assessment，就是把實質變更當例行更新出貨了。
Free-and-open-source software, and the six sub-tests for “commercial activity”. 你的 FOSS 專案到底有沒有「商業活動」？六題自己對。
The CRA does not regulate FOSS unless it’s placed on the market “in the course of a commercial activity”. The guidance breaks that into six sub-tests — charging a price, monetisation of services, support, donations, financing, integration — and a not-for-profit carve-out. The donation rule alone is enough to change product strategy. CRA 不管 FOSS，除非它是在「商業活動」之下被投入市場。指引把這個概念拆成六題：收費、服務變現、支援、捐贈、贊助、整合，再加一個非營利豁免。光是捐贈那一條，就足以改變一個專案的策略。
Legacy products: no redesign, but a present-day risk assessment is non-negotiable. 2027 前設計的舊產品要不要重做？答案是不用，但別高興太早。
Products designed before 11 December 2027 do not have to be re-engineered. They do have to demonstrate, today, that they meet the essential requirements based on their intended purpose. The Commission allows product-family grouping; it does not allow historical reconstruction as a substitute. 2027-12-11 之前設計的產品不必重新工程改造。但你今天就得拿出一份風險評估、證明它符合 essential requirements。執委會允許用 product family 一起評，但不接受用歷史文件回推當作替代。
Integrating an important component does not make the whole product important. 我用了一顆 important 的晶片，整台機器是不是也變 important？沒有。
The classification does not propagate from component to product. An app embedding a browser is not a browser. A laptop with a secure element is not a smartcard. The rule is clean — but APAC integrators routinely over-classify themselves into Notified Body work that wasn’t required. 分類不會從元件「傳染」到主機。一個內嵌 browser 的 app 不是 browser；一台裝了 secure element 的筆電不是 smartcard。規則本身很乾淨，但 APAC 整合者常常自己把自己分類得太重，跑去做不必要的 Notified Body 流程。
Risk cannot be transferred to the user. Not by ToS, not by manual, not by disclaimer. 風險想塞給使用者？EULA、說明書、免責聲明，都救不了你。
The Commission states it plainly: cybersecurity risk cannot be shifted to the user via documentation, and commercial cost considerations are not a justification for leaving risk unaddressed. If you cannot mitigate it technically or organisationally, the product may need to change before it goes on the market. 執委會講得很白：cybersecurity risk 不能透過文件丟給使用者，商業成本也不是擱著不處理的理由。如果你沒辦法用技術或流程去緩解，那這個產品可能必須在出貨前先改。