Azure ポータルへのログイン時に「本人確認に問題が発生しました。もう一度お試しください。」と表示され、エラー 399287 が出て SMS／電話認証が通らない事例が増えています。本記事では、実際に Microsoft 側でブロック解除されたケースをもとに、原因の仕組みと具体的な復旧手順、さらに再発防止に役立つ Azure／Microsoft Entra ID（旧 Azure AD）の設計ポイントを詳しく解説します。
Azure ログインで本人確認に失敗し、エラー 399287 が出る状況
事象の典型パターン
今回取り上げるケースは、次のような状況です。
- Microsoft アカウント（または職場アカウント）へのサインイン自体は成功する
- Azure ポータル（
https://portal.azure.com）に入るタイミングで追加の本人確認（MFA）が要求される - SMS または電話を選択してコード送信を行うと
「アカウントの確認に問題が発生しました。もう一度お試しください。」と表示される - 詳細表示を開くと Error Code: 399287 が記録されている
- 電話の国番号は +90（トルコ）
- 昨年までは同じ番号で問題なく Azure ポータルにアクセスできていた
- テナントの全体管理者（グローバル管理者）は 1 名のみ
このように「パスワードまでは通るが、MFA の SMS／電話で止まる」というのがエラー 399287 の典型的な症状です。
| 項目 | 内容 |
|---|---|
| サインイン可否 | Microsoft アカウントへのサインインは成功 |
| 問題が起きるタイミング | Azure ポータルに入る際の電話／SMS ベースの本人確認 |
| エラー | Error Code: 399287 「アカウントの確認に問題が発生しました。もう一度お試しください。」 |
| MFA メソッド | SMS／音声通話のみ登録。Microsoft Authenticator などアプリ認証は未登録 |
| 電話番号 | 国番号 +90（トルコ） |
| 管理者構成 | グローバル管理者が 1 名のみ、ブレークグラス アカウントなし |
エラー 399287 の正体：電話ベースの MFA が PhoneReputation によりブロックされた状態
Microsoft Entra ID（旧 Azure AD）の MFA 裏側で何が起きているか
Microsoft Q&A などの公式フォーラムでは、エラー 399287 は次のような状況で発生することが Microsoft 側から説明されています。
- Microsoft Entra ID（旧 Azure AD）の MFA で SMS／電話認証を実行しようとする
- 裏側で Microsoft の PhoneReputation サービス が、その電話番号や地域のリスク（レピュテーション）を判定
- 「レピュテーションが悪い（BadReputation）」等とみなされた番号／テナントでは、電話ベースの MFA がバックエンドでブロックされる
- その結果、ユーザー側には「アカウントの確認に問題が発生しました」という汎用的なエラー画面と、399287 が表示される
このブロックはあくまでその 電話を使った認証メソッドに対してのみかかるため、
- 通常のサインイン（パスワードまで）は成功する
- しかし Azure ポータルのように「MFA 必須」のアプリでは、MFA 段階で必ず失敗する
という矛盾した挙動になります。
なぜ電話番号のレピュテーションが悪化するのか：IRSF とテレフォニー詐欺
Microsoft のテレフォニー詐欺対策ドキュメントでは、IRSF（International Revenue Share Fraud：国際収益共有詐欺）が電話ベース MFA にとって大きなリスクであると説明されています。
IRSF の代表的な特徴は次の通りです。
- 国際電話や SMS の 料金体系の複雑さを悪用する
- 攻撃者は高額課金される国際番号・プレミアム番号を取得し、そこに大量の通話や SMS を発生させる
- そのトラフィックによる収益を、電話事業者や仲介業者と レベニューシェア（収益分配）する
- そのトラフィック源として、各種サービスの SMS 認証を悪用する（大量の偽サインアップや認証要求を流し込む）
こうした攻撃を防ぐため、Microsoft などのクラウド事業者は次のような対策を行います。
- 国番号や番号帯ごとのリスク評価（PhoneReputation）
- 特定の番号／地域からの認証要求が異常に多い場合の自動スロットリングやブロック
- 一部の国番号は 事前の「地域オプトイン」設定がないと SMS 認証を許可しない
今回のように +90（トルコ）の番号を利用している場合でも、直接その国が危険という意味ではなく、
- 同じ番号帯での異常トラフィック
- 過去に同番号が何度も認証失敗している
- IRSF と疑われるパターンが検知された
といった要因により、特定の番号／テナント単位でレピュテーションが悪化し、電話ベースの MFA が止められてしまうことがあります。
実際の解決事例：Microsoft 側でブロック解除とレピュテーションのクリアを実施
今回の実案件では、最終的に Microsoft エンジニアリング チームによるバックエンドのブロック解除とレピュテーションのクリアが行われ、問題が解消しました。
時系列で見る対応の流れ
| タイミング | 状態／実施内容 |
|---|---|
| 発生時 | Azure ポータルのログイン時に SMS／電話認証が 100% 失敗。エラー 399287 が出続ける。 |
| 一次切り分け | ブラウザ変更、シークレット ウィンドウ、別 PC／別回線でも同様。 ユーザー側の端末・ブラウザ起因ではないと判断。 |
| ログ調査 | Microsoft Entra 管理センターの「サインインログ」「認証方法アクティビティ」で該当ユーザーの試行を確認。 電話ベースの MFA が失敗していることを確認。 |
| サポート依頼 | グローバル管理者が Microsoft サポートにチケットを起票。 エラーコード、Request ID、Correlation ID、Timestamp、電話番号（+90）などを提供。 |
| エンジニアリング対応 | Microsoft エンジニアリング チームにエスカレーション。 当該電話番号／テナントに対する PhoneReputation ブロック解除とレピュテーションのクリアを実施。 |
| 復旧 | SMS 認証が通るようになり、Azure ポータルへのアクセスが可能に回復。 |
重要なのは、テナント管理者側の設定変更だけでは解決できず、Microsoft 側のバックエンド作業が必要だったという点です。
今すぐ実施したいこと：復旧後のチェックリスト
1. 復旧確認：Azure ポータルに再ログインして動作を検証
- Azure ポータル（
https://portal.azure.com）にアクセス。 - 対象アカウントでサインインし、SMS 認証を選択。
- SMS が届き、コード入力後にポータルへ正常に入れることを確認。
- Microsoft Entra 管理センター（
https://entra.microsoft.com）に入り、- 監視 & 健康状況 > サインインログ
- 監視 & 健康状況 > 認証方法アクティビティ
2. セキュリティ情報を強化：Microsoft Authenticator を既定にする
今回のように電話ベースの認証がブロックされると、SMS／電話しか登録していないアカウントは一気に詰みます。これを避けるため、Microsoft Authenticator アプリや FIDO2 パスキーを第一候補のメソッドにすることが推奨されています。
ユーザー側の操作手順（代表例）：
- ブラウザで https://aka.ms/mysecurityinfo にアクセス。
- 問題のアカウントでサインインする。
- 「+ サインイン方法を追加」から 「Authenticator アプリ」を選択。
- 画面の指示に従って、スマートフォンの Microsoft Authenticator アプリで QR コードを読み取る。
- 登録が完了したら、「既定のサインイン方法」を 「Microsoft Authenticator – 通知」または「Authenticator アプリまたはハードウェア トークン – コード」に変更。
テナント管理者側では、認証方法ポリシーで Authenticator を有効化し、SMS／音声は補助メソッドに格下げしておくと安全です。
3. 予備の認証手段を複数登録する
以下のように「最低 2 つ以上の強いメソッド + バックアップ用メソッド」を用意しておくと、ロックアウトリスクを大幅に下げられます。
- Microsoft Authenticator（通知／コード）
- FIDO2 セキュリティキー（YubiKey などのパスキー）
- 別回線の電話番号（可能なら別キャリア）
- 会社メール／代替メール
- バックアップコード（テナントのポリシーで許可している場合）
4. 条件付きアクセスと認証方法ポリシーを見直す
管理者は次のような方針をおすすめします。
- 条件付きアクセスで「強い認証」を要求し、
- 第一候補：FIDO2 パスキー / Microsoft Authenticator（パスキー・通知）
- 第二候補：Authenticator の OTP コード
- 第三候補：SMS／音声（どうしても必要なユーザーのみに限定）
- 認証方法ポリシーで、SMS／音声は特定グループのみ有効にし、乱用を防ぐ
| MFA メソッド | 推奨度 | 特徴 | 主な用途 |
|---|---|---|---|
| FIDO2 パスキー（セキュリティキー） | ◎（最優先） | フィッシング耐性が高く、SMS などのコードを使わない。 | グローバル管理者、特権アカウント、重要システムへのアクセス |
| Microsoft Authenticator（パスキー／通知／コード） | ◎ | スマホアプリでの承認。プッシュ通知やパスキーを利用し、利便性とセキュリティのバランスがよい。 | 一般ユーザー、管理者全般の標準メソッド |
| SMS／音声通話 | △（バックアップ用） | スマホにアプリを入れられない環境で有効だが、IRSF や到達性問題に弱い。 | 一部の現場端末、フィーチャーフォン利用者など |
まだエラー 399287 が解消しない場合の調査とサポート依頼
サインインログで失敗要因を確認する
テナント管理者は、まず Microsoft Entra のログで本当に PhoneReputation 起因なのかを確認しましょう。
- Microsoft Entra 管理センターにサインイン。
- 「ID > 監視 & 健康状況 > サインインログ」を開く。
- 対象ユーザーでフィルターし、ステータス「失敗」のイベントを確認。
- 詳細を開き、
- クライアントアプリ：Azure ポータル
- 結果の詳細：MFA 関連エラー
- Authentication Methods ログに「電話番号のレピュテーション」や「BadReputation」に関する記録がないか
ログ上で原因が特定できなくても、ここで取得した Request ID / Correlation ID / Timestamp が後述のサポート依頼に必須情報になります。
Microsoft サポートへエスカレーションする際に伝えるべき情報
テナント管理者（グローバル管理者）が Microsoft サポートに問い合わせる際は、次の情報をまとめておくと調査がスムーズです。
- エラーコード：399287
- Request Id：例）
1032e265-c5bf-4124-aabe-58c408219b00 - Correlation Id：例）
7f5f5c97-c872-48be-ad74-06e86e982e32 - Timestamp (UTC)：例）
2025-08-31T00:03:09Z - 対象ユーザーの UPN と表示名
- 電話番号（国番号付き）：例）
+90 xxx xxx xxxx - テナント ID（Directory ID）
- 再現手順（どの URL にアクセスして、どのボタンを押すと失敗するか）
- 昨年までは同番号で正常に利用できていたこと、管理者が 1 名のみであること
依頼内容としては、
- 当該電話番号／テナントが PhoneReputation によりブロックされていないかの確認
- 必要に応じて ブロック解除およびレピュテーションのクリアを依頼したい旨
を明確に伝えます。ユーザー側・管理者側ではこの PhoneReputation の内部ステータスは確認できないため、最終的には Microsoft 側のエンジニアリング チームでの対応が必要です。
再発防止のためのベストプラクティス
グローバル管理者を 1 名にしない：最低 2 名＋緊急アカウント
Microsoft は、テナントから締め出されるリスクを避けるために、少なくとも 2 つ以上の緊急アクセス（ブレークグラス）アカウントを持つことを推奨しています。
- いずれも クラウド専用（オンプレ AD から同期しない）アカウント
- テナントの グローバル管理者 ロールを恒久的に付与
- 通常業務では一切使用せず、緊急時のみ利用
- パスワードや FIDO2 キーなどの資格情報は、耐火金庫や専用の金庫などで厳重保管
今回のように、唯一の管理者アカウントが MFA で詰まるとテナント全体が人質に取られた状態になるため、早急に構成見直しをおすすめします。
ブレークグラス アカウントの具体的なイメージ
| アカウント種別 | 用途 | 認証方法 |
|---|---|---|
| BreakGlass-1 | 第一緊急用。管理者が通常使う Authenticator とは異なるメソッドで保護。 | FIDO2 セキュリティキー（パスキー）＋長いパスフレーズ |
| BreakGlass-2 | 第二緊急用。Conditional Access から除外し、万一の CA 誤設定時の救済に使用。 | 別の FIDO2 キー、または証明書ベース認証など |
最近の Mandatory MFA（管理ポータルへの MFA 強制）ポリシーではブレークグラス アカウントも MFA 登録が必須になりつつあるため、FIDO2 や証明書ベース認証での MFA 登録を忘れないようにしましょう。
一時アクセスパス（TAP）を使った安全な復旧フローの整備
Temporary Access Pass（TAP）は、Microsoft Entra ID が提供する 時間制限付きの一時コードで、ユーザーが普段の認証方法を失ったときに、新しいパスキーや Authenticator を登録し直すために利用できます。
代表的な運用フロー：
- 管理者が Entra 管理センターで「対象ユーザーに TAP を発行」する。
- ユーザーに TAP コードとサインイン URL（
https://aka.ms/mysecurityinfoなど）を安全な経路で伝える。 - ユーザーは TAP でサインインし、
- Microsoft Authenticator
- FIDO2 パスキー
- バックアップ用の電話／メール
- 再登録完了後は TAP を無効化または自然失効させる。
TAP は「一時的な強い認証」として設計されており、電話がブロックされている状況でも復旧できる手段として非常に有効です。
セルフサービス再登録と SSPR の活用
ユーザー自身が認証方法を更新できるよう、以下を検討してください。
- Self-Service Password Reset（SSPR） を有効化し、セキュリティ情報のセルフ登録を促す
- Authentication methods ポリシーで、ユーザー自身が Authenticator や FIDO2 を追加できるようにする
- ただし「代替メール」「代替電話」など本人確認のガードレールは常に最新に保つよう周知
監視とアラート：IRSF の兆候を早期検知する
PhoneReputation によるブロックがかかる前に、次のような挙動を監視してアラートを出しておくと安心です。
| 監視ポイント | 怪しい兆候の例 | 推奨アクション |
|---|---|---|
| MFA リクエスト数 | 短時間で同一番号に大量の SMS／音声認証要求が発生 | そのユーザーのアカウント状態を確認し、不要な再試行を止める。場合によっては一時的にサインインをブロック。 |
| 地域ごとのトラフィック | 普段使わない国番号や地域からの MFA 試行が急増 | その地域の電話ベース MFA を一時的に無効化し、Authenticator や FIDO2 への移行を促す。 |
| サインイン失敗率 | 特定ユーザー／グループの MFA 失敗が継続 | 認証方法の再登録（TAP の発行など）を検討し、必要に応じて Microsoft サポートにエスカレーション。 |
SMS／音声による MFA の位置づけ：完全廃止ではなく「最後の砦」として
SMS／音声ベースの MFA には、以下のようなメリットとデメリットがあります。
- メリット
- スマートフォンにアプリをインストールできないユーザーでも利用可能
- フィーチャーフォンや一部の業務端末でも利用しやすい
- デメリット
- IRSF や SIM スワップ、電話転送など、テレフォニー起因のリスクにさらされやすい
- キャリアやローミング、地域規制の影響で到達性が不安定になりやすい
- Microsoft 側の PhoneReputation／地域スロットリングにより、突然ブロックされることがある
実務的には、
- できる限り Authenticator／FIDO2／パスキーを第一選択とする
- SMS／音声は「どうしても他のメソッドが使えないユーザー向けのバックアップ手段」に位置づける
- MFA 設定画面でも、ユーザーが SMS を既定にしないようガイドする（ヘルプ記事・社内ポリシーで周知）
という方針が、セキュリティ・安定性・コストのバランスがよい運用になります。
まとめ：エラー 399287 は設計を見直すチャンス
最後に、本記事のポイントを整理します。
- 399287 は、電話ベースの MFA が Microsoft の PhoneReputation によりブロックされた場合に返されるエラーであり、パスワード自体の問題ではありません。
- 今回の実案件では、Microsoft エンジニアリング側で PhoneReputation ブロック解除とレピュテーションのクリアを行うことで解消しました。
- 復旧後は、必ず Microsoft Authenticator や FIDO2 パスキーを第一メソッドとして登録し直し、SMS／音声はバックアップに格下げしてください。
- グローバル管理者が 1 名のみの構成は非常に危険です。Microsoft が推奨するように、最低 2 つ以上のブレークグラス アカウント＋通常の管理者アカウントという冗長構成を取りましょう。
- Temporary Access Pass（TAP） を使えば、電話や Authenticator を失ったユーザーでも安全に認証方法を再登録できる復旧フローを構築できます。
- サインインログや認証方法アクティビティの継続的な監視により、IRSF の兆候や異常な電話トラフィックを早期に検知し、PhoneReputation によるブロックを未然に防ぎやすくなります。
エラー 399287 は、単なる一時的なトラブルではなく、「電話頼みの MFA から卒業し、より強い認証設計に移行する」きっかけと考えるのが得策です。今回のポイントを参考に、自社テナントの認証設計・管理者構成・緊急時の復旧手順を、ぜひ一度見直してみてください。
参考リンク
- Unable to Verify Identity for Azure Login – Error 399287（Microsoft Q&A）
- Understanding telephony fraud risk for Microsoft Entra multifactor authentication（IRSF とテレフォニー詐欺）
- Manage emergency access accounts in Microsoft Entra ID（ブレークグラス アカウント）
- Configure Temporary Access Pass to register authentication methods（TAP）
- Manage authentication methods for Microsoft Entra ID（認証方法ポリシー）
※本記事は上記の公開情報をもとに独自の観点を加えて整理したものであり、実際の環境での適用にあたっては、必ず自組織のセキュリティポリシーと Microsoft の最新ドキュメントをご確認ください。
出典：Microsoft Q&A「Unable to Verify Identity for Azure Login – Error 399287」
https://learn.microsoft.com/en-us/answers/questions/5539787/unable-to-verify-identity-for-azure-login-error-39
コメント