1.はじめに
前稿では、「電気用品、ガス用品等製品のIoT化等による安全確保の在り方に関するガイドライン」（以後、「ガイドライン」）を実践する上での重要な柱の１つである「予防安全機能」の詳細について解説した。
また、もう１つの柱である「遠隔操作者／使用者の能動的な行動を促す情報提供」を予防安全機能により実現するための考え方についても説明を行った。
本稿ではまず最初に、ガイドラインを実践する上でのもう１つの重要な柱である「安全機能と通信回線との分離」およびこれを下支えする基盤としての「機器の安全機能を構成するソフトウェアと公衆ネットワークとの通信を可能にするソフトウェアとの分割」について解説する。
ここで最初に読者の皆様に注意喚起しておきたいのは、「安全機能と通信回線との分離」は異常発生時の緊急措置であって、セキュリティ対策としてのファイアウォールのような通常時の境界防御措置とは異なるということである（図１参照）。
筆者はこのような誤解はまだかなり残っていて、ガイドラインの普及啓発を進めるにあたりこれを解いていく必要があると考えているため、本稿でも冒頭で指摘した。
なお、遠隔操作等に異常が発生した時の緊急措置のもう１つの柱は、「遠隔操作者／使用者の能動的な行動を促すための情報提供（警告等）」である（図1参照）。こちらもガイドラインを実践する上で非常に重要な意味を持っていることを指摘しておく。
図１ 遠隔操作・ソフトウェアアップデートの安全を守るための対策の構造
次に本稿では、図1の構造を前提として、ガイドラインが求める遠隔操作およびソフトウェアアップデートの安全・セキュリティ要求をどのように実現するかについて解説したい。ガイドラインの要求事項の理解を深めていただくため、通常時の要求と異常発生時の要求を明確に書き分けて解説を加えていく。
2.安全機能の通信回線との分離とソフトウェアの分割とは？
(1) ソフトウェアの分割に対する要求
ソフトウェアの分割とは、機能や要求水準を踏まえてソフトウェアをモジュールに分け、各モジュールの要求に則した信頼性の高いソフトウェアを実装することである。
各モジュールのソフトウェアは独立して動作・管理されるため、どれかのモジュールに生じた異常を他のモジュールの動作から切り離すことが可能になる。これによって、ソフトウェア全体としての動作がより一層安定してくる。
安全機能に関わる遠隔操作／ソフトウェアアップデートを行う電気用品／ガス用品等製品のソフトウェアがガイドラインを満たすためには、概ね図2のようなモジュール化（ソフトウェア分割）が必要となってくる（図2のエンジ色／薄緑色の四角の部分参照）。
このガイドラインの求めは、IEC 60335-1:2020の要求に基づいている。エンジ色の四角がIEC 60335-1:2020附属書Uが適用される範囲であり、まずは適用範囲外である薄緑色の四角との間でモジュールを分割することが必要である。
図２ 遠隔操作・ソフトウェアアップデートの安全を守るためのソフトウェア構造（分割構造）
附属書Uの適用範囲内では、まず「機器の安全機能を構成するソフトウェア」は、IEC 60335-1:2020 22.62の求めに応じてモジュール化する必要がある。
22.62 公共ネットワークを介した遠隔通信は、この規格への準拠を損なうものであってはならない。この要求は以下にのみ適用される。
(a) 以下のソフトウェアのダウンロードまたはデータの伝送を含む遠隔通信：
・22.46 に準拠するために必要な附属書 R（必ず守る必要がある） に従った措置（機能安全）
・本規格の第8～32節に準拠するために必要な手段
(b) ソフトウェアのダウンロード又はデータの送信を含む遠隔通信であって、上記のケースa)でカバーされないソフトウェアの部分にのみ影響を与えるものであって、上記のケースa)におけるソフトウェア又はデータとの不適切な分離又は分割によって本規格の遵守が損なわれる可能性があるもの。
・・・
適否は、製品の検査、技術文書の検査、および規範となる付属書Uの要求事項に従って、試験によって判定する。
次に「公衆ネットワークとの通信を、安全を確保したまま仲介するソフトウェア」は、附属書UのU.3.1の求めによって「機器の安全機能を構成するソフトウェア」と別モジュールとする必要がある。また、このソフトウェアが提供すべき機能はU3.2（遠隔操作の場合）およびU3.8（ソフトウェアアップデートの場合）で規定されている。
U.3.2 遠隔通信は機器により、以下を提供するソフトウェアを介して確立、実装、終了されなければならない。
- 以下に関連したデータ完全性保護
・データ破損 ・破損への対処 ・間違ったタイミングまたは順序 ・永続的な”自動送信”または繰り返し ・データ伝送の中断
- どんな理由であれ、不完全な、途中で切り捨てられた、エラーを含んだ、または正しい書式ではあってもそのタイプのメッセージに期待される範囲外の情報を伝達する通信を検知し、これに対応する手段
・・・
U.3.8 製造者によって提供され、遠隔通信を介して機器に送信されるソフトウェアアップデートは、インストール前に必ず以下について検証されることを確実にしなければならない：
- 通信中のデータ破損がないこと
・・・
最後に「インストール前に、ソフトウェアのバージョン・互換性をチェックするソフトウェア」も、「公衆ネットワークとの通信を、安全を確保したまま仲介するソフトウェア」との類似性から判断して、「機器の安全機能を構成するソフトウェア」とは別モジュールとすべきである。
当該ソフトウェアが提供すべき機能についてはU.3.8で規定されている。
U.3.8 製造者によって提供され、遠隔通信を介して機器に送信されるソフトウェアアップデートは、インストール前に必ず以下について検証されることを確実にしなければならない：
- 通信中のデータ破損がないこと
・・・
- ソフトウェアの版が、その版を設計した対象である機器と適合していること
・・・
(2) 安全機能の通信回線との分離
「安全機能と通信回線の分離」の要求を実現するために、具体的には何をすれば良いのかという問いを良く耳にしている。筆者は実際には、技術的観点から業界との対話に基づくコンセンサスを形成していく必要があると考えている。
しかし、それでは概念的な理解が進まないので、ここでは元々ベースとなっている国際標準規格の要求に基づき、 「安全機能と通信回線の分離」を実現するための基本的な考え方について解説していく。なお、(1)で述べたソフトウェアの分割は「安全機能と通信回線の分離」を実現する上での前提条件と考えていただくと分かりやすい。
IEC 60335-1:2020の観点からは、安全機能を通信回線と分離する上での重要な要求は次の2点に集約される。
(a) 故障／エラーを制御するための手段
(b) 公衆ネットワークとの遠隔通信に依存しない安全制御
この要求を満たす方法は色々あるものと考えるが、典型的には、使用者に危害を及ぼしうる機器の異常が発生した場合に、プログラマブル保護電子回路のソフトウェアを公衆ネットワークとの遠隔通信から切り離し、故障／エラーを制御するための手段をローカルで起動して、機器を安全に停止させることができれば良いと言うように解釈している。
なお、以下は筆者の私的な解釈ではあるが、異常発生時に公衆ネットワークと切り離しておく方が、プログラマブル保護電子回路のソフトウェアをより確実に動作させられると言えそうである。
従って、異常発生時の公衆ネットワークとの切り離しは、「安全機能と通信回線の分離」の実現においては、基本と解釈しても良いのではないかと思量している。
図３ 安全機能を通信回線と分離する上での重要な２要求の典型的な実現例（概念図）
(a)(b)のそれぞれの要求の根拠となるIEC 60335-1:2020の規定について以下に示す。
(a)の根拠：
22.62 公共ネットワークを介した遠隔通信は、この規格への準拠を損なうものであってはならない。この要求は以下にのみ適用される。
(a) 以下のソフトウェアのダウンロードまたはデータの伝送を含む遠隔通信：
・22.46 に準拠するために必要な、規範となる附属書 R に従った措置（機能安全）
・・・
適否は、製品の検査、技術文書の検査、および規範となる付属書Uの要求事項に従って、試験によって判定する。
22.46 この規格に適合することを確実にするために，プログラマブル保護電子回路を用いる場合，ソフトウェアは，表R.1に規定する故障／エラー状態を制御するための手段を含まなければならない。
必要な場合，表R.2に規定する故障／エラー状態を制御するための手段を含むソフトウェアを，特定の構造又は特定の危険への対処のために第2部の個別規格に規定する。
これらの要求事項は，機能目的又は箇条11に適合するために用いるソフトウェアには適用しない。適否は，附属書Rの関連する要求事項に従って，ソフトウェアの評価によって判定する。
U.3.2 遠隔通信は機器により、以下を提供するソフトウェアを介して確立、実装、終了されなければならない。
・・・
- 表R.1で指定された故障／エラー条件を制御する手段
適否は、R3.2.2のソフトウェアアーキテクチャの検査／試験、及びR.3.3に従ったソフト評価によって判定する。
U.3.8 製造者によって提供され、遠隔通信を介して機器に送信されるソフトウェアアップデートは、インストール前に必ず以下について検証されることを確実にしなければならない：
・・・
さらに、上記のチェックを実行するソフトウェアは、表R.1で指定した故障／エラー条件を制御するための手段を具備していなければならない。
適否は、規範となる附属書Rの関係する要求事項に従って、ソフトウェアと製造メーカーのバージョン管理文書の評価によって判定する。
(b)の根拠：
U.3.6 機器の安全制御は、遠隔通信に依存してはならない。
ここで、使用者に危害を及ぼしうる機器の異常が発生した場合、「プログラマブル保護電子回路のソフトウェア」を公衆ネットワークとの遠隔通信から切り離すことは基本的には「公衆ネットワークとの通信を、安全を確保したまま仲介するソフトウェア」の役割であると想定できる。
しかし、遠隔操作時のリスク増大が課題となるケースなどでは、「ソフトウェアによる自動的な切り離し」の信頼性を十分であるとは考えず、「プログラマブル保護電子回路のソフトウェア」を公衆ネットワークと、常時物理的に隔離する設計を選択する場合もあるだろう。
あるいは、「プログラマブル保護電子回路のソフトウェア」からは常に外向きにしか通信できず、公衆ネットワークからの遠隔通信には影響を受けないように設計することも考えられる。
このように、実際の設計は事業リスクを踏まえて選択するものであって、唯一の正解が存在する訳ではない。むしろ、こうした設計ノウハウが業界で蓄積されて成熟度が高まり、社会全般でブレがなく広く適用されることの方が大きな意味を持っているものと筆者は考えている。
一方、「故障／エラーを制御するための手段をローカルに起動して、機器を安全に停止させる」という部分は、IEC 60335-1 附属書Rが求める機能安全（プログラマブル保護電子回路上でソフトウェアを稼働させるケース）の要求事項であると言える。
このようにガイドラインにおいては、「安全機能と通信回線の分離」を通じて機能安全（プログラマブル保護電子回路上でソフトウェアを稼働させるケース）を否定しようとしている訳ではない。
遠隔操作による間接被害や機器の近くにいる使用者への危害の発生まで考慮すると、遠隔操作のリスクがスタンドアローンと比較してそれなりに高くなるケースが多いので、機能安全の適用においては、公衆ネットワークは不確実なものという前提でしっかりと安全設計していく姿勢が必要であるというメッセージを発しているものと考えている。
そして、これが難しいのであれば、ヒューズなどの物理的な保護手段を最終的な安全確保として組み込む設計を基本とすべきとしている。
(3) 予防安全機能の通信回線との分離についての考察
予防安全機能についても、安全を向上させるための機能であるため、通信回線と分離する方が良いのではないかという議論が存在している。しかし実際には、例えば今後クラウド上に実装されたAI基盤などを活用して、予防安全機能の効果を持続的に高めるといったような技術的に高度な実装が顕在化するのではないかと予想している。
このような推定から、予防安全機能の通信回線との分離は製造メーカーの活力を削ぐことにも繋がりかねないため、必ずしも望ましいとは言えず、その可否についてはケースバイケースであろうと考えている。
このため、令和2年度の「電気用品等製品のIoT化等による安全確保の在り方に関する調査報告書」では、予防安全機能の通信回線との分離は推奨していない。
実際には、15ページの中段以下において、次の条件に当てはまるケースに限って、「予防安全機能のソフトウェア」と「機器と公衆ネットワークとの通信を制御するソフトウェア」のモジュール分割を推奨している。
- 通常機能を兼ねる予防安全機能、通常機能を兼ねる追加の予防安全機能、又は予防安全機能（狭義）に該当すること
- 機能停止時の残留リスクが大きいこと
3.ガイドラインにおける不正アクセス対策につ3.
電気用品／ガス用品等製品の安全を確保する上で、情報セキュリティについてどこまで考慮する必要があるかは重要な論点である。IEC TC61はIEC 60335-1:2020を公表するにあたり、ISO/IEC JTC1と協議の上、この論点について合意を形成し、一定の方向性を提示している。具体的には、以下に示す情報セキュリティ7要素のうち、製品安全に関わるのは「２．完全性」「４．真正性」のみであるという原則であり、IEC 60335-1:2020附属書Uはこの原則に従って記述されている。
＜情報セキュリティ7要素＞
1. 機密性
2. 完全性
3. 可用性
4. 真正性
5. 信頼性
6. 責任追跡性
7. 否認防止
またIEC TC61は、今後ISO/IEC JTC1のSC27（セキュリティ技術）とSC41（モノのインターネットと関連技術）の検討成果を監視し、必要に応じてIEC 60335-1:2020附属書Uへの反映を継続的に行っていくこととしている。
ガイドラインが求める安全機能等の遠隔操作及びソフトウェアアップデートに関する不正アクセス対策は、基本的にはIEC 60335-1:2020附属書Uをベースとしている。一方で、ソフトウェアアップデートの不正アクセス対策については、一部ETSI EN 303 645の規定を参考にしている。以下では、ガイドラインが求める「遠隔操作時とソフトウェアアップデート時の不正アクセス対策」の構成と内容について詳しく解説する。
それぞれの対策の構成は、図1で示したフレームワークのとおり大きくは「通常時」と「異常発生への対応時」に分類され、さらにそれぞれは「実行手段」と「遠隔操作者／使用者の能動的な行動を促すための情報提供」に細分される。
(1) 安全機能等の遠隔操作時の不正アクセス対策 －誤使用等への対策
通常時の対策としては、まず情報セキュリティ対策としての誤使用／なりすまし使用防止（真正性確保）及び遠隔操作コマンド等の改ざん防止（完全性確保）がある。遠隔操作者／使用者の能動的な行動を促すための情報提供としては、ガイドラインは、遠隔監視できなくなった時に遠隔操作において注意すべき点（例：機器が自動停止することへの注意喚起など）を情報提供するように求めている。
一方、異常発生への対応時の対策としては、ガイドラインは２．で述べた安全機能と通信回線との分離に加えて、機器の近くにいる使用者による容易な手動での通信回線の切り離し／手元操作を優先する仕組みの徹底を求めている。
さらに遠隔操作者／使用者の能動的な行動を促すための情報提供としては、ガイドラインは不正アクセス時などに、遠隔操作者および使用者に警告する手段を確保するように求めている。
ガイドラインが求める、安全機能等の遠隔操作時の不正アクセス対策について、全体像を表１にまとめた。
表１ 遠隔操作時の不正アクセス対策
分類 | 対策種別 | 不正アクセス対策 |
|---|---|---|
通常時の対策 | 情報セキュリティ対策 | ・真正性の確保（誤使用のうちの、なりすまし使用の防止） 暗号技術を適用したアクセス権限管理と認証 ・完全性の確保 暗号技術を適用した遠隔操作コマンドやデータの改ざん防止 遠隔通信における伝送故障／エラー検知 等 |
遠隔操作者／使用者の能動的な行動を促すための情報提供 | ・遠隔監視できなくなった時に、遠隔操作において注意すべき点について、遠隔操作者に情報提供の上周知（例：機器が自動停止することへの注意喚起など） | |
異常発生時の対応に関する対策 | 情報セキュリティ対策 | ・安全機能と通信回線との分離 ・ソフトウェアが持つ、故障／エラー条件を制御する手段の発揮 ・機器の近くにいる使用者による手元操作の優先、手動での通信回線の切り離し |
遠隔操作者／使用者の能動的な行動を促すための情報提供 | ・不正アクセスを含め、通信故障時に遠隔操作者及び使用者に警告する手段の確保（例：遠隔操作の中止を促すなど） |
次に、これらの対策要求の根拠となっているIEC 60335-1:2020附属書Uの規定について以下に示す。なお、「安全機能と通信回線との分離」「ソフトウェアが持つ、故障／エラー条件を制御する手段の発揮」については２．(2)を参照されたい。
U.3.2 遠隔通信は機器により、以下を提供するソフトウェアを介して確立、実装、終了されなければならない。
- 以下に関連したデータ完全性保護
・データ破損 ・破損への対処 ・間違ったタイミングまたは順序 ・永続的な”自動送信”または繰り返し ・データ伝送の中断
- どんな理由であれ、不完全な、途中で切り捨てられた、エラーを含んだ、または正しい書式ではあってもそのタイプのメッセージに期待される範囲外の情報を伝達する通信を検知し、これに対応する手段 ・・・
U.3.4 アクセス権限承認の前に遠隔通信を有効にしてはならない。権限承認は認証に基づかなければならない。通信する両者のIDを保証するために、認証プロセスは暗号技術を用いなければならない。
U.3.5 不正アクセスを防止し、遠隔通信における伝送故障／エラーを検知するための措置を講じなければならない。
U.3.7 遠隔通信の権限がひとたび承認されたら、データ完全性を保護するために暗号技術が実装されなければならない。
・・・
(2) 安全機能等のソフトウェアアップデート時の不正アクセス対策
通常時の対策としては、まず遠隔操作の場合と同じように、製造メーカーになりすました不正なアップデートの提供からの防御等（真正性確保）及びダウンロードソフトウェアの改ざん防止（完全性確保）が求められている。
またガイドラインでは必ずしも目的を限定していないが、基本的には脆弱性の解消を目的として、セキュリティ要件を満たした安全なソフトウェアアップデートの開発を求めている。
さらに、機能安全のソフトウェア*のアップデートについては、アップデートを公開する前に試験を行い、機器の機能安全に影響がないことを確認する必要がある。
*ガイドラインでは明記されていないものの、「インストール前にソフトウェアのバージョン／互換性をチェックするソフトウェア」「公衆ネットワークとの通信を、安全を確保したまま仲介するソフトウェア」等のIEC 60335-1:2020附属書Uへの適合が求められるソフトウェアについては、機能安全のソフトウェアと同じように、アップデート時に試験を実施し、機器の安全確保に影響がないことを事前に確認しておく必要がある。
通常時の「遠隔操作者／使用者の能動的な行動を促すための情報提供」としては、ガイドラインは、使用者に正しいインストール手順の実行を促すための、「従わなければならない手順」情報を提供するように求めている。
さらに、脆弱性対策としての「ソフトウェアアップデートの提供条件、提供方法、向上するセキュリティ性能等」についての情報提供も求められているが、この要求についてはガイドラインがソフトウェアアップデートを求める対象範囲に関する解釈が必要である。
ソフトウェアアップデートができないものは、デバイスの交換時期について情報提供し、使用者によるデバイス交換を促すことを要求していることからも、この対象範囲の解釈は重要な意味を持っていることが分かる。
ガイドラインでは、この対象範囲を「公衆ネットワークへの接続を構成するデバイス」に限定している。当該デバイスは「機器と公衆ネットワークとの通信を制御するソフトウェア」を含むことは疑念のないところである。他方で、機器の安全機能等と「公衆ネットワークとの通信を、安全を確保したままで仲介するソフトウェア」まで含んでいるのかについては、筆者はステークホルダー間で対話と意識合わせを行うことが必要であると考えている（図２参照）。
一方、異常発生への対応時の対策としては、ガイドラインは遠隔操作時と同じように、安全機能と通信回線との分離に加えて、機器の近くにいる使用者による容易な手動での通信回線の切り離し／手元操作を優先する仕組みの徹底を求めている。
さらに遠隔操作者／使用者の能動的な行動を促すための情報提供としては、ガイドラインはアップデート中に機器の運転が停止した場合、遠隔操作者および使用者にその旨を通知する手段を確保するように求めている。
ガイドラインが求める、安全機能等のソフトウェアアップデート時の不正アクセス対策について、全体像を表２にまとめた。
表２ ソフトウェアアップデート時の不正アクセス対策
分類 | 対策種別 | 不正アクセス対策 |
|---|---|---|
通常時の対策 | 情報セキュリティ対策 | ・真正性の確保（なりすましの防止：製造メーカーになりすました不正なアップデートの提供からの防御など） 暗号技術を適用した認証とアクセス権限管理 ・完全性の確保 暗号技術を適用したダウンロードソフトウェアの改ざん防止 遠隔通信における伝送故障／エラー検知 等 ・セキュリティ要件を満たした安全なソフトウェアアップデートの開発（脆弱性対策と解釈してよいと考える） ・ソフトウェアアップデートを公開する前に試験を行い、機器の機能安全に影響がないことを確認 |
遠隔操作者／使用者の能動的な行動を促すための情報提供 | ・使用者に正しいインストール手順の実行を促すための、「従わなければならない手順」に係る情報提供・周知 ・脆弱性対策としてのソフトウェアアップデートの提供条件、提供方法、向上するセキュリティ性能等についての情報提供 - 使用者にソフトウェアアップデートの実行を促す - 特に、公衆ネットワークへの接続を構成するデバイスについては、アップデートを要求。アップデートできないものは、デバイスの交換時期を示し、使用者によるデバイス交換を促す | |
異常発生時の対応に関する対策 | 情報セキュリティ対策 | ・安全機能と通信回線との分離 ・ソフトウェアが持つ、故障／エラー条件を制御する手段の発揮 ・遠隔操作者や使用者による手元操作の優先、手動での通信回線の切り離し |
遠隔操作者／使用者の能動的な行動を促すための情報提供 | ・アップデート中に機器の運転が停止した場合、遠隔操作者及び使用者にその旨を通知する手段を確保 | |
次にこれらの対策要求の根拠となっているIEC 60335-1:2020附属書U及びETSI EN 303 645の規定について以下に示す（特に明記されていないものはIEC 60335-1:2020の規定）。なお、表1と重複している項目については、３．(1)を参照されたい。
22.46 この規格に適合することを確実にするために，・・・
ソフトウェアを変更したとき，その変更が保護電子回路に関わる試験の結果に影響を及ぼす場合，評価及び関連試験を繰り返す。・・・
U.2.1 ソフトウェアのダウンロードを提供する場合には、・・・また、指示書には、ソフトウェアのアップデート手続きにおいて従わなければならない手順を記載しなければならない。
ETSI EN 303 645
5.3-11 メーカーは、セキュリティアップデートが必要であることを、そのアップデートによって緩和されるリスクに関する情報とともに、認識可能かつ明白な方法でユーザに通知しなければならない。・・・
ETSI EN 303 645
5.3-12 ソフトウェアアップデートの適用により、デバイスの基本的な機能が中断される場合、デバイスはユーザに通知しなければならない。この通知には、デバイスがオフラインになると予想されるおおよその期間など、追加の詳細を含めることができる。
・アップデート中にデバイスが動作を継続することは、ユーザにとって非常に重要である場合がある。このため、上記の規定では、アップデートによって機能が中断される場合には、可能な限りユーザに通知することを推奨している。
・特に、安全関連の機能を果たすデバイスは、アップデートの場合に完全に電源が切れることはないと予想される。機能の中断は、正しく考慮または管理されていない場合、デバイスやシステムの種類によっては、重大な安全上の問題となる可能性がある。
ETSI EN 303 645
5.3-14 ソフトウェアのアップデートを受けることができない制約のあるデバイスについては、ソフトウェアのアップデートが行われない理由、ハードウェアの交換サポートの期間と方法、および定義されたサポート期間が、ユーザにとって明確かつ透明性のある方法で、製造業者によって公表されなければならない。
ETSI EN 303 645
5.3-15 ソフトウェアをアップデートすることができない制約のあるデバイスについては、その製品は分離可能であり、 ハードウェアは交換可能でなければならない。
ETSI EN 303 645
5.6.9 メーカーは、デバイス上に配置されるソフトウェアの安全な開発プロセスに従わなければならない。
・・・
4.ガイドラインにおけるソフトウェアアップデート時の安全要求
ガイドラインでは、ソフトウェアアップデートについて不正アクセス対策以外の要求事項を設けている。これらの要求事項はソフトウェアのアップデートを実行する各ステップに対して設定されている（図４参照）。
具体的には、ガイドラインはまず適正なバージョンのアップデートソフトウェアをダウンロードし、データ破損や対象機器との適合性を確認し、使用者の許諾を得てインストールを開始し、インストール中も安全要求への適合を維持し、インストール中に機器が異常停止した場合は使用者等に適切な情報を提供して警告し、インストールが終了した後も安全要求への適合を確保することを求めている。
図４ ソフトウェアアップデートの各ステップにおける安全要求
次にこれらの安全要求の根拠となっているIEC 60335-1:2020附属書U及びETSI EN 303 645の規定について以下に示す（特に明記されていないものはIEC 60335-1:2020の規定）。
U.2.1 ソフトウェアのダウンロードを提供する場合には、機器内で実行されているソフトウェアの現バージョンを識別するための、製造者によって与えられた固有の名称またはコードを取得する方法または場所についての指示が提供されなければならない。
・・・
U.3.8 製造者によって提供され、遠隔通信を介して機器に送信されるソフトウェアアップデートは、インストール前に必ず以下について検証されることを確実にしなければならない：
- 通信中のデータ破損がないこと
- ソフトウェアの版が、その版を設計した対象である機器と適合していること
・・・
U.3.9 ソフトウェアの機器への各インストールは、機器に責任を持つ人物の許可を得なければならない。使用者が、自動的なソフトウェアアップデートを可能にするモードを起動することは、許容される。
U.3.10 ソフトウェアのインストールが、そのインストール中またはインストール後に、この規格の要求遵守を無効にしてはならない。
ETSI EN 303 645
5.3-12 ソフトウェアアップデートの適用により、デバイスの基本的な機能が中断される場合、デバイスはユーザに通知しなければならない。
この通知には、デバイスがオフラインになると予想されるおおよその期間など、追加の詳細を含めることができる。
5.第５稿で解説する予定のテーマについて
次回の第5稿（最終稿）では、「遠隔操作に不向きな機器」への分類の考え方と、現在の分類状況について解説する予定である。製品戦略などに直接影響を及ぼす内容であるため、製造メーカーなどの関心が高く、ガイドラインとともに広く普及啓発すべき主題であると言える。
一方で、次のような課題も指摘されており、ステークホルダーとの対話等による解決が期待されていると言えよう。
- 一部の分類基準に対する具体的な解釈の提示・啓発
- 一部機器（バッテリーチャージャーなど）の分類についての業界団体との協議（業界団体と未協議のものなど）
- 調理家電などにおける、公衆ネットワークを利用したデータ（食材ストック、レシピ等）の監視／ダウンロードなど（機器の操作自体は手元で行うケース）の解釈 等