歐盟 CRA（Cyber Resilience Act）支援期間要求

Julian Meroi · 發布日期 2026年11月13日 · 最近校閱 2026年11月13日

依網路韌性法案，每一家製造商都必須決定要在多長的期間內處理其產品的漏洞，這段期間就是支援期間。支援期間必須反映產品的預期使用期間；除非產品的預期使用期間較短，否則至少應為 5 年；其結束日期也必須在購買時讓買方清楚知悉。

本指南說明如何做出這項決定、記錄其依據、將其套用於您投放市場的各個產品單位，並規劃支援期間結束後仍持續的義務。

支援期間涵蓋的範圍

支援期間是製造商必須確保產品的漏洞（包括其組件中的漏洞）依附件 I 第二部分的漏洞處理要求獲得有效處理的期間。這項義務自產品投放市場時起，於整個支援期間內適用。第 13 條第 8 項。

這些要求包括掌握產品的組成內容、不遲延地修補漏洞、測試產品的安全性、揭露已修補的漏洞、協調式漏洞揭露政策、受理通報的聯絡地址，以及安全地散布安全更新。我們的 CRA 漏洞處理指南 說明如何運作這套流程。

支援期間的重點是漏洞處理。客服支援、新功能、維修與保固，則由您的契約及其他法律規範，其期間可能不同。使用者資訊必須載明您所提供技術安全支援的類型及支援期間的結束日期，因此在對外公布的資訊中，應將安全支援與其他服務承諾清楚區分。

這些要求適用於自 2027 年 12 月 11 日起投放市場的產品。在該日之前投放市場的產品，只有在 2027 年 12 月 11 日當日或之後經實質修改時才受規範。第 14 條的通報義務則不同：自 2026 年 9 月 11 日起即已適用，也包括較早投放市場的產品。第 69 條。

支援期間應有多長

第 13 條第 8 項訂有三項相互搭配的規則：

1. 支援期間必須反映產品的預期使用期間，並特別考量使用者的合理期待、產品的性質（包括其預期用途），以及決定具數位元素的產品使用年限之相關歐盟法。
2. 支援期間至少應為 5 年。
3. 產品的預期使用期間短於 5 年者，支援期間應與該預期使用期間相當。

5 年是最低限度。 歐盟執委會的指引指出，5 年並非所有產品的預設值。CRA 的 Recitals 說明，預期使用期間較長的產品應有較長的支援期間，並舉出主機板、微處理器、路由器、數據機、交換器、作業系統與影片剪輯工具為例。用於工業環境的產品（例如工業控制系統）的使用期間往往明顯更長。歐盟執委會指引，第 126 段。

短於 5 年的支援期間，必須是產品確實預期使用較短期間。 其理由必須來自產品的性質。Recitals 以疫情期間使用的接觸者追蹤應用程式為例。1 年的保固或 1 年的維護合約，並不能證明產品只會使用 1 年。

支援期間反映預期使用期間，但不一定與之相等。 FAQ 指出，各項標準應以符合比例原則的方式適用，因此除非預期使用期間短於 5 年，否則並不期待製造商單純將支援期間設定為等同預期使用期間。無論您選擇多長的期間，您的紀錄都必須說明各項標準如何導出該期間。FAQ 第 4.5.1 節。

關閉

確認是否有類別規則。 市場監督資料顯示特定產品類別的支援期間不足時，歐盟執委會得採納授權法令，明定該類別的最短支援期間。市場監督機關會監督製造商如何適用各項標準，其專責行政合作小組（ADCO）也將公布平均支援期間，並提供包含各產品類別指示性支援期間的指引。平均值與指示性期間是您評估時的參考資料，並不構成法定最短期間。第 52 條第 16 項。

建立決定所需的證據

您必須將決定支援期間時所考量的資訊納入技術文件，附件 VII 也將其列為技術文件的一部分。CRA 並未規定格式或評分方法。對多數產品而言，證據可分為以下幾類：

• 預期使用：客戶保有並使用這類產品多久，可依據現場資料、汰換週期、維修紀錄或客戶合約判斷；以及買方從產品本身及其銷售方式可合理期待的內容。
• 性質與預期用途：產品的功能、安裝位置，以及汰換的難易程度。硬體則應考量實體耐用性與耗損。
• 關於產品使用年限的歐盟法：適用於該產品的其他歐盟規則，是否訂定或影響其使用年限。
• 得考量的其他因素：其他製造商類似產品的支援期間、運作環境的可得性、取自第三方且提供核心功能之組件的支援期間，以及 ADCO 與歐盟執委會的指引。
• 假設與未決事項：您無法確認的事項，以及何時會再次檢查。

請依產品情況以符合比例原則的方式適用。簡單的消費性產品所需的分析，少於預期運作數十年的工業控制器。單憑銷售目標或產品藍圖，並不能確立產品的使用期間。請將證據連同連結證據與支援期間的推論一併記錄，讓團隊以外的人也能理解。

同一預期使用期間也會用於網路安全風險評估，該評估必須考量產品的預期使用期間。我們的 CRA 技術文件指南 說明支援期間的證據在技術文件中的位置。

將支援期間套用於投放市場的各個產品單位

投放市場是指產品於歐盟市場的首次供應。依歐盟產品規則，這適用於每一個產品單位，而非整個型號。型號上市的日期、單位製造的日期、首次進入歐盟供應的日期，以及客戶購買的日期，都可能不同。請依據您的銷售與物流紀錄，確定每一個單位或每一批次首次在歐盟供應的時間。《藍皮書》第 2.3 節。

依 FAQ，已投放市場的單位在其支援期間結束後仍可繼續銷售。您之後才投放市場的同型號單位，則須依第 13 條第 8 項設定其自身的支援期間。FAQ 第 4.5.3 節。

由此產生兩項結果：

• 轉售不會開始新的支援期間。 經銷商或使用者轉售已投放市場的單位時，並非新的投放市場，因此該單位保有原本的結束日期。
• 整個型號採用單一結束日期須經檢查。 若您持續數年將同一型號的單位投放市場，所有單位共用一個結束日期，必須長到足以涵蓋您最後投放的單位，才符合第 13 條第 8 項。否則，請評估每一個新批次，並為其訂定各自的結束日期。

檢查供應商與平台的支援範圍

取自第三方且提供核心功能之組件的支援期間，是您得考量的因素之一，但並不會限縮您的義務。在您的支援期間內，您必須處理整個產品的漏洞，包括其自身支援已終止之組件中的漏洞。組件的漏洞若無法透過緩解措施充分處理，FAQ 期待您以其他方式修補，例如更換該組件或自行開發修補。FAQ 第 4.3.7 節。

訂定支援期間時，請預先規劃：

• 列出提供核心功能的組件及其已公告的終止支援日期。SBOM 是起點；我們的 CRA 軟體材料清單（SBOM）要求指南 說明如何建立 SBOM。
• 對於支援早於您結束的每一個組件，記錄您將如何填補這段缺口：延長支援協議、規劃中的移轉、更換組件或自行維護。
• 記錄仍待確認的事項，例如尚未簽署的供應商報價，或尚未測試的移轉。

供應商終止支援本身並不會縮短您的支援期間，CRA 也沒有規定支援期間須依循最短或最長的組件。組件本身若為 CRA 產品，其製造商負有自身的漏洞處理義務，可減輕您的工作，但您仍須對整個產品負責。若您為組件開發了修補，必須將其分享予維護該組件的個人或實體。

軟體版本與實質修改

每一個經實質修改的軟體版本，都需要各自宣告的支援期間。 軟體經常以一系列經實質修改的版本發布。歐盟執委會的指引指出，每一個投放市場的此類版本都需要符合第 13 條第 8 項的支援期間，包括 5 年的最短期間，除非可證明該版本的預期使用期間較短。

符合兩項條件時，您得僅就最新版本進行修補。 您將較新的經實質修改版本投放市場後，得僅就最後投放市場的版本處理及修補漏洞，但須符合以下條件：

1. 較早版本的使用者可免費取得最新版本；且
2. 使用者無須為調整其使用原版本的硬體與軟體環境而額外負擔成本。

第 13 條第 10 項。

歐盟執委會的指引以務實方式解讀「額外成本」。 指引將套用更新或維持安全運作環境本身所需的合理作業投入視為正常，包括人員時間、例行測試、組態調整，以及為處理生命週期已結束之組件或已知漏洞所需的底層軟體相依套件升級。強制購買新硬體、更換基礎架構與根本性變更運作環境，則屬額外成本。請依您的客戶實際升級時必須進行的工作來檢視。歐盟執委會指引，第 130 段。

此彈性僅涵蓋修補。 在支援期間內，其他漏洞處理要求仍然適用，例如協調式漏洞揭露政策與促進潛在漏洞資訊分享的措施，第 14 條的通報義務亦同。停止修補較早版本時，指引期待您在技術上可行的情況下，告知尚未升級的使用者。若硬體（例如智慧型手機）無法執行其出貨時作業系統的最新版本，Recitals 期待在支援期間內，至少為最新的相容版本提供安全更新。

指引並確認，只要使用者能免費且無額外成本地升級至最新版本，您仍得選擇繼續修補較早版本，包括以付費方式或依其他商業條件提供。

已投放市場產品的實質修改

實質修改是指產品投放市場後所為、影響其是否符合附件 I 第一部分要求，或改變其受評估之預期用途的變更。經修改的產品於市場上供應時，視為新產品，因此必須重新決定其支援期間。並非每一次更新都是實質修改，指引一般也不將翻新、維護或維修視為實質修改。請先判定變更的類型，並無論結論為何都記錄其理由。第 3 條第 30 款。

依歐盟執委會的指引，實質修改須依第 13 條第 8 項的標準重新評估，但不會自動重設或延長支援期間。關鍵在於該修改是否改變了決定原本預期使用期間的因素：

• 若未改變，支援期間依原本決定的剩餘預期使用期間計算，即使剩餘期間不足 5 年亦同。這通常發生在原本的期間取決於硬體的實體耐用性，而修改只涉及軟體功能或後端服務的情況。
• 若有改變，請依新的預期使用期間重新計算支援期間。指引舉出的例子是可程式邏輯控制器（PLC）的運算平台改為設計使用年限明顯更長的組件。

歐盟執委會指引，第 133 段至第 135 段。

這與將未修改型號的新單位投放市場是不同的問題，後者已在前面幾節說明。

訂閱制軟體

Recitals 承認，某些軟體依其性質只能以訂閱方式提供，特別是訂閱到期後使用者即無法再使用、因而不再使用的軟體。此時其預期使用期間可能短於 5 年。FAQ 舉出的例子是企業防毒軟體：它仰賴最新的病毒碼，只有在訂閱有效時才能運作，訂閱到期後即無法存取。FAQ 第 4.5.2 節。

單憑收費模式並不能證明預期使用期間較短。若客戶停止付費後仍可繼續使用該軟體，該軟體就仍在使用中。

FAQ 也描述了另一種情況：製造商投放市場的自由與開源軟體，而該製造商只能透過銷售訂閱制付費支援服務獲取收益。FAQ 承認此類軟體在使用者停止付費後可能仍繼續使用，並指出其支援期間此時等同有效訂閱的期間。這項解釋並未載於法規本身。第 13 條第 8 項僅在產品的預期使用期間短於 5 年時，才允許短於 5 年的支援期間，而 FAQ 不具法律拘束力。若您打算依據這項解釋，請確認您的事實與 FAQ 所述情況高度相符，並在技術文件中記錄您的推論。

範例：邊緣閘道器的支援期間決定

「範例邊緣閘道器」是一款假設的工業閘道器，用於將工廠現場的機器連接至監控平台。假設其屬於 CRA 適用範圍，且所有單位均於 2027 年 12 月 11 日之後投放市場。以下數字僅為範例的一部分，並非預設值或產業最短期間。

製造商針對先前閘道器型號的維修紀錄顯示，客戶通常在 9 至 11 年後、產線改裝時汰換這類閘道器。客戶購買這款閘道器是為了長期安裝，並期待長期支援。閘道器執行第三方的嵌入式作業系統，其供應商已公告安全支援至 2035 年 12 月。團隊未發現任何歐盟規則或授權法令為此類別訂定使用年限或最短支援期間。綜合上述考量，製造商將支援期間訂為 10 年。

• 批次 A 於 2028 年 1 月首次投放歐盟市場，結束日期為 2038 年 1 月。
• 批次 B 為同一型號，於 2030 年 1 月投放市場。團隊在投放前重新評估支援期間。證據並未改變，因此批次 B 同樣為 10 年，結束日期為 2040 年 1 月。
• 轉售的批次 A 單位 保有 2038 年 1 月的結束日期。之後的銷售不會使其成為批次 B 的單位。
• 作業系統 於 2035 年 12 月失去供應商支援。閘道器的支援期間不會因此縮短。團隊必須填補至 2040 年 1 月的缺口，方式是透過韌體更新將閘道器移轉至作業系統的較新版本，或與供應商議定延長支援。
• 一項安全更新 於 2037 年 1 月發布，必須至少維持可取得至 2047 年 1 月。這並不產生持續開發新更新至 2047 年的義務。

團隊於 2030 年 1 月檢視時的紀錄如下：

這是依據 CRA 第 13 條第 8 項至第 19 項、附件 II 與附件 VII，以及歐盟執委會指引與 FAQ 的實作範例。這些紀錄欄位、狀態、負責人與工作流程選擇並非 CRA 所強制要求，各列僅為樣本。決定支援期間並說明其理由、在整個期間內處理漏洞，以及告知使用者的義務，仍具拘束力。

最關鍵的是尚待處理的那一列。在移轉完成測試或延長支援簽署之前，團隊無法證明其將如何處理 2035 年 12 月至 2040 年 1 月之間作業系統中的漏洞。

告知使用者結束日期

購買時，應以易於取得的方式，清楚載明支援期間的結束日期，至少包含月份與年份。於適用時，應標示於產品、其包裝上或以數位方式提供。使用者資訊也必須載明您所提供技術安全支援的類型。第 13 條第 19 項。

若同一型號的單位有不同的結束日期，請確保買方看到的日期與其購買的單位相符，例如依批次印製日期，並顯示於產品介面中。

支援期間結束時，就產品的性質而言技術上可行者，應向使用者顯示通知，告知其產品的支援期間已屆滿。這項條件只適用於該通知；購買時載明結束日期則一律必要。

支援期間結束後仍持續的義務

支援期間結束時，附件 I 第二部分的漏洞處理要求對該產品也隨之結束。其他幾項義務則有各自的期間：

• 通報：第 14 條仍然適用。若您知悉產品中遭積極利用的漏洞，或影響其安全性的重大資安事件，就必須通報。我們的 CRA 通報要求指南 說明觸發條件與期限。
• 已發布的安全更新：在支援期間內提供的每一項安全更新，於發布後至少應維持可取得 10 年，或維持至支援期間結束為止，以較長者為準。這是讓已發布的更新維持可取得，並不要求提供新的更新。第 13 條第 9 項。
• 技術文件與歐盟符合性聲明：於產品投放市場後至少 10 年，或於支援期間內（以較長者為準），保存以供市場監督機關查閱。
• 使用者資訊與說明：於相同期間內，使其可供使用者與主管機關取得。以線上方式提供者，在該期間內必須可取得、便於使用且持續於線上提供。
• 軟體封存：您得維護歷史版本的公開封存。若您這麼做，應以易於取得的方式清楚告知使用者使用未受支援軟體的風險。

Recitals 也請製造商考慮在支援期間結束時，將原始碼釋出給承諾繼續處理漏洞的其他企業或公眾。這是建議而非要求，且釋出原始碼需要另行進行授權條款與資安審查。

投放市場前檢視決定

在將產品或新批次投放市場之前，請確認：

• 技術文件記錄了證據、推論，以及您無法確認的事項；
• 支援期間至少為 5 年，或技術文件說明了產品預期使用期間較短的理由；
• 每一個批次與每一個經實質修改的版本，都有經評估的結束日期；
• 每一個核心組件都涵蓋至您的結束日期，或其缺口已列為有負責人與計畫的待處理事項；
• 結束日期與支援類型，出現在買方購買時看得到的每一處；
• 就軟體而言，在停止修補較早版本前，已符合第 13 條第 10 項的條件；
• 已規劃支援期間結束通知、已發布更新的可取得性，以及文件與使用者資訊的保存。

此檢核表是依據 CRA 第 13 條與附件 VII 的實作範例。CRA 並未強制要求這份檢核表；決定、記錄及告知支援期間的規則仍具強制性。

Meroi Security 如何協助

Meroi Security 可依 CRA 檢視您決定支援期間的方式，整理技術文件所需的證據，依您的結束日期檢查組件與平台的支援範圍，並為每項產品建立結束日期資訊與支援期間結束的規劃。歡迎了解我們的 CRA 合規服務。