IDとパスワードだけのログインは、使い回しや漏えいしたパスワードを突くリスト型攻撃、フィッシングによる窃取に弱く、不正ログインの被害が後を絶ちません。対策として広く使われているのが、ログインのたびに変わる使い捨てのパスワード「ワンタイムパスワード（OTP）」です。取引先や監査、社内のセキュリティ方針から二要素認証の導入を求められ、検討を始めた担当者も多いのではないでしょうか。
もっとも、いざ自社に入れようとすると「SMSと認証アプリ、ハードウェアトークンのどれを選べばいいのか」、自前で作り込むか既存の製品を導入するか、費用はどのくらいかと、判断すべき点が次々に出てきます。OTPが何かはおおよそ分かっていても、知りたいのは「で、自社にはどう入れるのか」という具体のはずです。
本記事では、OTPの受け取り方式と生成方式の違いを押さえたうえで、「自社サービスへの実装」と「社内の認証基盤への製品導入」という2つの導入パターンの見分け方を軸に、方式の選び方、導入の流れ、実装手段別の費用相場、導入後の注意点までを順に解説します。自社に合う進め方を判断するための材料としてご活用ください。
目次
一括ダウンロードする
ワンタイムパスワード（OTP）とは？二要素認証での役割と生成方式のちがい
ワンタイムパスワード（OTP）は、ログインや取引の認証のたびに新しく発行され、一度きり・短時間しか使えない使い捨てのパスワードです。固定パスワードに加えてOTPの入力を求めることで、仮にIDとパスワードが漏れても、その瞬間のOTPがなければログインできない状態をつくれます。これがOTPを「二要素認証・多要素認証の一要素」として使う狙いです。
OTPは「どう生成するか（生成方式）」と「どう利用者へ届けるか（受け取り方式）」の2軸で整理すると理解しやすくなります。まずは生成方式から押さえ、受け取り方式はこのあとの比較で詳しく見ていきます。方式ごとの違いと選び方を先に確認したい場合は、「OTPの受け取り方式を比較」から読み進めても構いません。
OTPの生成方式（TOTP・HOTP・チャレンジレスポンス・メッセージ方式）のちがい
OTPの生成方式は、主に次の4つに分かれます。現在のスマートフォンの認証アプリやハードウェアトークンで主流なのは、時刻をもとにする「TOTP」です。
- 時刻同期方式（TOTP）：現在時刻をもとに一定間隔でコードを生成する方式です。IETFの標準仕様（RFC 6238）では更新間隔の既定値を30秒と定めており、Google認証システムやMicrosoft Authenticatorなどの認証アプリが採用しています。
- カウンタ同期方式（HOTP）：ボタンを押すなどのイベントごとにカウンタ（使用回数）を進めてコードを生成する方式です（RFC 4226）。時間ではなく操作回数を基準にするため、生成からの経過時間に縛られません。
- チャレンジレスポンス方式：サーバーが提示する一時的な値（チャレンジ）に対し、利用者側の端末やトークンが計算した答え（レスポンス）を返す方式です。専用のトークンや一部の金融機関のシステムなどで使われます。
- メッセージ方式：サーバー側で生成したコードを、SMSやメールで利用者へ送信する方式です。利用者は専用アプリやトークンを用意せずに受け取れます。
TOTPはHOTPを時刻ベースに拡張したもので、短時間で無効になるコードを発行できる点が特徴です。「30秒」はRFCが定める既定値であり、設定で変えられるシステムもあるため、「おおむね30秒ごとに更新される」と理解しておくとよいでしょう。
出典・参考資料（2件）
OTP「導入」の2つのパターン｜自社サービスへの実装と社内製品導入
「OTPを導入する」と言っても、自社が置かれた状況によって進め方は大きく2つに分かれます。どちらのパターンに当てはまるかで、選ぶ手段も費用も担当部署も変わるため、最初に自社がどちらかを見極めておくと、以降の検討が進めやすくなります。
パターン①：自社のサービス・アプリにOTPを組み込む（開発）
自社が提供するWebサービスや会員向けアプリのログイン・取引認証にOTPを加えるケースです。守る対象が自社の顧客・会員で、認証の処理を自社サービスの中に実装する必要があります。
多くは認証機能をAPIやCPaaS（通信機能をクラウドで提供するサービス）、認証基盤を外部提供するCIAM（顧客向けID管理）を使って組み込み、開発リソースが前提になります。SMS送信やTOTP検証の仕組みを自前でゼロから作るより、認証APIを利用して実装負荷と運用リスクを抑える進め方が一般的です。
パターン②：社内の認証基盤に製品を導入する
一方、守る対象が自社の従業員で、社内システムやSaaS・VPNへのログインを強化したいケースでは、ID管理基盤（IDaaS）や多要素認証（MFA）製品を導入するのが近道です。
開発は基本的に不要で、製品の設定とActive Directory（AD）やLDAPといった既存のID管理との連携が中心になります。認証アプリ（TOTP）に対応したID基盤を入れる、あるいは物理的なセキュリティキーを従業員に配布する、といった選択肢がここに含まれます。
判断の目安は、守る対象が顧客・会員か従業員か、認証を自社サービスに実装する必要があるか、社内に開発リソースがあるかの3点です。顧客向けサービスへの組み込みならパターン①、社内ログインの強化ならパターン②が基本線になります。
本記事ではこのあと、受け取り方式の選び方から費用・手順までを、相談先も見つけやすいパターン②（社内の認証基盤への製品導入）に沿って解説します。パターン①（自社サービスへの実装）を検討している方は、次に紹介する記事で組み込み型の選択肢を確認できます。
パターン①のように自社のWebサービスやアプリへ認証そのものを組み込みたい場合は、OTPに限らず、パスキーや生体認証に対応した認証SDK・APIを機能や料金で比べて選ぶことになります。組み込み型の認証の選択肢を具体的に検討したい方は、以下の記事もあわせてご覧ください。
パスワードレス認証とは？自社サービスに組み込む生体認証・パスキー対応SDK/APIを機能・料金で比較【選び方も解説】
自社アプリやWebサービスのログインを、パスワードに頼らない方式へ切り替えたいと考える開発・プロダクト部門が増えています。パスワードの使い回しやフィッシングによる不正ログインが後を絶たず、パスキーやFIDO2といったパスワードレス認証が、そ…
OTPの受け取り方式を比較（SMS・メール・認証アプリ・ハードウェアトークン）
ここからは、利用者がOTPをどう受け取るかという「受け取り方式」を比較します。安全性・コスト・使い勝手・運用負荷のバランスが方式ごとに異なり、どれを選ぶかが導入設計の軸になります。
| 受け取り方式 | SMS | メール | 認証アプリ（TOTP） | ハードウェアトークン |
|---|---|---|---|---|
| 安全性 | やや低い。公的なデジタルID標準（NIST SP 800-63-4）では電話網（PSTN）経由の認証は「制限付き」の扱いで、SIMスワップや番号ポーティング、不達のリスクが指摘される | 低い。同標準ではメールを認証コードの送付に使うことは推奨されていない（傍受・経路の改ざんなどのリスク） | 高い。コードが端末内で生成され、通信経路に乗らない | 高い。独立した専用端末でコードを生成・保持する |
| コスト | 送信ごとの従量課金が発生する | 比較的安価 | アプリ自体は無料。ID基盤側の費用が中心 | 端末の購入・配布コストがかかる |
| 使い勝手・運用負荷 | 利用者は専用アプリ不要で分かりやすいが、不達時の問い合わせ対応が生じやすい | 利用者には身近だが、メール遅延・迷惑メール振り分けのトラブルが起きやすい | 初回のQR読み取り設定が必要。機種変更時の移行に注意 | 持ち運びと紛失・故障時の再発行の運用が必要 |
各方式の特性は一般的な傾向をまとめたものです。安全性の評価はNIST SP 800-63-4の記載に基づきます。
公的な標準では、SMS（電話網経由）は使用を禁じられているわけではないものの「制限付き」とされ、メールでのコード送付は推奨されていません。認証アプリのTOTPやハードウェアトークンは、コードが通信経路を通らないぶん、SMS・メールより相対的に安全性が高いと位置づけられます。手軽さを取るか安全性を取るかで、自社の要件に合う方式を選ぶことになります。
出典・参考資料（1件）
- 出典：NIST Special Publication 800-63-4「Digital Identity Guidelines」（§3.1.3.2〜3.2.9）｜NIST（リンク）
自社に合うOTPの選び方
ここからは、導入パターンと受け取り方式を自社のケースに当てはめ、候補を絞る判断軸を整理します。次の観点を順に確認していくと、自社に合う方式が見えてきます。
対象ユーザーは誰か
認証を強化したいのが自社サービスの顧客・会員であれば、不特定多数が使うため、専用端末の配布が難しくSMSや認証アプリが現実的です。社内の従業員が対象なら、認証アプリや、より安全性の高いハードウェアトークンも配布・管理の対象にできます。守る相手が誰かで、取り得る手段の幅が変わります。
既存システムとの連携は必要か
社内導入（パターン②）では、Active DirectoryやLDAPでのアカウント管理、各SaaSへのシングルサインオン（SSO）との連携が実務上の要になります。既存のID管理と連携できるID基盤を選べば、アカウントの棚卸しや退職者の権限削除まで一元化でき、運用の手間を抑えられます。連携の可否と対応範囲は、製品選定で優先的に確認したい点です。
コストとUX（使い勝手）のバランスはどうか
SMSは導入が手軽な半面、送信ごとに費用がかかり、利用者数や認証頻度が多いほど運用コストが積み上がります。認証アプリはアプリ自体が無料で大規模でもコストを抑えやすい一方、初回設定の案内が要ります。ログインのたびにOTP入力を挟むと離脱や「カゴ落ち」につながることもあるため、安全性とUXのどちらをどこまで優先するかを、対象の業務ごとに見極める必要があります。
求められる安全性の水準はどこまでか
扱う情報の重要度が高い業務や、フィッシング対策を重視する場合は、SMS・メールよりTOTPやハードウェアトークンが適します。さらに高い耐性が必要なら、OTPの先にあるパスキー（FIDO2）などのフィッシング耐性のある方式も視野に入ります。この点は後半の「限界と次の一手」で詳しく触れます。
OTP導入の流れと手順（検討→選定→PoC→AD/LDAP連携→展開→運用）
社内の認証基盤にOTPを導入する場合の進め方を、検討から運用まで通しで示します。導入後に設定する項目だけでなく、その前段の検討・選定まで含めて把握しておくと、手戻りを防げます。
- 対象と方式の検討：どのシステム・業務のログインを守るか、対象ユーザーは誰かを整理し、SMS・認証アプリ・ハードウェアトークンのどの方式を軸にするかの当たりをつけます。
- 製品・サービスの選定：既存のAD/LDAP連携やSSOの要件、コスト、対応する認証方式を照らし合わせ、候補を2〜3社に絞ります。
- PoC（実機検証）：実際の端末・業務フローで試し、利用者の使い勝手と管理者の運用負荷を確認します。ハードウェアトークンは配布前に実機で検証しておくと安心です。
- 既存システムとの連携設定：Active DirectoryやLDAPと連携し、アカウントの自動連携（プロビジョニング）やSSOを設定します。認証の通知手段やパスワードポリシーもここで整えます。
- 利用者への展開：認証アプリの初期設定やトークンの配布を行い、利用者向けの手順案内を用意します。段階的に対象を広げると、問い合わせ対応を分散できます。
- 運用：端末紛失・機種変更時の再発行、不達時の対応、定期的なアカウント棚卸しを運用フローに組み込みます。
自社サービスへの実装（パターン①）の場合も、対象の見極め・方式選定・検証・段階展開という流れは共通です。違いは、連携設定の代わりに認証APIの組み込み開発が入る点にあります。
OTP導入・運用にかかる費用の相場（実装手段別）
費用は「どの受け取り方式・どの導入手段を選ぶか」で構造が変わります。手段別に、何にお金がかかるのか（課金の単位）を押さえておくと、見積もりの比較がしやすくなります。
- SMS方式：OTPを1通送るごとの送信従量課金が中心です。単価は利用するSMS送信サービスや送信通数・送信元表示で変わるため、各サービスの公式料金で確認します。認証の回数が多いほど費用が積み上がるため、利用者数と認証頻度から試算します。
- 認証アプリ（TOTP）方式：アプリ自体は無料で、費用は主にID基盤（IDaaS）側の月額に集約されます。1ユーザーあたり月額数百円程度からが目安で、利用者が多くても単価を抑えやすい方式です。
- ハードウェアトークン方式：トークン本体の初期費用＋配布・運用コストが中心です。本体は1本あたり数千円〜1万円程度（モデルや販路で変わります）で、サブスクリプションで配布・保証・予備まで含めて提供する形態もあります。紛失・故障時の予備や再発行の体制も含めて見積もります。
認証アプリ型のID基盤の例として、CloudGate UNOの料金は2026年11月時点で、Standard Plusプランが月額440円（税込）、Enterprise Plusプランが550円（税込）、Smart Packプランが660円（税込）のいずれも1ユーザー単位で、別途初期費用がかかります。
ハードウェアトークン型では、YubiKeyをサブスクリプションで導入するYubiKey as a Serviceが、同時点で200ライセンスから・契約期間3年または5年で、料金はティアや配布条件に応じた個別見積もりとされています。いずれも最新の料金は各社の公式情報でご確認ください。
自社サービスへ実装するパターン①の場合は、SMS送信やAPI呼び出しの従量課金が中心で、顧客向けのID基盤（CIAM）を使うときはその月額が加わる構造になります。組み込み型の料金は製品ごとに幅があるため、前掲の認証SDK・APIの比較記事もあわせてご確認ください。
一括ダウンロードする
OTP導入後の注意点とリスク対策
OTPは導入して終わりではなく、運用で生じる課題への備えが欠かせません。ここでは、導入後に実際に起きやすい運用面の注意点と対策を整理します（OTP自体が突破されるリスクは次の章で扱います）。
- ログインの手間とUX低下：認証の一手間が増えるため、顧客向けサービスでは離脱・カゴ落ちにつながることがあります。重要な操作時だけOTPを求めるなど、業務ごとに適用範囲を調整します。
- 端末紛失・機種変更によるロックアウト：認証アプリを入れたスマートフォンを失うと本人もログインできなくなります。機種変更前の移行手順や、管理者による再発行の運用をあらかじめ決めておきます。
- SMSの不達・受信トラブル：SMSは通信事業者や設定の影響で届かないことがあり、SIMの差し替え・番号移管に伴うリスクも指摘されています。不達時に別の手段へ切り替えられる設計にしておくと安心です。
- 問い合わせの増加：導入直後は「コードが届かない」「設定が分からない」といった問い合わせが増えます。利用者向けのFAQや手順書を用意し、ヘルプデスクの体制を整えておきます。
多要素認証はアカウントの不正利用対策として高い効果が報告されています。Microsoftは自動化された不正ログイン攻撃の99.9%以上をブロックできるとしています。ただしこれは主に機械的・大量型の攻撃を対象とした数値で、後述するリアルタイムの中間者攻撃はこの例外にあたる点に注意が必要です。
出典・参考資料（2件）
OTPだけでは不十分？限界と次の一手（リスクベース認証・多層防御・パスキー）
OTPは固定パスワードより安全ですが、万能ではありません。利用者が入力したOTPを、攻撃者が用意した偽サイトがリアルタイムで横取りして本物のサイトに転送する「中間者（AiTM）フィッシング」では、OTPを使っていても突破され得ます。これはSMSに限らず、認証アプリのTOTPやハードウェアトークンのOTPにも共通する、OTPという手段そのものの限界です。
かつてはワンタイムパスワードによる認証を行えばフィッシング耐性があると考えられていたが、利用者に送付されるワンタイムパスワードをフィッシャーが盗んで悪用するリアルタイムフィッシング攻撃により被害が多発した結果、単にワンタイムパスワードを利用するのみではフィッシング耐性を有するとはいえなくなっている。
出典：フィッシング対策ガイドライン 2026年度版｜フィッシング対策協議会（§4.2.1、2026年5月29日）
こうした背景から、より強い対策が求められる領域では、OTPの先にある方式への移行が進んでいます。たとえば金融分野では、金融庁が主要行等向けの監督指針を2026年2月に改正し、インターネットバンキングの重要な操作について、フィッシングに耐性のある多要素認証の実装・必須化を求めています。
ログイン、出金など、重要な操作時におけるフィッシングに耐性のある多要素認証（例：パスキーによる認証、PKI（公開鍵基盤）をベースとした認証）の実装及び必須化（デフォルトとして設定）
出典：主要行等向けの総合的な監督指針 新旧対照表 Ⅲ－３－８｜金融庁（2026年2月27日改正）
これは金融機関のインターネットバンキングを対象とした要件ですが、「素のOTPを超えて、フィッシング耐性のある認証（パスキーやPKI）へ」という方向性は、一般企業の認証設計を考えるうえでも示唆に富みます。OTP導入を入り口としつつ、次の一手として以下を検討する価値があります。
- リスクベース認証：いつもと違う端末・場所・時間帯のログインなど、リスクが高い場合にだけ追加の認証を求め、通常時のUXを保ちます。
- 多層防御：OTPを他の対策（アクセス制御、不正検知、端末の安全性チェックなど）と組み合わせ、1つの方式が破られても全体で守れるようにします。
- パスキー（FIDO2）：公開鍵暗号を使い、偽サイトに認証情報を渡さない仕組みで、中間者フィッシングに耐性があります。
自社の要件に合わせて、OTPで足場を固めつつ、将来的にパスキーなどのフィッシング耐性のある認証へ発展させられる製品を選んでおくと、乗り換えの手戻りを避けられます。
次の一手として挙げたリスクベース認証について、その仕組みや多要素認証との違い、具体的な導入手段をさらに詳しく知りたい方は、以下の記事で解説しています。
リスクベース認証とは？仕組み・多要素認証（MFA）との違い・導入手段をわかりやすく解説
会員サイトやECサイト、金融サービスへの不正ログイン・アカウント乗っ取りが後を絶ちません。ID・パスワードだけの認証では、パスワードが漏えいした時点で第三者の侵入を防げず、かといって全員に毎回追加認証を課すと利用者の離脱を招きます。セキュリ…
出典・参考資料（2件）
OTP導入に対応したサービス
ここまで見てきたOTPの導入は、受け取り方式の「形」によって相談先が変わります。ここでは、認証アプリ（TOTP）型のID基盤と物理トークン型という、形態の違いがわかる例を1つずつ取り上げます。他の選択肢も含めて広く比べたい場合は、本章の末尾にある多要素認証システムの比較記事もあわせてご覧ください。
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNOは、シングルサインオン（SSO）・多要素認証・アクセス制限・ID管理を1つにまとめた国産のクラウド型ID基盤（IDaaS）です。認証アプリによるOTPに対応し、Active Directory連携やアカウントの自動連携（プロビジョニング）まで含めて社内の認証をまとめて強化できます。
開発元のインターナショナルシステムリサーチはFIDOアライアンスに2014年から参画し、パスキー（FIDO2）によるパスワードレス認証も提供しているため、OTPを入り口に、将来フィッシング耐性のある認証へ発展させたい企業にも向きます。
認証方式を切り替えると運用面にどのような変化があるのか、開発元のインターナショナルシステムリサーチは導入後の効果について次のように述べています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。
2. YubiKey as a Service（株式会社インターナショナルシステムリサーチ）
物理的なセキュリティキーでログインを守りたい場合の選択肢が、YubiKey as a Serviceです。買い切りではなくサブスクリプションでYubiKeyを法人に供給する形で、契約期間中の長期保証や、増員・紛失に備えた毎年25%分の無償予備キー、出荷時カスタマイズが標準で付きます。
機種によってはOATH（TOTP）にも対応し、FIDO2/WebAuthnによるフィッシング耐性のある認証も利用できます。認証アプリより高い安全性を、端末管理の負担を抑えつつ導入したい企業に適した形態です。
認証アプリではなく物理キーが選ばれるのはどのような現場なのか、同社は次のように説明しています。
派遣社員や外部委託先が多い企業、または屋外の建設現場やメンテナンス現場など、スマートフォンの使用が困難な環境を有する企業に適しています。YubiKeyは、水に落としても泥が付いても壊れないため、過酷な環境下でも安定して動作します。
ここでは代表的な2つのサービスを取り上げましたが、認証方式や料金、タイプ別の選び方を含めて多要素認証システム全体を見比べたい場合は、以下の記事で主要なサービスを詳しく比較・解説しています。導入する製品の候補を広く検討したい方は、あわせてご覧ください。
多要素認証（MFA）システムおすすめ17選を徹底比較｜認証方式・料金・タイプ別の選び方
ID とパスワードだけのログインは、もはや「鍵をかけていない」のと同じ状態に近づいています。攻撃者は流出したパスワードのリストを使い回し、本物そっくりの偽サイトで認証情報を抜き取り、正規利用者になりすまして社内システムやクラウドサービスへ侵…
まとめ
OTPの導入は、まず「自社サービスへの実装（パターン①）」か「社内の認証基盤への製品導入（パターン②）」かを見極めるところから始まります。そのうえで、受け取り方式（SMS・メール・認証アプリ・ハードウェアトークン）を安全性・コスト・使い勝手で比べ、対象ユーザーと既存システムとの連携を踏まえて選ぶのが基本の流れです。
一方で、OTPは中間者フィッシングには突破され得る限界も持ちます。まずはOTPで足場を固めつつ、リスクベース認証やパスキーといったフィッシング耐性のある方式へ発展させられる製品を選んでおくと、長く使える認証基盤になります。方式の当たりがついたら、候補のサービス資料を取り寄せて、自社システムとの連携可否や費用を具体的に比較してみてください。
一括ダウンロードする
ワンタイムパスワード導入に関するよくある質問
Q. ワンタイムパスワード（OTP）とは何ですか？
A. ワンタイムパスワード（OTP）は、ログインや取引の認証のたびに新しく発行され、一度きり・短時間しか使えない使い捨てのパスワードです。固定のIDとパスワードに加えてOTPの入力を求めることで、仮にパスワードが漏れても、その瞬間のOTPがなければログインできない状態をつくれます。二要素認証・多要素認証の一要素として広く使われています。
Q. OTPのTOTPとHOTPの違いは何ですか？
A. TOTPは現在時刻をもとに一定間隔（標準では30秒）でコードが変わる方式、HOTPはボタン操作などのイベント回数（カウンタ）をもとにコードが変わる方式です。現在はTOTPが主流で、Google認証システムやMicrosoft Authenticatorなどの認証アプリが採用しています。HOTPは経過時間に縛られないため、操作に時間のかかる現場などで使われることがあります。
Q. OTPの導入は自前実装と製品導入のどちらを選べばよいですか？
A. OTPの導入は、守る対象が自社サービスの顧客・会員なら自社サービスへの実装（API/CPaaS）、自社の従業員なら社内の認証基盤への製品導入（IDaaS/MFA）が基本の分かれ道です。
顧客向けサービスのログインに組み込むならパターン①の実装で開発リソースが前提になり、社内システムやSaaS・VPNのログインを強化するならパターン②の製品導入で、開発なしに設定と既存ID管理との連携で進められます。自社がどちらのパスかをまず見極めると、選ぶ手段も費用も担当部署も定まります。
Q. OTPの導入にサーバー構築は必要ですか？
A. OTPの導入は、クラウド型のID基盤（IDaaS）や認証APIを利用すれば、自社でのサーバー構築は基本的に不要です。認証アプリ（TOTP）対応のID基盤やSMS送信の認証APIは提供側がサーバーを運用するため、自社は設定や組み込みに集中できます。オンプレミスの認証サーバーを自社で構築する選択肢もありますが、運用負荷を抑えたい場合はクラウド型が主流です。
Q. OTPが届かない場合はどうなりますか？
A. OTPが届かない事態は主にSMSやメールで起こり、通信事業者側の経路・受信拒否設定・迷惑メールへの振り分けなどが原因になります。届かないとその利用者はログインできなくなるため、企業側は不達時に別の手段（再送信や他の受け取り方式）へ切り替えられる設計にしておくと安心です。コードが端末内で生成される認証アプリ（TOTP）は、そもそも通信経路を通らないため不達の心配がありません。
Q. 認証アプリでOTPを使う場合、スマホの機種変更時はどうすればよいですか？
A. 認証アプリ（TOTP）でOTPを使っている場合は、機種変更の前に旧端末で移行手続きや登録解除を行い、新端末で再度初期設定（QRコードの読み取りなど）をするのが基本です。移行せずに旧端末を手放すと、本人もログインできなくなる「セルフロックアウト」が起こり得ます。導入時に、利用者向けの移行手順と、管理者による再発行の運用をあらかじめ決めておくとトラブルを防げます。
Q. OTPは本当に安全ですか？
A. OTPは固定パスワードだけのログインより安全ですが、万能ではありません。偽サイトが利用者の入力したOTPをリアルタイムで横取りして本物のサイトへ転送する中間者（AiTM）フィッシングでは、OTPを使っていても突破され得ます。
これはSMSに限らず、認証アプリやハードウェアトークンのOTPにも共通する限界です。OTP単体を過信せず、リスクベース認証や多層防御、さらにフィッシング耐性のあるパスキー（FIDO2）などと組み合わせるのが安全です。
多要素認証（MFA）システムの料金・資料を一括チェック
MCB FinTechカタログでは、OTP・パスキーに対応した多要素認証システムやID基盤の最新資料を無料で一括請求できます。対応する認証方式・既存システムとの連携・料金を、各社の資料でまとめて比較できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
