Content last updated 2026-02-09

2FA の解除

2FA 解除リクエストを処理する方法を詳述するワークフロー

概要

このワークフローは、GitLab.com アカウントの二要素認証（2FA）の無効化に焦点を当てています。リクエストの認証に関する一般的な原則は、アカウント認証ワークフローでカバーされています。

2FA 解除およびその他のアカウントアクションは、以下のワークフローが成功した場合にのみ完了できます。

GitLab 内での 2FA 解除

セルフサービスでの 2FA 解除

多くの場合、ユーザーは サポートに連絡せずに 自分で 2FA を無効化してアカウントへのアクセスを取り戻せます。サポートチケットを作成する前に、ユーザーは以下の該当するすべての回復方法を試すべきです。

なお、GitLab Support は、GitLab サブスクリプションを購入し、本人確認チャレンジに正常に合格しない限り、無料ユーザーの 2FA リセットには対応しません。無料ユーザーに対してセルフサービスの方法が機能しない場合は、まずサブスクリプションを購入するために GitLab Sales に連絡するよう案内してください。サブスクリプションを取得し購入の証明を提供できる場合に限り、サポートは 2FA リセットのための本人確認を進めるべきです。

利用可能な回復方法

GitLab リカバリーコード - ユーザーは多要素認証を最初に有効化したときに保存したリカバリーコードを使用できます。
SSH キーを使ったコードの再生成 - ユーザーが GitLab アカウントに SSH キーを追加している場合、SSH を使ってリカバリーコードを再生成できます。以下に説明します。
1. コンソール／ターミナルで ssh [email protected] 2fa_recovery_codes を実行します。
2. 新しいリカバリーコードを生成するか尋ねられたら ‘yes’ と答えます。
3. リカバリーコードのうち 1 つをコピーします。
4. https://gitlab.com に通常のユーザー名とパスワードでサインインします。二要素認証コードを尋ねられたら、先ほどコピーしたリカバリーコードを貼り付けます。
5. 認証に成功したら、Profile -> Account に進みます。
6. 二要素認証を無効化します。
7. 新しいデバイス（Google Authenticator、Duo Security など）で二要素認証を再度有効化します。
認証アプリのクラウドバックアップ - 一部の認証アプリは、新しいデバイスで 2FA コードを復元できるクラウドバックアップ機能を提供しています。これはデバイスを失う前にバックアップが有効化されていた場合にのみ機能します。
1. 新しいデバイスに認証アプリをインストールします。
2. 特定の認証アプリの回復プロセスに従います。
3. ユーザー名、パスワード、復元された 2FA コードを使って https://gitlab.com にサインインします。
注: GitLab Support は認証アプリ固有の回復問題には対応しません。詳細な回復手順については、ユーザーは認証アプリの公式ドキュメントを参照する必要があります。

Enterprise ユーザーに対する Enterprise オーナーによる 2FA 解除

トップレベルグループのオーナーは、グループメンバーでもあるすべての enterprise ユーザーに対して 2FA を無効化できます。ユーザーは、グループに検証済みドメインがあり、ユーザーが Enterprise ユーザーの基準を満たしている場合に、自動的に Enterprise ユーザーとしてクレームされます。

定義

アカウント保有者: アカウントを日常的に使用する人。本人がアカウントオーナーであるとは限りません。
Enterprise オーナー: GitLab で有償プランを購入したビジネス事業体を代表し、その有償ネームスペースで Owner 権限を持ち、Enterprise ユーザーとしてクレームされている 1 人以上の人。
Owner: GitLab で有償プランを購入したビジネス事業体を代表し、その有償ネームスペースで Owner 権限を持つが、Enterprise ユーザーとしてクレームされていない 1 人以上の人。

注: サポートの目的では、ユーザーがサポートにおける Enterprise ユーザーの定義を満たす場合は、引き続き enterprise ユーザーとみなされる可能性があります。

GitLab.com ユーザーの条件

GitLab.com ユーザーが 2FA リセットの対象となるためには、以下の条件 のいずれか を満たす必要があります。

ユーザーが GitLab.com の有償グループでシートを占めている、またはトップレベルグループのオーナーがそのユーザーを有償グループに追加する意向がある。
ユーザーが Enterprise ユーザーとしてクレームされている。
ユーザーが Enterprise ユーザーのサポートでの定義を満たしている。
ユーザーが GitLab.com の購入に関する現行の請求書のプライマリー請求担当者である。
GitLab チームメンバー（アカウントマネージャー、CSM、その他）がアカウント管理プロジェクトでこのアカウントの保有者と協力している。
ユーザーアカウントが、有償サブスクリプションを管理するための Customers Portal への SSO アクセスに必要である - Customers Portal アクセスにアカウントが使用される場合の 2FA リセット条件を参照。

より簡潔に言うと: 有償ユーザーである、アカウントを支払いに使用している、または私たちがアカウントを通じて連絡を取っている、ということです。

多くの場合、トップレベルグループのオーナーがユーザーに代わってチケットを提出することがあります。詳細と適格性については、アカウント認証マトリクスを参照してください。

アカウント認証マトリクス

アカウント認証マトリクスは Account Owner Verification ハンドブックページにあります。

Customers Portal アクセスにアカウントが使用される場合の条件

Customers Portal では、すべての顧客がリンクされた GitLab アカウントを通じてアクセスする必要があります。

ユーザーが対象であり、2FA をリセットできるのは、以下の条件 のいずれか が満たされる場合です:

リクエストが GitLab サブスクリプションの最新の請求書のプライマリー請求担当者から行われている。
GitLab アカウントが、サブスクリプション購入の最新の請求書のプライマリー請求担当者の Customers Portal アカウントにリンクされている。

請求書を提供できない場合は、レガシーのメール／パスワードでサインインするように提案してください。そこで請求書をダウンロードできます。

チケットを簡潔かつ正確に保つ

2FA 解除のチケットは 記録の対象 であるため、チケットは簡潔で、正確で、アクセス問題に厳密にフォーカスしている必要があります。 お客様が無関係なトピックを持ち込むことを許してはいけません。

サポート介入による 2FA の無効化

上記の手順を試した後のサポート介入による 2FA 解除は、チケット作成時に 有償プラン を持つユーザーに対してのみ可能です。

ワークフロー

アカウント保有者によって開始された 2FA 解除リクエスト

アカウント保有者によって開始されたリクエストは、セキュリティチャレンジを満たすための情報を提供するように自動返信が促します。

Step 0: 検証

いくつかの初期検証ステップが自動的に実行されます:

メール／ユーザー名の一致
グループメンバーシップの検証
グループサブスクリプションの検証

これらのいずれかが不正確な場合、チケットはクローズされます。

ユーザーが 2FA Assistance カテゴリを使用して 2FA リセットリクエストチケットを送信したが 2FA removal チケットサブカテゴリを使用していない場合、フォームのサブカテゴリを 2FA removal に設定してください。チケットが明らかに 2FA リセットに関するものでありながら、お客様が 2FA チケットカテゴリのいずれも使用していなかった場合は、General::Forms::Incorrect form used マクロを使用して、Support Operations にチケットに対する適切なアクションを取ってもらってください。ユーザーがサポート対象でない場合、チケットは自動的にクローズされます。

Step 1: チャレンジの回答を確認する

注: ユーザーが返してきた情報がごく僅かで、明らかに不十分または曖昧な場合は、その回答後すぐに追加情報を求める返信を行ってください。「コミットの正確な日付と時刻を提供してください、おおよそのものでなく」など、追加のガイダンスを提供できます。

チャレンジの回答を検証するには、Zendesk GitLab User Lookup App を使用するか、admin アクセスがある人は https://gitlab.com/admin/users/USERNAME で確認します。
ZenDesk GitLab Super App の 2FA Helper を使用して、ユーザーの回答に基づきリスクファクター（GitLab 内部）を判定します。データ分類基準と注釈は Internal Handbook - Data Classification table （GitLab 内部）にあり、これが情報源として扱われます。アプリ経由ではなく手動でコメントを残す必要がある場合は、Support::SaaS::Gitlab.com::2FA::2FA Internal Note マクロを使用してチケットに内部ノートを追加してください。
- ユーザーが有償ネームスペースのメンバーである場合、チャレンジの回答は有償ネームスペースに対して評価する必要があります。ユーザーが有償ネームスペースのメンバーでない場合は、追加のガイダンスのために 2FA リセット検討の条件を参照してください。
検証に合格した場合: Slack #support_gitlab-com でチームの別のメンバーに自分の決定をピアレビューしてもらうようリクエストします。ピアレビュアーが 2a の手順を実行します。
検証に失敗した場合: Step 2b に進みます。

Step 2a: ユーザーがアカウント所有権の証明に成功した場合

このセクションは通常ピアレビュアーが行います。必要であれば、ピアレビュアー（または承認マネージャー）が承認ノートを残し、その場合は元のレビュアーがアクションを実行します。

その決定に同意する場合、admin アカウントにサインインしてユーザーテーブルからユーザー名を見つけるか、https://gitlab.com/admin/users/usernamegoeshere に移動します
1. account タブで Edit をクリックし、Admin Note を追加して保存します。
2. account タブで Disable 2FA をクリックします。
3. Support::SaaS::Gitlab.com::2FA::2FA Removal Verification - Successful マクロを使用します。

Step 2b: ユーザーがアカウント所有権の証明に失敗した場合

注: 回答へのヒントを提供したり、どのチャレンジが正しかった／間違っていたかをユーザーに伝えたりしては いけません。それがソーシャルエンジニアリングの仕組みです！

ユーザーがリスクファクターをパスできない場合:
1. 検証なしでは 2FA を解除できないことを伝え、ただし Enterprise オーナーがユーザーに代わってリクエストを作成することは可能（資格を満たす場合）と伝えるために、Support::SaaS::Gitlab.com::2FA::2FA Removal Verification - GitLab.com - Failed - Final Response マクロを使用します。
2. チケットを「Solved」としてマークします。

Enterprise オーナーによって開始された 2FA 解除リクエスト

Enterprise オーナーによって開始されたリクエストには、Support PIN が含まれている必要があります。

Enterprise オーナーが開始した 2FA 解除のチケットが提出されると、Zendesk は次のチェックを行うことに注意してください:

サポート資格を持っているか？
リクエスター側のメールドメインがターゲットのメールドメインと一致するか？
リクエスターがトップレベル有償ネームスペースのオーナーか？
ターゲットがトップレベル有償ネームスペース配下のメンバーか？

これらのいずれかが失敗した場合、ユーザーには通常の 2FA チャレンジが送信されます。この場合は以下の Step 1b を使用してください。

他のチャレンジが送信される場合、オーナーは 自分の アカウントに関して回答すべきであることに注意してください。他の回答は受け入れられません。

Step 0: 検証

いくつかの初期検証ステップが自動的に実行されます:

メール／ユーザー名の一致
グループメンバーシップの検証
グループサブスクリプションの検証

これらのいずれかが不正確な場合、チケットはクローズされます。

Step 1a: Support PIN の検証

注: ユーザーが返してきた情報がごく僅かで、明らかに不十分または曖昧な場合は、その回答後すぐに追加情報を求める返信を行ってください。

ユーザーに通常のチャレンジ回答が送信されていた場合、代わりに Step 1b を使用します。
ZenDesk GitLab Super App の 2FA Helper（2025 年 5 月 1 日時点）を使用して、ユーザーの回答に基づいてリスクファクター（GitLab 内部）を判定します。データ分類基準と注釈は Internal Handbook - Data Classification table （GitLab 内部）にあり、これが情報源として扱われます。アプリ経由ではなく手動でコメントを残す必要がある場合は、Support::SaaS::Gitlab.com::2FA::2FA Internal Note マクロを使用してチケットに内部ノートを追加してください。
Support PIN を検証するには admin アクセスを使用し https://gitlab.com/admin/users/USERNAME で確認します。
- 注: Support PIN がチケットの該当オーナーから提供されたものであることを確認してください。チケット内の他のユーザーがオーナーに代わって提供した Support PIN は受け入れられません。
ユーザーに Support PIN レスポンスが送信されているため、他の必要な条件はすでに満たされています:
- リクエスターは Enterprise オーナー
- ターゲットは Enterprise ユーザー
検証に合格した場合: Slack #support_gitlab-com でチームの別のメンバーに自分の決定をピアレビューしてもらうようリクエストします。ピアレビュアーが 2a の手順を実行します。
検証に失敗した場合: Step 2b に進みます。

Step 1b: チャレンジの回答を確認する

注: ユーザーが返してきた情報がごく僅かで、明らかに不十分または曖昧な場合は、その回答後すぐに追加情報を求める返信を行ってください。

ユーザーに Zendesk で Support PIN の自動応答が送信された場合は、このステップをスキップします。
チャレンジの回答を検証するには、Zendesk GitLab User Lookup App を使用するか、admin アクセスがある人は https://gitlab.com/admin/users/USERNAME で確認します。
ZenDesk GitLab Super App の 2FA Helper を使用して、ユーザーの回答に基づきリスクファクター（GitLab 内部）を判定します。データ分類基準と注釈は Internal Handbook - Data Classification table （GitLab 内部）にあり、これが情報源として扱われます。アプリ経由ではなく手動でコメントを残す必要がある場合は、Support::SaaS::Gitlab.com::2FA::2FA Internal Note マクロを使用してチケットに内部ノートを追加してください。
- ユーザーが有償ネームスペースのメンバーである場合、チャレンジの回答は有償ネームスペースに対して評価する必要があります。ユーザーが有償ネームスペースのメンバーでない場合は、追加のガイダンスのために 2FA リセット検討の条件を参照してください。
検証に合格した場合: Slack #support_gitlab-com でチームの別のメンバーに自分の決定をピアレビューしてもらうようリクエストします。ピアレビュアーが 2a の手順を実行します
検証に失敗した場合: Step 2b に進みます

Step 2a: Enterprise オーナーが本人確認に成功した場合

その決定に同意する場合、admin アカウントにサインインしてユーザーテーブルからユーザー名を見つけるか、https://gitlab.com/admin/users/usernamegoeshere に移動します
1. account タブで Edit をクリックし、Admin Note を追加して保存します。
2. account タブで Disable 2FA をクリックします。
3. Support::SaaS::Gitlab.com::2FA::2FA Removal Verification - Successful マクロを使用します。

Step 2b: Enterprise オーナーが本人確認に失敗した場合

注: 回答へのヒントを提供したり、どのチャレンジが正しかった／間違っていたかをユーザーに伝えたりしては いけません。それがソーシャルエンジニアリングの仕組みです！

ユーザーがリスクファクターをパスできない場合:
1. Support::SaaS::GitLab.com::2FA::Additional 2FA Challenges マクロで追加のチャレンジを送信します。
2. オーナー保証として Support PIN を生成し、チケットへの返信で提供してもらうようオーナーに依頼することができます。注: 別のユーザーがチケットに CC されている場合、Support PIN を検証したらユーザーに新しい PIN を生成して以前のものを無効化するよう依頼してください。
  - 注: Support PIN がチケットの該当オーナーから提供されたものであることを確認してください。チケット内の他のユーザーがオーナーに代わって提供した Support PIN は受け入れられません。
3. オーナーを認証するためのバックアップ方法も活用できます。
ユーザーがそれでもリスクファクターをパスできない場合:
1. 検証なしでは 2FA を解除できないことを伝え、Support::SaaS::Gitlab.com::2FA::2FA Removal Verification - GitLab.com - Failed - Final Response マクロを使用します。
2. チケットを「Solved」としてマークします。

Owner（非 Enterprise ユーザー）によって開始された 2FA 解除リクエスト

Owner（非 Enterprise ユーザー）によって開始されたリクエストは、セキュリティチャレンジを満たすための情報を提供するように自動返信が促します。

注: ターゲットユーザーはチケットに CC される必要があり、チャレンジ質問はターゲットユーザーが直接回答する必要があります。オーナーがターゲットユーザーに代わって質問に回答することは 絶対に いけません。

初期検証およびその後のステップはアカウント保有者によって開始された 2FA 解除リクエストと同じです。

オーナーを認証するためのバックアップ方法

グループオーナーがオーナー保証を含めない場合、別の方法で本人確認できます。これは Support によって具体的に指示され、その状況に固有なものとして識別可能なアクションでなければなりません。例として、オーナーに以下を依頼することができます:

チケット番号を文字列として含むプライベートスニペットを作成する。
アクセス権を持つプロジェクトに、こちらが指定する特定のテキストを含む Issue を作成する。
こちらが指定するパスに新しいプロジェクトを作成する。

大規模顧客（廃止）

注: このプロセスは 2025 年 4 月 30 日に廃止されました。このプロセスを使用していたすべての顧客には通知済みです。

フローチャート

以下は、上記の GitLab 内での 2FA 解除セクションで説明されている手順を可視化するのに役立つフローチャートです。

flowchart TD
    A[Customer opens ticket]
    B{Is user a support contact?}
    C[Autoresponse is sent]
    D{🟡 Use Incorrect Form Macro}
    E[🛑 Ticket is closed]
    F[Follow Account Holder workflow]
    G[Follow Enterprise Owner workflow]
    H([Score challenges using Acct Verify App])
    I{Challenges passed?}
    J[Peer Review]
    K{Peer Review passed?}
    L{Check Appropriate workflow}
    M[Account Holder workflow]
    N[Enterprise Owner workflow]
    O[🛑 Close ticket]
    P([🟡 Send additional challenges - if none exist, 🛑 close ticket])
    Q((🟢 Peer reviewer disables 2FA, </br> sends response, solves ticket))
    A ---> B
    B ---> |Yes| C
    B ---> |No| D
    D ---> |Associated?| C
    D ---> | Not associated? | E
    C ---> |Request initiated by the account holder| F
    C ---> |Request initiated by an Enterprise owner| G
    F ---> H
    G ---> H
    H ---> I
    I ---> |Yes| J
    I ---> |No| L
    J ---> K
    K ---> |Yes| Q
    K ---> |No| P
    L ---> M
    L ---> N
    M ---> O
    N ---> P
    P ---> I

click D href "#step-0-validation"
click F href "#request-for-2fa-removal-initiated-by-the-account-holder"
click G href "#request-for-2fa-removal-initiated-by-an-enterprise-owner"

メールワンタイムパスワード（OTP）の強制

概要

GitLab.com では、パスワードでサインインするユーザーには MFA が必須*になります。ユーザーはアプリベースの TOTP または WebAuthn デバイスでこの要件を満たせます。どちらも設定されていない場合、ユーザーはサインインを完了するためにメール経由で送信されるワンタイムパスワードを入力する必要があります。

* GitLab チームメンバーは、タイミングについて Mandatory MFA Rollout Plan を参照できます。

意図された副作用: API、Git over HTTPS、Container Registry のパスワード認証は失敗します。代わりに別の認証メカニズムを使用する必要があります:

セルフサービスのオプション

ユーザーは Email OTP コードを、自分のプライマリーメールアドレスや、アカウントに設定された任意の検証済みセカンダリーメールアドレスに送信できます。

有償アカウントへのサポート介入

Email One-Time Passwords (Email OTP) 開発ガイドのロギングに関するセクションを参照して、Email OTP に関連する Issue のトリアージとデバッグを支援してください。

メールアカウントの喪失

ユーザーがメールアドレスへのアクセスを失い Email OTP を受信できない場合は、Lost Email Account ワークフローに従ってください。

Email OTP コードのメールが届かない場合のサポート介入

ユーザーがメールアドレスにはアクセスできるが Email OTP コードを受信できない場合、Mailgun ログの確認と Mailgun でメールを確認または再送する方法の手順に従ってください。

ブロックされた API エンドポイントの調査

サポートは ElasticSearch ログを使用して、現在ブロックされている API エンドポイントでパスワード認証を試みているエンドポイントおよびユーザーを見つけられます。

ワークフロー

ユーザーが対象条件を満たすことを確認します
アカウント認証マトリクスを使用して本人確認を完了します
お客様のトップレベルパスとユーザー名を収集します
https://log.gprd.gitlab.net/ にアクセスし pubsub-rails-inf-gprd-* インデックスを検索するか、以下の検索を使用します:
- お客様のネームスペース内のプロジェクトに対するパスワード認証付きの Git over HTTPs 操作の表示 - リンク
  - json.path の値を /gitlab-org/* のようにお客様のネームスペースに置き換えます。
- 単一ユーザーのパスワード認証付きの Git over HTTPs 操作の表示 - リンク
  - json.username の値を確認したいユーザー名に置き換えます。
- 単一ユーザーのすべてのパスワード認証イベントの表示 - リンク
  - json.username の値を確認したいユーザー名に置き換えます。
必要に応じて検索ウィンドウのルックバック期間を延ばします。

https://docs.gitlab.com/development/email_one_time_passwords/#password-api-authentication-failures も参照してください。

Email OTP の遅延に対するサポート介入

サポートは、トップレベルネームスペースのオーナーからリクエストを受けた場合に、有償ユーザーの Email OTP の強制を遅延させることができます。

Enterprise ユーザーに対する強制の遅延

Enterprise ユーザー に対する Email OTP 強制を遅延させるには、リクエストはトップレベルネームスペースの Enterprise オーナーから発信されている必要があります。各リクエストの適格性を確認するには、アカウント所有権検証適格性マトリクスを参照してください。これはサポートの Enterprise ユーザーの定義を満たすユーザーにも適用されます。

非 Enterprise ユーザーに対する強制の遅延

有償（非 Enterprise）ユーザー に対する Email OTP 強制を遅延させるには、リクエストはトップレベルネームスペースのオーナーから発信され、単一ユーザーをターゲット にする必要がありますが、アカウント所有権検証の回答はアカウント所有権検証適格性マトリクスに従ってターゲットユーザーが提出する必要があります。

1 チケットにつき 1 ユーザー。コミュニケーションはチケットに CC される必要があるターゲットユーザーから直接行われます。

強制の遅延がリクエストされる可能性のあるシナリオ:

API エンドポイントが Email OTP 要件によりブロックされている（上記参照）ため、別の認証への切り替えに時間が必要。
お客様が組織全体での移行計画のための遅延をリクエストしている。

ワークフロー

リクエスターがアカウント所有権検証適格性マトリクスに基づいて変更をリクエストする資格があることを確認します
チャレンジ質問を発行してアカウント所有権検証を完了します
#support_gitlab-com でピアレビューをリクエストします
遅延期間を決定します - 1 日から 90 日が許容されます。
リクエストタイプに基づいてユーザー ID を収集します:
- Enterprise オーナーが Enterprise ユーザーをターゲットとする場合: すべてのユーザー ID を収集します。これらの ID がすべて有償アカウントに属し、Enterprise ユーザーである（またはサポートの定義を満たす）ことを確認します。すべてのターゲットユーザーがすでに email_otp_required_after を設定済みであることを確認します。GitLab.com 管理者は /admin/users/<username> にアクセスして Email OTP フィールドを確認することでこれを確認できます。
- トップレベルグループオーナーが非 Enterprise ユーザーをターゲットとする場合: 1 人のターゲットユーザーに対してのみ強制を遅延できます。ターゲットユーザーの ID を収集し、有償アカウントに属することを確認します。ターゲットユーザーがすでに email_otp_required_after を設定済みであることを確認します。GitLab.com 管理者は /admin/users/<username> にアクセスして Email OTP フィールドを確認することでこれを確認できます。
少数のユーザーには、GitLab Admin エリアを使用します:
1. Admin > Users で、各ユーザーの「Edit」をクリックします
2. 「Access」セクションまでスクロールし「Email OTP」を探します
3. 日付ピッカーを使用して選択した遅延を反映する日付を選びます。（注: 空白の日付はアカウントセキュリティのロジックによってオーバーライドされる可能性があります）。
4. 変更を説明する Admin Note をアカウントに追加します。例: <date> | Email OTP required set to <value> | <ticket link>
5. Save をクリックします
6. 更新された Email OTP フィールドを確認します。UI には保存された値が反映され、検証ルールが尊重されます。例:
  1. MFA が必須（Gitlab::CurrentSettings.require_minimum_email_based_otp_for_users_with_passwords?）でユーザーが代替の MFA を持たない場合、nil にできない
  2. ユーザーが MFA を有効化していて、2FA を強制するネームスペース／トップレベルグループの一部である場合、値を設定できない
多数のユーザーの場合は、コンソールエスカレーション内部リクエストを起こして、適用対象のすべてのユーザーに対して email_otp_required_after を合意した将来日に設定するよう依頼します。

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)

ページのソースコードを見る - ページの編集 - please contribute.

2FA の解除

概要

関連トピック

GitLab チームメンバー

GitLab 内での 2FA 解除

セルフサービスでの 2FA 解除

利用可能な回復方法

Enterprise ユーザーに対する Enterprise オーナーによる 2FA 解除

定義

GitLab.com ユーザーの条件

アカウント認証マトリクス

Customers Portal アクセスにアカウントが使用される場合の条件

チケットを簡潔かつ正確に保つ

サポート介入による 2FA の無効化

ワークフロー

アカウント保有者によって開始された 2FA 解除リクエスト

Step 0: 検証

Step 1: チャレンジの回答を確認する

Step 2a: ユーザーがアカウント所有権の証明に成功した場合

Step 2b: ユーザーがアカウント所有権の証明に失敗した場合

Enterprise オーナーによって開始された 2FA 解除リクエスト

Step 0: 検証

Step 1a: Support PIN の検証

Step 1b: チャレンジの回答を確認する

Step 2a: Enterprise オーナーが本人確認に成功した場合

Step 2b: Enterprise オーナーが本人確認に失敗した場合

Owner（非 Enterprise ユーザー）によって開始された 2FA 解除リクエスト

オーナーを認証するためのバックアップ方法

大規模顧客（廃止）

フローチャート

メールワンタイムパスワード（OTP）の強制

概要

セルフサービスのオプション

有償アカウントへのサポート介入

メールアカウントの喪失

Email OTP コードのメールが届かない場合のサポート介入

ブロックされた API エンドポイントの調査

ワークフロー

Email OTP の遅延に対するサポート介入

Enterprise ユーザーに対する強制の遅延

非 Enterprise ユーザーに対する強制の遅延

ワークフロー