医療機器開発サイバーセキュリティ通知|
SaMD開発の薬事品質向け
日本国内の医療機器開発におけるサイバーセキュリティに関する通知 について、令和5年〜令和8年3月までのものをまとめました。
1. 通知まとめ
本資料が対象とする通知・事務連絡は以下です。
| テーマ | 発出日 | 通知名 |
|---|---|---|
| A. 基本要件基準第12条第3項 | 2023.3.31 | 第12条第3項の適用について(薬生機審発0331第8号) |
| A. 基本要件基準第12条第3項 | 2023.5.23 | 第12条第3項の適合性の確認について(薬生機審発0523第1号) |
| A. 基本要件基準第12条第3項 |
2023.7.20
|
第12条第3項適用に関するQ&A(第1弾・事務連絡) |
| A. 基本要件基準第12条第3項 | 2024.1.31 | 医療機器サイバーセキュリティに関するQ&A(第2弾・拡充版・事務連絡) |
| B. サイバーセキュリティ導入手引書 | 2023.3.31 | 「サイバーセキュリティ導入に関する手引書(第2版)」改訂(薬生機審発0331第11号/薬生安発0331第4号) |
| C. 市販後安全管理・脆弱性管理 | 2024.1.15 | サイバーセキュリティ関連不具合等報告の基本的考え方(医薬安発0115第2号) |
| C. 市販後安全管理・脆弱性管理 | 2024.3.28 | サイバーセキュリティを確保するための脆弱性の管理等について(医薬機審発0328第1号) |
| C. 市販後安全管理・脆弱性管理 | 2025.4.17 | サイバーセキュリティ対策関連情報提供(R6.3.31以前製造販売品)(医薬機審発0417第1号) |
| D. 手続き・注意喚起 | 2024.4.23 | サイバーセキュリティ対策関連の軽微変更手続き等の取扱い(医薬機審発0423第1号) |
| D. 手続き・注意喚起 | 2024.10.7 | サイバーセキュリティの確保等のために必要な取組の研究協力(アンケート)(事務連絡) |
| D. 手続き・注意喚起 | 2026.3.19 | VPN装置等のネットワーク機器におけるサイバーセキュリティ対策の徹底(注意喚起)(事務連絡) |
2. 関連通知の要求事項・詳細
A. 基本要件基準第12条第3項
① 新設条項の趣旨
- IMDRF N47・N60文書を踏まえ、プログラムを用いた医療機器に対しサイバーセキュリティを確保するための設計・製造・ライフサイクル活動の要求を基本要件基準第12条に第3項として追加(令和5年4月1日適用開始、1年間の経過措置)。
- 3つの観点:①全ライフサイクルにわたるサイバーセキュリティ計画、②サイバーリスクを低減する設計・製造、③適切な動作環境に必要なHW/NW/ITセキュリティ対策の最低限要件設定。
② 適用対象
- 「他の機器及びネットワーク等と接続して使用する医療機器」:IoT機器、周辺機器、外部記録媒体(USB/SD等)、電子カルテ、院内/院外/グローバルネットワーク等と電磁的情報のやり取りをする医療機器。
- 「外部からの不正アクセス及び攻撃アクセス等が想定される医療機器」:DoS/DDoS攻撃、マルウェア感染を意図する攻撃等が想定されるもの。
③ 適合性確認の要点
- JIS T 81001-5-1(またはIEC 81001-5-1等の国際的に用いられる適切な規格)への適合確認をもって、基本要件基準第12条第3項への適合とみなす。
- 高度管理・管理医療機器の承認/認証申請時には、適合性を示す資料の添付が必要。一般医療機器は届出時の資料添付は不要だが適合確認は必須。
- 製造販売業者等は、確認・検証を適切に記録し保管すること。調査権者の求めに応じて提示できること。
④ 経過措置
- 令和6年3月31日以前に承認/認証/届出済みの医療機器は、改めての申請・届出は不要。
- 令和6年4月1日以降に一部変更承認申請等が必要な場合は、改正後の基本要件基準への適合確認・資料添付が必要。
- 令和6年4月1日以降に製造販売する医療機器は、適合確認を行い、求めに応じて資料を提示できるようにしておくこと。
① 箇条4(一般要求事項)の確認事項
- サイバーセキュリティの確保に係る活動は、品質マネジメントシステム(QMS)に基づいて行われていること。
- 規制当局及び顧客に対して脆弱性を適時に通知する活動を確立すること。
- 医療機器のリスクマネジメントは、セキュリティの脆弱性・脅威等を考慮したものであること。
- QMSにおいて、セキュリティに対する対応方針、問い合わせ窓口を明確化し、顧客に対する脆弱性等の開示手順が定められていること(既存通知要求事項)。
② 箇条5(ソフトウェア開発プロセス)の確認事項
- 開発計画において、セキュリティ更新や開発環境等のセキュリティについて考慮すること。
- 製品のセキュリティ機能を含むセキュリティ要求事項を特定すること。
- 意図する使用環境、信頼境界、多層防御等を考慮してアーキテクチャー設計を行うこと。
- セキュリティ設計のベストプラクティスを考慮した設計及び実装を行うこと。
- ソフトウェアシステム試験を行って、セキュリティ要求事項が満たされ、リスクマネジメントプロセスで特定した脅威に対応する方法が実装・有効であることを確認すること。
- 意図する使用環境をシステム構成図やネットワーク構成図等を用いて明示すること(既存通知要求事項)。
③ 箇条6(保守プロセス)の確認事項
- 顧客に対するセキュリティ更新の通知方針について定めておくこと。
- ソフトウェア保守計画において、サポート終了(EOS)等の製品寿命に対して計画し、脆弱性の監視・セキュリティ更新等の将来的な脆弱性対策の実施計画をあらかじめ定めておくこと(既存通知要求事項)。
④ 箇条7(リスクマネジメント)の確認事項
- 意図する使用及び使用環境を考慮して、関連する脆弱性を特定し、脅威を推定・評価し、リスクコントロール手段によって脅威をコントロールし、その有効性を監視すること。
⑤ 箇条8(構成管理)・箇条9(問題解決)の確認事項
- 変更管理及び変更履歴を伴う構成管理プロセスを確立すること。構成管理プロセスは、当該医療機器のSBOM(ソフトウェア部品表)を適切に作成すること(既存通知要求事項)。
- セキュリティの脆弱性に関する情報伝達及び処理の手順を定め、情報開示を含めて手順に従って実施すること。
- 【申請書記載方法】承認(認証)申請書添付資料4項の「電気安全・電磁両立(ソフトウェアライフサイクルの後ろ)」に、各要件に対応する社内文書番号等を記載する。
主要Q&A
- Q1(適合性確認通知の位置づけ):適合性確認通知は、JIS T 81001-5-1等への適合性を示す資料をより具体化したもの。「セキュリティに対する窓口の明確化」「顧客に対する脆弱性等の開示手順」もJIS外の要求事項として含まれる。
- Q2(申請書への記載方法):各要件に対して社内文書番号等を特定する情報を示すことで可。承認申請書添付資料4項に記載する。令和6年4月1日以降も製造販売する既存品も同様の社内文書を特定できるようにしておくこと。
- Q3(既存品・JIS T 81001-5-1附属書F適用):JIS T 81001-5-1未適用の既存品には附属書F(トランジションヘルスソフトウェア)の適用が可能。「セキュリティ運用ガイドラインを更新する」「補完的コントロールを義務付ける」「一部を書き直す」等の対策も可。リスク評価の結果、受容できないリスクがないことを確認すること。
- Q4(セキュリティ問い合わせ窓口):セキュリティポリシー、取扱説明書、注意事項等情報等に、緊急で対応できる窓口(連絡先)を記載することが望ましい。
- Q5(SBOM の申請時提出):申請時の提出は不要だが、SBOMを作成していることを明示(文書名等)が必要。申請の際はSBOMを提示できるように準備しておくこと。
- Q6(SBOM の構成要素):最低限、製品の最上位のコンポーネント及びそれに直接含まれるコンポーネントを含む。各コンポーネントについて①サプライヤ名、②コンポーネント名、③バージョン、④固有識別子、⑤上流との関係、⑥作成者名、⑦タイムスタンプを明示すること。
- Q7(セキュリティ試験の第三者機関要件):脅威に対する方法が実装・有効であることが確認できれば第三者試験は必須ではない。
主要Q&A(第2弾で新たに追加・明確化された事項)
- Q1(保守のみ接続する機器・クラウド型プログラム):保守/修理作業においてのみ接続される医療機器も基本要件基準第12条第3項の適用対象。クラウドにアクセスして用いる医療機器プログラムも同様にサイバーセキュリティ対応が必要。リスク分析の際はシステム構成図・ネットワーク構成図を作成し、合理的に予見可能な誤使用を踏まえた脅威分析を行うこと。
- Q2(経過措置期間中の申請):経過措置期間中に申請を行い、承認取得が経過措置期間終了後となった場合、承認審査の中での適合確認は行われない(製造販売出荷までに適合性確認を行うこと)。
- Q4(第三者機関適合証明書):第三者機関による試験は必須ではないが、活用した場合は適合証明書に加えて適合性確認通知の各要求事項に対応する社内文書も特定すること。
- Q8(附属書Fトランジション適用時の記載):附属書F適用時は箇条4を実施し、5.2・5.7・7.1〜7.3とのギャップ分析を含むギャップ解消アクティビティを実行し文書化。移行計画を確立すること。箇条5のうち「開発計画のセキュリティ考慮」「アーキテクチャー設計」「ベストプラクティス設計・実装」の3事項は記載不要とできる。
- Q9(SBOMの作成情報が不足する場合):平成29年11月25日以降設計開発された品目は構成管理情報からSBOM作成可能。それ以前の品目はリスクマネジメントで対応し、受容可能なレベルに低減できることを確認して継続使用に適することを確実にすること。
- Q10(EOLとEOSの同日設定):医療機関の買替え対応が必要なため、EOLとEOSの間の限定的サポート期間を考慮する必要がある。同日設定は不可。
- Q11(市販後サイバーセキュリティの安全管理):製造販売後安全管理(GVP省令)において実施すること。安全確保措置(情報提供、脆弱性対策等)を実施する必要がある。
B. 市販後安全管理・脆弱性管理
① 報告の基本原則
- サイバーセキュリティ関連不具合等報告も、通常の不具合等報告と同様に医薬品医療機器等法第68条の10第1項に基づき、PMDA(様式8〜12)に提出する。
- 報告期限は重篤性に応じて情報入手日から15日・30日または定期報告(法施行規則第228条20第2項)。常に15日を前提に作業を進めること。
② サイバーセキュリティ不具合として報告が想定される事例
- 医療機器全般共通:脆弱性が認められ、不正アクセスにより悪用の実績(誤動作、機能不全等)が発生した場合。DDoS攻撃により画像診断装置等が意図せず機能停止した場合。アップグレード未実施のレガシー医療機器の脆弱性が悪用された場合。
- 個別機器の例:ネットワーク接続された輸液ポンプへの不正アクセスによる輸液過剰投与・停止。インスリンポンプの設定変更による低血糖。植込み型除細動器のペーシング不全・不整脈誘発。
③ 脆弱性に関する対応の考え方
- CVSS等による評価を行うが、医療機器として臨床環境や患者安全への影響へ置き換え再評価すること(MITRE Rubric for Applying CVSS to Medical Devices参照)。
- 脆弱性が存在するソフトウェアが使用されていない場合、またはセキュリティパッチ等の対策によりリスクを低減できる場合は、報告不要。ただし経時的にモニターすること。
- EOS後も含めた製品ライフサイクル全体を通して、情報収集義務(法68条の2の6第1項)及び行政報告義務(法68条の10第1項)が製造販売業者に残る。
④ 安全確保措置の手段
- 医療機関への情報提供、回収・改修等、添付文書・取扱説明書の改訂、同一製品への処置(販売停止等)。緊急安全性情報等の作成も検討。
- 脆弱性情報の開示タイミングには注意(緩和策・補完的対策を立案できていない段階での開示は攻撃の標的となるリスクあり)。CVD(協調的な脆弱性の開示)プロセスを確立・実施すること。
① 脆弱性の管理(IPA/JPCERT/CC活用)
- 脆弱性を特定・検出するため、IPA(独立行政法人情報処理推進機構)またはJPCERT/CCのウェブサイトから適時情報収集に努めること(IPA:https://www.ipa.go.jp/mailnews.html にメールアドレスを登録、JPCERT/CC:announce-join@jpcert.or.jp へメール送付)。
- 自社製品に関連する脆弱性と思われる情報を入手した際は、情報の受付・確認・評価を行い、修正策・緩和策・補完的対策を行う手順を確立すること。使用医療機関への情報提供手順も確立すること。
- 情報セキュリティ早期警戒パートナーシップ(IPAガイドライン2019年版「5.製品開発者の対応」)に基づき対処すること。自社対応だけでなく他の医療機器製造販売業者等への影響を考慮した上で適時・適切な範囲に開示すること。
② サイバー攻撃への対応体制整備
- 医療機関等がサイバー攻撃を受けた場合の体制を予め整備するため、必要な情報を医療機関等へ提供し適時更新すること。
- 医療機関に対し、サイバーセキュリティに関する保守計画、インシデントを処理するためのポリシー及び役割について説明した上で医療機器を納入すること。
- サイバー攻撃が医療機器に関係する場合、予め整理した内容に基づき医療機関と連携し、医療提供の復旧に協力すること。必要に応じてIPAの安心相談窓口またはJPCERT/CCへ相談可能。
① 対象と基本方針
- 令和6年3月31日以前に製造販売された医療機器で基本要件基準第12条第3項への適合が確認されていない医療機器について、製造販売業者等はサイバーリスクに関する評価を実施し、医療機関等への情報共有・脆弱性管理等を適切に行うこと。
- 医療機関等の求めに応じてSBOMを提示できるように準備しておくこと(EOS後で既に情報提供済みの場合を除く)。
② ライフサイクル段階に応じた医療機関への情報提供義務
- ① EOL未到達の場合:セキュリティパッチ・アップグレード等のサポートに関する情報を含めて提供すること。
- ② EOL超過(EOS未到達)の場合:限定的サポート(セキュリティパッチ、補完的対策等)に関する情報を含めて提供すること。
- ③ EOS超過の場合:補完的対策等の情報を含め、EOSに関する情報を速やかに提供すること。
③ その他の義務
- EOS未到達機器については、セキュリティパッチ等の適用計画を医療機関等へ示し、定期点検等の適切な時期に適用すること。評価等に時間を要する場合は、ファイアウォール等の補完的対策を先行してリスク緩和策として適用する等の段階的計画も可。
- EOS超過後も製造販売後安全管理情報を収集し、医療機関等へ情報提供を行うこと。不具合等が発生した場合は報告の要否を検討すること。
- 中古医療機器を取り扱う販売業者等の求めに応じても同様の対応をすること。
C. 手続き
① 前提・適用範囲
- 製品の有効性及び安全性に関わる機能に影響しない変更に限る。ペースメーカや植込み型除細動器等でネットワーク接続が有効性・安全性の根幹に関わるものや、本来の使用方法ができなくなる変更は対象外。
② 軽微変更届の対象となる事例
- 使用方法欄における動作環境であるOSの種類やクラウド動作の追加・変更・削除(使用目的・効果・性能に影響を与えない場合)。例:汎用PCで動作する製品へのクラウド環境動作の追加、iOS→Android追加など。
③ 一変申請・軽微変更届のいずれも不要な事例
- ネットワークポートの削除(有効性・安全性への影響がない場合)。
- ネットワーク接続の禁止または接続要件の厳格化への変更・追加(SSL通信への限定、接続相手の限定等)。
- セキュリティ機能(認証、認可、暗号化、ログ、リモートソフトウェア更新等)または補完的対策(ファイアウォール、マルウェア対策ソフト等)の変更または追加(患者安全に影響するものを除く)。
- OSバージョン等の追加・変更・削除(例:Windows 10→11追加、EOS済みOSの削除、DBバージョン追加等)。
- 使用方法欄における操作方法や注意事項の変更(例:EOS製品を使用不可としてリスク軽減を図る場合)。
- 【注意】次回の一変申請時には記載整備を要する。個別事例の取扱いはPMDAまたは登録認証機関に相談すること。
D. その他
概要
- 令和6年度厚生労働行政推進調査事業費補助金(厚生労働科学特別研究事業)「医療機関における医療機器のサイバーセキュリティの確保等のために必要な取組の研究」の一環として、全国の医療機器製造販売業許可・製造業登録取得企業を対象にアンケート調査を実施。
- 目的:医療機器全般のサイバーセキュリティ対策の現状把握、問題点・課題の収集分析、制度設計の提言案への反映。
- 回答期間:令和6年10月7日(月)〜令和6年11月15日(金)。
背景と要求事項
- 背景:VPN装置を悪用した外部からの侵入によるランサムウェア被害が増加。医療機関の電子カルテシステムが利用不能になるなど甚大な被害が発生するリスクがある。
- 責任分界の確認:リモートメンテナンスに使用するVPN装置等の付属機器について、保守契約等に基づき医療機関との間で責任分界が明らかになっていることを確認すること。
- 製造販売業者に管理責任がある機器の点検:ファームウェア等のバージョンが最新であること、サポート終了している機器が存在しないことを確認すること。サポート終了が確認された場合は、医療機関に情報提供し、連携の上、機器更新等の適切な対応を行うこと。
- VPN装置について、認証の強化、アクセス制御の実施その他の適切なセキュリティ対策を実施すること。
- 内閣官房国家サイバー統括室からの注意喚起(令和8年2月18日付)も適宜参照すること。
3. サイバーセキュリティに関する手引書(第2版)概要
① 目的・適用範囲
目的:IMDRF N60・N70(レガシー医療機器)・N73(SBOM)の追補ガイダンスの内容を踏まえ、製造販売業者が製品ライフサイクル全体(TPLC)を通じてサイバーセキュリティ対応を行うための国内導入手引き。
適用範囲:無線または有線により他の機器・ネットワーク等との接続が可能なプログラムを用いた医療機器(SaMDを含む)及びプログラムを用いた附属品等。クラス分類(Ⅰ〜Ⅳ)だけでなく、リスクベースアプローチによって判断する。
② 一般原則(4章)
製造販売業者は、NISTサイバーセキュリティフレームワーク・JSP等のベストプラクティスを活用し、設計・開発の段階においてセキュリティを計画・実現する。
PSIRT(Product Security Incident Response Team)等の製品セキュリティ体制を構築し、一連のサイバーセキュリティ活動をQMSの中に定着させる取組を行う。
「共同責任(Shared Responsibility)」における自らの責任を理解し、医療機関・使用者・規制当局・脆弱性発見者等のステークホルダーと連携可能な体制を整備する。
③ 市販前の考慮事項(5章)
セキュリティ要求事項・アーキテクチャー設計(5.1)
脅威モデリングを用いた脅威分析を行い、信頼境界・攻撃対象領域をシステム構成図において特定する。
設計原則(セキュアな通信、データ保護、機器の完全性、使用者の認証、ソフトウェア保守、物理的アクセス、リモートアクセス、信頼性及び可用性)を考慮する。
TPLCに関するリスクマネジメント原則(5.2)
JIS T 14971:2020及びTR T 24971:2020によって最新の技術に基づくリスクマネジメントをTPLC全体で実施。
CVSS等のスコアリングシステムを採用して透明性を確保するが、医療機器として臨床環境・患者安全への影響へ置き換えて再評価すること(MITRE Rubric参照)。
セキュリティ試験(5.3)
静的コード解析、動的解析、堅牢性試験、ソフトウェアコンポジション解析、ファジング等に加えて、STIGsやCISベンチマーク等を用いた定量的セキュリティ評価を実施・文書化すること。市販後においても繰り返し評価を実施する。
TPLCサイバーセキュリティマネジメント計画(5.4)
脆弱性の監視・開示・修正・バックアップ・復旧・情報共有・製品寿命開示に関する計画を市販前に具体化する。
顧客向け文書(5.5)
注意事項等情報・取扱説明書・顧客向けセキュリティ文書(MDS2、SBOM等)を整備する。SBOMは製品リリース時に医療機関へ提供し、変更管理を実施すること。
④ 市販後の考慮事項(6章)
情報共有(6.2)
市販前計画に基づき、国内外で確認されたサイバーセキュリティ脅威・脆弱性情報を継続的に収集・分析し、医療機関へ提供すること。ISAO等に積極的に参加することが推奨される。
協調的な脆弱性の開示(CVD)(6.3)
緩和策・補完的対策が立案できていない段階での開示は攻撃の標的になるリスクがあるため、開示タイミングに注意すること。ISO/IEC 29147(脆弱性の開示)・ISO/IEC 30111(脆弱性の処理プロセス)に従ったCVDプロセスを確立すること。
脆弱性の修正(6.4)
セキュリティパッチ等のアップデートは、医療機器としての機能の追加・変更がない場合は都度の薬事承認不要。ただし機能の追加・変更を伴う場合は一部変更申請等が必要。
インシデントへの対応(6.5)
不正アクセス・設定変更・データ喪失等のインシデント対応手順を整備する。JPCERT/CCを通じたCVE取得・脆弱性情報登録が必要となる場合がある(製品開発者リストへの登録推奨)。PSIRTの構築が望ましい。
レガシー医療機器(6.6)
EOL・EOSについて設計段階から計画・定義する。EOL超〜EOS超の「限定的サポート段階」を設け、ファイアウォール等の補完的対策を医療機器の使用環境として指定・提示すること。
販売開始から5年以内でも保護できない医療機器はレガシーとみなされる。EOS後も情報収集義務・行政報告義務は製造販売業者に残る。
⑤ SBOM(ソフトウェア部品表)(附属書A)
- SBOMは製造販売業者が作成(または開発委託先・OEM/ODM先等からの提供を確認・管理・発行)し、製品リリース時に医療機関へ提供する。
- 最小限の要素(NTIAに基づく):サプライヤー名、コンポーネント名、バージョン、固有識別子、コンポーネントハッシュ(オプション)、関係(上流との関係)、作成者名、タイムスタンプ。
- 推奨フォーマット:CycloneDX、SPDX、SWIDのいずれか(標準化された自動化可能なフォーマット)。
- SBOMは機密情報として覚書・契約・使用許諾等によって管理し、規制当局・医療機関等へのコミュニケーションチャネルを保護することが望ましい。
⑥ 業許可に関する考慮事項(7章)
- 製造販売業者・販売業者・貸与業者・修理業者の各ステークホルダーがサイバーセキュリティ対応においても連携する。SBOM・MDS2・CVDに必要な情報を適切かつ遅滞なく共有すること。
- リース医療機器・中古医療機器においても、EOLまたはEOSまでの段階においては、各業者と必要な連携をとり、適切な情報提供・セキュリティパッチの適用等を行うこと。
4. 厚労省ウェブサイト
サイバーセキュリティに関する最新情報は厚生労働省ウェブサイトにてご確認ください。
https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000179749_00009.html
(「医療機器におけるサイバーセキュリティについて」のページにアクセスします)