Microsoft Defender for Endpoint on iOS featuresで最初に確認すべき結論は、iOS端末へのMicrosoft Defender展開は、アプリ配布だけでは完了しないという点です。Web保護、ネットワーク保護、条件付きアクセス、MAM、プライバシー制御、脆弱性評価は、Microsoft Intuneのアプリ構成ポリシーや端末の管理状態によって挙動が変わります。
2026年6月2日公開・更新の公式情報で特に重要なのは、不審なネットワークをユーザーが信頼済みにする機能の廃止予定、オープンWi-Fi接続時の扱いがアラート中心からデバイスタイムラインイベント中心に変わっている点、そしてWeb保護に使われるローカルVPNの影響です。管理者は、MDM管理端末とMAMのみのBYOD端末を分けて、Intuneポリシー、SOCの検知ルール、ユーザー向け案内を見直す必要があります。(Microsoft Learn)
Microsoft Defender for Endpoint on iOS featuresとは
Microsoft Defender for Endpoint on iOS featuresは、iPhoneやiPadにMicrosoft Defender for Endpointの主要な保護機能を展開・制御するための設定群です。対象はMicrosoft Defender for Endpoint Plan 1およびPlan 2で、主にMicrosoft Intuneを使って構成します。(Microsoft Learn)
iOS向けのDefenderでは、次のような機能を管理できます。
| 機能 | 主な目的 | 管理者が見るべきポイント |
|---|---|---|
| Web保護 | フィッシングや悪意あるWebサイトから保護 | ローカルVPNが必要。VPN無効化時はWeb保護も無効 |
| ネットワーク保護 | 危険なWi-Fiや不審なネットワーク利用を検知 | 2026年6月以降の信頼フロー廃止に注意 |
| 条件付きアクセス | デバイスリスクに応じて社内リソースアクセスを制御 | Intune、Microsoft Entra ID、Defenderの連携が前提 |
| MAM連携 | 未登録端末でもアプリ単位で会社データを保護 | Authenticator登録とアプリ保護ポリシーの設計が重要 |
| プライバシー制御 | フィッシング報告やアプリ情報の収集範囲を制御 | BYODではユーザー同意や説明が必要 |
| 脆弱性評価 | iOSやアプリの脆弱性を可視化 | アプリ評価はMDM管理端末中心に考える |
| 脱獄検出 | Jailbreak端末のリスクを検知 | コンプライアンスポリシーと組み合わせる |
| デバイスタグ | 端末を部門・用途別に分類 | Intuneから設定できるタグは基本的に1つ |
重要なのは、同じ「iOS端末」でも、会社支給端末としてMDM管理しているのか、BYODとしてMAMのみで保護するのかによって使える設定や運用上の注意点が変わることです。
今回の更新で管理者が優先して確認すべき変更点
不審なネットワークをユーザーが信頼済みにする機能は廃止へ
最も影響が大きいのは、DefenderEndUserTrustFlowEnableによって提供されていた、エンドユーザーが不審なネットワークを信頼または信頼解除できるアプリ内体験の廃止です。
公式情報では、この廃止は2026年6月初めから段階的に展開され、約2週間で反映される見込みとされています。新しい挙動では、ユーザーは不審なネットワークを信頼済みにできなくなり、過去に信頼済みにされた不審なネットワークも自動的に未信頼として扱われます。該当ネットワークに接続した場合は、ユーザーにアプリ内通知が表示されます。(Microsoft Learn)
この変更により、次のような運用は見直しが必要です。
| これまでの運用 | 今後の見直しポイント |
|---|---|
| ユーザーに「問題なければ信頼済みにする」と案内していた | ユーザー判断ではなく、管理者ポリシーと通知対応に寄せる |
| ヘルプデスクが「信頼済みに追加してください」と案内していた | 案内文、FAQ、手順書を更新する |
| 信頼済みネットワークを前提に例外運用していた | ネットワーク側の安全性確認、Wi-Fi設計、例外の代替策を確認する |
| SOCが信頼済みネットワークを低リスクとして扱っていた | デバイスタイムラインやネットワーク保護イベントの見方を更新する |
特に、店舗、工場、学校、病院、イベント会場など、現場ごとにWi-Fi環境が異なる組織では注意が必要です。ユーザーが現場判断で「このWi-Fiは安全」と扱えなくなるため、業務用Wi-FiのSSID管理、証明書ベース認証、社内VPNとの併用可否を事前に確認しておくべきです。
オープンWi-Fi接続はアラートではなくデバイスタイムライン中心で確認する
2025年5月19日以降、ユーザーがオープンな無線ネットワークに接続しても、Microsoft Defenderポータル上で従来のようなアラートは生成されなくなりました。代わりに、接続・切断のアクティビティはデバイスタイムライン上のイベントとして確認する形になっています。(Microsoft Learn)
この変更はSOC運用に影響します。たとえば、これまで「オープンWi-Fi接続アラート」をトリガーにチケットを作成していた場合、アラートが上がらないため、検知漏れのように見える可能性があります。実際にはイベントとして記録されるため、確認先と運用ルールを変える必要があります。
また、同じユーザーが24時間以内に同じ種類の接続・切断を繰り返した場合、接続イベントと切断イベントはそれぞれ1件ずつ生成される仕様です。短時間に何度も接続したからといって、その回数分のイベントが並ぶわけではありません。(Microsoft Learn)
GCC環境では従来のアラート動作が適用されるとされているため、商用クラウドと政府機関向けクラウドを併用している組織では、環境ごとの違いも確認してください。(Microsoft Learn)
Web保護とVPNの関係を誤解しない
Microsoft Defender for Endpoint on iOSのWeb保護は既定で有効です。フィッシング対策やURL・ドメインのカスタムインジケーターを利用できますが、iOSではIPベースのカスタムインジケーターはサポートされません。また、WebコンテンツフィルタリングはAndroidとiOSのモバイルプラットフォームでは現在サポートされていません。(Microsoft Learn)
ここで誤解されやすいのがVPNです。iOS版DefenderはWeb保護のためにVPNを使用しますが、これは一般的な外部接続型VPNではなく、端末内で動作するローカルまたはセルフループ型VPNです。通常の意味で通信を社外VPNサーバーへ転送するものではありません。(Microsoft Learn)
ただし、利用者の見え方としては「VPNが構成されている」状態になります。そのため、次のようなケースでは事前検証が必要です。
| 確認項目 | 起きやすい問題 | 対応の考え方 |
|---|---|---|
| 既存の社内VPNアプリ | iOSでは複数のデバイス全体VPNを同時に有効化できない | どのVPNがアクティブになるかを実機で確認する |
| 金融・業務アプリ | VPN構成がある端末でアプリが動作しない場合がある | 対象アプリを洗い出してパイロット配布する |
| BYOD端末 | ユーザーがVPN許可を嫌がりオンボーディングが止まる | optional VPN permissionの利用を検討する |
| ユーザー操作 | VPNを無効化するとWeb保護も無効になる | ヘルプデスク向けに説明文を用意する |
Web保護を無効にする場合は、Intuneのアプリ構成ポリシーでWebProtection = falseを設定します。MDM管理端末では「Managed devices」、MAMのみの未登録端末では「Managed apps」から設定します。(Microsoft Learn)
注意点は、Web保護を無効化してもDefenderの他の機能がすべて止まるわけではないことです。一方で、フィッシング対策やWeb脅威からの保護という重要な保護層は失われます。業務アプリとの互換性だけを理由に一律無効化するのではなく、対象グループを限定して検証するのが現実的です。
ネットワーク保護の設定で確認すべきキー
ネットワーク保護は既定で有効です。MDM管理端末とMAM端末のどちらにも構成できますが、公式情報では、ネットワーク保護ポリシーはMDMまたはMAMのどちらか一方で作成する必要があるとされています。また、初期化にはエンドユーザーが一度Microsoft Defenderアプリを開く必要があります。(Microsoft Learn)
主な設定キーは次のとおりです。
| 設定キー | 既定値 | 用途 | 管理上の注意 |
|---|---|---|---|
DefenderNetworkProtectionEnable | true | ネットワーク保護の有効・無効 | falseで無効化。原則は有効のまま検証する |
DefenderOpenNetworkDetection | 2 | オープンネットワーク検出 | 0は無効、1は監査、2は有効 |
DefenderEndUserTrustFlowEnable | false | ユーザーによる信頼・信頼解除体験 | 2026年6月から廃止予定。新規設計で依存しない |
DefenderNetworkProtectionAutoRemediation | true | 修復アクションに関するアラート制御 | オープンWi-Fi検出そのものには適用されない点に注意 |
DefenderNetworkProtectionPrivacy | true | ネットワーク保護のプライバシー制御 | 収集データや同意表示に影響する |
実務では、まずDefenderOpenNetworkDetectionを監査モードにしてイベント量や誤検知傾向を確認し、その後に有効化する方法が安全です。いきなり全社展開すると、出張者や店舗勤務者から「いつものWi-Fiで警告が出る」と問い合わせが増える可能性があります。
MDMとMAMのどちらで展開するべきか
Microsoft Defender for Endpoint on iOS featuresは、Intuneに登録済みのMDM端末だけでなく、未登録端末に対するMAM構成にも対応しています。MAMでは、Defenderのリスク信号をIntuneのアプリ保護ポリシーで利用し、未登録端末からの会社データアクセスをアプリ単位で制御できます。(Microsoft Learn)
選び方は次のとおりです。
| 展開方式 | 向いている端末 | 強み | 注意点 |
|---|---|---|---|
| MDM | 会社支給iPhone、監督対象端末、厳格に管理したい端末 | 端末全体の制御、コンプライアンス、脆弱性評価と相性がよい | VPNやプライバシー設定を含め、ユーザー影響を検証する必要がある |
| MAM | BYOD、外部委託先、端末登録を避けたい利用者 | 会社データをアプリ単位で保護できる | Authenticator登録やアプリ保護ポリシー設計が重要 |
| MDM + MAM | 会社支給端末でアプリデータ保護も強化したい場合 | 端末管理とアプリ保護を組み合わせられる | ポリシーの重複、例外グループ、ユーザー体験を整理する必要がある |
開発者が関係するのは、主に業務アプリや社内アプリをMAM対象にする場合です。Intuneのアプリ保護ポリシーは、Intune SDKに対応したアプリやApp Wrapping Toolでラップされたアプリを前提に管理されます。社内アプリでコピー制御、共有制御、条件付き起動を使う場合は、アプリ側の対応状況を確認してください。(Microsoft Learn)
プライバシー制御はBYOD展開で必ず説明する
iOS版Defenderでは、フィッシング検出時の報告にドメイン名を含めるかどうかを制御できます。DefenderExcludeURLInReport = trueを設定すると、フィッシングサイトが検出・ブロックされた場合でも、フィッシングアラートにドメイン名を含めない動作になります。(Microsoft Learn)
この設定は、MDM管理端末とMAM端末の両方で構成できます。特にBYODでは、セキュリティ部門が必要とする可視性と、従業員のプライバシー期待値のバランスを取ることが重要です。
監督対象デバイスでは、エンドユーザー側のプライバシーコントロールは表示されず、管理者が設定を制御します。一方、非監督対象デバイスでは、管理者が許可している場合にMicrosoft Defenderアプリの設定内でユーザーが情報共有を選べます。プライバシー制御のオン・オフは、デバイスコンプライアンスチェックや条件付きアクセスには影響しないとされています。(Microsoft Learn)
運用上は、次のような説明を事前に用意しておくと問い合わせを減らせます。
| 説明すべき内容 | ユーザーに伝える表現例 |
|---|---|
| ローカルVPNの目的 | 「通信を外部VPNに転送するためではなく、危険なWebサイトを検出するために端末内で使います」 |
| 収集される情報 | 「組織の設定により、危険サイト情報やアプリ情報の共有範囲が変わります」 |
| VPNを無効化した場合 | 「DefenderのWeb保護が働かなくなるため、業務データ保護に影響する場合があります」 |
| BYODでの同意 | 「端末全体を管理するのではなく、会社データを扱うアプリの保護を目的としています」 |
Optional VPN PermissionはBYOD展開の摩擦を下げるが、保護低下に注意
DefenderOptionalVPNを使うと、MDM管理端末でVPN権限を必須にせず、ユーザーがVPN許可をスキップした状態でもオンボーディングを進められます。これは、BYOD端末への展開で「VPN許可が心理的なハードルになる」場合に有効です。(Microsoft Learn)
ただし、VPNをスキップしても端末のオンボーディングやハートビート送信は可能ですが、VPNが無効である間はWeb保護が有効になりません。後からユーザーがアプリ内でWeb保護を有効にすると、VPN構成がインストールされます。(Microsoft Learn)
ここで混同しやすいのが、DefenderOptionalVPNとWebProtection = falseの違いです。
| 設定 | 目的 | 後からWeb保護を有効化できるか |
|---|---|---|
DefenderOptionalVPN = true | 初回オンボーディング時にVPN許可をスキップ可能にする | できる |
WebProtection = false | Web保護そのものを無効化して展開する | 基本的にユーザー側では後から有効化できない |
展開設計では、「VPN許可を一時的に後回しにする」のか、「Web保護を組織方針として無効化する」のかを明確に分けてください。
脱獄検出とコンプライアンスポリシーはセットで確認する
Microsoft Defender for Endpoint on iOSは、管理対象・非管理対象のiOS端末に対してJailbreak検出を行います。端末が脱獄状態と判断された場合、高リスクアラートがMicrosoft Defenderポータルに報告され、デバイスリスクスコアを使ったコンプライアンスや条件付きアクセスが構成されていれば、会社データへのアクセスをブロックできます。(Microsoft Learn)
また、脱獄検出時にはアプリ内のユーザーデータがクリアされ、ユーザーがアプリを開いた際にDefender for EndpointのループバックVPNプロファイルも削除されます。ただし、Intuneから配布されたVPNプロファイルは削除されません。(Microsoft Learn)
管理者は、IntuneのコンプライアンスポリシーでiOS/iPadOSを対象にし、Device HealthのJailbroken devicesをBlockに設定する運用を検討してください。Defender側の検出だけに頼るのではなく、条件付きアクセスと組み合わせることで、実際のアクセス制御までつなげられます。
カスタムインジケーターはURL・ドメイン中心で設計する
iOS版Defenderでは、カスタムインジケーターを使ってURLやドメインを制御できます。ただし、iOSではIPベースのカスタムインジケーターはサポートされません。(Microsoft Learn)
また、URLやドメインをインジケーターに設定してアクセスされた場合でも、iOSではMicrosoft Defenderポータルにアラートが生成されないとされています。未監督デバイスでは、プライバシーの観点からMDEポータルのTimelineにカスタムURLインジケーターブロックのURLが表示されず、非表示として扱われます。(Microsoft Learn)
実務では、Windows向けDefenderのインジケーター設計をそのままiOSへ流用しないことが重要です。特に、IPアドレスによるブロック、詳細URLパス単位の調査、アラート自動生成を前提にしたSOC手順は、iOS側の仕様と合わない場合があります。
脆弱性評価は「OS」と「アプリ」で対象範囲が違う
Microsoft Defender for Endpoint on iOSは、iOSバージョンとアプリの脆弱性評価に対応しています。ただし、iOSバージョンの脆弱性評価はMDM管理端末とMAM端末の両方で利用できる一方、アプリの脆弱性評価はMDM管理端末が対象です。(Microsoft Learn)
アプリの脆弱性評価を有効にするには、Intune管理センターでEndpoint Security > Microsoft Defender for Endpointから、iOS/iPadOSデバイス向けのApp syncを有効化します。非監督デバイスでアプリ一覧を収集する場合は、DefenderTVMPrivacyModeの設定やユーザー承認が関係します。(Microsoft Learn)
注意したいのは、データがすぐに反映されるとは限らない点です。対象端末にクライアントバージョンが展開された後、脆弱性情報の処理には数時間、アプリ一覧全体の反映には最大24時間程度かかる場合があります。(Microsoft Learn)
SSLインスペクションを利用している環境では、脅威と脆弱性管理機能が動作するよう、商用環境ではsecuritycenter.windows.com、GCC環境ではsecuritycenter.windows.usの扱いを確認してください。(Microsoft Learn)
展開前に確認したい主要設定キー
Microsoft Defender for Endpoint on iOS featuresでは、設定キーの型や既定値を間違えると、意図した動作になりません。Intuneの構成プロファイルを作成する際は、キー名だけでなく、String、Boolean、Integerの違いも確認してください。
| 設定キー | 値の型 | 主な用途 | 既定値・注意点 |
|---|---|---|---|
WebProtection | String | Web保護の有効・無効 | 既定はtrue。falseで無効 |
DefenderNetworkProtectionEnable | String | ネットワーク保護の有効・無効 | 既定は有効 |
DefenderOpenNetworkDetection | Integer | オープンネットワーク検出 | 0無効、1監査、2有効 |
DefenderEndUserTrustFlowEnable | String | ユーザー信頼フロー | 廃止予定のため新規運用で依存しない |
DefenderNetworkProtectionAutoRemediation | String | 修復通知関連 | 既定はtrue |
DefenderNetworkProtectionPrivacy | String | ネットワーク保護のプライバシー | 既定はtrue |
DefenderExcludeURLInReport | Boolean | フィッシング報告からドメイン名を除外 | 既定はfalse |
DefenderOptionalVPN | Boolean | VPN許可を任意化 | 既定はfalse。MDM管理端末向け |
DefenderTVMPrivacyMode | String | アプリ脆弱性評価のプライバシー | 非監督端末では既定True |
DisableSignOut | String | Defenderアプリからのサインアウト抑止 | trueでサインアウトボタン非表示 |
DefenderDeviceTag | String | デバイスタグ付与 | Intuneから反映できるタグは基本1つ |
SuppressOSUpdateNotification | String | OS更新通知の抑止 | trueで通知を抑止 |
DefenderFeedbackData | Boolean | アプリ内フィードバック送信可否 | 既定はtrue。US Governmentでは既定false |
DisableSignOutは、ユーザーがDefenderアプリからサインアウトして保護を回避するリスクを下げる設定です。会社支給端末や高リスク業務端末では有効化を検討する価値があります。(Microsoft Learn)
DefenderDeviceTagは、オンボーディング時に端末へタグを付け、Microsoft Defenderポータルのデバイスインベントリで分類しやすくするための設定です。ただし、Intuneから複数タグを構成しても反映されるタグは1つとされており、Defenderアプリを開かないと同期されません。反映まで最大18時間かかる場合がある点も見落としやすいポイントです。(Microsoft Learn)
管理者向けの展開手順
Microsoft Defender for Endpoint on iOS featuresを安全に展開するには、次の順番で進めると失敗を減らせます。
| 手順 | 実施内容 | 確認ポイント |
|---|---|---|
| 端末分類 | MDM、MAM、監督対象、非監督対象、BYODを分ける | 同じiOSでも適用可能な機能が違う |
| 既存VPN確認 | 社内VPN、ゼロトラスト製品、業務アプリのVPN制限を確認 | iOSでは同時に有効なデバイス全体VPNは1つ |
| Intune連携確認 | DefenderとIntune、MAM利用時のAuthenticator登録を確認 | 条件付きアクセスやAPP連携の前提 |
| ポリシー設計 | Web保護、ネットワーク保護、プライバシー、通知を決める | MDM/MAMでネットワーク保護ポリシーを重複させない |
| パイロット配布 | 情シス、営業、現場部門など複数パターンで試す | Wi-Fi警告、VPN影響、アプリ互換性を見る |
| ユーザー案内 | VPN表示、通知、プライバシー、問い合わせ先を説明 | 「VPN＝通信監視」と誤解されやすい |
| SOC運用更新 | オープンWi-Fi関連の検知先を見直す | アラートではなくタイムラインイベント中心 |
| 本番展開 | グループ単位で段階展開 | 反映遅延、アプリ未起動端末、タグ同期を監視 |
特に重要なのは、アプリ配布後にユーザーがDefenderアプリを開く必要がある設定があることです。ネットワーク保護の初期化、ハートビート送信、デバイスタグ反映などは、単にアプリをインストールしただけでは完了しない場合があります。(Microsoft Learn)
開発者・アプリ担当者が確認すべきポイント
開発者が直接Defenderの設定キーを管理しない場合でも、MAMやアプリ保護ポリシーを利用する組織では、業務アプリ側の検証が必要です。
確認すべきポイントは次の3つです。
まず、社内アプリがIntune SDKやApp Wrapping Toolに対応しているかを確認します。MAMでは会社データのコピー、保存、共有、条件付き起動などをアプリ単位で制御するため、アプリ側がIntuneの管理対象として正しく動作しなければ、期待した保護が効きません。(Microsoft Learn)
次に、VPN構成がある端末でアプリが正常に動作するかを確認します。特定の金融系、認証系、ネットワーク制御系アプリでは、VPN構成があるだけで動作に影響することがあります。DefenderのVPNはローカルVPNですが、アプリ側が「VPNが有効な端末」と判定する可能性はあります。
最後に、条件付きアクセスやアプリ保護ポリシーでブロックされた場合のユーザー体験を確認します。たとえば、OutlookやTeamsなどの管理対象アプリからDefenderのインストールやオンボーディングを促す導線が発生する場合、ユーザーに何が表示されるかをヘルプデスクと共有しておくと、問い合わせ対応が早くなります。
展開時に失敗しやすいポイント
Microsoft Defender for Endpoint on iOS featuresの展開でよくある失敗は、機能そのものではなく、前提条件とユーザー体験の見落としです。
| 失敗しやすいポイント | 何が起きるか | 対策 |
|---|---|---|
| MDMとMAMでネットワーク保護ポリシーを重複作成する | 想定外の設定競合や管理の混乱が起きる | どちらで管理するかを端末分類ごとに決める |
| VPNを嫌がるユーザーへの説明がない | オンボーディングが止まる、VPNを無効化される | ローカルVPNの目的を事前に説明する |
| Defenderアプリ未起動端末を見落とす | ネットワーク保護やタグが反映されない | 配布後に初回起動を促す |
| オープンWi-Fiのアラート廃止をSOCが知らない | 「検知されていない」と誤判断する | デバイスタイムライン確認に運用を変更する |
| 旧手順書に「信頼済みにする」と書かれている | 廃止後にユーザーが操作できず混乱する | FAQ、ヘルプデスク台本、教育資料を更新する |
| プライバシー設定を説明しない | BYOD利用者から不信感を持たれる | 収集情報、同意、端末管理範囲を明文化する |
| 反映時間を考慮しない | タグや脆弱性情報が表示されず設定ミスと誤認する | 最大24時間程度の遅延を見込んで確認する |
すぐに実施すべき確認リスト
既にiOS向けDefenderを展開している管理者は、まず次の項目を確認してください。
DefenderEndUserTrustFlowEnableに依存した運用や手順書が残っていないか- オープンWi-Fi接続をアラート前提で監視していないか
- MDMとMAMの両方でネットワーク保護ポリシーを作成していないか
- Web保護を無効化しているグループと理由を把握しているか
- 既存VPNや業務アプリとDefenderのローカルVPNが競合しないか
- BYOD向けにVPN、プライバシー、Authenticator登録の説明を用意しているか
- Defenderアプリの最新バージョンが対象端末に展開されているか
- SOC、ヘルプデスク、アプリ開発担当に今回の変更点を共有しているか
- デバイスタグや脆弱性評価の反映遅延を考慮して検証しているか
新規展開の場合は、全社一斉展開ではなく、会社支給端末、BYOD、現場Wi-Fi利用者、出張者などを含む小規模なパイロットグループから始めるのが安全です。Microsoft Defender for Endpoint on iOS featuresは保護機能が多い分、設定の粒度も細かくなっています。まずは端末の管理状態を分類し、Web保護とネットワーク保護の方針を決め、ユーザーが迷わない説明を用意することが、安定展開への近道です。
コメント