はじめに
こんにちは、IDチームのTamaduです。
Okta Verify authenticator を FastPass・プッシュ・TOTP の3つの認証方法ごとに制御できるようにする「Flexible Okta Verify authenticator configuration」が、2026年8月12日からセルフサービス早期アクセス（EA）として提供されています。Okta からの通知では、2027年第1四半期に一般提供（GA）を開始し、GA 時にすべてのテナントへ自動的に有効化する予定とされています。正確な GA 日は未定です。一度有効化すると従来の Okta Verify authenticator の構成が恒久的に置き換えられ、管理者自身では無効化できません。元の構成に戻したい場合は、Okta サポートへの問い合わせが必要です。
変更内容そのものは公式ドキュメントに整理されているので、本記事は実際に検証環境で有効化して確かめた結果を中心に、既存ユーザーへの影響、グループごとの登録ポリシー設定例、有効化前のチェックリストをまとめます。
3行まとめ
- Okta Verify が FastPass・プッシュ・TOTP の3つの Authenticator に分かれ、グループ単位で必須 / オプション / 無効を個別指定できるようになります。現在はセルフサービス EA で、2027年第1四半期の GA 時にすべてのテナントへ自動的に有効化される予定です。EA 期間中に一度有効化すると、従来の構成には管理者自身で戻せません。
- 検証環境で有効化し、既存の Okta Verify 登録を維持したままサインインできることと、登録ポリシーでプッシュを無効化・再有効化したときの挙動を確認しました。
- 確認した挙動をもとに、グループごとの登録ポリシー設定例と、有効化前にやっておくことをまとめます。
そもそも何が変わるのか
これまで Authenticator 登録ポリシー上で単一の Authenticator だった Okta Verify が、次の3つに分かれます。
- Okta Verify：Okta FastPass
- Okta Verify：プッシュ通知
- Okta Verify：TOTP
従来、認証方法ごとの有効・無効は Okta 組織（org）全体の Okta Verify 設定でしか制御できませんでしたが、変更後は登録ポリシーでグループ単位で必須 / オプション / 無効（Required / Optional / Disabled）を指定できます。
有効化時の初期設定には、注意点が2つあります。まず、自動変換の対象は Okta Verify を「必須」にしているポリシーだけで、「オプション」または「無効」のポリシーは影響を受けません。そして、変更結果は「有効化前に org 全体の Okta Verify 設定でどの検証オプション（Okta FastPass / プッシュ通知 / TOTP）を有効にしていたか」によって変わります。公式ドキュメントでは、次の4パターンが示されています。
| 以前の Okta Verify の方法 | Okta Verify - Okta FastPass | Okta Verify - プッシュ通知 | Okta Verify - TOTP |
|---|---|---|---|
| Okta FastPass、プッシュ通知、TOTP | 必須 | オプション | オプション |
| プッシュ通知、TOTP | 無効 | 必須 | オプション |
| Okta FastPass、TOTP | 必須 | 無効 | オプション |
| TOTP のみ | 無効 | 無効 | 必須 |
表からは、有効だった方法のうちフィッシング耐性が最も高いものが「必須」、残りが「オプション」という規則性が読み取れます（規則自体は公式に明記されていません）。
本記事の検証環境は1行目に該当し、実機でも表のとおりでした。他の3パターンは未検証のため、自組織がどの行かは事前に org 全体の Okta Verify 設定で確認してください。
検証結果
冒頭のとおり、この EA 機能は有効化後に管理者自身で無効化できません。有効化時の確認ダイアログにも「To roll back, contact Okta Support.」と明記されていました。
有効化したら何がどう変わるか
Authenticator 一覧は「独立した3つの並び」ではなく「親子構造」になる
有効化後に［セキュリティ］>［Authenticator］の Setup タブを開くと、Okta Verify は完全に独立した3つの Authenticator に分かれるのではなく、親の「Okta Verify」の下に「Okta Verify - Okta FastPass / Push / TOTP」がぶら下がる階層表示になりました。Actions メニューは親の行にのみ存在し、子の3つの認証方法には個別の Actions がありません。
有効化前は、Okta Verify は1行で表示されていました。
有効化後は次のようになります。
また、Status は3つの認証方法とも Active でした。今回の環境では、有効化前の org 設定で FastPass、プッシュ通知、TOTP のすべてを有効にしていたため、その状態が引き継がれたものと考えられます。
初期マッピングは公式記載どおり
登録ポリシー側を確認すると、表の1行目のとおり、Okta Verify を「必須」にしていたポリシーは FastPass のみ必須、プッシュと TOTP はオプション になっていました（「オプション」だったポリシーは変換対象外で変化なし）。今回の環境では、従来の Okta Verify の必須設定が、FastPass 必須・プッシュと TOTP はオプションという登録設定に変換されたことを確認できました。これは登録設定の変換結果であり、この結果だけでアプリの認証要件が緩和されたと判断することはできません。
Grace period は認証方法別に設定できない
ポリシーの編集画面を開くと、「Okta Verify」ブロックの中に FastPass / プッシュ / TOTP の3つの Enrollment ドロップダウンが並ぶ構成になっています。Grace period（猶予期間）の設定欄は3つの認証方法それぞれにありますが、同一ポリシー内では単一の値が強制されます（公式ドキュメントにも明記されています）。実機でも認証方法別の指定はできませんでした。たとえば「FastPass は猶予なしで必須化しつつ、TOTP の廃止は猶予をもって段階的に進める」といった移行は、1つのポリシー内では表現できません。認証方法ごとに移行スケジュールを分けたい場合は、ポリシーをグループに分けて設計することになります。
機能の有効化だけでは、今回確認した既存ユーザーに再登録や通常のサインインへの影響はなかった
最も気になっていたのは、有効化前から Okta Verify を使っているユーザーへの影響です。今回検証した既存ユーザーでは、機能の有効化後も再登録は求められず、確認したサインインフローは従来どおり成功しました。エンドユーザーの設定画面（セキュリティ方式）も「Okta Verify + 登録デバイス名」の表示のままで、3つの認証方法には分かれませんでした。管理コンソールのユーザー詳細・デバイス登録の表示にも変化はありませんでした。
ただし、後述のプッシュ無効化の検証では、変更後の再サインインで認証の選択肢が変わりました。
一点補足すると、今回確認した管理コンソールでは「このユーザーがどの認証方法に登録済みか」を確認する画面は見当たらず、Reset Authenticators も「Okta Verify」1項目（デバイス単位）のままでした。ポリシーでは認証方法別に制御できるようになった一方、認証方法単位の登録状態の確認やリセット操作は、今回確認した管理画面では見当たりませんでした。API 等を含めた可否までは検証していません。
プッシュを無効化すると、登録済みユーザーはどうなるか
GA 後、多くの組織が「一般社員グループの TOTP を無効にする」といった設定変更を検討すると思いますが、すでにその認証方法を登録・利用しているユーザーに何が起きるのかは公式ドキュメントに記載がありません。
FastPass / プッシュ / TOTP をすべて利用できる登録済みユーザーがいる状態で、所属グループの登録ポリシーの「Push enrollment」を Optional から Disabled に変更して保存し、挙動を確認しました。
以下は今回検証したプッシュ通知の挙動です。FastPass と TOTP の無効化・再有効化は未検証であり、同じ挙動になると断定するものではありません。
保存後にサインアウトして再サインインすると、認証方法の選択画面から「プッシュ通知を受け取る」が消えていました。猶予期間も警告も通知もなく、選択肢が減るだけでした。残った TOTP での認証は正常に成功しました。
プッシュ無効化後も登録情報の表示は変わらなかった
一方で、エンドユーザーの設定画面（セキュリティ方式）は無効化の前後でまったく変化しませんでした。「Okta Verify + 登録デバイス名」の表示はそのまま残り、管理コンソールのデバイス登録にも変化はありません。
プッシュ再有効化後は、再登録なしで利用できた
Push enrollment を Optional に戻して再度サインインすると、「プッシュ通知を受け取る」が選択肢に復活し、再登録なしでそのままプッシュ認証が成功しました。
| 操作 | 今回のプッシュ通知の検証で確認した挙動 |
|---|---|
| Push enrollment を Disabled にして保存 | 変更後の再サインインでプッシュの選択肢が消えた。確認したフローでは通知・警告の表示なし |
| Push enrollment が Disabled の期間 | ユーザー画面・管理コンソールの登録情報の表示は変わらず、TOTP での認証は成功した |
| Push enrollment を Optional に戻す | 再サインインでプッシュの選択肢が復活し、再登録なしで認証に成功した |
検証結果を踏まえた登録ポリシーの設計例
認証方法を3つに分けて設定できるようになると、全員に同じ方法を許可する必要がなくなります。
たとえば、一般社員には FastPass を使ってもらい、FastPass を利用しにくいユーザーにはプッシュを認める。プッシュの利用も難しい環境に限って TOTP を残す、といった分け方ができます。
実際に登録ポリシーを組むなら、次のようなパターンが考えられます。
| パターン | 対象 | FastPass | プッシュ | TOTP | 考え方 |
|---|---|---|---|---|---|
| FastPass を標準にする | 会社支給 PC を使う一般社員 | 必須 | オプション | 無効 | FastPass を基本とし、プッシュは予備として残す |
| プッシュを標準にする | BYOD やスマートフォン中心のユーザー | オプション | 必須 | 無効 | 番号チャレンジを有効にしたプッシュを使う。利用できる場合は FastPass も残す |
| TOTP を例外として残す | FastPass やプッシュを利用できないユーザー | 無効 | 無効 | 必須 | 対象者を専用グループに分け、そのグループだけ TOTP を認める |
全社共通のポリシーで TOTP を有効にしている場合でも、実際に必要としているのは一部のユーザーだけかもしれません。今回の変更を機に対象者を専用グループへ分ければ、一般社員のポリシーから TOTP を外せます。
もちろん、すべての組織でこの3パターンがそのまま使えるわけではありません。端末の管理状況や業務上の制約を確認したうえで、まずは検証用のグループで試すのがよいと思います。
なお、ここで扱っているのは、どの認証方法をユーザーに登録させるかを決める登録ポリシーです。サインイン時に実際に要求する認証方法は、アプリ側の認証ポリシーも含めて確認する必要があります。
有効化前のチェックリスト
本機能の有効化に備え、以下の準備をおすすめします。
- 現行設定の棚卸し：org 全体の Okta Verify 設定と、各登録ポリシー・認証ポリシーで Okta Verify をどう参照しているかを一覧化する
- 初期マッピングの確認：現行設定から、有効化時に3つの認証方法がどの初期値になるかを把握する
- Okta Verify アプリのバージョン確認：iOS 9.68.0 以降 / Android 9.0.0 以降へ更新されているか、MDM 等で確認する
- ドキュメントとアナウンスの準備：登録手順書・ヘルプデスク向け FAQ を更新する
さいごに
Okta からの通知では、本機能は2027年第1四半期の GA 時にすべてのテナントへ自動的に有効化される予定です。正確な GA 日は未定ですが、GA 前に挙動と影響範囲を把握しておくことが重要です。本記事が、その備えの一助になれば幸いです。
参考
- Flexible Okta Verify authenticator configuration
- Okta Customer Comm Reminder | FastPass Same-Device Enrollment Behavior Update and Flexible Okta Verify Configuration（2026年9月30日受信）
