製造商與產品的網路韌性要求 第一部分：一般要求（六之四）

BSI技術指引 TR-03183-1

適合一般產品及資訊安全產業界，具備基礎教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱歐盟與德國的BSI官方網站、洽詢各家驗證公司、諮詢顧問等。 CC BY-SA 4。0。

（見前篇）

5 風險導向方法

5.1 （網路與資訊安全）風險的相關性

根據CRA第13條及附錄一的第一部分，製造商應確保其產品設計、開發及生產符合附錄I第一部分所列的網路與資訊安全基本要求，並根據風險確保適當的網路與資訊安全水準。

為此；製造商應對凡是與PwDE相關的（網路與資訊安全）風險進行評鑑，並在產品規劃、設計、開發、生產、交付及維護階段（包含數位元素）中納入考量，以透過預防事件及降低（網路與資訊安全）衝擊來降低網路與資訊安全風險。

此處提供的方法為建立適合CRA涵蓋產品的網路與資訊安全層級，並使製造商能在整個產品生命週期中盡職運用，並依其特定使用情境採取適當的措施與流程。

風險評鑑係在不同應用情境中受到廣泛採用，因為每個決策本身就有風險。就該指引的範圍而言，「風險」一詞始終針對網路與資訊安全，目標是將對 PwDE、使用者、前後環節及連接至 PwDE 的網路的風險降低至可接受的水準。

法規中所述的「最小化minimizing」一詞不會在此份指引中予以使用，因為一般情況而言，將相關風險降至最低並非目標，這通常不可行，也非適當處理風險所必需。

5.2 風險術語/詞彙說明

風險評鑑時會使用資產、（網路與資訊安全）威脅、（網路與資訊安全）風險及（網路與資訊安全）事件」等詞彙。

資產Asset：資產是指所有值得保護且由PwDE創造、處理、儲存或以其他方式影響的資產。這些內容可包括由PwDE產品所創造、傳輸、儲存或以其他方式處理的資料、PwDE產品提供、使用或影響的網路資源、實體或其他資產，以及PwDE產品本身的完整性與正常運作，以及PwDE產品使用者的隱私、安全與健康，以及所有受PwDE影響者。

（網路與資訊安全）事件Incident：根據CRA第三條，事件「是指對網路及資訊系統安全造成實際不利影響的任何情況」。接著（資安）事件發生的是指單一與資訊安全相關的情況，對PwDE的資產安全產生不利影響。

（網路與資訊安全）威脅Threat：根據CRA第三條，威脅指「任何可能損害、干擾或以其他方式不利衝擊網路與資訊系統、系統使用者及其他人的潛在情況、事件或措施」。威脅僅會認定存在事件的潛在可能性，並不包括威脅的可能性與潛在衝擊。這種衍生表述方式係屬必要，因為某個事件只能在該事件發生後予以處理，相較之下，威脅則可用來評估潛在的資安措施，以預防、偵測及修正事件。

（網路與資訊安全）風險Risk：根據CRA第三條，網路與資訊安全風險是指因事件所造成的損失或中斷的潛在損失，應以損失或中斷的規模與事件發生機率的綜合來表述。將可能性與衝擊（損失或中斷的規模）附加於威脅中，能規劃適當的安全措施以預防、偵測及修正事件，並優先執行。

由於該技術指引僅涵蓋與網路與資訊安全相關的風險，網路與資訊安全(Cybersecurity)一詞不會在此處與事件、威脅及風險給出說明。

5.3 風險導向方法的量身打造

適當的風險處理方式高度依賴於PwDE的類型及其預期目的及可預見的使用。該技術指引中的風險處理方式乃基於ISO 31000的風險管理過程，構成風險導向方法中共通的一般活動，適用於各種PwDE產品。為了簡化特定用例的風險處理，並讓導入流程更為順暢，活動以及輸入與產出通常都可以量身打造，只要符合該指引中所列的一般面向與要求。針對特定使用情境進行量身打造的做法稱為「量身打造化」，若以鼓勵考量，本文中會多處說明之。

一般建議採用廣泛採用的標準與架構，以量身打造風險導向方法，納入現有產業對產品特定風險及其適當處理的知識。

該指引可單獨使用，或配合本章所述一般活動，與其他產業特定標準結合使用。

5.4 風險處理

如圖六所示，最小風險處理活動包括風險評鑑，包括識別、分析與評估潛在風險，並進行風險處理以降低風險至可接受水準。這兩項活動皆基於描述PwDE的風險前後環節及風險分析與評鑑準則。

ISO 31000 使用風險管理一詞，同時包含「溝通與諮詢」活動，用於與利害關係人溝通與協調風險；「審查與監督」，用於審查現有風險評鑑並回應新風險；以及「記錄與報告」，用於風險文件化。這些活動也部分包含在製造商更新風險評鑑與風險報告的義務中，若有需要，將另行說明。

圖六：風險處理概觀

5.5 風險處理作為一個流程

風險處理流程會根據組織的具體需求而個別化。一般來說，有幾個方面需要考慮：

• 風險處理是反覆進行的：無法一次性處理所有相關風險，因為即使風險評鑑最嚴謹，仍很可能仍有未被評估的風險，因為現實複雜且外部因素常常變動，風險緩解措施將引入新的或影響患者內既有的互動， 這些必須重新評估。因此，透過實施可用且結構化的流程來應對變化與不確定性，保持彈性非常重要。這不僅適用於上市前，也適用於上市後。
• 風險處理是多層次的：風險處理是 PwDE 生命週期中每個環節的一部分，根據治理、設計、開發、生產及營運等相關利害關係人，有不同層次的細緻度。這種多層次的做法將確保適當的利害關係人參與，以及多元觀點以達成良好成果。此指引將保持在產品設計的細緻度上，旨在協助技術專家準備CRA考試，同時給予他們具體實施的自由。
• 風險處理是溝通：成功風險處理的關鍵在於溝通，因為所有參與 PwDE 的人員都能提供有價值的見解與資訊，以妥善處理風險。因此，對風險保持透明並與相關利害關係人溝通非常重要。

5.6 風險處理的展望

風險處理基於參與者的專業知識及其觀點。風險處理必須在不同觀點間找到適當的平衡。風險處理的常見觀點包括：

• 資安觀點：防護與環境必須保護使用者或其他利害關係人。資安試圖評估 PwDE 中哪些面向有價值，以及如何保護它們。此觀點旨在代表使用者或其他受受 PwDE 影響實體的資安需求，並盡可能降低資安風險。
• 開發者觀點：PwDE 必須為使用者提供一個功能。開發商以功能為核心，因此風險必須與PwDE的預期目的一致評估與處理。這種觀點是為了確保 PwDE 對使用者來說仍可使用且功能正常。
• 攻擊者觀點：PwDE 會受到潛在攻擊者的威脅。攻擊者會試圖評估一個患有多重的DE是否值得攻擊，以及如何進行。這種觀點對平衡很重要，因為它實際上損害了使用者的利益。通常產品開發中沒有真正的攻擊者參與，因此這可以透過內部攻擊性安全專家（例如滲透測試員或其他資安專家）來模擬。

5.7 風險背景

風險前後環節包含執行風險評鑑所需的所有資訊。風險前後環節對特定數位元素產品高度個人化，包含以下組成部分。

5.7.1 預期目的與可預見使用

僅影響製造商的風險，例如必要的資安措施成本或資安措施對潛在商機的影響，通常不會被考慮，由製造商自行決定。

為了評估風險評鑑的範圍，有必要定義 PwDE 在網路與資訊安全的背景下。根據第13條第1款，帶有數位元素的產品僅在符合附錄一第一部分所列基本網路與資訊安全要求時，且須妥善安裝、維護、用於其預期用途或合理可預見的條件下使用，且在適用情況下已安裝必要的安全更新；製造商所制定的流程符合附錄一第一部分所列的基本資安要求。

這表示製造商可以假設其產品已用於其預期用途或其他合理可預見的使用情境。「合理可預見使用」指的使用不一定是製造商所提供的預期目的，但很可能因合理可預見的人類行為或技術操作或互動而產生的使用。

CRA也涵蓋合理可預見的濫用，這通常不屬於風險評鑑範圍，但當構成重大安全風險時，必須依第8章進行文件記錄。「合理可預見的誤用」指的是帶有數位元素的產品，其使用方式不符合其預期目的，但可能因可合理預見的人類行為或與其他系統互動而產生。使用者故意惡意或有害行為，故意危害 PwDE 或其他系統的安全，例如越獄裝置或故意設定產品不安全，通常不屬於預期目的或可預見使用範圍。

基於此假設，製造商可根據產品的預期用途及合理可預見使用來建立風險評鑑。依據第13條第3款，該規定包括多項事項
• 產品的功能性，以達成預期目的
• 可用於合理可預見用途（但不包含於預期目的）的潛在自由度
• 產品將被使用的（操作）環境（室內或室外、私人或辦公室或其他）
• 預期的目標使用者與使用情境（一般使用者或專業使用者，單人或多用戶或其他）
• 產品預期使用的時長

5.7.2 產品架構

除了預期目的與可預見用途外，產品架構對於有效風險評鑑也很重要。架構是產品的高階技術描述，應包含：
• PwDE的連接能力（廣域網、藍牙、無線區域網或其他）
• PwDE與遠端資料處理解決方案之間的（潛在）關聯與通訊
• 與其他身心障礙者（PwDE）之間的（潛在）關係與溝通
• 殘疾與環境（PwDE）的邊界

一般而言，風險前後環節也包含被評估的受害人（PwDE）範圍，因為風險評鑑，尤其是風險處理，往往只能對製造商負責的產品或零件進行充分執行。與PwDE外元件相關的風險，可能必須由其他實體處理。對於CRA範圍內的組件來說，這通常不是問題，因為它們必須以符合預期目的風險的方式設計、開發及生產，以確保適當的網路與資訊安全水準。

製造商通常對由製造商自行整合的第三方元件負責，並依據《加拿大稅務法》第13條第5款行使盡職調查。如何處理製造商整合的第三方元件相關風險，將於第5.9節討論。

5.7.3 決策準則

風險評鑑旨在識別必須處理的風險。是否需要治療風險的決定取決於該風險的潛在影響及其他因素。為了建立一個可理解且一致的評估，決策所用的因素與標準必須納入風險脈絡中。

一般建議採用現有的具體標準，基於現有的產業知識與最佳實務。

該指引所述的風險評鑑將採用三種標準：

• 影響標準包含資產類型及事件預期基礎影響的資訊，基於受影響資產類型及機密性、完整性與可用性的喪失。基礎影響可依事件持續時間、受影響資產數量或其他因素而提高。
• 似然標準包含根據產品情境所提供的既有補償，估算事件發生的可能性資訊。
• 接受準則根據潛在影響及風險發生的可能性，定義哪些風險是可接受的。

本章末將提供使用這些決策準則的策略及初步標準，製造商可依其特定流程調整使用情境。

5.8 RH_RA.1 - 風險評鑑

根據PwDE的情境，可以識別並分析PwDE潛在的資安風險。以下要求是基於ISO 31000的一般方法，旨在一般評估PwDE的網路與資訊安全風險。風險評鑑包括風險識別、風險分析與風險評鑑。

5.8.1 RH_RA.1.1 - 風險識別

5.8.1.1 RH_RA.1.1.1 - 資產識別（活動）

5.8.1.1.1 一般

為了識別產品潛在風險，必須確定因風險實現而可能受影響的受害人資產。資產是PwDE中值得保護的一切。

其中包括：
• PwDE、其組成部分與功能
• 由PwDE收集、儲存或處理的資料資產

資產清單不應包含 PwDE 以外的物件，因為這些物件無法被 PwDE 直接保護，且會變得多餘，因為所有可能受到 PwDE 影響的外部物件，在 PwDE 中都有相應的資產。

為了讓已識別的資產清單易於管理，建議根據使用情境及資產目錄的一般類型將資產分組。影響標準中的資產清單可作為資產管理的基礎。

5.8.1.1.2 輸入
• 產品具備基於預期目的及合理可預見使用方式的數位元素的功能性
• 建議：共同資產及資產類型目錄

5.8.1.1.3 控制
製造商必須識別所有 PwDE 的資產

5.8.1.1.4 輸出
• （分類）PwDE資產列表

5.8.1.1.5 參考CRA
• CRA附錄一 第一部分（1）

5.8.1.2 RH_RA.1.1.2 - 威脅建模（活動）

5.8.1.2.1 一般

可識別因先前識別資產受到威脅而對PwDE造成的潛在風險。

這包括所有可能對PwDE資產造成不利影響的威脅。這與威脅引發事件的可能性或影響無關，因為在分析與評估待識別風險時，會考慮這些因素。

一般而言，威脅取決於PwDE的預期目的及合理可預見的使用，而不考慮特定威脅行為者。一般建議採用基於現有威脅目錄的結構化威脅識別方法。

由於威脅可能影響 PwDE 的不同組成部分及其關係，威脅識別可透過資料流模型補充，以便更容易定位受影響的 PwDE 組成部分。

若 PwDE 的元件或 RDPS 被重複用於其他 PwDE，例如用於多個物聯網裝置的伴隨應用程式，或製造商用於多個 PwDE 的 RDPS，通常建議將威脅建模及風險評鑑拆分成組件，以便更方便重複使用。

如此一來，共用元件的風險處理可以在一處完成，且只需在必要時針對每個新產品更新。

5.8.1.2.2 輸入
• 預期目的及合理可預見使用
• 產品架構
• 資產列表
• （可選：威脅目錄）

5.8.1.2.3 控制
製造商必須識別對資產及可能受影響的 PwDE 元件的威脅。

5.8.1.2.4 輸出
• 已識別風險清單，包括對資產及可能受影響組件的威脅PwDE。

5.8.1.2.5 參考CRA
• CRA附錄一 第一部分（1）

5.8.2 RH_RA.1.2 - 風險分析（活動）

5.8.2.1 一般

對已識別風險的分析是評估風險的必要條件，並包括事故（影響）所造成的損失或干擾的規模，以及事故發生的可能性。影響主要透過受影響資產的價值來定義，因為對重要資產產生負面影響的事件，其影響高於影響較不重要資產的事件。影響可根據受影響資產的影響標準及其他放大因素來判斷，這些因素可能包括受影響資產的數量及不利影響的持續時間。通常，資產的價值及其潛在影響取決於產品的使用情況及相關利害關係人的利益，因為企業作為消費者可能有其他優先事項。

事故發生的可能性受多種因素影響，可能包括

• 攻擊者動機（有價值資產會提高事件發生的可能性，因為更有資格的攻擊者會有更高的動機）
• PwDE的通訊能力與溝通關係（根據外部行為者可存取的通訊能力與功能，產品可能更容易發生事件）
• 透過現有漏洞可能曝露PwDE
• 透過作業環境可能曝露於PwDE- 已實施或設計的安全控管

一般而言，判斷風險可能性需具備具體經驗，以及適用的統計數據與威脅情報。為了保持可能性的估算可理解，必須建立適當的可能性標準。若無法評估已識別風險的影響或可能性，因為該風險依賴其他參數，例如攻擊者潛力、事件持續時間、受影響產品數量，則應依參數將已識別風險拆分為多個風險。這將導致更多已識別的風險，擴展RH_RA 1.1.2所產生的清單。

註：影響與可能性的佐證理由說明

可能性與影響的評估可透過量化、定性方法或兩者混合進行。通常建議採用符合特定使用情境的產業適當方法進行風險分析。

一般而言，風險分析是主觀的，並基於執行風險分析者的經驗。額外資訊用於限定或量化風險的影響或可能性，能提升風險分析的可靠性，但也會增加風險分析的複雜度與工作量。

由於通常無法完全、精確且客觀地評估風險的可能性與影響，因此應將用於風險分析的努力與努力相比較

治療潛在風險。風險分析的結果是判斷是否必須處理風險
- 是或不是。

因此，處理潛在風險可能比承擔風險更可靠且容易努力精確評估其影響與可能性。為了支持這個說法，本技術指引將採用基於資產類型及作業環境，並未採用量化方法，故非給出錯誤地認為數值準確，

5.8.2.2 輸入
• 已識別風險清單
• 根據可能性標準判斷事件發生的可能性
• 根據影響標準評估潛在事件的影響

5.8.2.3 控制
製造商必須分析 PwDE 的風險，包括其可能性及潛在影響。

5.8.2.4 輸出
• （已分析的）風險清單，包括影響與可能性

5.8.2.5 參考CRA
• CRA附錄一 第一部分（1）

5.8.3 RH_RA.1.3 - 風險評估（活動）

5.8.3.1 一般
風險分析完成後，製造商需評估是否需處理該風險，或是否能基於風險的衝擊與可能性接受。此活動依賴於包含風險接受規則的接受準則。與其他決策準則一樣，這些準則可以是一般性的、產業、組織或產品的特定準則。一般來說，凡是有可能發生且會對使用者造成明顯不良效應的風險，都應該受到處理。

註解：關於接受的理由
通常可以定義多層次的驗收準則，並針對不同使用情境定義風險接受度。為不同使用情境（例如消費者、企業、政府）建立風險接受度，以處理多個情境並識別出一組風險，並更方便溝通產品的預期用途，這可能很有用。該指引未採用此方法，以保持風險評鑑的彈性與普遍適用性。概念上兩者無差別，因為每一個用於評估風險接受度的額外參數都可以簡化為衝擊與可能性。

5.8.3.2 輸入
• 分析風險清單
• 驗收準則

5.8.3.3 控制
製造商必須評估 PwDE 分析中的風險是否可以接受。

5.8.3.4 輸出
• （評估風險）清單，必須處理或已可接受

5.8.3.5 參考CRA
• CRA附錄一 第一部分（1）

（未完，見次篇）

製造商與產品的網路韌性要求 第一部分：一般要求（六之三）

BSI技術指引 TR-03183-1

適合一般產品及資訊安全產業界，具備基礎教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱歐盟與德國的BSI官方網站、洽詢各家驗證公司、諮詢顧問等。 CC BY-SA 4。0。

（見前篇）

第二部分漏洞處理要求項目

帶有數位元素產品的製造商應：

1. 識別並記錄帶有數位元素的產品中的漏洞與元件，包括以常用且機器可讀格式繪製軟體材料清單，至少涵蓋產品頂層相依性；
2. 針對帶有數位元素的產品所面臨的風險，立即處理並修復漏洞，包括提供安全更新；在技術上可行的情況下，新的安全更新應與功能更新分開提供；
3. 對包含數位元素的產品安全性進行有效且定期的測試與檢討；
4. 安全更新發布後，分享並公開已修復漏洞的資訊，包括漏洞描述、使用者識別受影響數位元素的產品資訊、漏洞影響、嚴重程度，以及清晰易取得的資訊，幫助使用者修復漏洞；在正當理由的情況下，製造商認為公開的安全風險超過安全效益，可能會延遲公開有關已修復漏洞的資訊，直到使用者獲得適用相關修補程式的機會；
5. 制定並執行協調性漏洞揭露政策；
6. 採取措施促進其產品潛在漏洞資訊與數位元件及產品內第三方元件的共享，包括提供聯絡地址以通報產品中發現的數位元件漏洞；
7. 提供機制以安全分發帶有數位元素產品的更新，以確保漏洞能及時修正或緩解，並在安全更新適用時自動進行；
8. 確保若有安全更新可用以解決已識別的安全問題，必須立即發布，原則上皆免費提供，除非製造商與企業用戶另有協議，且針對帶有數位元素的量身訂做產品；發布該項補釘時並附有提供相關資訊的警示資訊，包括可能採取的措施。

PWDE與製造商必須遵守並展現符合CRA的基本資安要求。如圖四所示，基本要求分為第一部分，涵蓋基於網路與資訊安全風險評鑑的PwDE設計、開發與生產要求，第二部分則包含製造商漏洞處理的要求，包括漏洞識別、修復與揭露。

圖四：基本資訊安全要求結構與交互作用

只有符合第一部分要求的 PwDE 才能放入歐洲市場，這必須由製造商先予做到而展現之。第二部分要求由製造商自PwDE放入市場之日起，並於產品整個支援期間內達成之。第一部分的要求著重於確保產品設計與預設安全，而第二部分則著重於持續的漏洞處理流程。

然而，上述兩個部分並非彼此獨立，因為第一部分（2）點（a）要求產品必須沒有已知可利用漏洞，因此製造商必須先建立漏洞處理流程，以減輕已知可利用漏洞，然後才將PwDE放入市場。第二部分要求製造商識別、處理並修復漏洞，這可能包括更新 PwDE 的風險評鑑，以及變更第一部分要求的實施方式。

第一部分（1）是CRA的總體要求，要求製造商根據網路與資訊安全風險評鑑，確保PwDE達到適當的網路與資訊安全等級。此處包括識別潛在風險，並在PwDE上實施適當措施以降低這些風險。第一部分（2）以高層級涵括的產品需求支持第一項要求，這些要求必須根據風險評鑑並適用時實施於 PwDE。

3.10 不合規的後果

放入市場的PwDE係受到相應的市場監督主管機關之管制。製造商應根據市場監督機關的合理要求，提供所有必要的資訊與文件，以紙本或電子形式展現產品與數位元素及製造商所建立的符合基本資安要求的流程。

製造商必須配合市場監督主管機關，採取任何措施，消除其放入市場的數位元素產品所帶來的網路與資訊安全風險。

違反CRA義務可能導致重大罰款（最高可達1,500萬歐元，或是佔企業全球年營業額的2.5%）、市場限制或產品召回。

3.11 如何準備CRA

簡單來說，以下幾個面向即使沒有具體法規指引，也應考慮以妥善面對CRA的考驗：
1. 對必須受到PwDE保護的資產及潛在威脅進行誠實的網路與資訊安全風險評鑑；
2. 根據CRA的基本要求，利用適當的安全控管，將風險降低至可容忍的程度；
3. 將用戶放在心上，並以開放透明的方式溝通，以用戶的最佳利益為依歸；
4. 維護 PwDE 在整個生命週期中的資訊安全性，並與相關單位合作防範漏洞；
5. 採用現有最佳實務，無須重新發明輪子。

遵循上述的各個面向，每一家製造商，尤其是已經熟悉網路與資訊安全的廠商，都應該具備充分的CRA準備妥當情況。

此份技術指引將更詳細說明CRA的潛在待實施考量，特別是針對剛接觸資安主題的製造商。

4 使用方式 Usage

該技術指引提供製造商或第三方代表製造商進行自我評鑑。執行評鑑時必須考慮以下說明與評鑑程序。

4.1 評估員Assessor

評鑑由評鑑人員執行，評鑑人員可以是製造商自身組織或由第三方為之。選擇評估者時需考慮以下因素：

• 評估員需具備足夠的技術知識及評鑑方法，以合格方式執行評鑑；
• 評估員需取得或被提供所有執行評鑑所需的資訊；
• 評估者必須保持公正，不應參與帶有數位元素產品（PwDE）的開發事項，以促進獨立地評鑑。

即使評鑑是由開發團隊執行，也必須以適當的批判心態進行評鑑，並保持客觀。

4.2 評鑑範圍

符合性評鑑針對PwDE的設計或完成的PwDE實例進行。將採用圖五中的通用 PwDE 架構。

PwDE由依據（CRA第3（1）條）提供到市場的硬體及/或軟體元件組成。這些「提供到市場的元件」會銷售到各處並受到使用者控制。

提請注意：某個PwDE 可能接觸到多個使用者，例如：安裝 PwDE 的整合者、負責配置與維護 PwDE 的管理者，或實際使用 PwDE 功能的終端使用者。經銷商若原封不動地轉售 PwDE，則不被視為使用者，因為經銷商既不更改 PwDE，也不使用其功能。

若PwDE允許從硬體或軟體面向改造元件，或由製造商（或其他經濟營運者）提供到市場、或受渠等控制的元件，此等元件在評鑑中毋須納入考量。而得能容納該等元件的界面則是 PwDE 的一部分，亦須受到前述的評鑑。此外，風險評鑑還必須考慮可能用到帶有額外元件的效應。

同樣的情況也適用於應與其他PwDE一起使用、由製造商（或其他經濟營運者）提供到市場或由其控制的PwDE。

使用者整合的額外元件不屬於 PwDE，例如額外的應用程式或服務。雖然此等未由製造商整合的元件不屬於 PwDE 的一部分，但若使用者整合第三方元件符合 PwDE 的預期目的或可預見用途，執行風險評鑑時仍須考慮相關風險。

除了市面上的軟體/硬體元件外，PwDE 還包含由製造商設計與開發、或由製造商負責的遠端資料處理解決方案（RDPS, remote data processing solutions），若缺乏該等解決方案，將阻礙帶有數位元件的產品執行其功能（CRA 第 3（2） 條）。

圖五：通用型PwDE架構

根據CRA第26條，委員會將提供更多關於RDPS的指引文件。在此段等待期間，此份技術指引將假設由製造商設計與開發、提供「已提供到市場的元件」功能的軟體，皆為 PwDE 的「RDPS」。開發亦包括第三方軟體的量身打造及實施 PwDE 使用的新特性。設定第三方軟體的行為並不視為開發。

此處包括由製造商設計與開發、為 PwDE 必要功能所必需的 RDPS，以及對使用者而言不重要的其他 PwDE 功能所必需的 RDPS，如；遠端遙傳或廣告，因為這些非必要功能也可能對 PwDE 構成風險。抑或即使由製造商開發，但若軟體對 PwDE 功能沒有直接衝擊，則並不屬於 PwDE，例如：時程安排程序、後端日誌架構、無商業邏輯的儲存或其他基礎設施服務。

RDPS 元件的基礎架構，即硬體、第三方軟體及運作 RDPS 元件所需的組織措施，並不屬於 PwDE 的一部分。然而，製造商仍負責 RDPS 元件，並必須透過提供必要的基礎設施來確保安全運作。

4.3 評鑑時間點

由於無法避開使用者自行修改 PwDE為不安全狀態，因此只有依照使用者手冊建議初始配置及（可能的）更新至最新版本後的狀態才對評鑑才有參考價值。此狀態可透過執行以下步驟達成：

• 取得新產品或將產品重置至原始狀態，例如恢復出廠設定或全新安裝。
• 依照使用手冊建議啟動產品及初步設定。
• 若在初始設定時尚未更新，則執行最新版本軟體。

4.4 情態動詞

該指引中關鍵詞「必須must」、「絕不must not」、「要求required」、「應shall」、「不應shall not」、「須should」、「不須should not」、「建議recommended」及「可選optional」，當且僅以全部大寫字母寫出時，應依BCP 14（RFC 2119， RFC 8174）中所述解釋，如此處所示。

1. 「必須must」這個詞，或「要求REQUIRED」或「應SHALL」，表示該定義是絕對必要的規範要求。
2. 「絕不must not」或「不應SHALL NOT」，表示該定義為絕對禁止的規範。
3. 「should」或形容詞「RECOMMENDED」，表示可能存在正當理由或在特定情況下忽略特定項目，但其完整含意必須是理解並謹慎權衡後才得以選擇另一條途徑。
4. 「須should」或形容詞「不建議NOT recommended」，表示在特定情況下會因某種有效的理由，使該行為可以接受甚至甚有用處，但在實施任何以此情態動詞描述的行為前，應充分理解其含義並仔細權衡。

4.5 控制

CRA的要求由該條例自身寫出各項規定。該份技術指引將制定控制措施，旨在降低PwDE的資安風險，並滿足CRA的基本資安要求。

每個控制部分包含以下事項：
• 輸入（僅限活動）：製造商活動的預期輸入；
• 風險前後環節（可選）：基於風險的情境，且適用於控制時；
• 控制：必須由PwDE或其部分（如適用時）達成；
• 產出（僅限活動）：製造商活動的預期產出；
• 目標（可選）：由控制所保護的元件或功能類型；
• 評鑑指引（可選）：針對控制評鑑的額外指引。根據相關涉及的風險，可能會提供不同層級的評鑑指導；
• 實作指引（可選）：控制的實作特定資訊，例如特定的密碼演算法、或 PwDE 的特定配置；此事項並非強制性要求，而是由於涉及相關風險，建議以特定方式實施控制措施；
• 補償（可選）：若無法執行此控制，則可作為補償的替代控制；
• 參考到CRA：控制事項須引述所對應的CRA基本要求、或其他由控制措施支持的要求。此處的參考資料可用來識別由PwDE實施的基本要求。

4.6 評鑑程序

該節給出評鑑程序，以評鑑該技術指引中所述的安全控管是否得到遵循。考慮重現性與一致性，每個評鑑步驟都應由評估者記錄並納入第4.8節定義的測試報告中。

評鑑透過依照以下規則評估該指引中每項控制措施的適用性與實現性予以執行：

控制：控制由一個帶有 MUST（必須）的規範性陳述組成，若陳述可被評鑑為【通過PASS】，否則控制【未達成（FAIL）】。控制事項可以標記為【不適用（N/A）】，若
• 可以參照到某種補償方式，
• 控制事項的目標機制並不存在於PwDE中，
• 控制語句中的「如果if」條件不適用，
• 或該控制事項與其他法規相抵觸。

一般來說，控制事項的評估範圍須足夠具體，若不夠具體，控制事項將由額外的指引補充，這些指引必須用於評鑑控制事項。控制事項至少必須根據（PwDE）的文件在概念層面進行評鑑。建議根據PwDE或製造商的行為進行功能評鑑，以取得額外保證，但並非強制要求。

基於風險的控制：基於風險的控制包含一個或多個風險前後環節、一個要求事項及可選的評鑑準則。若風險不適用於產品，則風險導向控制可能評鑑為【不適用（N/A）】。若係稱控制事項得由受風險影響的PwDE或其部分達成，則基於風險的控制之評鑑結果為【通過PASS】。

一般而言，CRA的要求只要採取適當的控制措施，即可充分降低網路與資訊安全風險。該指引使用以下類型的控制以方便區分：

活動：活動是行政控制，包含製造商應執行的活動以及預期的輸入與產出。若製造商執行要求中所述活動並產生所要求的產出，則流程控制即係【通過PASS】；否則，控制便是【未達成（FAIL）】。

機制：機制為主動技術控制，若控制依照 PwDE 描述實施，則稱為【通過PASS】，否則控制便是【未達成（FAIL）】。

文件化：文件化是在 PwDE 的運行過程的產出物，但不是直接屬於 PwDE 的部分。若製造商以上述方式提供文件供內部、外部或公眾使用，則文件控制係【通過PASS】。文件評鑑不包括對係稱流程的評鑑。

評鑑最好整合進開發流程及持續型品質保證流程，若可能時，宜採自動化方式為之。

若所有控制點均標示為【通過PASS】或【不適用（N/A）】，則整體判定為【通過PASS】，否則便是【未達成（FAIL）】。

評鑑步驟可能包含以下各項術語，評估者必須對此有所了解及採用之：

• （普遍認可）的【現今技術水準state of the art】是指特定領域內，針對特定使用情境，目前且普遍認可的最佳實務。這裡通常不是要求使用最新技術，而是採用知名且成熟的技術、方法與流程，以符合特定使用情境。如有需要，會提供現今技術水準的示例或準則。

• （普遍認可）【現今技術水準的密碼學State of the art cryptography】遵循常見且知名的密碼學建議，例如 BSI TR-02102、SOG-IS 協議密碼機制或符合 ISO 18033-1 附錄 A 要求的類似標準。若密碼機制適合相應的使用情境，且目前尚無既有技術可行使此事項的攻擊，則可視為現今技術水準。

提供與發佈表示資訊的分配方式。預設情況下，製造商若未另行指定提供或發佈，則無需提供文件或其他紀錄給第三方。【提供】指的是授權特定第三方存取文件，例如PwDE的使用者。【發佈】意味著某件事被記錄下來，並可免費、輕鬆且公開地存取。

• 支援與實施表示某功能是否必須由PwDE直接實施，或僅在整合至其他PwDE的前後環節下支援。

• 預設且總是顯示 PwDE 配置/政策的有效性。「預設」意指若使用者未另行設定，PwDE 會依照描述方式運作。「總是」表示該項行為屬於強制執行，使用者無法更改。

4.7 整體判決的詮釋

整體判決僅作為指標，顯示PwDE是否符合該技術指引的要求，但並非直接聲明符合CRA規定。

【未達成（FAIL）】不一定代表PwDE不符合CRA規範，因為該指引中的某些要求可能不適用於所有帶有數位元件的產品。【通過PASS】也不代表PwDE產品符合《網路韌性條例》（CRA），因為PwDE可能帶有該技術指引未涵蓋的風險。

4.8 測試報告

根據CRA第31條，製造商必須在將PwDE放入市場前，先擬具制定技術文件。其中包括：

• 產品總體描述，包含數位元素，包括其預期用途、影響符合基本資安要求的軟體版本、附錄II中所列使用者資訊與說明，以及展示外部特徵、標記與硬體內部佈局的照片或插圖。
• 描述產品設計、開發與生產過程，包含數位元素與漏洞處理流程
• PwDE產品的生產與監控流程的必要資訊與規範，包含數位元素，並確證此等流程；
• 評鑑PwDE產品所面臨的資安風險，包括附錄一第一部分適用的基本資安要求；
• 為查證PwDE產品的符合性所進行的測試報告，以及符合附錄一的第一部分及第二部分所列出適用係稱產品的基本資安要求之漏洞處理流程；

利用該份技術指引，可以產生測試報告以記錄對PwDE產品的評鑑。

根據該份技術指引的要求，測試報告至少必須包含以下資訊：
• 評鑑日期
• 識別PwDE產品，至少包括以下資訊：
– PwDE產品的名稱與型號；
– PwDE產品說明及預期目的；
– 硬體與軟體版本；
– 軟體物料清單（SBOM）（如適用時）；
– 針對硬體 PwDE：展示外部特徵的照片或插圖，標記；以及內部佈局與硬體元件，並包含數位元素；
• 風險評鑑
– 已識別的資產與威脅；
– 評估風險；
– 可接受的風險；
• 設計文件化
– PwDE架構，包含硬體與軟體元件及數位化元件，以及網路和實體介面；
– 適用的控制措施，包括風險緩解及相應的必要網路與資訊安全措施要求；
– 選擇控制措施的實施內容說明；
– 選定之控制事項的查證流程；
• 說明漏洞處理活動
• 查證漏洞處理活動
• 提供給使用者的文件。

（未完，見次篇）

匈牙利布達城堡迷宮概略

歷史與形成

匈牙利布達城堡迷宮（Der Labirintus / Labirintus Budavári）位於布達佩斯城堡山（Castle Hill）地下，是世界上獨特的大型石灰華洞穴系統之一。其自然形成可追溯至約五十萬年前，由城堡山石灰岩受熱泉水長期侵蝕、溶解而成，形成了泉源、洞穴、地下通道與地窖的複雜網絡。

中世紀時期，人們將這些天然洞穴擴建成人工通道，用作儲藏室、防空洞、監獄，甚至戰時庇護所。第二次世界大戰期間進一步擴建，成為長達數公里的地下迷宮網絡。目前開放參觀的部分約1,000 至 1,200 米長，涵蓋中世紀石砌走廊與現代擴建部分。

迷宮曾作為監獄使用，最著名的傳說與弗拉德·采佩什（Vlad Tepes，又稱穿刺公 Vlad the Impaler）有關。據說 1462 年左右，他被匈牙利國王馬加什一世（Matthias Corvinus）囚禁於此長達數年至十四年不等，在黑暗潮濕的地下遭受折磨。後來他成為德古拉（Dracula）傳說的原型，這也讓迷宮增添濃厚的神秘與恐怖色彩。

主要景點與特色

- 德古拉之室（Dracula’s Chamber）：紀念弗拉德被囚的區域，有相關蠟像與歷史說明。
- 黑暗迷宮（Maze of Darkness）：完全漆黑的通道，遊客需手握綠色軟管前行，考驗方向感與勇氣，極具沉浸式體驗。
- 蠟像與歷史展覽：展示匈牙利歷史人物、著名洞穴介紹，以及中世紀生活場景。還有霧氣瀰漫的區域，重現昔日潮濕陰冷的氛圍。
- 黑伯爵（Black Count）傳說：19 世紀據說有「黑伯爵」鬼魂出沒，有人認為與弗拉德有關，或是貧困伯爵與盜匪勾結的歷史人物。其鬼魂據說仍在此舉辦地下化裝舞會。
- 其他展區：包括「鬼魂迷宮」、吸血鬼狩獵主題活動，以及探討全球著名洞穴的展示。

迷宮整體氣氛陰森潮濕，結合歷史蠟像、燈光效果與完全黑暗段落，非常適合喜愛冒險與恐怖元素的遊客。開放時間通常為每日上午 10 點至晚上 7 點，入口位於 Úri utca 9 號（城堡區內一條安靜小街）。

靈性與魔鬼相關特色

迷宮因長年黑暗、潮濕與歷史上的監禁、折磨用途，自然滋生大量靈異傳說：
- 吸血鬼與弗拉德傳說：被視為德古拉靈感來源之一，部分遊客與導覽強調其「吸血鬼」氛圍。
- 黑伯爵鬼魂：據稱會在通道中現身，伴隨低語聲、溫度驟降、白霧與難以捕捉的陰影等超自然現象。
- 其他靈異報導：遊客偶爾提及不安感覺、耳語聲或歷史幽魂存在，強化了「歐洲最陰森地下景點之一」的名聲。
- 整體環境讓人聯想到中世紀的苦難、煉獄與魔鬼力量，適合探索「光明與黑暗」、「歷史與超自然」的交匯。

參觀建議與其他推薦

推薦指數：如果您喜歡歷史、冒險與輕度恐怖體驗，強烈推薦（尤其夜晚前參觀更添氛圍）。不適合 claustrophobia（幽閉恐懼症）患者或幼童。穿舒適防滑鞋，注意地面潮濕。

其他布達佩斯值得推薦的特色景點：

- 醫院岩洞（Hospital in the Rock）：同樣在城堡山地下，二戰與冷戰時期的秘密醫院兼核掩體，歷史真實性更高。
- 蓋勒特山洞穴教堂（Gellért Hill Cave Church）：天然洞穴改建的教堂，具有強烈靈性與宗教氛圍。
- 布達城堡地下其他通道：探索更廣的城堡山洞穴系統。
- 塞切尼溫泉浴場：利用同一熱泉系統的地面享受，與地下迷宮形成有趣對比。
- 鬼魂步行導覽（Ghost Walks）：布達佩斯夜間鬼魂主題導覽，可先參加以加深對迷宮歷史的理解。

布達城堡迷宮是結合自然奇觀、中世紀歷史、恐怖傳說與冒險體驗的獨特景點，值得親身探索其陰森卻迷人的地下世界。若想更深入了解特定傳說，建議現場參加導覽或主題活動！

醫療器材維護管理計劃概要（五之一）

 

適合一般醫療保健服務產業界，器材與設備維護、維修者，具備基礎教育背景的讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO的官方網站、洽詢各家專業公司、諮詢顧問等。 CC BY-SA 4。0。

介紹

ISO/TS 5137:2026（以下稱為【該文件】）做出《保健提供組織（HDO, healthcare delivery organizations）》（或稱《醫療保健服務組織》）對可重複使用的《醫療器材維護/維修管理計劃（maintenance management programme, MMP）》特定要求，包括：測試與調試、服務及最終除役與處置，或提供與前述事項的相關活動（例如：技術支援性質）。

該文件中的要求亦可由零組件供應商或其他外部第三方使用，為係稱HDO組織提供維護/維修服務。

考慮各處不同地方、國家或區域的要求，該文件僅能作為置於各界參考的頂層標準，提供HDO進行醫療器材維護/維修時的基礎性要求事項。該文件中的要求事項僅係維護/維修與通用型指引架構。HDO或維修提供者宜建立並維持有效的醫療器材維護/維修計畫。

考慮到適用的法規要求會因為不同國家及地區而有所差異。HDO組織宜於了解該文件中的要求內容，須如何根據醫療器材維修及維護的相關司法管轄區的法規要求，得以在當地或該區域有效地實施。

該文件並非意在暗示不同維護/維修管理計畫結構需要整齊劃一的內容、文件化須一致性，或各組織制定的文件須與該文件各章節條款結構的齊一性。

該文件遵循ISO 13485的章節架構。因此，若HDO內部的維護/維修服務提供者（或其供應商）持有 ISO 13485 或 ISO 9001驗證證明，或希望獲得上述標準的第三者驗證證書，該供應商可將該文件的要求納入其具備的品質管理系統之內。

1. 範圍

該文件做出《保健提供組織（HDO）》監督下，需加以維護/維修的可重複使用醫療器材之《維護/維修管理計畫》的要求 。該文件既不提供指引，也不適用於修改醫療器材的原本預期使用或性能。該文件不適用於製造商自行安裝、測試、維護及售後服務其自身的醫療器。

2. （略）

3. 術語及辭彙

3.1授權代表 authorized representative, AR
在特定領土內設立的自然人或法人，已收到並接受來自該特定領土外製造商的書面授權，代表該製造商執行與該製造商在（特定領土）當地法規要求之義務相關的特定任務。
例：歐盟境外的醫療器材製造商，指派歐盟境內的自然人（或法人組織）為《歐盟授權代表》。

3.2生物醫學工程服務代表 biomedical engineering services representative
生物醫學工程服務（BES）的代表者

3.3生物醫學工程服務, biomedical engineering service, BES
在組織內部或外部的第三方組織，負責與受到委派，以執行、實施或管理醫療器材（3.10）維護/維修（3.9）活動。

3.4 Calibration校正
在規定條件下的操作，其第一步驟係由按照量測標準及含有不確定度之對應器示值，建立量值與所提供之量測不確定度之間的關係。
第二步驟則使用上述獲得之資訊，建立從器示值獲得量測結果的關係。
參見ISO/IEC Guide 99、CNS 10895，第3.39項之定義。

3.5 Competence專業能力
個別人員合宜地執行特定工作所需的書面要求，涵蓋知識、技能與行為的綜合體現；

3.6 Downtime 停機時間
器材無法使用的時間，以百分比表示；

3.7 保健提供組織（又稱醫療服務組織）healthcare delivery organization, HDO
提供醫療保健類服務的診所或醫院等機構或企業；
註：典型代表：醫院、診所、護理院、醫療中心、區域醫療集團等。

適用對象範圍：不包括醫療器材的製造商（自行負責安裝/架設/測試/維護/翻修自己製造的醫療器材）、植入式或一次性使用器材、設備改裝 / 翻新 / 再製造。

3.8 incident不良事件
涉及醫療器材（3.10）的不良事件，導致或可能造成人身傷害，包括器材故障、性能衰減、使用錯誤、資訊不適宜或非期望的副作用。

3.9 維護/維修maintenance
結合所有技術與行政手段，包括監督方式，以維持醫療器材（3.10）及系統處於正常運作狀態，或重置以恢復到正常運作狀態。

3.10 醫療器材 medical device
儀器、設備、工具、機械、器具、植入物、體外使用試劑、軟體、材料、材料或其他類似或相關物品，不論單獨使用或組合使用，由製造商預期提供人類使用，以達到下列一個或多個特定的醫療目的：

• 疾病的診斷、預防、監督、治療或緩解；
• 損傷的診斷、監督、治療、緩解或補償；
• 生理結構或生理過程的檢查、替代、調節或支持；
• 生命的支持或維持；
• 妊娠控制；
• 醫療器材的消毒；
• 通過對取自人體的樣本進行體外檢查的方式提供資訊。

並且其在人體內或人體上的主要預期效用不是通過藥理學、免疫學或代謝的方式實現，但這些方式可輔助實現預期功能。
註：在一些司法管轄區可能認為是【醫療器材】，但在另一些管轄區不認為是醫療器材的產品包括（但不限於下述）：

• 消毒物資，
• 殘障人士的輔助器具，
• 包含動物與/或人體組織的器材，
• 使用於體外受精或輔助生殖技術的器材。

3.11 medical device supplier醫療器材供應者
為下列角色者：製造商、授權代表（AR）（3.1）、經銷商或醫療器材（3.10）註冊持有者。

3.12 method statement方法敘述
生物醫學工程服務（BES）（3.3）的文件，將維護/維修（3.9）需求轉化為交付計畫，包含資源、配置與方法學。

3.13 nonconforming medical device不符合的醫療器材
醫療器材（3.10）未按預期功能運作。

3.14 preventive maintenance預防型維護/維修
規劃出維護/維修（3.9）計畫，陳述間隔期間、任務及應執行的活動，以確保所有醫療器材（3.10）依製造商規格運作並處於安全運作狀態。

3.15 predictive maintenance預測型維護/維修
採用資料驅動的主動式維護/維修（3.9）方法分析設備狀況並預測何時須執行維護/維修。

3.16 verification查證
經由提供客觀證據，確認已達成規定的要求。

3.17 Risk 風險
傷害發生機率與傷害嚴重程度的組合

3.18 risk management風險管理
系統性應用管理政策、程序與實務以做出分析、加以評估、實施控制及保持監督風險的任務（3.17）

4 維護/維修管理計畫

4.1 一般要求
4.1.1 HDO應按該文件要求將維護/維修管理計畫文件化，並維持其有效力與有效率。法規要求當予應用。

HDO應建立、實施並維護該文件所需記錄的任何要求、程序、活動，或要求的安排事項。法規要求當予應用。

維護/維修管理計畫應確保：

• 醫療器材如預期般運作；
• 對病患、使用者及其他人員，該醫療器材都是安全的。

維護/維修包括定期與非定期維護/維修，應基於製造商提供的使用說明書及維護手冊進行，並遵循良好的工程實務。若是製造商未提供資訊的情況，應採用適用的安全標準及臨床性能要求事項。

4.1.2 對於每個維護管理流程，HDO 應具備以下事項：
a. 決定所需的準則與方法，以確保該等流程的運作與控制實際有效果;
b. 確保獲得相應資源與必要資訊，以支持該等流程的運作與監督;
c. 實施必要的措施以達成規劃成果，並維持該等流程實際有效果;
d. 監督、適當地執行量測、並分析該等過程;
e. 建立並維持需要的紀錄，以展現符合該文件及符合相關法規要求。

4.1.3 維護/維修管理計畫可能包括以下內容：
a. 負責維修活動人員的訓練;
b. 初步檢查、預防型維護、安全性、評估與查證醫療器材及零配件;
c. 快速回應的維修服務，能將醫療器材停機時間降到最低;
d. 持續改進的品質保證計畫;
e. 維護活動的標準化;
f. 協助訓練醫療人員如何安全且有效地操作醫療器材。

4.2 外包活動
當HDO選擇外包任何影響維護活動的流程時，應監督並確保對該等流程的控制。HDO應負責遵守該文件並遵守外包流程的相關法規要求。
註：通常考慮承包商的「KPI 考核指標」，例如：「平均修復時間 (MTTR)」或「維護達成率」。

4.3 文件化要求
4.3.1 一般
維護/維修管理計畫文件應包含
a. 文件化的品質目標
b. 該文件所要求的文件化程序與紀錄
c. 組織認定為確保有效規劃、運作與控制流程所需的文件，包括紀錄；
d. 其他文件;
e. 註：適用的法規要求可能要求特定的文件化。
f. 風險登記/評鑑；
g. 方法的文字式敘述。

4.3.2 文件管制
紀錄是一種特殊類型的文件，應依據4.3.3所規定的要求進行管理。
文件化的程序應定義需要的控制措施：
a. 在發行前審查並核准文件的適宜性及充分性
b. 必要時審查、更新並重新核准文件
c. 確保文件的當前修訂狀態及變更已予以識別出來
d. 確保相關文件的版本在使用點可以獲得;
e. 確保文件內容是清晰易辨且易於識別;
f. 確保組織已決定了對維護管理系統規劃與運作必要、外部來源的文件已予以識別，並管制其分發;
g. 防止文件損壞或遺失
h. 防止過時文件遭到誤用，並對其適當地予以識別。

HDO應確保文件變更經原始核准部門、或其他有相關背景資訊以供決策依據的指定功能，予以審查並核准。

HDO應定義至少一份過時文件副本應予保存的期限。

4.3.3 紀錄管制
應保存紀錄以提供佐證符合性該文件要求及維護/維修管理計畫的有效運作。

HDO應文件化程序，定義所需的控制措施，有關於記錄的識別、深刻地審查、核准、儲存、保全與完整性、檢索、保存時間及處置。

紀錄應保持清晰、易於識別及檢索。紀錄變更應保持可以識別出來。

HDO應保留這些紀錄，至少保存至醫療器材製造商定義的使用壽命內，且不得少於醫療器材除役起兩年。
註：採用特定的法規要求可以給出保存紀錄的期限。

4.3.4 維護管理資訊系統Maintenance management information system (MMIS)
HDO應確保設立《維護管理資訊系統（MMIS）》，以管理維護/維修管理計畫的所有面向。MMIS 應持續維護與更新。

BES應訓練所有相關方使用MMIS。

MMIS 對授權使用者開放存取，包含但不限於以下模組：
a. 資產登記模組;
b. 字詞順序檢索模組;
c. 預防型維護模組;
d. 維修歷史模組;
e. 供應商-客戶登記模組或《核准供應商清單（ASL）》，且歸屬於HDO 內設有的品質管理系統（QMS）。
如適用，資料備份應定期進行。

4.3.5 技術儲藏庫 Technical library
HDO將建立、維護並管理技術文件儲藏庫。儲藏庫應開放給相關人員，且儲存下列文件類型：
a. 操作與維護手冊;
b. 使用說明;
c. 圖像、圖示、示意圖;
d. 軟體
e. 指引文件與法規;
f. 訓練教材
g. 其他相關文件。

（未完，見續篇）

製造商與產品的網路韌性要求 第一部分：一般要求（六之二）

BSI技術指引 TR-03183-1

適合一般產品及資訊安全產業界，具備基礎教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱歐盟與德國的BSI官方網站、洽詢各家驗證公司、諮詢顧問等。 CC BY-SA 4。0。

（見前篇）

3.2.2 「放入市場」及「提供到市場上」

CRA 適用於所有在歐盟內「放入市場placed on the market」的 PwDE。此定義源自《歐盟產品規則實施藍色指引》，適用於歐洲產品法規。

定義：「放入市場」指產品首次在歐盟放入市場的時刻。這是由製造商或進口商執行，且指的是每一件產品，而非特定類型或型號。一旦產品放入歐盟市場，就可以沿著歐盟境內的銷售鏈轉售或轉移，而不會再次被視為「放入市場」。

示例：德國一家製造商生產一批智慧恆溫器。當這些恆溫器首次銷售給法國經銷商時，就會「放入市場」。CRA的一些要求也適用於產品提供到市場後才是放入市場。此種類型被稱為「提供到市場上」。

定義：「提供到市場上」指在商業活動過程中，為經銷、消費或在歐盟市場提供任何產品，無論是以有價或免費形式。此處指的是每一次提供的產品，用於經銷、消費或在歐盟市場使用，涵蓋所有產品的轉移類型，包括：銷售、短期租賃、借用或免費贈送。此定義適用於產品放入市場後的整個供應鏈。

示例：如果法國的經銷商將智慧恆溫器賣給零售商，零售商再賣給最終用戶，這些交易都是「提供到市場上」。

總結來說，產品放入市場係首次在歐盟市場供應、供經銷、消費或使用該產品；而在產品放入市場後，在歐盟市場提供（銷售、轉移等）則是指產品放入市場後，市場中再提供給任何供應鏈上的角色（如銷售、轉移等）。

3.3 製造商

該技術指引將聚焦於CRA看待製造商的觀點。「製造商」被定義為自然人或法人，開發或製造帶有數位元素的產品，或設計、開發或製造帶有數位元素的產品，並以其名稱或商標行銷，無論是為了獲取報酬或免費提供。

「製造商」生產有形產品，如器材，或創造或提供無形產品，如軟體及軟體元件。在軟體的語境中，「製造商」是軟體作者角色的同義辭。

該技術指引不會詳細說明CRA定義的「經銷商」、「進口商」或其他經濟營運商，因為該技術指引所述技術要求並非為該等角色的需求而量身打造。

3.4 時間軸

《網路韌性法案CRA》於2024年12月10日生效，但對於帶有數位元素的產品進入歐洲市場尚未強制實施，因為實施該等要求尚需經過若干個過渡期。

• 製造商主動通報漏洞遭到不正當利用及嚴重事件的義務（CRA第14條）將於2026年9月11日開始。
• 自2027年12月11日起，必須遵守所有帶有數位元素的產品在歐洲市場的CRA要求。
• 帶有數位元素且於2027年12月11日之前放入市場的產品，僅在該產品於2027年12月11日之後經過重大修改（substantia modification）時，才會受到CRA約束（CRA第69（2）條）。

歐盟委員會將提供CRA指引，說明何謂【重大修改】。根據新法規架構（NLF），若PwDE的類型與目的發生在初次風險評鑑中未預見的變更，則可視為屬於【重大修改】。因此，對 PwDE 進行安全更新與錯誤修正的典型維護通常不被視為重大修改。

CRA第14條規定的義務適用於所有於2027年12月11日前放入市場且屬於該條例範圍內帶有數位元素的產品（CRA第69（3）條）。

3.5 概念

CRA基於多項基礎概念，協同一致地強化歐盟數位產品領域的資安。此等概念包括：

設計與預設安全

CRA 要求製造商從源頭開始就將網路與資訊安全整合進產品規劃、設計、開發與維護中，並結合數位元素。此種「本質設計安全」原則確保安全性不是事後想到才追加進去的，而是產品開發的基本考量面向。同時也要求產品預設具備安全性，意即使用者無需額外採取措施來確保基本安全。

風險導向方法

必要的資安需求必須基於資安風險評鑑予以實施，並考量帶有數位元素產品的預期目的及合理可預見的使用情況。此方法確保所有與PWDE相關的網路與資訊安全風險都必須受到妥善處理，確保任何類型的PWDE皆享有適當的網路與資訊安全水準。

生命週期責任

製造商在產品整個生命週期中負責資安，而不僅僅是在銷售階段。意即包括及時提供安全更新、處理漏洞，以及在產品支援期間內提供各種相關支援，以反映產品預期使用的時間長度，通常為至少五年。

透明度與使用者資訊

CRA 強調透明度，要求製造商提供清楚且易於理解的產品安全特性及更新政策資訊。這讓消費者和企業能對購買和使用的產品做出知曉情況的決定。

3.6 製造商的義務

CRA第13及14條規定了對數位元件產品製造商的全面義務。這些義務涵蓋整個產品生命週期，從設計與開發到上市後支援。以下是主要要求的摘要。

放入市場前義務

製造商在將帶有數位元素（PwDE）的產品推向市場前，有多項應盡義務：

• 確保產品符合附錄一所敘述的基本資安要求，包括設計、開發及生產產品，以達到適當的資安水準。資安等級是基於對每款產品的資安風險評鑑，以及對潛在風險的適當處理，達到可容忍的程度，考量預期目的、合理可預見的使用、營運環境及預期使用期間。
• 整合第三方元組件（包括開源軟體）時，務必進行盡職調查，並針對這些元組件中的漏洞進行處理與修復。製造商必須向製造或維護該元組件的個人或實體報告第三方元組件中發現的漏洞。若製造商開發軟體或硬體修改以解決元組件中發現的漏洞，必須將相關程式碼或文件以機器可讀格式與製造或維護該元組件的個人或實體分享。
• 擬定技術文件（CRA第31條），至少包含附錄VII中所列資訊，展現符合基本網路與資訊安全要求。這些文件包含產品、其預期用途、設計與開發的資訊。同時也必須包含網路與資訊安全風險評鑑，識別潛在威脅與漏洞，評估其影響，並概述為減輕這些風險所採取的措施。• 向附錄 II 中明確的資訊與指示，如製造商識別、聯絡方式及單一漏洞通報聯絡點。PwDE 必須附有附錄二中所列使用者資訊，無論是紙本或電子形式。
• 執行符合性評鑑程序，以展現符合基本的資安要求。符合性評鑑可透過自我評鑑或由第三者公告機構進行，須視 PwDE的類型而決定評鑑方式。
• 若能展現符合基本資安要求，即著手擬定歐盟符合性聲明（DOC），並在產品上貼附CE標誌。

上述各項義務旨在確保製造商能夠在其產品生命週期中，採取主動且風險導向的網路與資訊安全策略，從而提升歐盟市場數位產品的整體安全性。 

產品監控與上市後義務

PwDE 放入市場後，製造商必須系統性地記錄並定期檢視產品的資安面向。這包括根據需要更新風險評鑑，並適當處理新浮現的風險。此外，製造商應在其指定支援期間監督產品安全漏洞，並適當處理發現的漏洞，包括免費提供安全更新補丁。

這些放入市場後義務必須在製造商根據預期使用時期的長度所設定的產品支援期間內無間斷地維持住。一般而言，除非產品類型及其可預見使用期間不適用太長期間，否則支援期至少須為五年。

此外，製造商還必須確保安全更新及技術文件在產品上市後至少10年內或整個支援期間（以兩者較長期間為準）都能夠取得。

通報義務

CRA第14條規定了對PwDE的強制通報義務。製造商必須在得知 PwDE 的資安漏洞及嚴重的資安事件後，通報這些事件對帶有數位元素的產品安全性造成負面影響。必須透過CRA第16條設立的單一報告平台，同時向指定的CSIRT（電腦安全事件應變小組）及歐盟網路與資訊安全機構ENISA（歐盟網路與資訊安全機構）發出通知。

以下為針對資安漏洞發出通報的時間與內容：

• 早期警示通知：必須在得知漏洞後24小時內提交，且應在適用時標明製造商將係稱產品放入市場的已知道之成員國。
• 漏洞通知：若尚未提供，須於知悉漏洞後72小時內提交更詳細通知。內容應該包括產品的一般資訊、漏洞利用的性質與漏洞、已採取的矯正或緩解措施，以及對使用者的指引。若相關，也應標示資訊的敏感度。
• 最終報告：若尚未提供，必須在漏洞的修正或緩解措施取得後14天內提交最終報告，內容包括漏洞的描述、嚴重程度與影響，以及修正措施的細節。若有以下情形亦應一併報告，即包含任何惡意攻擊者利用該漏洞的資訊。

針對嚴重事件發出通報的時間與內容：

• 早期警示通報：必須在得知漏洞後24小時內提交，且不得延誤。至少包括事件是否懷疑由非法或惡意行為引起，並應在適用情況下指出製造商知悉其產品已在該成員國境內提供數位元素；
• 事故通報：若尚未提供，須於知悉後72小時內提交更詳細通報。內容應該包括產品的一般資訊、漏洞利用的性質與漏洞、已採取的矯正或緩解措施，以及對使用者的指引。若相關，也應標示資訊的敏感度。
• 最終報告：若尚未提供，必須在事件通報後一個月內提交最終報告，內容包括事件的詳細描述，包括嚴重程度、影響及潛在根本原因，以及已採取的緩解措施細節。

除了強制性通報外，製造商及其他相關方可自願通報任何可能影響產品風險的漏洞或網路威脅，以及任何影響產品安全的事件或差點事故。這些自願通知可向CSIRT或ENISA提交。

自願通報不會對通報人施加超出未通報時存在的額外義務。CSIRTs與ENISA必須確保所提供資訊的保密性與適當保護。若非製造商通知存在漏洞或嚴重事件，CSIRT 必須立即通知製造商。CSIRT可優先處理強制性通知而非自願性通知，並依CRA第16條程序處理所有通知。

3.7 符合推定

《網路韌性法》採用「符合推定」（CRA第27條）概念，意指若產品具備數位元素及製造商流程符合特定的歐洲調和標準、共同規範或歐洲資安驗證計畫，則推定符合CRA的基本資安要求。

歐洲調和標準（HES）是由一個或多個歐洲標準化組織應歐盟委員會要求制定的標準。若調和標準符合其主旨要求，歐盟委員會將在《歐盟官方公報》上發布列為參考用文獻。以此種方式發表的HES可用於符合推定的規範。在CRA歐洲調和標準為背景考量情況下，即視為符合該條例附錄一或其部分內容所列出的基本網路與資訊安全要求。

若要求的歐洲調和標準（HES）無法及時交付或無法交付，歐盟委員會可制定實施法案，建立涵蓋技術要求的共同規範，提供符合附錄一中基本網路與資訊安全要求的替代性手段。

歐盟委員會亦可採納特定的歐洲網路與資訊安全驗證方案及《網路與資訊安全法》（CSA），用以展現帶有數位元素的產品符合附錄一所列基本網路與資訊安全要求或其部分。

調和標準的符合推定並不代表製造商免於履行基本的資安要求，因為歐洲調和標準、共同規範及歐洲資安驗證計畫必須符合其特定情境下的必要資安要求或其部分內容。

此外，符合推定僅適用於基本的資安要求。來自CRA其他部分的義務，將不會由歐洲調和標準、共同規範或歐洲網路與資訊安全驗證方案予以涵蓋。

3.8 產品類型

CRA 根據核心功能將帶有數位元素的產品分類為三大主要產品類型（見圖三），每個類型對符合性評鑑的要求各有不同。歐盟委員會將另行以技術說明的形式，提供核心功能及產品類型的具體範圍的進一步指引與說明。 

 

圖三：產品類型

3.8.1 預設型類型

包含所有帶有數位元素但未明確列為《重要》或《關鍵》的產品類型。此類型包含智慧電視、網路印表機、藍牙喇叭、媒體播放器軟體等。此類型約佔所有數位元素產品 90%。

如何展現一致性？製造商根據CRA附錄 I 的基本網路與資訊安全要求進行自我評鑑，即可符合此類型（CRA 第 32（1） 條）。此類基於內部控制的符合評鑑完全由製造商負責，無需第三方介入。此規定符合新法規架構（NLF）的符合審查程序模組「A」。另外，第三方由公告機構進行的評鑑，也可以自願採用，並透過歐洲資安驗證計畫推定符合標準。

3.8.2 重要型產品I類

具有附錄三中某項產品類型核心功能的數位元素產品被視為《重要》。《重要》區域分為第一類和第二類。第一類包括身份管理系統、得到授權的存取管理軟體/硬體、獨立/嵌入式瀏覽器、登入密碼管理器、反惡意軟體、VPN 產品、網路管理系統、作業系統、路由器、數據機、交換器、具安全相關功能的微處理器/微控制器、具備安全功能的智慧家庭產品、網際網路連結型玩具、個人穿戴裝置。

如何展現一致性？一般而言，製造商依據歐洲調和標準或共同規範自我評鑑，是展現符合基本網路與資訊安全要求的主要方式，基於符合推定（CRA第32（2）條），如第3.7節所述。也可透過歐洲至少「重要」等級的資安驗證計畫，推定符合標準，以展現符合基本資安要求。

若無能夠適用的歐洲調和標準、共同規範或歐洲資安驗證方案，則需由公告機構進行第三方評鑑。此舉符合新法規架構（NLF）的符合評鑑模組「B」。該公告機構將根據CRA附錄一的基本網路與資訊安全要求評鑑產品，並核發符合證書。為了使用該證書生產符合標準的產品，製造商必須確保生產 PwDE 的過程符合證書中所描述的核准型號。此內部生產控制基於新法規架構（NLF）的「C」模組，且只能與其他評鑑模組結合使用，此類型產品係結合「B」模組與「C」模組。

另一條符合途徑，可透過符合新法規架構（NLF）符合評鑑程序模組「H」的驗證完整品質保證系統達成。

3.8.3 重要型產品 II 類

CRA附錄三中列出的數位元件第二類《重要》產品，包括：虛擬機監控程式、容器運行系統、防火牆、入侵偵測與防範系統、防篡改微處理器及防篡改微控制器。

如何展現一致性？第二類產品不允許製造商進行自我評鑑（CRA第32（3）條）。因此，僅能基於模組 B+C 或模組 H 進行第三方評鑑。只有透過至少達到「重要」等級的歐洲資安驗證系統，才能推定符合基本資安要求。

3.8.4 關鍵產品

具有CRA附錄四中產品類型核心功能的數位元素被視為《關鍵》產品，包括：安全模組硬體、智慧電表閘道器、智慧卡、安全元件及其他用於先進安全目的等器材，包括安全的加密處理。

如何展現一致性？《關鍵》產品需依據歐洲資安驗證計畫（CRA第32（4）條）取得驗證。這可能包括基於歐洲共同準則（EUCC）的資安驗證。相應產品類型的相關方案將透過歐盟制定的授權法案獲得核准。若不存在此類法案，則需依照《重要》類型II的程序證明一致性。 

3.9 基本要求

CRA的核心要求即附錄一所列的基本要求。因此，本技術指引將逐字列出該等要求內容。

基本資安需求

第一部分 關於數位元素產品屬性的資安要求

a. 帶有數位元素的產品應遵循下述方式設計、開發及生產，以確保根據風險達到適當的網路與資訊安全水準。
b. 根據第13（2）條所述的網路與資訊安全風險評鑑，且在適用情況下，帶有數位元素的產品應：

1. 在市場上可獲得之際並無已知可利用的漏洞；
2. 除非製造商與商業用戶另有協議，並以安全預設配置在市場上可獲得之，該產品包含數位元素的量身打造產品，包括可將產品重設至原始狀態；
3. 確保漏洞能透過安全更新予以解決，包括在適當時間內安裝的自動安全更新，該更新已設定為原先預設之設定狀態，並具備清晰且易用的退出機制，透過通知用戶可用更新，以及暫時延後更新的選項；
4. 確保透過適當的控制機制防止未經授權存取，包括但不限於驗證、身份或存取管理系統，並對可能的未經授權存取進行報告；
5. 保護儲存、傳輸或其他處理資料的機密性，無論是個人資料還是其他資料，例如透過最先進機制加密靜態或傳輸中的相關資料，並使用其他技術手段；
6. 保護儲存、傳輸或其他資料（個人或其他）、指令、程式及設定架構的完整性，防止未經使用者授權的操作或修改，並回報毀損情況；
7. 僅處理相應、相關且侷限於產品預期用途所需的資料，包含個人或其他資料（資料最小化）；
8. 保護本初且基本功能的可用性，即使在事件發生後，也包括透過韌性與緩解措施來防範阻斷服務攻擊；
9. 將產品本身或連接裝置對其他裝置或網路所提供服務可用性的負面衝擊降到最低；
10. 設計、開發及生產以限制攻擊面，包括外部介面；
11. 設計、開發並生產，以利用適當的利用緩解機制與技術，以減少事件的衝擊；
12. 透過記錄與監督相關內部活動，包括存取或修改資料、服務或功能的活動，並提供使用者的退出機制，提供安全相關資訊；
13. 提供使用者安全且輕鬆地永久移除所有資料與設定的可能性，並在這些資料可轉移至其他產品或系統時，確保此過程安全。

（未完，見次篇）

製造商與產品的網路韌性要求 第一部分：一般要求（六之一）

BSI技術指引 TR-03183-1

適合一般產品及資訊安全產業界，具備基礎教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱歐盟與德國的BSI官方網站、洽詢各家驗證公司、諮詢顧問等。 CC BY-SA 4。0。

圖一：該指引目錄

1 介紹

《網路韌性法案》（EU 2024/2847 CRA）旨在提升歐盟網路與資訊安全的關鍵倡議。隨著數位產品與服務日益成為日常生活與商業的核心，CRA 引入了橫向法律網路與資訊安全架構，以應對因數位元素產品日益複雜且普及所帶來的網路與資訊安全風險。

透過為歐洲市場中帶有數位元素的產品建立必要的資訊安全（cybersecurity）要求，CRA 旨在減少市場碎片化，並確保所有使用者都能享有適當的資安水準。該法規鼓勵製造商在整個產品生命週期中採用安全設計原則及主動的漏洞管理。而且CRA支持韌性的數位環境，促進對科技的信任，並強化歐盟在全球數位經濟中的地位。

該技術指引（TR）旨在協助具備數位元素的產品製造商，根據CRA附錄I（基本網路與資訊安全需求）、附錄II（給使用者的資訊與指示）及附錄VII（技術文件內容）中所敘述或衍生出的安全目標，準備CRA所需的要求事項、建議、測試措施及評鑑準則。

對該技術指引的回饋可作為目前及未來在標準化請求中支持工會數位元素產品網路與資訊安全政策的參考。此請求包括制定標準化成果，旨在成為歐洲調和標準。符合這些歐洲調和標準，將推定在其範圍及可能的限制範圍內符符合法規要求規範。此等事項適用於一般性的水準標準以及產品類型的垂直標準。

當該技術指引內容被上述標準化要求下的相應標準化成果涵蓋後，將以前述形式化作業予以取代。

德國BSI聯邦資訊安全辦公室（見圖2），撰寫技術指引 TR-03183：製造商與產品的網路韌性要求，提供產業界參考運用。到目前為止（2026年5月）已公告的指引如示，參見德國BSI官方網站以獲得後續更新版本：

• TR-03183-1 製造商與產品的網路韌性要求 第一部分：一般要求
• TR-03183 -2製造商與產品的網路韌性要求 第二部分：軟體元組件清單（SBOM）
• TR-03183-3製造商與產品的網路韌性要求 第三部分：漏洞報告與通知版本
• TR-03183-H（草稿）製造商與產品的網路韌性要求 第H部分：基於完全品質保證（模式H）的符合性

圖二：德國BSI網站標識

2 重要：該指引現況

由於CRA的技術與法律細節仍在制定中，該指引將與歐洲標準化、法律澄清及對該指引的進一步回饋同步進行進一步發展。為此，該技術指引將作為「活文件」處理，並定期更新。

此文件可用於

• 為製造商收集有關CRA的資訊；
• CRA 實施的回饋平台及支持 CRA 標準化；
• 一份提供給CRA的資訊，以及為缺乏足夠結構化的安全設計與漏洞處理流程的製造商制定指引。

該指引不具備

• 對製造商建立任何義務；
• 在適用時，對CRA基本資安要求給予符合性的假設推定；
• 持續地反映當前標準化內容的狀態；
• 敘述能處理CRA的唯一方式。

3 網路韌性概述

《網路韌性法案》（CRA）指的是歐洲議會及理事會於2024年10月23日通過的第2024/2847號條例，該條例乃關於數位元素產品的橫向網路與資訊安全要求，並修訂了歐盟第168/2013號條例、（EU）2019/1020條例及（EU）2020/1828指令，是首部對歐盟市場上帶有數位元素產品設定強制性網路與資訊安全等級的橫向歐洲條例。其適用於能直接或間接連接器材或網路的硬體與軟體產品，例如：智慧型手機、筆記型電腦、智慧家庭裝置、物聯網產品、軟體應用程式，甚至是微處理器和防火牆等元件。製造商需在產品整個支援期間對資訊安全負起責任。另一方面，得以支援使用者獲得適當地選擇產品，確保產品具備網路與資訊安全的性能。新條例適用於所有歐盟成員國，並將會逐步地實施相關做法。

CRA的目標是：

• 保護消費者與企業免受數位產品中的資安漏洞與弱點影響；
• 解決供應鏈中的資安風險，確保產品設計與預設狀態皆為安全屬性，並讓使用者擁有安全地使用產品的必要資訊；
• 調和歐盟的網路與資訊安全標準，以統一地方式取代分散的法規狀況。

此章係歐洲產品法規的基本介紹，並概述CRA所訂定的概念與義務。

3.1 新立法架構 New Legislative Framework

CRA是遵循新立法架構（NLF）寫成的條例，該架構是一套於2008年通過的歐盟（EU）條例與決定，並於2010年全面生效。該架構設計目的是提升產品在歐盟內部市場的運行，並強化產品安全，進而提升歐盟內部市場的安全與法規一致性。該架構旨在透過統一產品法規及降低技術性貿易障礙，促進歐盟內貨物的自由流通。它強化歐盟內部市場監督規則，以更好地保護歐盟境內消費者和專職從業人士免受不安全或是被發現不安全的產品影響，包括從歐盟境外進口的產品。

該架構訂定了明確的符合法規評定規則，確保產品在放入市場前符合歐盟法規，並由歐洲調和標準支持。NLF為產品提供共同法律架構，並協調歐盟經濟營運者的義務達到一致且合於歐盟條約的基本水準。

新立法架構的基本理念是給予必要信任替代前期實施管制措施。該架構要求製造商確保其產品符合適用的法律要求。透過在產品貼附CE標誌，製造商宣告該等產品符合相關指令與條例的基本安全與基本性能要求。

雖然大多數產品在放入市場前毋需取得核准，但成員國市場監督的主管機關隨時會在歐盟境內執行抽樣檢查，主要透過在境內市場上（包括供應鏈各個階段、倉庫、店舖等）隨機抽樣。某些產品由授權的獨立第三方（即公告機構）進行上市前符合性評鑑，僅適用於相關條例中明確寫出的特定產品類型。

NLF的條例與CRA一致，訂定與條例管制下的產品相關基本要求。製造商可選擇各種各樣符合該等要求的技術解決方案。

3.2 CRA 的範圍

CRA 適用於市場上含有數位元件（PwDE: Products with digital elements）的產品，若其預期目的或合理可預見的使用，係包含直接或間接資料連結至器材或網路。（CRA第2條第1款）這包括透過軟體介面的邏輯連接，以及透過實體傳遞方式實現的電子資訊系統或元件之間的物理連接，包括電氣、光學或機械介面、導線或無線電波。

PwDE 是一種軟體或硬體產品及其遠端資料處理解決方案（RDPS），包括可能單獨上市的軟體或硬體元件。RDPS 包含軟體由製造商設計與開發，或由製造商負責的範圍內所有的資料處理，若缺乏此項功能，將阻礙帶有數位元素的產品執行其原有功能（CRA 第 3（1） 及 （2） 條）。

除了數位硬體（大多數已具備符合CE標誌的要求事項）外，商業發行的軟體也將受CE標誌約束。這也包括市場上免費提供但具有商業意圖的軟體，例如：具有營利服務模式的線上儲存服務行動應用程式，或由廣告支持的軟體。（CRA第3（22）條）。

3.2.1 排除事項

CRA 排除了一些已經受其他條例約束的產品類型：

• 屬於《歐盟醫療器材條例》（Regulation （EU）2017/745或《歐盟體外診斷醫療器材條例》（Regulation （EU）2017/746（《CRA》第2（2）a）&,b）條）適用範圍的醫療器材；
• 屬於歐盟法規2019/2144（CRA第2（2）c）條）範疇內的機動車輛及其拖車；
• 具備數位元素且依民航領域共同規則認證的產品，如歐盟法規2018/1139（CRA第2（3）條）；
• 屬於歐洲議會及理事會指令2014/90/EU（CRA第2（4）條）範疇內的海事設備；

CRA也不適用於：

• 市場上可用以替換相同零件的備件（CRA第2（6）條）；
• 專為國家安全而開發或修改的數位元素產品（CRA第2（7）條）；
• 專門設計用於處理機密資訊的產品（CRA第2（7）條）；
• 無商業意圖的軟體，如：自由開源軟體（FOSS）（CRA第3（22）條）；
• 雲端服務可獨立於使用者基礎設施，即無需本地客戶端上市的 I/P/SaaS（CRA 第 3（1） 條）；

（未完，見次篇）

連續血糖監測系統 (CGM)符合資訊安全條例模擬（五之五）

 （續前篇）

適合醫療器材及資訊安全產業界，具備大學教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO與歐盟官方網站、洽詢各家驗證公司、諮詢顧問等。CC BY-SA 4。0。

13.外部第三方合作

在 CGM 系統的整個生命週期中，製造商往往需要與眾多外部第三方進行合作，包括供應商、測試實驗室、驗證機構、雲端服務提供商等。該等外部第三方的網路與資訊安全狀況直接影響到 CGM 系統的整體安全性。因此，建立一套健全的第三方風險管理機制至關重要。

供應商管理

• 供應商評估：在選擇供應商時，應將其網路與資訊安全能力作為重要的評估標準。這包括審查其資訊安全管理系統（如 ISO/IEC 27001 驗證）、安全開發流程、漏洞管理政策等。
• 合約條款：在與供應商簽訂合約時，應明確約定網路與資訊安全責任、資料保護要求、漏洞披露和事件響應機制。
• 持續監控：定期對關鍵供應商進行網路與資訊安全稽核和績效評估，確保其持續符合安全要求。
• SBOM 要求：要求供應商提供其軟體元組件的 SBOM，以實現供應鏈的透明度。

測試實驗室

• 資格查證：選擇具備相關資質和經驗的第三方測試實驗室，進行網路與資訊安全測試（如滲透測試、漏洞掃描）。確保該等實驗室遵循國際標準和現今技術水準的最佳實務。
• 測試範圍與方法：製造商宜明確做出測試範圍、測試方法和驗收準則，確保受測件的測試結果足以涵蓋量產階段的同型器材及元組件，得以展現此等測試的有效性和可靠性。

公告機構 (Notified Body) 與稽核機構

• MDR 驗證：與指定的公告機構合作，進行 MDR 符合性評鑑，包括CGM系統技術文件審查和 QMS 稽核（MDR附錄IX）。確保公告機構對網路與資訊安全要求有深入理解。
• ENISA 驗證：若選擇進行 ENISA 網路與資訊安全驗證（如 EUCC），則需與經 ENISA 授權的符合性評估機構 (CAB) 合作，進行CGM系統的產品或服務之評鑑和驗證。

雲端服務提供商

• 安全協議：與雲端服務提供商簽訂服務級別協議 (SLA)，明確約定安全控制措施、資料主權、隱私保護和事件響應流程。
• 符合法規性證明：要求雲端服務提供商提供其安全驗證（如 ISO/IEC 27001、CSA STAR 驗證）和符合法規性的報告。

臨床資料與臨床評估

• 資料安全：確保在臨床試驗和臨床評估過程中，患者資料的收集、儲存、傳輸和分析都符合資料保護法規（如 GDPR）和網路與資訊安全要求。
• 安全評估：在臨床評估中納入對網路與資訊安全事件對患者臨床結果潛在影響的評鑑。

透過與該等外部第三方的有效合作和管理，製造商可以共同構建一個更安全的 CGM 生態系統，整體地降低網路與資訊安全風險。

14.實務案例分析

網路與資訊安全事件在醫療器材領域層出不窮，對患者安全、資料隱私和製造商聲譽造成嚴重影響。本節將探討一些正反面實務案例，以期從中汲取經驗教訓。

負面案例：醫療器材召回與漏洞披露

• 美敦力胰島素泵漏洞 (Medtronic Insulin Pump Vulnerability)：2019 年，FDA 曾發布關於美敦力 MiniMed 胰島素泵的網路與資訊安全漏洞警報。駭客可能透過無線連接，未經授權地更改泵的設定，導致過量或不足的胰島素輸送，對患者造成嚴重傷害。儘管沒有實際傷害報告，但此事件凸顯了遠端連接醫療器材的潛在風險，並促使 FDA 發布了相關召回通知。

• 雅培心臟器材漏洞 (Abbott Cardiac Devices Vulnerabilities)：2017 年，FDA 曾針對雅培（當時為 St. Jude Medical）的心臟植入式器材（如心臟起搏器和除顫器）發布網路與資訊安全漏洞警告。該等漏洞可能允許未經授權的存取，進而耗盡電池或更改治療設定。製造商透過軟體更新解決了該等問題，但事件引發了對植入式醫療器材網路與資訊安全的高度關注。

• 自動化 Impella 控制器召回 (Automated Impella Controller Recall)：2025 年 10 月，FDA 發布了一項針對 Abiomed 自動化 Impella 控制器的召回，原因為網路與資訊安全問題。該召回涉及軟體修正，而非將器材從市場上撤回，但強調了即使是關鍵生命支持器材也可能面臨網路與資訊安全風險。

 該等案例共同揭示了醫療器材網路與資訊安全漏洞的嚴重性，以及製造商在產品生命週期中持續關注和管理網路與資訊安全風險的必要性。及時的漏洞披露、有效的軟體更新和召回管理是應對此類事件的關鍵。

正面案例：主動的安全響應與合作

雖然醫療器材網路與資訊安全事件多為負面，但一些製造商透過主動的安全響應和與主管機關的合作，展現了良好的實踐：

• 協同漏洞披露 (Coordinated Vulnerability Disclosure, CVD)：越來越多的醫療器材製造商開始採用 CVD 流程，與安全研究人員合作，鼓勵負責任地披露漏洞，並在漏洞公開前進行修復。這有助於在潛在威脅被惡意利用之前，及時解決問題。
• 建立產品安全事件響應團隊 (PSIRT)：許多領先的醫療器材公司已建立專門的 PSIRT 團隊，負責監控、評估和響應產品的網路與資訊安全事件。該等團隊通常與內部研發、法規、法律和客戶服務部門緊密合作，確保快速有效的響應。
• 整合安全設計原則：一些製造商在產品開發初期就將網路與資訊安全作為核心設計原則，例如採用安全啟動、硬體信任根、資料加密和最小權限原則。這有助於從源頭上減少漏洞，並提升產品的整體安全性。
• 與 ENISA 和 FDA 的合作：製造商積極參與 ENISA 和 FDA 關於醫療器材網路與資訊安全指引的制定和討論，這不僅有助於影響未來的法規，也使其能夠更好地理解和準備應對新的符合法規要求。

該等正面案例表明，透過建立健全的內部機制、積極與外部合作夥伴和主管機關溝通，製造商可以有效提升其網路與資訊安全韌性，並在面對潛在威脅時做出快速而負責任的響應。

15.方案對比與建議

15.1 本模擬報告針對 CGM 製造商提出了兩種歐盟網路與資訊安全符合法規方案：A 方案（50% 符合法規）和 B 方案（70% 符合法規）。以下將對這兩種方案進行詳細對比，並提出最終建議。

(圖15.1)

15.2 核心發現

• 法規環境複雜但明確：EU MDR 2017/745已建立完整的網路安全要求架構，IEC 81001-5-1雖尚未正式公告為調和標準，但已被公告機構視為現今技術水準。製造商無需等待標準正式調和，宜立即採用。
• 時間緊迫但可行：2026年至2032年的6年期間，對於從FDA 510(k)基礎建立完整EU MDR網路與資訊安全符合體系尚稱充足，但需立即啟動各項措施，尤其是團隊擴編與流程建立。
• 資源限制可透過委外克服：少於100人的公司規模，透過策略性委外（歐盟授權代表、滲透測試、驗證顧問）可有效補充內部能力不足。
• 網路與資訊安全與臨床安全不可分割：CGM連接AID系統的特性，使網路與資訊安全失效直接等同於臨床風險。這是選擇Plan B（70%合規）的關鍵理由。

最終建議

綜合考量符合法規目標、成本效益、市場競爭力、法規風險和品牌聲譽，本短文建議 CGM 製造商採納 B 方案，並將其作為 2032 年的戰略目標。

儘管 B 方案的初期投入顯著高於 A 方案，但其所帶來的長期效益和風險規避能力是 A 方案無法比擬的。在日益嚴峻的網路與資訊安全環境和不斷收緊的法規要求下，僅僅滿足最低符合法規要求（A 方案）將使製造商面臨巨大的不確定性和潛在風險。一旦發生網路與資訊安全事件，可能導致巨額罰款、產品召回、市場禁止進入和品牌聲譽的毀滅性打擊，該等損失將遠超 B 方案的額外投入。

採納 B 方案，不僅能確保製造商在 2032 年前達到歐盟網路與資訊安全法規的領先水準，更能透過 ENISA 驗證等措施，向市場和患者展現其對產品安全的堅定承諾。這將為製造商帶來顯著的競爭優勢，提升品牌信任度，並為未來的產品創新和市場擴張奠定堅實的基礎。建議製造商應盡早啟動 B 方案的實施，並在執行過程中保持靈活性，持續監測法規和技術的最新發展，確保符合法規策略的有效性和前瞻性。

(圖15.2)

短期目標（2026-2027）

• 完成網路與資訊安全風險管理計畫與威脅模型
• 建立安全開發生命週期（SSDLC）流程
• 完成首次第三方滲透測試
• 準備MDR技術文件（含網路與資訊安全章節）

中期目標（2028-2029）

• 取得CE標誌（Plan A與Plan B共同里程碑）
• 建立上市後監督（PMS）與定期安全更新報告（PSUR）流程
• Plan B：啟動ISO 27001與ENISA驗證準備

長期目標（2030-2032）

• Plan B：取得網路與資訊安全驗證
• 建立自動化安全更新與威脅情報整合機制
• 完成2032年合規驗證，確保持續放入目標市場

15.3 風險提示

• 標準演進風險：IEC 81001-5-1預計2028年正式調和，可能伴隨修訂。建議持續參與標準化組織（如AAMI、DIN）的短訊推送，以掌握最新動態。
• 公告機構容量風險：MDR實施後公告機構數量不足，稽核排程可能延遲。建議儘早簽約並建立良好關係。
• 供應鏈地緣政治風險：BLE晶片、加密模組等關鍵元件涉及國際供應鏈，需建立替代供應商名單。

16.結論

本模擬報告為連續血糖監測系統 (CGM) 製造商提供了全面的歐盟網路與資訊安全符合法規策略分析，旨在協助其應對 EU 2019/881 (Cybersecurity Act) 和 EU 2017/745 (MDR) 等關鍵法規的挑戰。透過深入探討法規架構、風險管理、設計開發、資訊安全法規、查證與確證、人力資源配置、市場監督、成本估算以及實務案例，我們勾勒出了一條清晰的符合法規路徑。

此文強烈建議製造商採納更為全面的 B 方案，即在滿足 MDR 基本要求的基礎上，積極追求 ENISA 網路與資訊安全驗證，並實施進階的網路與資訊安全措施。這不僅是為了避免潛在的巨額罰款和市場風險，更是為了在競爭激烈的醫療器材市場中，建立領先的網路與資訊安全防護，贏得患者和主管機關的信任，確保企業的長期可持續發展。

網路與資訊安全符合法規是一個持續演進的過程，需要製造商在技術、流程和人員方面進行持續投資。透過本模擬報告提供的策略指引，我們相信 CGM 製造商能夠有效應對未來的挑戰，並在 2032 年前成功達成其網路與資訊安全符合法規目標。

17.免責聲明

本模擬報告所提供的資訊係基於2025年4月前公開可得之法規、標準與產業資訊編製，僅供參考和一般性指引之用，不應被視為法律、技術或專業建議。本模擬報告的內容基於截至撰寫日期可獲得的公開資訊和專業判斷，但歐盟醫療器材法規、標準和網路與資訊安全技術發展可能會有進一步的修正，隨著技術與市場狀況及時更新。因此，製造商在制定和實施具體符合法規策略時，每半年與法律顧問及資訊安全專家重新審視一次本模擬報告，多方查證，以確保其決策的準確性和適用性：

• 定期查證法規更新：特別關注歐盟公報（OJEU）協調標準更新、MDCG指引文件發布
• 諮詢專業法規顧問：本報告不構成法律意見，具體合規策略應與具備資格的法規顧問、網路與資訊安全專家，向其確認最新狀況；
• 考量個案差異：本報告基於CGM特性編製，其他器材需洽詢驗證機構，依其評估結果調整採用；
• 成本估算僅供參考：實際成本受市場條件、供應商選擇、專案範圍變更等因素影響

本模擬報告不對因依賴此模擬報告內容而採取的任何措施或作為承擔任何責任。亦不因使用本模擬報告內容而產生的任何損失承擔責任。

 18.參考文獻

[1] Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 on ENISA (the European Union Agency for Cybersecurity) and on information and communications technology cybersecurity certification and repealing Regulation (EU) No 526/2013 (Cybersecurity Act). EUR-Lex.

[2] Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EU) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC. EUR-Lex.

[3] IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product lifecycle.

[4] ISO/TS 6268-1:2025 Health informatics — Cybersecurity framework for telehealth environments - Part 1: Overview and concepts.

[5] Cybersecurity Certification Framework. ENISA.

[6] Homepage - European Union Cybersecurity Certification. ENISA.

[7] Cybersecurity Specialist Salary in Frankfurt am Main, Germany (2026). SalaryExpert. https://www.salaryexpert.com/salary/job/cybersecurity-specialist/germany/frankfurt-am-main

[8] How Much Can You Earn In Cybersecurity? (USA vs Germany). YouTube.

[9] EN IEC 81001-5-1 Guide: Cybersecurity for MDR and IVDR. Thema-Med.

[10] The Top 7 Medical Device Vulnerabilities of 2025. RunSafe Security.

[11] ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements.

[12] German Medical Devices Act (MPDG).

[13] Regulation (EU) 2019/1020 of the European Parliament and of the Council of 20 June 2019 on market surveillance and compliance of products and amending Directive 2004/42/EC and Regulations (EC) No 765/2008 and (EU) No 305/2011. EUR-Lex.

[14] The First Recall of a Diabetes Device Because of Cybersecurity Vulnerabilities. PMC. https://pmc.ncbi.nlm.nih.gov/articles/PMC6955451/

[15] Cybersecurity vulnerabilities in medical devices: a complex problem. PMC. https://pmc.ncbi.nlm.nih.gov/articles/PMC4516335/

[16] Alert: Automated Impella Controller Correction due to Cybersecurity Issue. FDA. https://www.fda.gov/medical-devices/medical-device-recalls-and-early-alerts/alert-automated-impella-controller-correction-due-cybersecurity-issue-abiomed

[17] FDA Cybersecurity Guidance (Pre-market/Post-market): FDA.gov

（全文完）