こんにちは、IDチームのTamaduです。
「Okta Identity Threat Protection（ITP）を検討したいが、自社利用SaaSでどこまで効くか分からない」というご相談をいただきます。
本記事では2026年時点の対応SaaSマップと採用判断のポイントを整理しました。
結論サマリー（TL;DR）
- Okta Identity Threat Protection（ITP）とは、ログイン後のセッションを継続的に評価し、リスク変化に応じてセッション終了やステップアップ認証などを自動実行する機能です［出典: Okta公式ドキュメント / https://help.okta.com/oie/en-us/content/topics/itp/overview.htm ］。提供面では、現行のOkta公式Pricing上、ITPは Professional / Enterprise スイートに含まれ、Core Essentials / Essentials では Add-on として提供されます（Starterは対象外）［出典: Okta公式Pricing / https://www.okta.com/pricing/ ］。
- 2026年時点で、Universal LogoutはBox / Google Workspace / Microsoft 365（部分対応）/ Salesforce / Slack Enterprise Grid / Zoom / Dropbox for Business / Splunk / Zendesk など主要SaaSに広がりましたが、依然としてSaaSごとの実装差・部分対応が残ります［出典: Okta公式 / https://help.okta.com/oie/en-us/content/topics/itp/universal-logout-supported-third-party-apps-list.htm ］。
- 採用判断の最大ポイントは「自社で利用中のSaaSが Full / Partial のどちらに該当するか（または未対応か）」と「Federation Broker Modeを併用していないか」の2点です。これを満たさない場合、ITP契約後も期待した『一斉ログアウト』が成立しません。
- 2026年前半のリリースノートでは、Detection settings in session protection の GA in Production、Linux as a platform condition の GA in Preview、Express Submission in the OIN Wizard（SaaSベンダーがAuth0対応アプリをOINへ効率的に提出可能に）など、ITP周辺の運用機能が継続的に強化されています［出典: Okta API release notes 2026 / https://developer.okta.com/docs/release-notes/2026-okta-identity-engine/ ］。
1. 想定読者と、この記事で分かること
本記事は、Okta Workforce Identityをすでに運用している、もしくは導入検討中の以下のような方を想定しています。
- IDaaS運用担当・情シス：セッションハイジャックや盗難クッキー対策を強化したいが、ITPの追加投資価値を社内で説明しきれない。
- SOC・セキュリティ運用担当：EDRやSIEMの脅威シグナルをIDaaS側のアクションに繋ぎたい。
- セキュリティアーキテクト：ITPと既存のAdaptive MFA・Device Assurance・Workflowsの棲み分けを設計したい。
読み終えると、ITP導入を「主要利用SaaSが対応していて契約する価値があるか/ないか」「Federation Broker Modeをどう扱うか」までを根拠を持って判断できる状態を目指します。
2. Okta Identity Threat Protection（ITP）とは
Okta Identity Threat Protection（ITP）とは、Okta IDの利用文脈を継続的に評価し、リスク変化に応じて自動的に保護アクションを実行する機能群です。具体的にはログイン時点だけでなくログイン後のセッション中も、ユーザーリスク・エンティティリスクを評価し続けます［出典: Okta / https://help.okta.com/oie/en-us/content/topics/itp/overview.htm ］。
主な構成要素は次の3つです。
| 機能 | 役割 |
|---|---|
| Entity Risk Policy | ユーザー・グループ・リスクレベル別に、自動アクション（セッション終了、MFA要求、Workflow起動、Universal Logout 等）を定義する |
| Session Protection Policy | セッション中のリスク条件変化（IP変動、デバイス変動、シグナル受信など）に応じた動作を定義する |
| Universal Logout | リスク検知時に対応SaaS横断でセッション・トークンを一括失効する |
ITPはOkta独自のAIで挙動分析を行うほか、外部EDRやIdPからのリスクシグナル（Shared Signals Framework / CAEP）受信にも対応します。
3. Universal Logout の対応SaaS最新マップ（2026年）
Universal Logoutとは、ITPがリスクを検知したときに、対応SaaSと対応デバイスでセッションとトークンを横断的に終了させる仕組みです［出典: Okta / https://help.okta.com/oie/en-us/content/topics/itp/universal-logout.htm ］。Okta公式のサポート一覧では、対応状況は Full Universal Logout support と Partial Universal Logout support の2区分に分かれます（2026年6月時点でFullは15アプリ、PartialはMicrosoftスタックほか計11グループ）。なお、ITPを有効化しておらずAdaptive MFAのみの組織では、Universal Logoutは管理コンソールからの手動実行かつレートリミット付きとなりますが、これは対応区分ではなく実行方式の制約であり、Full/Partialとは分けて理解する必要があります。
3.1 Full Universal Logout 対応（主要SaaS抜粋）
| SaaS | 備考 |
|---|---|
| Box | Secure Identity Integration（SII）対応 |
| Dropbox for Business | SII対応／devices API でセッション失効 |
| Google Workspace ＋ Google Cloud Platform | 共通アイデンティティスタック。片方のトリガーで両方失効 |
| Salesforce | SII対応／AuthSession API 利用 |
| Slack（Enterprise Grid のみ） | SII対応／admin.users.session.reset 利用 |
| Splunk | SII対応 |
| Zoom | SII対応／SSOトークンを失効 |
| Zendesk | Delete Session API 利用 |
| Cerby / Island / PagerDuty / Salto / Surf | 各社の Universal Logout 連携あり |
（出典: Third-party apps that support Universal Logout）
本表は主要SaaSの抜粋です。2026年6月時点の公式Full一覧は15アプリで、上記のほか Sastrify・Zerocater 等も含まれます。最新かつ完全な一覧はOkta公式表をご確認ください。
3.2 Partial Universal Logout（Microsoftスタック中心。その他SaaSも一部対応）
Okta公式一覧では、Microsoftスタックに加えて Archlet / BetterLogiq / Brellium / Cleo Health / Doppel / Exabeam / Lyster / OX Security / Safety AZ / Svix も Partial Universal Logout に分類されています（2026年6月時点。各SaaSの個別挙動は公式一覧の最新Notesを確認してください）。本記事では、日本企業で影響が大きく設計上の誤解が起きやすい Microsoft スタックを中心に説明します。
Microsoft 365 / Azure Portal / Defender for Cloud Apps / Defender for Endpoint / Defender for Office 365 / Dynamics 365 / Power BI / Power Platform / Sentinel / Visual Studio / SQL Server Management Studio は同一アイデンティティスタック扱いで、Universal Logoutはリフレッシュトークンの失効までしか行わず、既存のアクセストークンが期限切れになるか明示的サインアウトされるまでユーザーセッションは継続します［出典: Okta / 同上 ］。
この仕様は、Microsoft側のRevoke user accessの制約に由来するもので、Okta側の不具合ではありません。「Microsoft 365もITPで止められる」と一足飛びに説明すると現場で齟齬を生む典型ポイントです。
3.3 AMFA単独・カスタム連携の制約
- ITPを契約しておらずAdaptive MFA（AMFA）のみの場合、Universal Logoutは『管理コンソールからの手動実行のみ』かつレートリミット付きとなります［出典: Okta / https://help.okta.com/oie/en-us/content/topics/apps/universal-logout-amfa.htm ］。
- Federation Broker Modeを有効にしたカスタムSAML/OIDCアプリでは Universal Logout が動作しません。明示的ユーザー割り当てを使う必要があります［出典: Okta / https://help.okta.com/oie/en-us/content/topics/itp/config-universal-logout.htm ］。
- 汎用SAML/OIDCアプリと連携する場合、対象アプリは Global Token Revocation 仕様 + Signed JWT 認証に対応している必要があります［出典: Okta / 同上 ］。
3.4 周辺の進化
ITP と周辺機能の進化を時系列で整理します。
EA = Early Access(早期アクセス) / GA in Preview = Preview環境一般提供 / GA in Production = 本番環境一般提供
| 時期 | 機能 | ステータス | 概要 |
| 2025.02 | Auth0 × Okta Universal Logout 連携 | GA | Auth0配下アプリへの一斉ログアウトが可能に |
| 2026.02 | Session Protection - Detection settings | GA in Preview | セッション保護の検出設定が Preview 環境で利用可 |
| 2026.02 | Linux as a platform condition | GA in Preview | プラットフォーム条件に Linux が追加 |
| 2026.02 | Okta as a fallback IdP | self-service EA in Preview | 一次IdP失敗時に Okta をフォールバック先に |
| 2026.04 | Session Protection - Detection settings | GA in Production | 本番環境への一般提供到達（リリースノート2026.04.0掲載。Expected in Preview Orgs列は2025-12-10表記） |
| 2026.04 | ITP managed with Terraform | GA | Okta Terraform ProviderでITP設定をIaC管理可能に |
| 2026.05 | Identity claims sourcing policy（Reauthentication to an IdP） | self-service EA in Preview | フェデレーションユーザーを最新の有効なSSO IdPへ再認証させる |
| EA中(時期未定) | Bot Protection | Early Access | ITP配下のボット検知・対処機能 |
(出典:Auth0公式ブログ 2025-02-05 / Okta API release notes 2026 / Okta Bot Protection )
Auth0連携により、Auth0側でGlobal Token Revocationエンドポイントを自前実装する必要はなくなりました。ただし、アプリ固有のWebセッションを即時終了させるには、OIDC Back-Channel Logout等の設計・実装が必要になる場合があります。
Bot Protection は ITP の機能拡張として開発中で、GA時期は公式に未発表です。本番運用での採用検討時はロードマップ確認が必要です。
4. 採用判断の5ステップ
以下を順に確認すれば、ITP/Universal Logoutを「採用する／待つ／別の方法で代替する」の判断ができます。
- 自社利用SaaS棚卸し：Okta連携している全SaaSをリスト化し、Full / Partial / 未対応 / カスタムSAMLの4分類で色分けする。
- Federation Broker Mode利用有無の確認：使っているカスタムアプリでBroker Modeを有効化していると、Universal Logoutは効きません。
- Microsoftスタックの扱い決め：Partial対応であることを前提に、Conditional AccessのSign-in frequencyやContinuous Access Evaluationと組み合わせるかを設計する。
- 連携元シグナルの設計：CrowdStrike Falcon、Microsoft Entra、Google Workspaceなど、どこからリスクシグナルを取り込みたいかを明確化する（Shared Signals / CAEP対応）。
- 段階展開計画：Okta社自身は、基盤設定→監視のみ（monitoring-only）→主要な高リスクアプリへのUniversal Logout適用、という段階で展開したと説明しています［出典: Okta / https://www.okta.com/blog/product-innovation/adopting-okta-identity-threat-protection/ ］。全社一律への拡大は各社の判断として切り分けつつ、本記事でも監視から限定適用へ進める段階展開を推奨します。
5. 弊社の観点：日本企業の導入判断で繰り返し出る論点
クラウドネイティブが国内のOkta導入・運用支援で繰り返し受ける相談を抽象化すると、以下のパターンが典型です（具体的な顧客・案件は記載していません）。
- 「対応SaaSが自社の主要業務SaaSに足りない」：特に国産SaaSや業界特化SaaS。短期的には、Workflowsで擬似的なロックダウン（パスワードリセット＋セッション失効）を組むほうが現実的な場合があります。
- 「Microsoft 365が事実上の業務基盤」：Partial対応であるため、Entra IDのCAE設定、Conditional Access、Defender for Cloud AppsのSession Policyを併用する設計が必要です。
- 「ADを残したままITPを始めたい」：ADとの並行運用は技術的には可能です。弊社の支援経験では、重要SaaSの認証・認可判断をOktaに集約しているほど、セッション保護やEntity Risk Policyの設計効果を説明しやすくなる傾向があります。AD廃止計画と併せて検討することをおすすめします。
- 「ITPは入れたいがコストが説明しづらい」：『EDRが入っているのに、IDレイヤーは静的なまま』という現状リスクを示すと経営層への説明が通りやすい傾向があります。
6. 提供形態とコスト
ITPの提供形態は次のとおりです（2026年6月時点・Okta公式Pricing）。
- Professional / Enterprise スイートに標準付属（両スイートとも個別見積）
- Core Essentials / Essentials では Add-on として提供（Starterは対象外）
| プラン | ITP |
|---|---|
| Starter | 対象外（—） |
| Core Essentials / Essentials | Add-on として提供 |
| Professional | 標準付属 |
| Enterprise | 標準付属 |
ITPはOkta公式Pricing上、Professional / Enterprise スイートに含まれます（2026年6月時点。両スイートとも個別見積）。Starter（$6/user/月）は対象外、Core Essentials（$14/user/月）/ Essentials（$17/user/月）では Add-on として表示されています。なお、ITP一般提供（2024年8月）時点の公開list priceは $4/user/月（米ドル）でしたが、現行Pricingページには単体価格として掲載されていません。国内価格・最小契約条件はOkta社または販売代理店にご確認ください。ITPの利用には Okta Identity Engine・Universal Directory・SSO・Adaptive MFA が前提です。
7. まとめ：次のアクション
- まず自社のOkta連携SaaSを Full / Partial / 未対応 でラベル付けしてください。これだけでITPの効き目は8割見えます。
- Federation Broker Modeの棚卸しを行い、ITP導入後にUniversal Logoutが効かないアプリを特定してください。
- Microsoftスタックの扱いはEntra側のCAE/Conditional Accessとの併用設計を前提に進めてください。
- 段階展開（監視のみ → 限定的な高リスクアプリでの自動ログアウト → 必要に応じて対象拡大）で運用負荷とリスクをコントロールしてください。
8. FAQ
Q1. Okta Identity Threat Protectionは、Adaptive MFAでもある程度代替できますか？
A. ログイン時の動的MFA要求まではAMFAで可能ですが、ログイン後の継続的なセッション評価と、対応SaaSへの自動Universal Logoutは ITP の専用機能です。AMFAではUniversal Logoutを手動かつレートリミット付きでしか実行できません［出典: Okta / https://help.okta.com/oie/en-us/content/topics/apps/universal-logout-amfa.htm ］。
Q2. Universal LogoutでMicrosoft 365もログアウトされますか？
A. Partial対応です。リフレッシュトークンは即失効しますが、既存アクセストークンが期限切れになるかユーザーが明示的にサインアウトするまでセッションは継続します［出典: Okta / https://help.okta.com/oie/en-us/content/topics/itp/universal-logout-supported-third-party-apps-list.htm ］。
Q3. 国産SaaSを Universal Logout 対応にするにはどうしたら良いですか？
A. 対象アプリ側で Global Token Revocation 仕様への対応 と Signed JWT 認証を実装する必要があります。Okta側だけでは対応できません［出典: Okta / https://help.okta.com/oie/en-us/content/topics/itp/config-universal-logout.htm ］。
Q4. Federation Broker Modeを使い続けたいのですが、共存できますか？
A. Federation Broker Modeを有効にしたカスタムSAML/OIDCアプリではUniversal Logoutは動作しません。明示的ユーザー割り当てへの切り替えが必要です［出典: Okta / 同上 ］。
Q5. Auth0配下のアプリにも効きますか？
A. はい。Auth0はOkta Workforce IdentityのUniversal Logout連携を一般提供しています。Auth0側でGlobal Token Revocationエンドポイントを自前実装する必要はありません。ただし、アプリ固有のWebセッションを即時終了させたい場合は、OIDC Back-Channel Logout等の設計・実装が必要になることがあります［出典: Auth0 / https://auth0.com/blog/okta-universal-logout-integration-now-supported-in-auth0/ ］。
9. 参考リンク（一次情報）
- Identity Threat Protection with Okta AI（Okta公式）
- Universal Logout（Okta公式）
- Third-party apps that support Universal Logout（Okta公式）
- Configure Universal Logout for supported apps（Okta公式）
- AMFA環境でのUniversal Logout（Okta公式）
- Okta Identity Engine API release notes 2026（Okta公式）
- Okta社の自社ITP導入レポート（Okta公式ブログ 2025-10-16）
- Auth0 が Okta Universal Logout 連携を一般提供（Auth0 公式ブログ 2025-02-05）
