NIS2・CRA・NIST CSF 2.0をIEC 62443で読み解く　OTコンプライアンス実務ガイド

OT COMPLIANCE GUIDE 異なる規制を IEC 62443でつなぐ 実務ガイド NIS2・CRA・NIST CSF 2.0・ゼロトラスト をOTの実装へ IEC 62443という共通言語 2026.09 Secomea合同会社

INTRODUCTION 規制が分断するOTセキュリティの現実 今日の製造業は、事業継続性、生産性、サイバーセキュリティ、そして規制遵守を同時に満たすことが求められています。 その重要性は、スマート製造の推進、グローバルなサプライチェーンの複雑化、そして国家の重要インフラを狙ったサイバー攻撃の増加により、かつてないほど高まっています。 しかし、現場では複数の規制やフレームワークがそれぞれ異なる目的と適用範囲で存在し、個別に対応するだけでは一貫性のあるセキュリティ対策を構築することが困難になっています。ITとOTの要件の違いも重なり、対 応が断片化しやすいのが現状です。 NIS2 重要インフラのサイバー耐性強化 CRA デジタル製品のセキュリティ要件 NIST CSF 2.0 リスク管理のフレームワーク 各国の法規制 業界・地域ごとの追加要求 OT IEC 62443 OTセキュリティの共通言語として、規制と現場をつなぐ このガイドでわかること 主要規制の背景と要求事項の違い IEC 62443を基盤とした統合的な対応の考え方 製造業における実践的なセキュリティ強化のステップ 規制対応を事業価値につなげる方法 異なる規制を個別に追うのではなく、IEC 62443という共通言語でつなぐことで、複雑な要求を体系的に整理し、実効性のあるOTセキュリティを実現できます。本ガイドは、そのための考え方と実践のヒントを提供しま す。 2 | IEC 62443 という共通言語 - OTコンプライアンス実務ガイド SECOMEA

C O N T E N T S 目次 はじめ に — 本ガイドについて 第 1 部 　 な ぜ束 ね るの か 1 なぜ今、OTコンプライアンスが重いのか 2 規格をバラバラに追う消耗 ／ NIS2とCRA・CRAタイムライン 第 2 部 　 共 通 言 語としての I E C 6 2 4 4 3 3 同じ要件、異なる言葉 — 4層モデル 4 なぜ IEC 62443 が「橋」になるのか 5 一度の実装で束ねる — 3つの代表要件マッピング 第 3 部 　 現 場 へ — 失 敗・責 任・実 装 6 OTリモートアクセスの典型的な失敗 7 責任の線引き — 誰が、どこまで担うのか 8 Secomeaの位置づけ — IEC 62443の実装例として 9 次の一歩 — 自社の現場に引き寄せる 付 録 A 用語集 B 出典一覧 規制やフレームワークは、それぞれが違う言葉を使っていても、現場に求めているセ キュリティの中身は驚くほど重なっている。 Built for OT. Approved by IT.

A B O U T T H I S G U I D E 本ガイドについて 対象読者 EU 取引で NIS2 を求められる工場の運営者、EU へ輸出する装置メーカー（製造者）として CRA に向き合う方、親会社 やグループの方針で NIST CSF を運用する方。要するに、複数の規制・フレームワークを別々のプロジェクトとして追いか け、そのたびに同じような作業をやり直しているOT 製造業の実務担当者です。 本ガイドの約束 規制やフレームワークは、それぞれが違う言葉を使っていても、現場に求めているセキュリティの中身は驚くほど重なってい ます。本ガイドは、IEC 62443 を「実装の共通言語（背骨）」に据えることで、NIS2・CRA・NIST CSF への対応を一つの 実装基盤に束ね、監査のたびにやり直す消耗を減らすための実務的な地図を示します。 読み方 第1〜2章で「なぜ今この課題が重いのか」を共有し、第3〜4章で「なぜ IEC 62443 が各規制をつなぐ背骨になるのか」を 説明します。第5章で代表的な3つの要件を使って「一つの実装が複数規制の証跡に再利用できる」ことを具体的に示しま す。続く第6章で「OT リモートアクセスの典型的な失敗」を IEC 62443 で整理し、第7章で責任の線引き、第8章で Secomea の位置づけ、第9章で次の一歩へ進みます。 本ガイドが扱う「束ねる」の意味 本ガイドのいう「一度の実装で束ねる」は、実装と統制を共通化し、重複作業を減らし、対応状況を説明できる証跡を再利 用できることを指します。ある規格への準拠が、他の規格の法的な適合を自動的に完了させるという意味ではありませ ん。各規制の適合判断は、それぞれの要件・手続きに従って行う必要があります。なお、本ガイドは実務上の整理であり、個 別の製品・法人の法的適合性を判断するものではありません。

C H A P T E R 0 1 なぜ今、OTコンプライアンスが重いのか OT（制御技術）の現場をとりまく環境が、ここ数年で大きく変わりました。変化は、おおむね3つの力に整理できま す。 1つ目は、脅威の増大です。 製造業は、いまや最も狙われやすい産業です。IBM X-Force の年次脅威レポート（2026年 版）によれば、X-Force が観測したインシデントのうち製造業が占める割合は 27.7% にのぼり、製造業は 5年連続で最多 の標的となりました〔出典：IBM 2026 X-Force Threat Intelligence Index〕。なお、この数値は X-Force が観測・対応 したインシデントに占める比率であり、世界中のすべてのサイバー攻撃を母集団とした統計ではありません。それでも、X- Force の観測範囲において、製造業が主要な標的であり続けていることは明らかです。製造業のサプライチェーンはグロー バルに広がっており、日本を含むアジア太平洋地域の工場・装置メーカーにとっても、これは対岸の火事ではありません。 にもかかわらず、OT の現場では、いまも VPN ベースの遠隔アクセスが多く残っており、認証・権限・接続先の制御が不十 分なまま運用されると、攻撃者の入口になり得ます。だからこそ業界全体では、固定的な VPN から、接続のたびに本人と 権限を検証するゼロトラスト型の遠隔アクセスへと移行が進んでいます。ただし、IT 向けのゼロトラスト製品をそのまま持 ち込むのではなく、OT のプロトコルや可用性の要件を理解した仕組みが必要です（第2章で詳述）。 2つ目は、規制の強化です。 NIS2 指令と CRA（サイバーレジリエンス法）は、いずれも従来より厳格で、アクセス制御・脆弱 性管理・インシデント対応・サプライチェーン管理について、監査や顧客説明に耐える統制を求めています。「つながってさ えいればよい」時代は終わり、OT の遠隔保守では、これらの要求が「誰が・いつ・何に・どうつないだか」を説明できるリ モートアクセス管理として具体化します。 しかも、これは「まだ先の話」ではありません。CRA では、2026年9月11日から、悪用が確認された脆弱性および重大なイ ンシデントの報告義務が先行して適用されます。製品要件そのものの本格適用は2027年12月ですが、24時間・72時間と いう短い期限で正確に報告するには、その前から脆弱性を受け付け・判断・報告できる体制を整えておくことが事実上欠 かせません（詳細は第2章）。 3つ目は、エコシステムの変化です。 設備・部品・サービスの供給者が増えるほど、関与する組織が増え、リスクの接点も増 えます。中央で制御する仕組みがなければ、各社がばらばらに最適化し、結果として全体のコンプライアンスは混乱します。 この3つの力が同時に効いているために、OT のコンプライアンスは「いつかやる課題」ではなく「いま設計すべき課題」に なっています。

C H A P T E R 0 2 規格をバラバラに追う消耗 複数の規制に向き合う現場で起きているのは、同じような対策を、規制ごとに別プロジェクトとして何度もやり直す という消耗です。日本の OT 製造業では、EU との取引で NIS2 を、EU への輸出で CRA を、親会社やグループの 要請で NIST CSF を——というように、複数の枠組みが同時に走ることが珍しくありません。 2-1. NIS2 は事業者を、CRA はベンダーを規制する この消耗を解く鍵は、各規制が「誰を」規制しているかを正しく捉えることです。 NIS2 は事業者（オペレーター）を規制します。 工場を運営し、設備やサービスを使う側の義務です。供給品をどうホス ティングし、どんな運用リスクを負い、サプライヤにどんなセキュリティ要件を伝えるか——が問われます。 CRA はベンダー（装置メーカー・製造者）を規制します。 製品をつくって市場に出す側の義務です。セキュアな設計・開 発、製品寿命にわたるサポート、脆弱性の適時解決、SBOM（ソフトウェア部品表）を含むコンポーネント情報の作成・維 持と必要に応じた説明——が問われます。 なお、NIS2 が対象とするのは一定のセクター・規模に該当する事業者（essential / important entities）であり、すべて の工場が自動的に対象になるわけではありません。本ガイドでは実務上の理解を助けるため、NIS2 を「運用する側」、 CRA を「製品を市場に出す側」の義務として整理します。 そして重要なのは、リモートアクセスがちょうどこの両者の「間」に座るという事実です。事業者（NIS2）とベンダー（CRA） は、遠隔保守やサービスを通じて、いまや構造的に接続されています。事業者がリモートアクセスをどう管理するかは NIS2 の論点であり、そのアクセス手段を提供する製品がどうつくられているかは CRA の論点です。一つの遠隔アクセス 経路に、二つの規制が同時に関係するのです。 図 1 — リモートアクセス は N I S 2 と C R A の「 間 」に座る 事業者（オペレーター） ベンダー（装置メーカー） NIS2 CRA リモートアクセス 工場を運営し 製品をつくって 設備・サービスを使う側 市場に出す側 「運用する側」の義務 一つの遠隔アクセス経路に、二つの規制が同時に関係する 「製品を出す側」の義務 一つの組織が、自社工場を運営しつつ（NIS2）接続製品も出す（CRA）＝両対象になり得る NIS2（指令）は事業者を、CRA（規則）は製品を規制する。遠隔保守の経路は両者の構造的な接点であり、同一組織が両方の対象になることも珍しく ない。

また、一つの組織が両方の対象になることも珍しくありません。たとえば、自社で工場を運営しながら（NIS2 の事業者）、 同時に接続機能を持つ製品を EU 市場に出している（CRA の製造者）——という重なりは十分に起こり得ます。両者は 相互排他ではなく、サプライチェーン全体を覆う補完関係にあります。 2-2.「 機械」から「デジタル要素を持つ製品」へ CRA では、接続性を備えた産業機器が、その性質に応じて、ハードウェア＋ソフトウェア＋接続性を備えた「デジタル要素 を持つ製品」として規制の対象になり得ます。とりわけ、PLC を組み込んだ産業機械そのものが対象になり得る点には注 意が要ります。これは、サイバーセキュリティを「IT 部門の問題」から「製品そのものの責任」へと移す転換です。 装置メーカーにとっては、統合した部品の脆弱性にも責任が及び、「一度売って終わり」ではなく、継続的にセキュリティを 維持し続ける運用——いわばソフトウェア企業のような姿勢——が求められるようになります。 （なお、医療機器・自動車・航空・海事機器など、別の EU 法が優先して適用される製品分野は CRA の対象から除外・限 定される場合があります。自社製品がどう扱われるかは個別の確認が必要です。） 2-3. NIS2 と CRA は何が違うのか 両者は目的も対象も異なります。整理すると次のとおりです。 観点 NIS2（事業者の義務） CRA（製品の義務） 範囲 自社の IT 基盤と生産・現場 市場に出す製品 主な責任部門 IT 部門・プラント管理 製品開発 対象システム PC・メール・Web・IaaS／MES・PLC・機械・リモート 接続製品・IoT サービス・機械クラウド サービス 主な役割 ユーザ・事業者・サービス提供者 製造者・販売者 法形式 指令（各国の国内法を通じて適用） 規則（EU 全域で直接適用） 時間軸 国内法化期限 2024年10月17日／翌18日に適用開始 報告義務 2026年9月11日先行適用／製品要件は2027 （各国で国内法化が進行中） 年12月11日から本格適用 めざすもの 強靭な生産（Resilient Production） 強靭な製品（Resilient Products） 「強靭な生産」を求める NIS2 と、「強靭な製品」を求める CRA。視点は違っても、現場で必要になる技術的対策——安全 なアクセス、適切なセグメンテーション、脆弱性の管理——は大きく重なります。

図 2 — C R A の 時 間 軸（法 的 義 務と実 務 上 の 備えを分 ける） 現在（2026-06） 2024-12-10 2026-09-11 2027-12-11 発効 報告義務 先行適用 主要義務 本格適用 24h 早期警告／72h 通知 必須要件・適合性評価 14日（脆弱性）・1ヶ月（重大）最終報告 CE マーキング・技術文書 2026年9月の時点で求められるのは「報告」。SBOM 維持や脆弱性開示ポリシーの法的完備は2027年12月から。ただし短い報告期限に応えるには、 背後の脆弱性管理体制を前倒しで整えておくことが実務上は欠かせない。 CRA の時間軸を正しく押さえる CRA は2024年12月10日に発効しましたが、義務が一斉に始まるわけではありません。2026年9月11日からは「報告義 務」だけが先行し、必須サイバーセキュリティ要件・適合性評価・CE マーキング・技術文書といった主要義務の本格適用は 2027年12月11日です。したがって、2026年9月の時点で SBOM 維持や脆弱性開示（CVD）ポリシーまで法的に完備して いなければならない、という読み方は正確ではありません。一方で、報告義務に短い期限で応えるには、背後の脆弱性管 理体制を前倒しで整えておくことが実務上は欠かせません。「法的に課される義務」と「実務上の備え」は分けて考えるの が安全です。 2-4. IT のやり方を OT にそのまま持ち込めない もう一つの落とし穴は、IT のセキュリティをそのまま OT に当てはめてしまうことです。両者は前提が違います。情報システ ム（IT）では「機密性」が最優先になりがちですが、止まれば生産そのものが止まり、安全にも関わる OT では、可用性と完 全性が機密性より優先されることが多くなります。これは「OT では機密性が不要」という意味ではなく、守るべきものの優 先順位が IT とは入れ替わるということです。ISO 27001 のような IT 向けの上位概念だけでは、OT 現場で実装できる具 体的な統制までは届きません。OT には、OT のための実装規律が要ります。

C H A P T E R 0 3 同じ要件、異なる言葉 ― 4層モデル 各規制・フレームワークは、抽象度の異なる「層」に位置づけると、互いの関係が見えてきます。 図 3 — 4 層モデル：I E C 6 2 4 4 3 という背 骨 の 上 に各 層 が 乗る 規制層 「何を」達成すべきか NIS2 ／ CRA 事業者の義務／製品の義務 統制・成果整理層 どう整理・伝達するか NIST CSF 2.0 統治・識別・防御・検知・対応・復旧 セキュリティ原則層 どう設計・強制するか ゼロトラスト 最小権限・常時検証 実 装 層 （ 背 骨 ） OT システムを実際にどう守るか IEC 62443 ゾーン（区画）・コンジット（通信経路）・SL・FR1〜7 上の3層は「何をすべきか・どう整理／設計するか」を語る。OT 環境で実際にどう作るかを定義するのは最下層の IEC 62443 だけ。だからこそ上位の どの層からも参照できる「実装の共通言語」になり得る。 上の3層は「何をすべきか」「どう整理・設計するか」を語ります。しかし、OT 環境で実際にどう作るかを具体的に定義して いるのは、最下層の IEC 62443 です。だからこそ IEC 62443 は、上位のどの層からも参照できる「実装の共通言語」にな り得ます。 3-1. OT のリスクは「文脈」で変わる IEC 62443 が OT 向けである理由は、リスクの捉え方に表れています。OT のリスクは、脆弱性そのもの（Flaw）× 置かれ た文脈（Context）× もたらす結果（Consequence）で決まります。同じ脆弱性でも、インターネットに直接さらされている 機器なら高リスク、何層ものセグメンテーションの奥にある機器なら低リスク——というように、文脈次第でパッチの判断さ え変わります。 加えて、OT は性質の異なる「3つの世界」を一つとして動かしています。ミリ秒単位で動く PLC、稼働の安定が最優先で旧 式システムのパッチが遅れがちな DCS、地理的に広がり攻撃面が拡大しやすい SCADA。これらを束ねて安全に運用する には、機器単位ではなくシステムとして設計する発想が要ります。 3-2.「 断片的な統制」から「構造化された防御」へ IEC 62443 は、単に CRA や NIS2 に従うための道具ではありません。ばらばらの個別対策（断片的な統制）から、構造化 され、リスクに基づき、多層に防御するアプローチへ移行させる——その設計思想こそが本質です。孤立した機器を一つ ずつ守るのではなく、相互接続されたシステム全体をどう守るかを問う。これが OT に適した規律です。 参照する（実装に落とす）

C H A P T E R 0 4 なぜ IEC 62443 が「橋」になるのか IEC 62443 が複数の規制をつなぐ「橋」になれるのは、橋を架けるのに必要な基礎概念を、すべて自前で定義し ているからです。 IEC 62443 が定義するもの だからこそ接続できる システムの構造：区画（ゾーン）と、区画どうしをつ NIS2（事業者の義務）：求められるリスク管理措置 なぐ通信経路（コンジット） を、ゾーン・SL・FR という実装に落とせる 統制の体系：基盤要件 FR1〜FR7（識別・認証／ CRA（製品の義務）：求められるセキュア開発・脆弱 使用制御／システム完全性／データ機密性／デー 性管理を、4-1／4-2 に対応づけられる タフロー制限／事象への適時対応／資源の可用 NIST CSF 2.0（統制構造）：統治〜復旧の各機能 性） を、FR と統制で具体化できる セキュリティレベル：SL1〜SL4（脅威・リスク分析か ら目標値を導く） 製品ライフサイクル：4-（1 セキュア開発ライフサイク ル）／4-2（コンポーネント技術要件） 4-1. IEC 62443 の全体像と「誰が関与するか」 IEC 62443 は階層構造を持ち、それぞれが主にどの役割に関与するかが定まっています。 図 4 — I E C 6 2 4 4 3 シリーズ の 構 造と関 与する役 割 1. 全般 （共通） 用語・概念・用語集・ライフサイクル 2. ポリシーと手順 資産所有者 IACS セキュリティ管理・パッチ管理・設置/保守 3. システム ＜3-2 ゾーン&コンジットの SL／3-3 システム要件＞ システム統合者 セキュリティ技術・統合環境としての要件と SL 4. コンポーネント ＜4-1 製品開発要件／4-2 技術要件＞ コンポーネント供給者 製品単体が備えるべきプロセスと能力 3-3 は「システム」に対する規格（統合者の文脈）、4-1／4-2 は「コンポーネント（製品）」に対する規格（供給者の文脈）。したがって単体の機器に「3-3 を取得」とは言わない。コンポーネント単体なら 4-2、システムや統合環境なら 3-3 が正確な対応。

区分 主な内容 主に関与する役割 1. 全般 用語・概念・用語集・ライフサイクル （共通） 2. ポリシーと手 IACS セキュリティ管理システム要件・パッチ管理・設置/保守 資産所有者 順 3. システム セキュリティ技術・ゾーン&コンジットの SL（3-2）・システム要件と SL（3-3） システム統合者 4. コンポーネ 製品開発要件（4-1）・コンポーネント技術要件（4-2） コンポーネント供給者 ント ここで押さえておきたいのは、3-3 は「システム」に対する規格（システム統合者の文脈）であり、4-1／4-2 は「コンポーネ ント（製品）」に対する規格（供給者の文脈）だという区別です。したがって、単体のコンポーネントや機器について「3-3 を 取得した」という言い方は、規格の構造上ふさわしくありません。コンポーネント単体なら 4-2、システムや統合環境なら 3-3、というのが正確な対応です。なお、これらの役割は実務では重なり合うこともあります（たとえば 3-2 には資産所有者 と統合者の双方が関わります）。 セキュリティレベルの3つの顔 IEC 62443 では、セキュリティレベルを目的別に区別します。SL-T（目標）は資産所有者がリスク分析から定める到達目 標、SL-C（能力）は製品やシステムが備える能力、SL-A（達成）は実際の運用環境で達成された水準です。ベンダーが製品 について示せるのは、原則として能力としての SL-C です。実運用で達成される SL-A は、統合のしかた・設定・補完対策・ 日々の運用によって変わるため、製品単体だけでは決まりません。

C H A P T E R 0 5 一度の実装で束ねる ― 3つの代表要件マッピング フレームワークを並べて比べると、同じ概念が言葉を変えて何度も現れます。ここでは代表的な3つの要件で、各規 格が IEC 62443 でどう一つの実装に束ねられるかを示します。各表の最下行（IEC 62443）が、共通の実装の着地 点です。 表1　アクセス制御 フレームワーク 求める要件 NIS2 サイバーリスク管理措置の一部としてのアクセス制御 CRA 製品ライフサイクル全体での安全なアクセス制御・不正利用からの保護 NIST CSF 2.0 PR.AA（識別管理・認証・アクセス制御） ゼロトラスト 最小権限の徹底・全アクセス要求での ID 検証 IEC 62443 識別・認証制御（FR1）／使用制御（FR2） 実務ではこうなる：役割ベースのアクセス制御／強力な認証（ユーザ＋サービス）／OT 全体での最小権限の強制／ゾーン・コンジット単位でのアク セス範囲の限定。 表2　ネットワークセグメンテーション フレームワーク 求める要件 NIS2 インシデントの影響を局限するリスク管理・封じ込め措置 CRA 安全なシステム設計・不正なデータフローからの保護 NIST CSF 2.0 PR.IR（技術インフラのレジリエンス ― セキュリティアーキテクチャの管理） ゼロトラスト 横方向の移動（ラテラルムーブメント）の阻止・システム隔離 IEC 62443 ゾーンとコンジット／制限されたデータフロー（FR5） 実務ではこうなる：OT システムをリスクに応じたゾーンに分割／厳格に制御された通信経路／横展開の抑止／サイバーインシデントの封じ込め。

表3　脆弱性管理 フレームワーク 求める要件 NIS2 リスク管理・インシデント対応・脆弱性管理プロセス CRA 脆弱性ハンドリング・報告・製品ライフサイクルにわたる責任 NIST CSF 2.0 ID.RA（リスク評価 ― 脆弱性の識別）／PR.PS（プラットフォームセキュリティ）／RS（対応） ゼロトラスト 継続的な監視と改善 IEC 62443 セキュア開発・脆弱性ハンドリング（4-1）／パッチ管理（2-3）／コンポーネント技術要件（4-2） 実務ではこうなる：セキュア開発プロセス／継続的な脆弱性管理／事業者とベンダー間の協調的な対応／コンポーネント・依存関係の可視化。 まとめ — 言葉は違っても、実装の重なりは大きい 規制やフレームワークごとに、目的・手続き・証明のしかたは異なります。しかし、現場で実装する統制要素には大きな重な りがあります。IEC 62443 を共通言語に据えれば、一つの実装基盤を、複数規格への対応状況を説明できる証跡として 再利用できます。規制が増えるたびにゼロからやり直すのではなく、背骨となる実装の上に、各規制の文脈を重ねていく ——これが消耗を減らす考え方です。 （※前述のとおり、証跡の再利用は重複作業の削減を意味します。各規制の最終的な適合判断は、それぞれの要件・手続きに従って行ってください。）

C H A P T E R 0 6 OTリモートアクセスの典型的な失敗と IEC 62443 での整理 ここまでの章で、IEC 62443 が NIS2・CRA・NIST CSF をつなぐ「背骨」になることを、概念のレベルで見てきまし た。ここからは視点を現場に下ろします。IEC 62443 のような規格は、条文だけを読むと抽象的に見えます。けれど も、自社の現場で実際に起きているリモートアクセスの「つまずき」に当ててみると、規格が何を言おうとしている のか、そして何を整えればよいのかが、急にはっきりします。 OT のリモートアクセスでよく見かける失敗は、おおむね6つに整理できます。どれも、現場の事情を考えれば「そうなってし まう」理由がある、ありふれた状態です。重要なのは、これらが別々の問題に見えて、実は IEC 62443 の同じ構造（基盤要 件 FR・ゾーンとコンジット・最小権限）で一貫して説明できるということです。 よくある失敗 現場で起きること IEC 62443 での整理 共用の VPN アカウント 「誰が」つないだのか説明できない 識別・認証制御（FR1）／使用制御（FR2） ベンダーごとに別々の VPN アクセスを統制・棚卸しできない ゾーンとコンジット／データフロー制限（FR5） フラットな OT ネットワーク 侵入されると一気に横展開される ゾーン設計／データフロー制限（FR5） 保守用 PC の持ち込み マルウェアや設定不備の入口になる 使用制御（FR2）／資産管理（2系） ログが IT 側にしかない 監査・事故調査に耐えられない 事象への適時対応（FR6） 常時つなぎっぱなし 「必要なときだけ」の原則に反する 最小権限・ゼロトラスト／使用制御（FR2） 以下、ひとつずつ見ていきます。 6-1. 共用の VPN アカウント —「誰が」が消える 複数の担当者やベンダーが、一つの VPN アカウントを使い回している。OT の現場では珍しくない状態です。日々の保守 を回すには手軽ですが、ひとたびインシデントが起きると「、いつ・誰が・何の作業のために接続したのか」を後から説明で きません。 IEC 62443 の言葉でいえば、これは識別・認証制御（FR1）と使用制御（FR2）が効いていない状態です。FR1 は「接続し てくる相手が誰かを一意に識別し、認証する」ことを、FR2 は「識別された相手に、許された操作だけをさせる」ことを求め ます。アカウントを共有した瞬間に、この2つの土台が崩れます。NIS2 のインシデント報告も、CRA の脆弱性報告も、「誰が 関与したか」を辿れることを前提にしている以上、ここは真っ先に手当てしておきたい土台です。 6-2. ベンダーごとに別々の VPN —「統制」が散らばる 装置メーカー・SIer・保守業者が、それぞれ自前の VPN や接続手段を持ち込み、現場に並走している。結果として、どの ベンダーが・どの経路で・どの機器にアクセスできるのかを、誰も一元的に把握できなくなります。棚卸しもできず、退職 者やプロジェクト終了後のアクセスが残り続ける、ということも起こります。

IEC 62443 は、こうした「経路の乱立」をゾーンとコンジットの考え方で整理します。アクセスは、許可された区画（ゾーン） に向けて、許可された通信経路（コンジット）を通ってのみ行われるべきもの——それ以外の経路は存在しないのが理想で す。データフロー制限（FR5）は、まさにこの「許された流れ以外を通さない」を要件にしています。ベンダーごとにバラバラ の経路を作るのではなく、統制された一つの入口に集約することが、規格の方向と一致します。 6-3. フラットな OT ネットワーク —「横展開」を止められない 生産現場のネットワークが区画されておらず、平らに一面でつながっている。古くから動いてきた設備では、よくある構成で す。しかしこの状態では、一台が侵害されると、攻撃者はそこを足場にして、ネットワーク全体へ容易に横展開（ラテラル ムーブメント）できてしまいます。 これも IEC 62443 の中核、ゾーン設計と FR5（データフロー制限）の出番です。リスクの異なる機器を別々のゾーンに分 け、ゾーン間の通信を必要最小限のコンジットに絞る。そうすれば、万一どこかが破られても、被害をそのゾーンに封じ込め られます。第3章で触れた「同じ脆弱性でも文脈でリスクが変わる」という考え方は、まさにこのセグメンテーションを前提に しています。 6-4. 保守用 PC の持ち込み —「管理外の機器」が入口になる ベンダーが、自社で管理している保守用のノート PC を現場に持ち込み、OT ネットワークに直接つなぐ。日常的な光景です が、その PC が社外でマルウェアに感染していたり、設定が不十分だったりすれば、そのまま OT への入口になります。持 ち込み機器は、現場側からは中身が見えない「管理外の資産」です。 IEC 62443 では、これは使用制御（FR2）と、資産所有者に求められる資産管理（2系：IACS セキュリティ管理）の論点で す。何を・誰が・どの条件で接続してよいかを定め、管理外の機器が無条件に内部へ入れない仕組みを設けること。理想 は、保守作業を「管理された経路と環境」の上で完結させ、持ち込み機器を OT ネットワークに直結させないことです。 6-5. ログが IT 側にしかない —「説明責任」を果たせない 接続や操作のログが、IT 部門のシステムにしか残っていない。あるいは、OT 側の作業記録が断片的にしか取れていな い。この状態では、監査を求められたとき、あるいは事故の原因を遡って調べたいときに、必要な証跡が出てきません。 IEC 62443 の事象への適時対応（FR6）は、セキュリティに関わる出来事を記録し、適時に検知・対応できることを求めま す。NIS2 のインシデント報告や、CRA の報告義務（第2章で見た 2026年9月開始の先行義務）に短い期限で正確に応え るには、「誰が・いつ・何に接続し、何をしたか」が後から辿れる記録が不可欠です。ログは、コンプライアンスを「説明でき る」状態にするための土台です。 6-6. 常時つなぎっぱなし —「最小権限」に反する 遠隔保守の経路を、使うときも使わないときも、常に開いたままにしている。つなぎ直す手間を省くための運用ですが、開 いている時間が長いほど、攻撃の機会も広がります。これは「必要なときに、必要な範囲だけ」というセキュリティの基本原 則に反します。

ゼロトラストの考え方、そして IEC 62443 の使用制御（FR2）は、ここで「最小権限」と「必要時のみの接続（ジャストインタイ ム）」を促します。接続は、申請・承認を経て、必要な時間だけ開き、終わったら閉じる。常時開放を「必要時のみの開放」へ 切り替えることが、攻撃面を構造的に小さくします。 まとめ — 6つの失敗は、一つの構造で解ける ここで挙げた6つの失敗は、一見すると別々のトラブルです。けれども整理してみると、識別・認証（FR1）、使用制御（FR2）、 データフロー制限（FR5）、事象への適時対応（FR6）、そしてゾーンとコンジット・最小権限という、IEC 62443 の同じ構造 の上に、すべてが乗っています。 図 5 — 6 つの 失 敗 は 、I E C 6 2 4 4 3 の 同じ構 造 に収 斂する 共用の VPN アカウント ベンダーごとに別々の VPN IEC 62443 フラットな OT ネットワーク 一つの構造 FR1 識別・認証 FR2 使用制御 保守用 PC の持ち込み FR5 データフロー制限 FR6 事象への適時対応 ログが IT 側にしかない ゾーンとコンジット・最小権限 常時つなぎっぱなし 別々に見える失敗も、FR1・FR2・FR5・FR6 とゾーンとコンジット・最小権限という同じ土台に乗る。穴を見つけるたびに場当たりで塞ぐのではなく、背 骨に沿って設計すれば複数の失敗を一貫して解消できる。 これが意味するのは重要なことです。穴を見つけるたびに場当たりで塞ぐのではなく、背骨（IEC 62443）に沿って設計す れば、複数の失敗を同時に・一貫した考え方で解消できる——これが、規格を「監査のための義務」ではなく「現場を強く する道具」として使うということです。 ただし、ここで一つの問いが残ります。これらの対策を「誰が」担うのか。ネットワークの区画は資産所有者の責任か、それと も統合者か。製品が備えるべき機能は、どこまでがベンダーの責任か。この線引きを曖昧にしたまま進めると、各者が局所 最適に走り、かえって全体のリスクが増します。次の第7章では、この責任の線引きを扱います。そして第8章では、本章で挙 げた6つの失敗に対して、セキュアリモートアクセスが実装例としてどう応えるのか——ID ベースのアクセス制御、ベンダー アクセスの一元的な統制、ゾーン／コンジットとの整合、監査証跡、必要時のみの接続——を、具体的に見ていきます。

C H A P T E R 0 7 責任の線引き ― 誰が、どこまで担うのか 第6章の最後に、一つの問いを残しました。第6章で見た弱点に対処していくとして、それを「誰が」担うのか——と いう問いです。ネットワークの区画は資産所有者の仕事か、統合者の仕事か。製品が備えるべきセキュリティ機能は、 どこまでがベンダーの責任か。この線引きが曖昧なまま進めると、各者が自分の見える範囲だけを最適化し、隙間 にリスクが残ります。 IEC 62443 の優れているところは、この「誰が」に共通の答え方を与えることです。 7-1. セキュリティは、一社では完結しない 複雑なエコシステムでは、安全性も強靭性も、関わる各者が「自分の担う部分」を正しく果たすことの積み重ねで成り立ち ます。自動車にたとえれば分かりやすいでしょう。部品メーカーが安全な部品をつくり、組立メーカーがそれを正しく組み上 げ、使う人が適切に運転・整備する——どこか一つが欠けても、車全体の安全は保てません。 OT も同じです。コンポーネントの供給者がセキュアな使い方を定義し、装置メーカー（システム統合者）が責任を持って統 合し、資産所有者が正しく運用・保守する。サイバーセキュリティ・安全・保守性は、特定の一社が丸ごと引き受けられるもの ではなく、エコシステム全体で分担される責任です。だからこそ、各者が「自分はどこを担うのか」を共通の言葉で理解して いることが、出発点になります。 7-2. 3つの役割 —「活動」で分ける IEC 62443 は、関わる人を「肩書き」ではなく「何をするか（活動）」で役割に分けます。大きく3つです。 図 6 — 3 つの 役 割 は「 活 動 」で分 か れる／ 説 明 責 任 は 資 産 所 有 者 に固 定 資産所有者 システム統合者 製品供給者 運用する 統合する 開発する Operates Integrates Develops 2系・パッチ管理・保守 3系（3-2 ゾーン&コンジット） 4系（4-1 セキュア開発） 到達目標 SL-T を定める 3-3 システム要件 4-2 コンポーネント技術要件 ※ 役割は「組織」ではなく「活動」。一社が複数の役割を担い得る（固定的な一対一ではない） 最終的な説明責任（accountability）は、資産所有者に固定される 他者へ委譲できない。支援は受けられるが、全体をセキュアに保つ責めは運用する当事者に残る 役割は活動で分かれ、一社が複数を担い得る。ただし IACS をセキュアに運用する最終的な説明責任だけは、資産所有者に固定され委譲できない。

役割 中心となる活動 主に関わる IEC 62443 資産所有者 運用する（Operates） 2系（IACS セキュリティ管理・パッチ管理・保守）／到達目標 SL-T を定める システム統合者 統合する（Integrates） 3系（3-2 ゾーン&コンジットの SL／3-3 システム要件） 製品供給者 開発する（Develops） 4系（4-1 セキュア開発ライフサイクル／4-2 コンポーネント技術 要件） ここで大切なのは、この3つは「組織」ではなく「活動」だということです。一つの会社が、ある場面では製品供給者として、 別の場面ではサービス提供者として関わることもあります。逆に、資産所有者が統合の一部を自前で担うこともあります。 役割は固定的な一対一の割り当てではなく、その場面で「何をしているか」で決まる——この捉え方が、現実の複雑な体 制を正確に映します。 7-3. 説明責任は、資産所有者に固定される 役割は活動で分かれますが、一つだけ、移せないものがあります。それは、IACS（産業用オートメーション・制御システム） をセキュアに運用することへの最終的な説明責任（accountability）です。これは資産所有者に固定されており、他者へ 委譲できません。 供給者や統合者の支援を受けて実装を進めることはできます。むしろ、適切な実装には製品供給者やサービス提供者の 支援が欠かせません。けれども、「自社の IACS と、それが制御する設備を、全体としてセキュアに保つ」という最終的な責 めは、運用する当事者である資産所有者から動きません。だからこそ資産所有者は、調達や契約を通じて、サプライチェー ン全体にセキュリティ要件を織り込む必要があります——どんな製品を選び、どんな統合を求め、どんな運用を約束させる か、を含めて。 「製品の導入」は「規制対応の完了」ではない IEC 62443 に準拠した製品やサービスを導入することは、強い土台になります。しかし、それ自体が NIS2 や CRA への 適合を自動的に完了させるわけではありません。製品が備える能力（SL-C）を、実際の運用環境でどう設定し、どう運用 し、どう記録するか——その結果として達成される水準（SL-A）と、全体の説明責任は、資産所有者の側に残ります。本ガイ ドが「束ねる」と言うのは、あくまで実装と証跡の共通化のことであり、適合判断の代行ではありません。 7-4. FR 別の詳細は、責任分担モデルへ 「では、FR1（識別・認証）のこの部分は供給者の責任で、こちらは資産所有者の責任で……」という要件ごとの細かい線 引きは、本ガイドの範囲を超えます。これは、当社が secomea.co.jp/compliance/iec-62443/ で公開している「IEC 62443 に基づく責任分担モデル」で、FR ごとに整理しています。本章では、その全体像——「責任は活動で分かれ、説明 責任は資産所有者に固定される」——を押さえておけば十分です。詳細を詰める段になったら、責任分担モデルを参照し てください。

まとめ — レジリエンスは「連合」しなければならない 強靭な OT エコシステムは、どれか一社の努力だけでは達成できません。各者が共通のフレームを持たずにそれぞれ最 適化すると、個々には合理的でも、全体としては隙間とリスク（systemic risk）を生みます。IEC 62443 が与えるのは、その 「共通のフレーム」——共通言語と、共有された工学的な規律です。 そして、NIS2 と CRA が施行されたことで、この共通フレームの重要性は一段上がりました。事業者（NIS2）と製品供給者 （CRA）が構造的に接続された以上、レジリエンスはもはや各社の局所的な努力ではなく、エコシステム全体にわたって 「連合（federated）」されなければならないものになったからです。誰がどこを担うのかを、関わる全員が同じ言葉で理解 していること——それが、これからの OT セキュリティの前提です。 では、この責任分担の中で、セキュアリモートアクセスという一つの製品領域は、具体的にどこを、どう担えるのでしょうか。 次の第8章では、第6章で挙げた6つの失敗に立ち返り、それぞれに対する実装例を見ていきます。

C H A P T E R 0 8 Secomea の位置づけ ― IEC 62443 の実装例として 第7章で見たように、責任は活動で分かれ、説明責任は資産所有者に固定されます。そのうえで、この分担の中で 「セキュアリモートアクセス」という一つの製品領域が、具体的にどこを、どう担えるのか。ここでは、第6章で挙げた6 つの失敗に立ち返り、それぞれに対する実装例として見ていきます。Secomea を「売り込む」ためではなく、IEC 62443 の考え方が実際の製品でどう形になるかの一例として読んでください。 8-1. 接続する「一人ひとり」を識別する 共用アカウントの問題（6-1）に対する答えは、接続する人を個人として識別・認証することです。アカウントを共有するので はなく、誰が接続しているのかを一意に特定し、その人に許された操作だけを許可する。これにより、「いつ・誰が・何のた めに接続したか」が、アカウント単位ではなく個人単位で残ります。これは IEC 62443 の識別・認証制御（FR1）と使用制 御（FR2）を、現場の運用に落とした形です。 8-2. ベンダーアクセスを一元的に統制する ベンダーごとに経路が乱立する問題（6-2）には、外部ベンダーのアクセスを一つの統制された基盤に集約することで応 えます。装置メーカー・SIer・保守業者などのアクセスを、バラバラの VPN ではなく中央で定義し、誰がどの機器にアクセ スできるかを棚卸しし、不要になれば失効させる。保守用 PC の持ち込み（6-4）も、この統制された経路の上で作業を完 結させることで、管理外の機器を OT ネットワークに直結させずに済みます。これはゾーン（区画）とコンジット（区画間の通 信経路）およびデータフロー制限（FR5）の考え方に沿うものです。 8-3.「 許可された通信経路（コンジット）」として振る舞う フラットな OT ネットワークの問題（6-3）に対しては、各接続がOT ネットワークへ無制限に入り込むのではなく、許可され た区画（ゾーン）へ、許可された通信経路（コンジット）を通じてのみ到達する設計が効きます。セグメント化された構造の 中で、リモートアクセスそのものが「統制された一つの通信経路（コンジット）」として振る舞う。万一の侵害時にも、被害をそ のゾーンに封じ込めやすくなります。ゾーン設計と FR5 を、遠隔アクセスの側から支える形です。 8-4. 監査に耐える記録を残す ログが IT 側にしかない問題（6-5）には、接続・承認・セッションの記録を残すことで応えます。誰が・いつ・どの機器に・何 の作業のためにつなぎ、何をしたか——を後から辿れるようにする。これは、監査や事故調査はもちろん、第2章で見た NIS2 のインシデント報告や CRA の報告義務（2026年9月開始）に、短い期限で正確に応えるための土台になります。IEC 62443 の事象への適時対応（FR6）に対応します。