EU RED（EN 18031）與 CRA（歐盟網路韌性法案）
Applicability Check
EN 18031 是歐盟認可的調和標準，對應 RED 的 3 項網路安全要求：網路防護（-1）、個資保護（-2）、金融資產保護（-3）。只要回答 4 個問題，即可看到適用哪份標準、原因，以及可自我宣告或須經公告機構評估。
尚未作答
本工具結果僅供初步參考，實際適用範圍以產品技術文件與實驗室評估為準。
Process
第 5、6 步最常需要來回修補。安合規律透過前置的 Gap Analysis（差距分析）提早找出問題，有助於縮短整體時程。點選各步驟，查看實際檢測內容。
提供檢測所需之實體裝置、App，以及 Server 的存取資訊與技術文件。
| 範圍 | 適合情境 | 必備條件 | 工作量與時程 |
|---|---|---|---|
| 1. 僅裝置 | 產品設定固定、可離線運作 | 無線功能送測版本須於出廠時關閉 | 最低・最快 |
| 2. 裝置 + App | 以 App 遠端控制裝置 | 須具備配對控制與傳輸加密 | 中等 |
| 3. 裝置 + App + Server | 資料會上傳至伺服器儲存／運算 | 除上述外，另加伺服器資料加密與防護 | 最高・需時較長 |
備註：僅用於控制裝置的 App 無法單獨進行認證，須與實體裝置一併檢測。
由 Lab 工程師逐項比對 EN 18031 標準與技術文件，優先找出系統架構與標準要求之間的不符合項目。
運用 EN 18031 標準之「決策樹（Decision Trees）」，判定各防護機制的適用性，以及不適用理由的合理性；同時審查安全開發流程（SDLC）紀錄，確認資安需求已納入設計規格。
Decision Trees依 EN 18031 決策樹逐項確認各防護機制的適用路徑，並檢視不適用理由是否完整、合理。SDLC審查製造商或委外廠商的開發紀錄，確認在分析、設計、實作、驗證 4 大階段中，皆已將資安威脅與防禦機制納入考量。盤點開源軟體物料清單，找出函式庫與框架中的已知弱點（CVE）。
SBOM / CVE透過專業工具（如 Black Duck）檢查第三方元件、函式庫與框架中是否存在 CVE 已知弱點。有無提供原始碼皆可進行分析。實測驗證產品的防護機制，確認是否與技術文件一致，以及實作是否足以達成防護目的。
實測確認產品實際具備的防護機制，與技術文件所列一致、無遺漏。例如實測發現某個身分驗證機制未列入文件，即須補正。
透過程式碼掃描與滲透測試，針對裝置、App、Server 及其間的無線連線，逐項確認各機制的實作是否適當：
ACM檢驗身分存取控制邏輯，驗證未授權的 App 能否取得裝置控制權，並確認配對機制（如實體按鍵確認或配對鑑別）是否能阻擋未授權存取。AUM確認程式中無硬編碼憑證（Hardcoded Credentials）或通用預設密碼；預設密碼須為每台唯一，或於首次使用時強制變更。SCM確認裝置、App 與雲端之間的傳輸採用符合最佳實務的加密機制，並驗證控制指令與敏感資料交換是否具備抗重放防護（如 Nonce／時效性權杖）。SUM評估更新管道安全性，確認裝置具備更新能力，且每次安裝韌體前皆經數位簽章或金鑰驗證來源與完整性。SSM / CCK評估金鑰、權杖（Token）與機敏設定於裝置本地儲存（Flash／EEPROM）時的保護措施。GEC確認送測樣品已關閉未使用的網路介面與服務，降低攻擊面。其他機制（如 RLM、CRY、LGM、DLM、UNM）依產品適用性評估。
依據檢測報告，由廠商研發團隊執行漏洞修補，並同步修正底層安全開發設計（如鑑別邏輯、金鑰存放與架構參數）；隨後由安合規律進行複測，直到確認問題已修正。
安合規律台北實驗室依 ISO/IEC 17025 出具檢測報告。產品如需公告機構評估，可銜接 Applus+ Laboratories（NB 0370），檢測報告可作為審查參考。
上市後備妥檢測報告與資安技術文件。歐盟主管機關可透過授權代表要求限期提供。
檢測範圍（單一裝置最快；納入 App／Server 則時程增加）、開啟的無線介面數量、開發紀錄的完整度，以及漏洞修補來回的次數。
Before You Start
提早盤點並避開以下 3 大缺口，有助於節省修補時間與成本。
軟韌體多由外部開發，卻無人保有「安全開發流程（SDLC）」紀錄，導致開發流程審查無法完成。
裝置雖具備更新能力，但在安裝前卻缺乏金鑰或簽章來確認更新檔的真實性。
過度依賴藍牙預設加密（常未啟用），導致生理資料或個人資料以明文傳輸，不符合標準對個人資料傳輸的保護要求。
點擊後，盤點結果將自動帶入下方表單。
FAQ
可以。完整套用標準且未涉及限制條件的產品，製造商可自行宣告符合，但仍須備妥技術文件供主管機關調閱。若允許不設定密碼、兒童產品未提供家長存取控制，或適用 EN 18031-3，相關部分須經公告機構評估。
法規未強制要求。自我宣告的產品，由製造商自行負責備妥技術文件；第三方實驗室的檢測報告可作為技術文件的客觀佐證，於市場抽查或主管機關調閱時，有助於說明產品的符合性。
無法。僅用於控制裝置的 App 本身不構成獨立功能，須與裝置一併檢測。
標準要求的不是 OTA 本身，而是韌體可以更新，且每次更新安裝前都經過驗證。未經驗證的更新方式會被列為不符合項目。無實際更新可能的一次性產品，可提出不設更新機制的理由，由實驗室個案評估。
含已知弱點的元件須於上市前更新或替換；若經評估該弱點在產品中無法被利用，可提出說明，再由實驗室複測確認。
受 MDR／IVDR 規範的醫療器材不在 RED 網路安全要求範圍內，法規上不強制。但 EN 18031 的檢測結果可作為 MDR 與 FDA 資安文件的參考證據。了解醫療器材資安檢測 →
CRA 是歐盟針對數位產品的新資安法規，部分技術標準參考 EN 18031 系列發展。現階段完成 EN 18031 檢測所累積的技術文件與檢測證據，可作為後續 CRA 合規的基礎。了解 EU CRA →
EU RED（EN 18031）与 CRA（欧盟网络弹性法案）
Applicability Check
EN 18031 是欧盟认可的协调标准，对应 RED 的 3 项网络安全要求：网络防护（-1）、个人信息保护（-2）、金融资产保护（-3）。只要回答 4 个问题，即可看到适用哪份标准、原因，以及可自我声明或须经公告机构评估。
尚未作答
本工具结果仅供初步参考，实际适用范围以产品技术文件与实验室评估为准。
Process
第 5、6 步最常需要来回修补。安合规律通过前置的 Gap Analysis（差距分析）提早找出问题，有助于缩短整体周期。点击各步骤，查看实际检测内容。
提供检测所需之实物设备、App，以及 Server 的访问信息与技术文件。
| 范围 | 适合情境 | 必备条件 | 工作量与周期 |
|---|---|---|---|
| 1. 仅设备 | 产品设置固定、可离线运行 | 无线功能送检版本须于出厂时关闭 | 最低・最快 |
| 2. 设备 + App | 以 App 远程控制设备 | 须具备配对控制与传输加密 | 中等 |
| 3. 设备 + App + Server | 数据会上传至服务器保存／运算 | 除上述外，另加服务器数据加密与防护 | 最高・需时较长 |
备注：仅用于控制设备的 App 无法单独进行认证，须与实物设备一并检测。
由 Lab 工程师逐项比对 EN 18031 标准与技术文件，优先找出系统架构与标准要求之间的不符合项目。
运用 EN 18031 标准之「决策树（Decision Trees）」，判定各防护机制的适用性，以及不适用理由的合理性；同时审查安全开发流程（SDLC）记录，确认网络安全需求已纳入设计规格。
Decision Trees依 EN 18031 决策树逐项确认各防护机制的适用路径，并检查不适用理由是否完整、合理。SDLC审查制造商或外包厂商的开发记录，确认在分析、设计、实现、验证 4 大阶段中，皆已将网络安全威胁与防御机制纳入考量。盘点开源软件物料清单，找出库与框架中的已知漏洞（CVE）。
SBOM / CVE通过专业工具（如 Black Duck）检查第三方组件、库与框架中是否存在 CVE 已知漏洞。有无提供源代码皆可进行分析。实测验证产品的防护机制，确认是否与技术文件一致，以及实现是否足以达成防护目的。
实测确认产品实际具备的防护机制，与技术文件所列一致、无遗漏。例如实测发现某个身份验证机制未列入文件，即须补正。
通过代码扫描与渗透测试，针对设备、App、Server 及其间的无线连接，逐项确认各机制的实现是否适当：
ACM检验身份访问控制逻辑，验证未授权的 App 能否取得设备控制权，并确认配对机制（如物理按键确认或配对认证）是否能阻挡未授权访问。AUM确认代码中无硬编码凭据（Hardcoded Credentials）或通用默认密码；默认密码须为每台唯一，或于首次使用时强制修改。SCM确认设备、App 与云端之间的传输采用符合最佳实践的加密机制，并验证控制指令与敏感数据交换是否具备抗重放防护（如 Nonce／时效性令牌）。SUM评估更新管道安全性，确认设备具备更新能力，且每次安装固件前皆经数字签名或密钥验证来源与完整性。SSM / CCK评估密钥、令牌（Token）与敏感设置于设备本地存储（Flash／EEPROM）时的保护措施。GEC确认送检样品已关闭未使用的网络接口与服务，降低攻击面。其他机制（如 RLM、CRY、LGM、DLM、UNM）依产品适用性评估。
依据检测报告，由厂商研发团队执行漏洞修补，并同步修正底层安全开发设计（如认证逻辑、密钥存放与架构参数）；随后由安合规律进行复测，直到确认问题已修正。
安合规律台北实验室依 ISO/IEC 17025 出具检测报告。产品如需公告机构评估，可衔接 Applus+ Laboratories（NB 0370），检测报告可作为审查参考。
上市后备齐检测报告与网络安全技术文件。欧盟监管机构可通过授权代表要求限期提供。
检测范围（单一设备最快；纳入 App／Server 则周期增加）、启用的无线接口数量、开发记录的完整度，以及漏洞修补来回的次数。
Before You Start
提早盘点并避开以下 3 大缺口，有助于节省修补时间与成本。
软件和固件多由外部开发，却无人保有「安全开发流程（SDLC）」记录，导致开发流程审查无法完成。
设备虽具备更新能力，但在安装前却缺乏密钥或签名来确认更新文件的真实性。
过度依赖蓝牙默认加密（常未启用），导致生理数据或个人数据以明文传输，不符合标准对个人数据传输的保护要求。
点击后，盘点结果将自动带入下方表单。
FAQ
可以。完整套用标准且未涉及限制条件的产品，制造商可自行声明符合，但仍须备齐技术文件供监管机构调取。若允许不设置密码、儿童产品未提供家长控制，或适用 EN 18031-3，相关部分须经公告机构评估。
法规未强制要求。自我声明的产品，由制造商自行负责备齐技术文件；第三方实验室的检测报告可作为技术文件的客观佐证，于市场抽查或监管机构调取时，有助于说明产品的符合性。
无法。仅用于控制设备的 App 本身不构成独立功能，须与设备一并检测。
标准要求的不是 OTA 本身，而是固件可以更新，且每次更新安装前都经过验证。未经验证的更新方式会被列为不符合项目。无实际更新可能的一次性产品，可提出不设更新机制的理由，由实验室个案评估。
含已知漏洞的组件须于上市前更新或替换；若经评估该漏洞在产品中无法被利用，可提出说明，再由实验室复测确认。
受 MDR／IVDR 规范的医疗器械不在 RED 网络安全要求范围内，法规上不强制。但 EN 18031 的检测结果可作为 MDR 与 FDA 网络安全文件的参考证据。了解医疗器械网络安全检测 →
CRA 是欧盟针对数字产品的新网络安全法规，部分技术标准参考 EN 18031 系列发展。现阶段完成 EN 18031 检测所累积的技术文件与检测证据，可作为后续 CRA 合规的基础。了解 EU CRA →
EU RED (EN 18031) and the CRA (EU Cyber Resilience Act)
Applicability Check
EN 18031 is the EU harmonised standard for the three RED cybersecurity requirements: network protection (-1), personal data protection (-2) and protection of financial assets (-3). Answer four questions to see which parts apply, why, and whether you can self-declare conformity or need Notified Body assessment.
No answers yet
This tool gives a preliminary indication only. The actual scope is determined from the product’s technical documentation and the laboratory’s assessment.
Process
Steps 5 and 6 are where most back-and-forth happens. SV Surveillance runs a gap assessment up front to surface issues early, which helps shorten the overall timeline. Select a step to see what is actually tested.
Provide the physical devices and app needed for testing, plus access details and technical documentation for the server.
| Scope | Typical fit | Prerequisites | Effort and time |
|---|---|---|---|
| 1. Device only | Fixed settings; works offline | Radios disabled at the factory in the version submitted for testing | Lowest · fastest |
| 2. Device + app | An app controls the device remotely | Pairing control and transmission encryption in place | Medium |
| 3. Device + app + server | Data is uploaded to a server for storage or processing | All of the above, plus server-side data encryption and protection | Highest · longest |
Note: an app that only controls the device cannot be certified on its own; it is tested together with the physical device.
Lab engineers compare the technical documentation with EN 18031 clause by clause, focusing first on non-conformities between the system architecture and the standard’s requirements.
Using the decision trees in EN 18031, the lab determines which security mechanisms apply and whether the justification for any that do not is sound. It also reviews the secure development lifecycle (SDLC) records to confirm that security requirements are reflected in the design specification.
Decision TreesEach security mechanism is walked through the EN 18031 decision trees, and any “not applicable” justification is checked for completeness and soundness.SDLCDevelopment records from the manufacturer or its outsourced developer are reviewed to confirm that security threats and defences were considered in all four phases: analysis, design, implementation and verification.The open-source software bill of materials is inventoried and libraries and frameworks are checked for known vulnerabilities (CVEs).
SBOM / CVEProfessional tooling (such as Black Duck) checks third-party components, libraries and frameworks for known CVEs. Analysis is possible with or without source code.The product’s security mechanisms are verified in hands-on testing, to confirm that they match the technical documentation and that their implementation is adequate for its protective purpose.
Hands-on testing confirms that the security mechanisms the product actually has match those listed in the technical documentation, with nothing missing. For example, if testing finds an authentication mechanism that is not in the documentation, the documentation must be corrected.
Through code scanning and penetration testing of the device, app, server and the wireless links between them, each mechanism is checked item by item to confirm that it is implemented appropriately:
ACMTests the access-control logic, checks whether an unauthorised app can take control of the device, and confirms that pairing (for example a physical button press or pairing authentication) blocks unauthorised access.AUMConfirms there are no hard-coded credentials or universal default passwords; default passwords must be unique per device or changed on first use.SCMConfirms that traffic between device, app and cloud uses encryption in line with best practice, and verifies replay protection (such as nonces or time-limited tokens) on control commands and sensitive data exchanges.SUMAssesses the security of the update channel, confirms the device can be updated, and verifies that every firmware install checks source and integrity with a digital signature or key.SSM / CCKAssesses how keys, tokens and sensitive settings are protected when stored locally on the device (Flash / EEPROM).GECConfirms that unused network interfaces and services are disabled on the submitted samples, reducing the attack surface.Other mechanisms (such as RLM, CRY, LGM, DLM and UNM) are assessed according to their applicability to the product.
Working from the test report, the manufacturer’s R&D team fixes the vulnerabilities and corrects the underlying security design (such as authentication logic, key storage and architecture parameters). SV Surveillance then retests until the findings are confirmed as resolved.
SV Surveillance’s Taipei laboratory issues the test report under ISO/IEC 17025. Where the product needs Notified Body assessment, this can continue with Applus+ Laboratories (NB 0370), and the test report can serve as input to its review.
After launch, keep the test report and security technical documentation ready. EU market surveillance authorities can request them through your authorised representative, with a deadline they set.
The test scope (device only is fastest; adding an app or server adds time), the number of active wireless interfaces, how complete the development records are, and how many fix-and-retest rounds are needed.
Before You Start
Checking early for these three common gaps saves fix-and-retest time and cost.
Firmware and software are often developed externally, but nobody holds the secure development lifecycle (SDLC) records, so the development process review cannot be completed.
The device can be updated, but nothing checks an update’s authenticity with a key or signature before it is installed.
Relying on Bluetooth’s built-in encryption (often not enabled) leaves physiological or personal data travelling in clear text, which does not meet the standard’s protection requirements for personal data in transit.
Your checklist status is copied into the form below when you click.
FAQ
Yes. Where a product applies the standard in full and none of the restrictions are involved, the manufacturer can declare conformity itself, but it must still keep the technical documentation ready for the authorities. If the product lets users skip setting a password, is a toy or childcare product without parental access control, or falls under EN 18031-3, those parts need Notified Body assessment.
The law does not require it. For self-declared products, the manufacturer is responsible for the technical documentation; a third-party laboratory’s test report serves as objective evidence in that documentation and helps demonstrate conformity during market surveillance checks or when authorities request the file.
No. An app that only controls a device has no independent function, so it is tested together with the device.
The standard does not require OTA as such; it requires that the firmware can be updated and that every update is verified before it is installed. An update method without verification is recorded as a non-conformity. A single-use product with no practical way to be updated can justify having no update mechanism, and the laboratory assesses that case by case.
Components with known vulnerabilities must be updated or replaced before the product goes to market. If an assessment shows the vulnerability cannot be exploited in the product, this can be documented and the laboratory confirms it in a retest.
Medical devices regulated under the MDR or IVDR are outside the scope of the RED cybersecurity requirements, so it is not a legal requirement. EN 18031 test results can still serve as supporting evidence in MDR and FDA cybersecurity documentation. Medical device cybersecurity testing →
The CRA is the EU’s new cybersecurity regulation for products with digital elements, and some of its technical standards are being developed with reference to the EN 18031 series. The technical documentation and test evidence built up through EN 18031 testing now serve as groundwork for CRA compliance later. About the EU CRA →
EU 無線機器指令（RED／EN 18031）とサイバーレジリエンス法（CRA）
Applicability Check
EN 18031 は、RED の 3 つのサイバーセキュリティ要件に対応する EU の整合規格です：ネットワークの保護（-1）、個人データの保護（-2）、金融資産の保護（-3）。4 つの質問に答えると、適用される規格とその理由、自己宣言できるか、ノーティファイドボディによる評価が必要かを確認できます。
まだ回答がありません
本ツールの結果は初期判断の目安です。実際の適用範囲は、製品の技術文書と試験所の評価に基づいて決まります。
Process
修正と再試験の往復が最も多いのはステップ 5 と 6 です。SV Surveillance は事前のギャップ分析で問題を早期に洗い出し、全体の期間短縮に役立てます。各ステップを選ぶと、実際の試験内容を確認できます。
試験に必要な実機とアプリ、サーバーのアクセス情報と技術文書を提出していただきます。
| 範囲 | 想定される製品 | 前提条件 | 工数と期間 |
|---|---|---|---|
| 1. 機器のみ | 設定が固定され、オフラインで動作する | 試験提出版では無線機能を出荷時に無効化していること | 最小・最短 |
| 2. 機器 + アプリ | アプリで機器を遠隔操作する | ペアリング制御と通信の暗号化が必要 | 中程度 |
| 3. 機器 + アプリ + サーバー | データをサーバーに送信して保存・処理する | 上記に加え、サーバー側のデータ暗号化と保護 | 最大・長期間 |
注：機器の操作だけに使うアプリは単独で認証を受けられず、実機と一緒に試験します。
試験所のエンジニアが EN 18031 と技術文書を項目ごとに照合し、システムアーキテクチャと規格要求との不適合を優先的に洗い出します。
EN 18031 のデシジョンツリー（決定木）を用いて、各セキュリティメカニズムが適用されるか、また適用外とする理由が妥当かを判定します。あわせてセキュア開発ライフサイクル（SDLC）の記録を確認し、セキュリティ要件が設計仕様に反映されていることを確かめます。
Decision TreesEN 18031 のデシジョンツリーに沿って各セキュリティメカニズムの適用可否を確認し、適用外とする理由が十分かつ妥当かを検証します。SDLC製造業者または委託先の開発記録を確認し、分析・設計・実装・検証の 4 段階すべてでセキュリティ上の脅威と対策が考慮されていることを確かめます。オープンソースのソフトウェア部品表（SBOM）を作成し、ライブラリやフレームワークに既知の脆弱性（CVE）がないかを確認します。
SBOM / CVE専用ツール（Black Duck など）で、サードパーティ製コンポーネント、ライブラリ、フレームワークに既知の CVE がないかを確認します。ソースコードの有無にかかわらず分析できます。製品のセキュリティメカニズムを実機試験で検証し、技術文書の記載と一致しているか、保護の目的に対して実装が十分かを確認します。
実機試験により、製品が実際に備えるセキュリティメカニズムが技術文書の記載と一致し、漏れがないことを確認します。たとえば技術文書にない認証メカニズムが試験で見つかった場合は、技術文書の修正が必要です。
機器、アプリ、サーバーとそれらを結ぶ無線通信を対象に、コードスキャンとペネトレーションテストで各メカニズムの実装が適切かを項目ごとに確認します：
ACMアクセス制御のロジックを検査し、未許可のアプリが機器を操作できないか、ペアリングの仕組み（物理ボタンでの確認やペアリング認証など）が不正アクセスを防げるかを検証します。AUMハードコードされた認証情報や共通の初期パスワードがないことを確認します。初期パスワードは機器ごとに固有であるか、初回使用時に変更を必須とする必要があります。SCM機器、アプリ、クラウド間の通信がベストプラクティスに沿った暗号化を使用していることを確認し、制御コマンドや機微データのやり取りにリプレイ攻撃対策（ノンスや有効期限付きトークンなど）があるかを検証します。SUMアップデート経路の安全性を評価し、機器が更新可能であること、ファームウェアのインストールのたびにデジタル署名や鍵で配布元と完全性を検証していることを確認します。SSM / CCK鍵、トークン、機微な設定値を機器内（Flash／EEPROM）に保存する際の保護策を評価します。GEC提出試料で未使用のネットワークインターフェースやサービスが無効化され、攻撃対象領域が縮小されていることを確認します。その他のメカニズム（RLM、CRY、LGM、DLM、UNM など）は、製品への適用性に応じて評価します。
試験報告書に基づき、製造業者の開発チームが脆弱性を修正し、基盤となるセキュリティ設計（認証ロジック、鍵の保管方法、アーキテクチャのパラメーターなど）もあわせて見直します。その後、問題の解消が確認できるまで SV Surveillance が再試験を行います。
SV Surveillance の台北試験所が ISO/IEC 17025 に基づいて試験報告書を発行します。ノーティファイドボディによる評価が必要な製品は Applus+ Laboratories（NB 0370）での評価に引き継ぐことができ、試験報告書は審査の参考資料として活用できます。
上市後も試験報告書とセキュリティ関連の技術文書を保管しておく必要があります。EU の市場監視当局は、EU 域内の認定代理人を通じて期限を定めて提出を求めることができます。
試験範囲（機器のみが最短。アプリやサーバーを含めると期間が延びます）、有効な無線インターフェースの数、開発記録の充実度、そして修正と再試験の往復回数です。
Before You Start
次の 3 つのよくある不備を早めに確認しておくと、修正と再試験の時間とコストを抑えられます。
ソフトウェアやファームウェアを外部に委託していても、セキュア開発ライフサイクル（SDLC）の記録を誰も保持しておらず、開発プロセスのレビューを完了できません。
機器は更新できるものの、インストール前に鍵や署名で更新ファイルの真正性を確認する仕組みがありません。
Bluetooth 標準の暗号化（有効になっていないことが多い）に頼りきりで、生体データや個人データが平文で送信され、通信中の個人データ保護に関する規格要求を満たしていません。
クリックすると、チェック結果が下のフォームに自動入力されます。
FAQ
できます。規格を完全に適用し、制限事項に該当しない製品は、製造業者が自ら適合を宣言できます。ただし、当局の求めに応じて提出できるよう技術文書を準備しておく必要があります。パスワードを設定しない利用を許可する製品、保護者によるアクセス制御のない子ども向け製品、または EN 18031-3 が適用される製品は、該当部分についてノーティファイドボディによる評価が必要です。
法令上の義務ではありません。自己宣言する製品は、製造業者が自らの責任で技術文書を準備します。第三者試験所の試験報告書は技術文書の客観的な裏付けとなり、市場監視による抜き取り検査や当局からの提出要求の際に、製品の適合性を説明するのに役立ちます。
できません。機器を操作するだけのアプリはそれ自体で独立した機能を持たないため、機器と一緒に試験します。
規格が求めているのは OTA そのものではなく、ファームウェアを更新でき、かつインストール前に毎回検証されることです。検証のない更新方法は不適合となります。実際に更新する可能性のない使い切りの製品は、更新機能を設けない理由を示し、試験所が個別に評価します。
既知の脆弱性を含むコンポーネントは、上市前に更新または交換する必要があります。評価の結果、その脆弱性が製品内で悪用できないと判断できる場合は説明を提出し、試験所が再試験で確認します。
MDR／IVDR の対象となる医療機器は RED のサイバーセキュリティ要件の対象外であり、法令上の義務はありません。ただし EN 18031 の試験結果は、MDR や FDA 向けのサイバーセキュリティ文書の裏付け資料として活用できます。医療機器のサイバーセキュリティについて →
CRA は、デジタル要素を持つ製品を対象とする EU の新しいサイバーセキュリティ規則で、その技術規格の一部は EN 18031 シリーズを参考に策定が進められています。現時点で EN 18031 試験により蓄積した技術文書と試験エビデンスは、今後の CRA 対応の基盤となります。EU CRA について →