A Taiwan firmware engineer pushes a security patch on a Tuesday. By Friday, the question is in legal: was that update a substantial modification? If it was, the product needs a fresh conformity assessment, the CE marking re-affixed, the Declaration of Conformity re-issued. If it wasn’t, the patch ships and life goes on. The difference between those two outcomes is roughly six months and €30,000. 一個台灣韌體工程師星期二推一次安全 patch。到星期五，法務問了一個問題：那次更新算 substantial modification 嗎？算的話，產品要重做 conformity assessment、重貼 CE 標誌、重發 Declaration of Conformity。不算的話，patch 出貨，日子繼續過。這兩個結果之間的差距，大概是六個月加 €30,000。
The CRA defines “substantial modification” in Article 3(30) and gives some hints in Recital 39. The Draft Guidance fills in what those hints mean in practice. Section 4.3 supplies four questions a manufacturer should answer before shipping any update. The questions don’t live in the regulation itself — they live in eight pages of Brussels prose — and they’re the cleanest decision tool the Commission has issued so far on this topic. CRA 第 3 條第 30 項定義「substantial modification」，Recital 39 給了一些提示。指引草案把那些提示在實作上的意思填出來。§4.3 給出四個製造商在出貨更新前該回答的問題。這四題不在法規本身裡——它們在八頁布魯塞爾官式文字裡——但目前是執委會在這個主題上發出來最乾淨的決策工具。
The four questions四個問題Answer these before you ship.出貨之前，先回答這些。
The Draft Guidance restates Recital 39 as four operational questions a manufacturer must answer for each update: 指引草案把 Recital 39 重新表述為四個操作性的問題，製造商要對每次更新回答：
| №編號 | Question問題 | If yes —如果 yes—— |
|---|---|---|
| Q1 | Does the update introduce new threat vectors?這次更新引入新的威脅向量嗎？ | Likely substantial modification很可能算 substantial modification |
| Q2 | Does it enable new attack scenarios?它讓新的攻擊情境變得可行嗎？ | Likely substantial modification很可能算 substantial modification |
| Q3 | Does it change the likelihood of existing attack scenarios?它改變了既有攻擊情境的發生機率嗎？ | Possibly substantial modification可能算 substantial modification |
| Q4 | Does it change the impact of existing attack scenarios?它改變了既有攻擊情境的衝擊嗎？ | Possibly substantial modification可能算 substantial modification |
If the answer to any of these is yes, and the new or altered risk was not in your original risk assessment, the update is a substantial modification. The fix is simple in principle: anticipate widely in your original risk assessment, so that future updates fall inside what you already assessed. The Commission specifically rewards manufacturers who do this. 如果任一答案是 yes，而這個新風險或變化的風險、原始 risk assessment 沒包到——這次更新就是 substantial modification。原則上的解法很簡單：原始 risk assessment 寫得廣一點，讓未來的更新都落在你已經評估過的範圍裡。執委會明確獎勵這樣做的製造商。
Worked examples具體案例Eight that the Commission supplied.執委會給的八個例子。
Section 4.3 of the Draft Guidance walks through worked examples (Examples 35-42 in the document). They’re drawn deliberately to bracket the difficult decisions. Here are the most diagnostic ones, condensed: 指引草案 §4.3 走過幾個具體案例（文件中 Examples 35-42）。它們刻意被選來涵蓋困難的判斷。下面是最具診斷性的幾個，濃縮版：
| Update更新 | Substantial?算 substantial？ | Why為什麼 |
|---|---|---|
| Adding device control to a monitoring dashboard為監控儀表板加上裝置控制功能 | YESYES | Intended purpose shifts from situational awareness to operational controlIntended purpose 從態勢感知，變成運作層的控制 |
| Auto-analysis & profiling on a personal data app為個人資料 app 加上自動分析跟輪廓建立 | YESYES | From user-controlled tool to automated decision system從使用者控制的工具，變成自動化決策系統 |
| Activating a feature already in the original risk assessment啟用一個原始風險評估已經涵蓋的功能 | NONO | Already assessed; the manufacturer foresaw it已經評估過了；製造商預見到了 |
| Adding “Remember Me” persistent login加上「Remember Me」持續登入 | YESYES | Token theft, unauthorised access, session hijacking risks not in original assessmentToken theft、未授權存取、session hijacking 的風險，原始評估沒包到 |
| Pure security patch for a buffer overflow針對 buffer overflow 的純安全 patch | NONO | Reduces risk; doesn’t change intended purpose降低風險；沒有改變 intended purpose |
| Disabling deprecated crypto, activating already-supported alternative停用過期的 crypto，啟用既支援的替代演算法 | NONO | Crypto agility was foreseen in original designCrypto agility 在原設計裡已經預見 |
| Tightening firewall rules, enforcing MFA already available強化防火牆規則、強制使用既存的 MFA | NONO | Strengthens existing security posture強化既有的安全姿態 |
| Moving from local encryption to remote encryption service (forced)從本地加密改成遠端加密服務（強制） | YESYES | Architecture changes; intended purpose fundamentally altered架構變了；intended purpose 根本上被改變 |
The size of the change is not the test. The test is whether the change introduces risks your original risk assessment did not see. 變更的大小不是測試。測試是這個變更有沒有引入你原本 risk assessment 沒看到的風險。
The “Remember Me” trap「Remember Me」陷阱Why a small UX feature triggers a fresh conformity assessment.為什麼一個小 UX 功能會觸發重新 conformity assessment。
The “Remember Me” example (Example 39 in the Draft Guidance) is worth lingering on. The feature is one checkbox on a login screen. It feels like a UX improvement. But it introduces: 「Remember Me」這個例子（指引草案中 Example 39）值得多停一下。它就是登入畫面上的一個 checkbox。感覺像一次 UX 改善。但它引入：
A new attack surface (a stored authentication token on the device); a new threat actor possibility (someone with physical access to a logged-out-but-remembered device); a new attack scenario (token theft via local malware); a new impact dimension (extended account takeover window). The original risk assessment, written for a no-persistence login flow, didn’t consider any of these. The four questions all answer yes. The product is substantially modified. 一個新攻擊面（裝置上儲存的驗證 token）；一個新的威脅行為人可能性（拿到「登出但記住的」裝置實體存取權的人）；一個新的攻擊情境（透過本地惡意軟體偷 token）；一個新的衝擊維度（更長的帳號接管時間窗）。原始 risk assessment 是為「沒有持續登入」的流程寫的，根本沒考慮這些。四題答案全部 yes。產品被 substantially modified。
The implication is uncomfortable. A “tiny” UX feature that took two engineers an afternoon to build can trigger a six-month conformity assessment cycle. The asymmetry between development cost and compliance cost is the point. The Commission is signalling: write your risk assessment widely from the start, or pay for it later one feature at a time. 這個推論很扎人。一個「小小的」UX 功能，兩個工程師一個下午就做完——可能觸發六個月的 conformity assessment 循環。開發成本跟合規成本之間的不對稱，就是重點。執委會在發出訊號：原始 risk assessment 寫廣一點，不然以後一個功能一個功能慢慢付。
The crypto-agility shelterCrypto-agility 庇護所A way to insulate yourself from future modifications.把未來的更動隔離開來的一個方法。
Example 43 in the Draft Guidance is the architectural reverse of the Remember Me trap. A manufacturer ships a product with a configurable encryption framework supporting multiple algorithms. The original risk assessment names the algorithms it currently supports, names the ones it might rotate to in future, and names the deprecation pathway for the existing ones. Crypto-agility is the design property; documented foresight is the legal property. Later, the manufacturer disables a deprecated algorithm and activates an already-supported one. Not a substantial modification. Because the original assessment foresaw it. 指引草案 Example 43，是 Remember Me 陷阱在架構上的反面。一家製造商出貨一個產品，附一個可設定的加密框架，支援多種演算法。原始 risk assessment 列出它目前支援的演算法、列出它未來可能輪替到的演算法、列出現有演算法的退役路徑。Crypto-agility 是設計屬性；有文件的前瞻性是法律屬性。後來，製造商停用一個過期演算法、啟用一個既支援的替代演算法。不算 substantial modification。因為原始評估已經預見到它。
The lesson generalises beyond crypto. If you can foresee in your original risk assessment that the product will rotate authentication methods, change network protocols, swap data-storage backends, or expand into adjacent threat models, you buy yourself the right to ship those changes as routine updates rather than substantial modifications. The cost of writing the wider assessment is small; the cost of triggering a fresh conformity assessment for every adjacent change is enormous. 這個道理可以推廣到 crypto 之外。如果你能在原始 risk assessment 預見產品會輪替驗證方式、變更網路協定、換資料儲存後端、或擴展到相鄰威脅模型——你就為自己換到「把這些變更當例行更新出貨」的權利，而不是每次都觸發 substantial modification。寫更寬的評估，成本很小；每次相鄰變更都重新做 conformity assessment，成本很大。
APAC implicationsAPAC 落地Three patterns from the firmware side.韌體端常見的三個模式。
Pattern 1: The OTA confidence trap. Many APAC IoT vendors push OTA firmware updates monthly. Their assumption: it’s an update, not a redesign, so it’s never substantial. False. The four questions get applied to each OTA. A monthly cadence does not earn a free pass. What earns a free pass is a wide original risk assessment that anticipates feature evolution. 模式一：OTA 過度自信陷阱。很多 APAC IoT 廠每月推 OTA 韌體更新。他們的假設：是更新、不是重新設計，所以永遠不算 substantial。錯。四題對每次 OTA 都要重新適用。月月推不會換來通行證。換來通行證的，是「寫得寬、預見功能演化」的原始 risk assessment。
Pattern 2: The “just a config change” defence. A Korean smart-camera vendor enables cloud-recording-by-default in a firmware update, replacing the previous SD-card-only behaviour. The change is described internally as “a configuration default change”. The Commission would not see it that way. The product’s data flow has fundamentally changed; new attack scenarios (cloud breach, MITM on the upload channel) are now in scope; this is substantial. The label on the change ticket doesn’t determine the legal nature of the change. 模式二：「只是改個 config」這種辯詞。一家韓國智慧攝影機廠在韌體更新裡，把預設行為從「只存 SD 卡」改成「預設上傳雲端」。內部把這個變更描述為「配置預設值變更」。執委會不會這樣看。產品的資料流根本變了；新的攻擊情境（雲端破解、上傳通道 MITM）現在進入範圍；這算 substantial。變更單上的標籤，不決定變更的法律性質。
Pattern 3: The compounding micro-update. Twelve OTA updates in twelve months, each individually small, none individually substantial. By month 13, the product looks nothing like its day-one risk assessment. Nothing in the CRA addresses this directly — but it’s a market surveillance authority’s favourite finding. The defensive practice: keep your risk assessment alive. Update it whenever the four questions move, even when no individual update meets the substantial threshold. Article 13(3) says the risk assessment must be updated “throughout the support period”. Living document, not snapshot. 模式三：累積微更新。12 個月推了 12 次 OTA，每次單獨看都很小，每次單獨都不到 substantial 門檻。到第 13 個月，產品已經完全不像第一天那份 risk assessment 寫的了。CRA 沒有直接處理這件事——但這是市場監督機關最愛的發現。防禦性的做法：讓你的 risk assessment 活著。每次四題的答案有變動就更新它，即使單一更新沒到 substantial 門檻。第 13 條第 3 項說 risk assessment 必須在「整個 support period 內」持續更新。是活文件，不是快照。
What to do tomorrow明天就做的事Build the four questions into your release checklist.把四題寫進你的 release checklist。
Add four checkboxes to the form your engineers fill out before pushing any update to production. Q1 to Q4. If any checkbox is yes, the release goes through a separate review track that involves your risk assessment and your CRA documentation. If all four are no, it’s a routine release. 在工程師推 production 之前要填的表單上，加四個 checkbox。Q1 到 Q4。任何一個是 yes，那次 release 走另一條評審路徑，涉及你的 risk assessment 跟 CRA 文件。四題都 no，就是例行 release。
Then once a quarter, do an independent re-read of the original risk assessment against the current product. Does it still describe the actual product? If it doesn’t, the cumulative drift is itself the substantial modification, even if no single update was. Update the assessment. The cost of keeping it alive is much smaller than the cost of being caught with a stale one. 然後每季，找個獨立的人對原始 risk assessment 跟現在的產品做一次 re-read。它還能描述真實的產品嗎？不能的話，累積的 drift 本身就是那個 substantial modification——即使單一更新沒有任何一個是。更新評估。讓它活著的成本，比被抓到拿過期評估的成本小很多。