電話によるソーシャルエンジニアリング（Vishing）とは？Help Desk・MFAリセットを狙う攻撃の仕組みと対策

最終確認日：2026年8月13日
本記事では、Mandiant M-Trends 2026、Google Threat Intelligence、NIST SP 800-63-4、MITRE ATT&CK、Microsoft、CISAなどの一次情報を基に、電話を使ったソーシャルエンジニアリングについて解説します。

冒頭文

「怪しいメールを開かない」

これは現在も重要なセキュリティ対策です。

しかし、メールだけを警戒していれば十分という時代ではなくなっています。

Mandiantが2025年に実施したインシデント調査では、脆弱性悪用が初期感染ベクトルの32%を占めて首位でした。一方、対話型のVoice Phishing（Vishing：ビッシング）が11%まで増加し、第2位になりました。メールフィッシングは2024年の14%から2025年には6%へ低下しています。

攻撃者が狙っているのは、電話に出た一般社員だけではありません。

特に重要なのが、

• Help Desk
• 情報システム部門
• コールセンター
• SaaS管理者
• 人事
• ID管理担当者

です。

なぜなら、パスワード変更やMFAリセットを実行できる人間は、事実上「認証システムの一部」だからです。

結論

電話によるソーシャルエンジニアリングへの最も重要な対策は、

「怪しい電話を見抜ける社員を作る」ことではなく、「電話だけでは重要なアカウント変更が成立しない仕組みを作る」ことです。

NIST SP 800-63-4も、第三者であるCustomer Service Agentなどがソーシャルエンジニアリングの対象になり得る認証方式を避けることをセキュリティ上の対策として挙げています。

理想は次の構造です。

電話
 ↓
「本人です」
 ↓
信用しない
 ↓
登録済みの別経路で本人確認
 ↓
高リスク操作なら追加確認
 ↓
Password / MFA変更
 ↓
変更を本人へ別経路で通知
 ↓
Identity Logを監視

つまり、

電話は「依頼を受ける入口」にはできても、「本人であることの証明」にはしない。

という考え方が重要です。

この記事の要点

• 2025年のMandiant調査ではVoice Phishingが初期感染ベクトルの11%を占め、第2位になった。
• 電話フィッシングはMITRE ATT&CKでT1566.004 Spearphishing Voiceとして整理されている。
• 攻撃者は社員だけでなくHelp Deskや情シスを狙ってPassword・MFAリセットを突破する。
• 発信者番号、氏名、社員番号、部署名を知っていることだけでは本人確認にならない。
• Caller IDは偽装できるため、表示された電話番号を本人確認の根拠にしてはいけない。
• PasswordやOTPを電話相手へ伝える運用を禁止する必要がある。
• MFAリセットと新規MFAデバイス登録は高リスク操作として扱う必要がある。
• FIDO2やPasskeyなどのフィッシング耐性MFAは有効だが、弱いAccount Recoveryが残ればHelp Desk経由で迂回される可能性がある。
• インバウンド電話とは別の信頼済み経路で本人確認することが重要である。
• Security Awarenessだけでは不十分で、本人確認フローそのものを攻撃されにくく設計する必要がある。

この記事で分かること

この記事では、

1. 電話によるソーシャルエンジニアリングとは何か
2. なぜ2026年に重要になっているのか
3. 実際にどのような攻撃が観測されているのか
4. Help Deskがなぜ狙われるのか
5. MFAがあっても突破される理由
6. 社員が持つべき意識
7. Help Deskが持つべき意識
8. 技術的な対策
9. 運用面の対策
10. インシデント発生時の対応
11. 再発防止

を順番に説明します。

対象読者

主な対象は次の担当者です。

• 一般社員
• Help Desk担当者
• 情報システム担当者
• SOC / CSIRT
• ID管理担当者
• Microsoft Entra ID管理者
• Okta管理者
• Google Workspace管理者
• SaaS管理者
• コールセンター管理者
• 人事担当者
• セキュリティ教育担当者

Vishingとは

Vishingは、

Voice + Phishing

を組み合わせた言葉です。

簡単に言えば、

電話や音声通話を使って相手を信用させ、認証情報やシステムへのアクセスを取得する攻撃

です。

MITRE ATT&CKでは、

T1566.004 – Phishing: Spearphishing Voice

として正式に分類されています。MITREは、攻撃者が信頼できる人物になりすましたり、緊急性や不安を作り出したりして、音声通信を通じてシステムへのアクセスを得る手法として説明しています。

何が起きているのか

MandiantのM-Trends 2026は、2025年に世界各地で行った50万時間以上のインシデント調査を基にしています。

初期感染ベクトルでは、

という傾向が報告されています。

ただし、この11%を、

「世界中のサイバー攻撃の11%が電話攻撃」

と解釈してはいけません。

これはMandiantが2025年に対応した対象インシデントを基にした統計です。

全世界すべての企業を無作為抽出した統計ではありません。

実際に観測された攻撃

Google Threat Intelligenceは2026年1月、ShinyHuntersブランドの恐喝活動に関連して追跡しているUNC6661やUNC6671などが、Vishingを使った攻撃を行っていることを報告しました。

UNC6661では、攻撃者がIT担当者になりすまして社員へ電話し、

「会社でMFA設定を更新しています」

などと説明していました。

その後、

攻撃者
 ↓
社員へ電話
 ↓
「IT部門です」
 ↓
偽の社内SSOサイトへ誘導
 ↓
SSO資格情報を入力
 ↓
MFA Codeを入力
 ↓
攻撃者が認証情報を取得
 ↓
攻撃者の端末をMFA登録
 ↓
SaaSへ侵入

という攻撃が観測されています。

UNC6671についても、IT担当者を装ったVishingから認証情報とMFA Codeを盗み、少なくとも一部ではOkta環境へのアクセスを取得したことがMandiantから報告されています。

重要なのは、この活動についてMandiantが、

ベンダー製品の脆弱性を利用した攻撃ではない

と明記していることです。

なぜHelp Deskが狙われるのか

例えばFIDO2 Passkeyを利用しているユーザーを考えます。

攻撃者
 ↓
Passwordを盗む
 ↓
Passkeyが必要
 ↓
Loginできない

ここまでは安全です。

しかし攻撃者が、

Help Desk
 ↓
「スマートフォンをなくしました」
 ↓
「MFAを使えません」
 ↓
「今日中に重要な仕事があります」
 ↓
MFA Reset

を成功させれば、

認証機能そのものではなく、認証回復プロセスを攻撃できます。

Microsoftも、従来型のHelp Desk主導Account Recoveryについて、攻撃者がSupport Staffを操作して不正アクセスを取得するSocial Engineering Riskがあると説明しています。

MFAがあれば安全というわけではない

MFAは非常に重要です。

しかし、すべてのMFAが同じ強さではありません。

NIST SP 800-63-4では、OTPのように利用者が認証コードを手動入力する方式は、フィッシング耐性のある認証とはみなされません。攻撃者が偽サイト経由でコードを中継できるためです。

Microsoftも現在、

• Passkey / FIDO2
• Windows Hello for Business
• Certificate-based Authentication

などのフィッシング耐性認証を推奨しています。

MFA Fatigueと電話を組み合わせる攻撃

攻撃者がPasswordを既に持っている場合、

Login
 ↓
MFA Push
 ↓
Reject
 ↓
MFA Push
 ↓
Reject
 ↓
MFA Push

を繰り返す場合があります。

MITRE ATT&CKでは、

T1621 – Multi-Factor Authentication Request Generation

として整理されています。

さらに、

攻撃者から電話

「IT部門です。
先ほどからMFA通知が届いていると思います。
システム更新のため承認してください」

と組み合わせると、

MFA Fatigue
+
Authority
+
Urgency
+
Vishing

になります。

MITREもSpearphishing VoiceとMFA Request Generationが組み合わされる可能性を明記しています。

Caller IDを信用してはいけない

電話画面に、

03-xxxx-xxxx
社内IT
Microsoft
取引先

などと表示されても、それだけでは本人確認になりません。

FTCはCaller IDの名前や電話番号を攻撃者が偽装できる「Caller ID Spoofing」について警告しており、Caller IDを発信者確認に利用しないよう案内しています。

つまり、

知っている電話番号
=
知っている相手

ではありません。

攻撃者が利用する心理

Vishingは技術だけではありません。

人間の判断を操作します。

特に注意したいのが次の要素です。

最後の「知識」が特に危険です。

攻撃者が、

• 氏名
• メールアドレス
• 部署
• 役職
• 上司
• 社員番号
• 利用サービス

を知っていても、本人である証明にはなりません。

社員はどういう意識を持つべきか

「相手を疑う」のではなく「手続きを守る」

重要なのは、

「電話相手は全員攻撃者だ」

と疑うことではありません。

適切な考え方は、

相手が誰であっても本人確認ルールを変えない。

です。

社長でも、上司でも、IT担当者でも、取引先でも同じです。

緊急と言われたときほど手続きを省略しない

攻撃者は、

急いでいる
↓
確認を省略させる

ことを狙います。

そのため、

「緊急」という言葉は確認を省略する理由ではなく、追加確認する理由

と考えます。

IT担当者でもPasswordを聞かない

社員教育として非常に単純なルールを作れます。

Password
OTP
MFA Code
Backup Code
Passkey
Recovery Code

を電話相手へ渡さない。

本当にIT担当者だったとしても同じです。

身に覚えのないMFA通知は承認しない

自分がLoginしていないのに、

Approve sign-in?

が届いた場合、

Rejectして終わりではなくSecurityへ報告する

ことが重要です。

MITREも、ユーザーが自分で開始していないMFA要求を承認しないよう教育し、不審な要求を報告することを対策として挙げています。

「電話を切る」は失礼ではない

怪しいと感じた場合、

一度電話を切る
 ↓
社内ポータルを見る
 ↓
登録済みHelp Desk番号へ自分から電話

とします。

相手から指定された電話番号へCallbackしてはいけません。

Help Deskはどういう意識を持つべきか

Help Deskでは、

利用者を助けること

と、

利用者の要求をそのまま実行すること

を分ける必要があります。

特に、

Password Reset
MFA Reset
New MFA Enrollment
Device Registration
Privilege Change
Account Recovery

は普通の問い合わせではありません。

Security Operationです。

Help Deskで実装したい本人確認フロー

推奨例です。

Inbound Call
     ↓
Ticket作成
     ↓
Account変更要求か？
     ↓ YES
電話上の情報だけでは処理しない
     ↓
登録済み情報でOut-of-Band確認
     ↓
高リスクAccountか？
     ↓ YES
追加本人確認
     ↓
必要なら承認者
     ↓
Reset / MFA変更
     ↓
本人へ別経路で通知
     ↓
Identity Log監視

Google/Mandiantも、Password ResetやMFA変更のようなAccount Changeについて、より強力な多層本人確認をHelp Deskへ導入することを推奨しています。

本人確認に使わない方がよい情報

次の情報だけで本人確認を成立させてはいけません。

氏名
社員番号
部署
電話番号
メールアドレス
上司名
生年月日
会社名
役職

攻撃者が事前調査によって取得できる可能性があるためです。

高リスク操作では別経路確認を行う

例えば、

電話
 ↓
MFA Reset依頼

を受けた場合、

同じ電話の中だけで本人確認を完了させず、

既存の管理端末
登録済み連絡先
社内承認Workflow
対面確認
信頼済みVideo Verification

など別のTrust Pathを利用します。

Mandiantは脅威が高まっている状況では、本人・有効なID・Visual Confirmationを組み合わせた強い本人確認も提案しています。

ベンダーを名乗る電話にも注意する

攻撃者が、

Microsoft Support
Okta Support
通信事業者
SaaS Vendor
外部保守会社

を名乗る場合があります。

Mandiantは第三者ベンダーSupportを装ってHelp DeskへVishingするケースも観測しています。推奨策として、着信電話を一度終了し、登録済みの正規連絡先からVendor Account Managerへ独立して確認する方法を挙げています。

技術的対策1：フィッシング耐性MFAへ移行する

優先度は高いです。

候補として、

• FIDO2 Security Key
• Passkey
• Windows Hello for Business
• Certificate-based Authentication

などがあります。

NISTもフィッシング耐性について、利用者の注意力だけに頼らず偽VerifierへのAuthenticator Secretや有効なAuthenticator Outputの開示を防ぐAuthentication Protocolの性質として定義しています。

技術的対策2：MFA Reset権限を最小化する

Help Desk全員が、

全社員
+
管理者
+
役員

のMFAを自由にResetできる設計は避けます。

特に、

• Global Administrator
• Authentication Administrator
• Security Administrator
• Helpdesk Administrator
• Password Administrator
• Privileged Authentication Administrator

などIdentity関連の管理Roleは強く保護する必要があります。

Microsoftも管理RoleについてPhishing-resistant MFAを要求することを推奨しています。

技術的対策3：Recovery Credentialを短命にする

Microsoft EntraではTemporary Access Pass（TAP）をAccount RecoveryやPasswordless Method登録に利用できます。

TAPは時間制限付きCodeとして構成でき、Single-useにもできます。

重要なのは、

永続的なRecovery Password

より、

短時間
+
用途限定
+
可能なら一回限り

にする考え方です。

技術的対策4：新しいMFA登録を監視する

攻撃成功時には、

Password Reset
        ↓
MFA Reset
        ↓
New MFA Enrollment
        ↓
Login

というIdentity Eventが発生する可能性があります。

MandiantはOktaやEntra IDについて、

• Authentication Event
• MFA Lifecycle Event
• Authentication Method変更
• Conditional Access変更
• Device Registration

などをSIEMへ取り込むことを推奨しています。

特に強い検知シグナル

例えば次の組み合わせです。

Password Reset
      +
MFA Reset
      +
10分後
      +
New Device Registration
      +
普段と違うASN
      +
大量SaaS Access

個別のイベントだけを見るより、

Identity Eventを時系列で相関させる

方が有効です。

MITRE ATT&CKも、Voice Callの後にBrowser NavigationやRemote Management Tool実行が起きるケース、MFA PushやConsent Grantとの相関監視をVishing Detectionとして挙げています。

インシデントが疑われた場合の対処

「電話でMFA Codeを渡してしまった」

「Help DeskでMFAをResetしてしまった」

場合、放置してはいけません。

まずIdentityを封じ込めます。

MandiantはVishing/SaaS侵害が疑われる場合、

• 侵害Accountの無効化
• Active Session TokenのRevoke
• OAuth AuthorizationのRevoke
• MFA Registrationの制限
• Password Resetの制限
• Remote Accessの制限

をImmediate Containmentとして推奨しています。

インシデント対応フロー

Vishing疑い
 ↓
対象Account特定
 ↓
Account一時停止
 ↓
Active Session Revoke
 ↓
OAuth Token確認・Revoke
 ↓
MFA Method確認
 ↓
不正Device削除
 ↓
Password / Credential再発行
 ↓
SaaS Login Log確認
 ↓
Data Export確認
 ↓
Privilege変更確認
 ↓
影響範囲確認
 ↓
安全な本人確認
 ↓
Account復旧

単純なPassword Resetだけで終わらせないことが重要です。

すでにSession Tokenが盗まれている場合、Passwordを変更しても既存Sessionが残る可能性があるためです。MandiantもContainmentではSession TokenとOAuth AuthorizationのRevokeを優先しています。

動作確認

対策導入後は、次のScenarioを社内演習します。

Scenario 1

「スマホを紛失しました。
MFAを今すぐ解除してください」

期待動作：

電話だけではResetしない
↓
既定の本人確認Workflowへ

Scenario 2

「役員です。
会議が始まるので特別対応してください」

期待動作：

役職に関係なく同じ本人確認

Scenario 3

「Vendor Supportです。
障害対応のため管理Accountが必要です」

期待動作：

Inbound Call終了
↓
登録済みVendor Contactへ別経路で確認

Mandiantも内部Vishing / Phishing演習によってUser Trainingが機能しているか検証することを推奨しています。

再発防止

Resetを「問い合わせ対応」から「Security Workflow」へ変える

最も重要な変更です。

問い合わせ
↓
本人っぽい
↓
Reset

を、

Request
↓
Independent Verification
↓
Risk Assessment
↓
Approval
↓
Reset
↓
Notification
↓
Logging

へ変更します。

Help Deskに「断る権限」を与える

社員教育だけではなく、組織文化も重要です。

Help Desk担当者が、

役員だから
上司だから
取引先だから
急いでいるから
怒っているから

という理由で手続きを省略させられない状態を作ります。

本人確認手順を守った結果、業務が数分遅れた担当者を責めないことが重要です。

「引っかかった人を責める」運用にしない

Vishingでは、早期申告が被害を大きく左右します。

「MFAを承認してしまいました」

と言い出しにくい文化を作ると、攻撃者へ時間を与えます。

Security Awarenessの目標を、

絶対に失敗しない社員

ではなく、

異常を早く止めて報告できる社員

に置く方が実務的です。

注意点・よくある誤解

誤解1：Security Awareness研修をすれば解決する

不十分です。

研修は必要ですが、人間は必ず判断ミスをします。

したがって、

Training
+
Technical Control
+
Identity Verification
+
Logging
+
Incident Response

が必要です。

誤解2：Passkeyを入れればHelp Desk攻撃も防げる

完全ではありません。

PasskeyそのものはRemote Phishingに強い仕組みですが、Help DeskがAccount Recoveryを経由してPasskeyやMFAを解除できる場合、Recovery Workflow側が別の攻撃面になります。

認証を強くするだけでなく、Authenticator Lifecycle全体を守る必要があります。NIST SP 800-63-4もAuthenticator BindingやRecoveryを認証ライフサイクルの一部として扱っています。

誤解3：Caller IDが社内番号なら安全

安全ではありません。

Caller ID Spoofingがあるためです。FTCもCaller IDを発信者本人確認へ利用しないよう注意しています。

誤解4：声を知っているから安全

声だけに依存した本人確認は避けるべきです。

重要操作では、Voiceとは独立した信頼済みChannelを使用します。

誤解5：MFA Resetだけ監視すればよい

不十分です。

攻撃者はMFA変更後、

Device Registration
OAuth Consent
Mailbox Access
Data Export
Role Change
Session Persistence

へ進む可能性があります。

MandiantもIdentity Providerだけではなく、その後のSaaS Authorizationや大量Data Exportを監視する必要性を指摘しています。

批判的に見るべき3つのポイント

1. 「Vishing 11%」だけを見て電話対策へ予算を集中させるのは危険

M-Trends 2026でも最大のInitial Infection Vectorは依然として脆弱性悪用の32%です。

したがって、

Vishing対策を強化
↓
Patch Managementを削減

では本末転倒です。

2. 厳しすぎる本人確認は業務障害にもなる

すべてのPassword Resetについて、

本人出社
+
上司承認
+
Security承認

を要求すれば安全性は高くなります。

しかしリモートワークや海外拠点では運用不能になる可能性があります。

操作Riskに応じて、

一般Account
Privileged Account
Break-glass
Executive
Vendor

を分けるべきです。

3. Video確認も万能ではない

Video本人確認も一つの手段ですが、単独の絶対的な本人証明と考えるべきではありません。

重要なのは、

一つの確認方法

ではなく、

複数の独立したTrust Signal

を組み合わせることです。

どういう意識を組織全体で持つべきか

最終的には次の5つに集約できます。

1. 「知っている人」ではなく「確認されたIdentity」を信用する

声、名前、役職、電話番号はIdentityそのものではありません。

2. SecurityはIT部門だけの仕事ではない

Help Desk
HR
総務
Call Center
Reception
Vendor Management

もIdentity Security Boundaryです。

3. 緊急時ほど通常手順を守る

攻撃者は例外を作らせようとします。

例外処理ほど強い承認を要求します。

4. AuthenticationよりRecoveryが弱くならないようにする

強いPasskey
+
弱い電話Recovery

ではIdentity System全体として弱点が残ります。

5. 「気付いたらすぐ言う」を評価する

攻撃を完全にゼロにすることは現実的ではありません。

重要なのは、

Detect
↓
Report
↓
Contain
↓
Recover

を速くすることです。

まとめ

2026年のSocial Engineering対策では、

「怪しいメールを開かない」だけでは不十分です。

Mandiantの2025年インシデント調査では、Voice Phishingが11%へ増加し、Initial Infection Vectorの第2位となりました。

攻撃者は、

社員
↓
Help Desk
↓
Password Reset
↓
MFA Reset
↓
SaaS Login

という、人間が管理するIdentity Workflowそのものを攻撃できます。

そのため最も重要なのは、

「社員が攻撃を見抜くこと」から、「社員が見抜けなくても重要操作が簡単には成立しないこと」へ考え方を変えることです。

電話を禁止する必要はありません。

電話を、

本人確認手段

ではなく、

問い合わせを開始する通信手段

として扱います。

そして、

Independent Verification
+
Phishing-resistant MFA
+
Strong Recovery
+
Least Privilege
+
Identity Logging
+
Rapid Incident Response

を組み合わせます。

これが、Vishingが一般化する環境で組織が持つべき基本姿勢です。

FAQ

Q. IT部門から電話が来たらどうすればよいですか？

電話を受けること自体は問題ありません。

ただしPassword、OTP、Recovery Codeを伝えたり、身に覚えのないMFAを承認したりしないでください。

重要操作を求められた場合、一度電話を終了し、社内ポータルなどに登録された正規Support Channelから確認します。

Q. MFAがあればVishingは防げますか？

MFAは非常に有効ですが、種類によります。

SMS、OTP、PushはSocial Engineeringで利用される可能性があります。NISTやMicrosoftはFIDO2 / PasskeyなどのPhishing-resistant Authenticationを推奨しています。

Q. Help Deskでは何を最優先で変更すべきですか？

Password Reset、MFA Reset、Device Registrationについて、Inbound Callだけでは完結しない本人確認Workflowへ変更することを推奨します。

Q. 上司からの電話なら本人確認を省略してよいですか？

推奨できません。

役職が高いAccountほど侵害時の影響も大きいため、むしろ強い本人確認が必要です。

Q. 電話番号をCallbackすれば安全ですか？

着信履歴に表示された番号へそのままCallbackするのではなく、会社Directoryや契約情報など、別途管理された信頼済み連絡先を利用してください。

Q. インシデント後はPasswordを変えるだけで十分ですか？

不十分な場合があります。

Active Session、OAuth Token、登録済みMFA Method、新規Device、SaaSアクセスなども確認する必要があります。MandiantもSession TokenとOAuth AuthorizationのRevokeをImmediate Containmentとして推奨しています。

参考情報

参考情報

Mandiant / Google Cloud：M-Trends 2026

M-Trends 2026: Data, Insights, and Strategies From the Frontlines

英語版：
https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026

日本語版：
https://cloud.google.com/blog/ja/topics/threat-intelligence/m-trends-2026

M-Trends 2026 Executive Edition

https://cloud.google.com/security/resources/m-trends-executive-edition

Google Threat Intelligence：Vishing / ShinyHunters

Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft

https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft

Google Threat Intelligence / Mandiant：Vishing防御ガイド

Guidance from the Frontlines: Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS

英語版：
https://cloud.google.com/blog/topics/threat-intelligence/defense-against-shinyhunters-cybercrime-saas

日本語版：
https://cloud.google.com/blog/ja/topics/threat-intelligence/defense-against-shinyhunters-cybercrime-saas

NIST SP 800-63-4：Digital Identity Guidelines

NIST SP 800-63-4

https://pages.nist.gov/800-63-4/

SP 800-63B: Authentication and Authenticator Management

https://pages.nist.gov/800-63-4/sp800-63b.html

Authenticator / Phishing Resistance

https://pages.nist.gov/800-63-4/sp800-63b/authenticators/

Security Considerations

https://pages.nist.gov/800-63-4/sp800-63b/security/

MITRE ATT&CK：Voice Phishing

T1566.004 – Phishing: Spearphishing Voice

https://attack.mitre.org/techniques/T1566/004/

MITRE ATT&CK：MFA Fatigue

T1621 – Multi-Factor Authentication Request Generation

https://attack.mitre.org/techniques/T1621/

MITRE ATT&CK：Account Manipulation

T1098 – Account Manipulation

https://attack.mitre.org/techniques/T1098/

Microsoft Entra ID：フィッシング耐性MFA

Require phishing-resistant MFA for administrator roles

https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-admin-phish-resistant-mfa

Microsoft Entra ID：Temporary Access Pass

Temporary Access Pass

https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-temporary-access-pass

Microsoft Entra ID：Account Recovery

Account recovery overview

https://learn.microsoft.com/en-us/entra/identity/authentication/concept-account-recovery-overview

Microsoft：Phishing-resistant MFA

Implement phishing-resistant MFA

https://learn.microsoft.com/en-us/security/zero-trust/sfi/phishing-resistant-mfa

CISA：Multi-Factor Authentication

Require Multifactor Authentication

https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/require-multifactor-authentication

FTC：Caller ID Spoofing・電話詐欺

Phone Scams

https://consumer.ftc.gov/articles/phone-scams