パスワードの終焉
「パスワードはもういらない」——そんな言葉が、いよいよ現実味を帯びてきました。
もっと正確に言えば、「パスワードだけに頼る運用から、より安全な認証方式へ移行すべき時代になった」と言えるでしょう。
2026年現在、主要なWebサービスや大手プラットフォーム、金融機関などで「パスキー（Passkeys）」やパスワードレス認証への対応が進んでおり、パスワードのみに依存した運用は、セキュリティと運用効率の両面で明らかに限界を見せ始めています。
また、Verizonの「Data Breach Investigations Report 2024」などの統計では、ハッキング関連の侵害の多くで盗まれた資格情報（ID・パスワードなど）が悪用されていることが示されており、認証情報まわりが攻撃の重要な入り口になっていることがわかります。
参考：FIDO Alliance “Statistics Sources”（Verizon Data Breach Investigations Report 2024 など）
こうした「玄関口」のリスクを構造的に減らすことは、企業防衛における優先度の高い対策のひとつです。
本記事では、パスワード依存からの脱却を見据えた「パスキー」と「多要素認証（MFA）」の導入手順を、具体的なステップで整理します。
なぜ今、パスワード依存を見直すのか
従来のパスワード管理は、ユーザーの記憶力と、企業側のポリシー運用・教育・管理コストに大きく依存してきました。
しかし、現代の攻撃手口と利用サービス数の増加を踏まえると、次のようなリスクは無視しにくくなっています。
初期侵入の「売買」が一般化
攻撃者が企業ネットワークへの初期アクセス権（ID/パスワードなどの認証情報）を売買する「IAB（Initial Access Broker）」と呼ばれる市場が拡大しており、認証情報を起点とした侵入がビジネスとして成立する状況になっています。
フィッシング詐欺の高度化
本物そっくりの偽サイトでID／パスワードに加え、SMS認証コードやワンタイムパスコードをリアルタイムで盗み取る「中間者攻撃（AiTM）」などの手口が増えています。
このため、「パスワード＋SMSコード」といった従来型のMFAだけでは、すべてのフィッシング攻撃を防ぎきれないケースも出てきています。
こうした背景から、パスキー（Passkeys）などのフィッシング耐性に優れた認証方式が注目されています。
パスキーとは何か（FIDO2 / WebAuthn）
パスキーは、FIDO2／WebAuthnといった国際標準に基づき、「ユーザーが持っているデバイス（スマホやPCなど）」と「生体情報（顔・指紋）やPIN」を組み合わせることで、共有パスワードを使わずに認証する仕組みです。
サーバー側に保存されるのは公開鍵のみであり、秘密鍵はユーザーのデバイスから外へ出ないため、パスワード窃取やリスト攻撃といった従来型の攻撃に対して強い耐性を持ちます。
また、FIDO2／WebAuthnではサービスごと（ドメインごと）に公開鍵／秘密鍵のペアが発行され、認証時にはブラウザやOSがアクセス先ドメイン等を含むチャレンジに署名します。
これにより、「正規のドメインでのみ認証が成立する（オリジンバインディング）」という性質が実現され、フィッシングサイト側で同じ認証情報をそのまま悪用されるリスクを大きく抑えられます。
参考：FIDO2 / WebAuthn 概要（英語）
参考：Passwordless Authentication with FIDO2 and WebAuthn | Frontegg
パスキーとMFAを導入する「3つの現実的ステップ」
すべてを一度に入れ替える必要はありません。自社の現状に合わせて、次のようなステップで段階的に進めるのが現実的です。
ステップ1：現状のSaaS利用状況と認証方式を可視化
まずは自社で利用しているクラウドサービス（SaaS）や社内Webシステムをリストアップし、どの認証方式を使っているかを棚卸しします。
バラバラのID管理や、同じパスワードの使い回しが放置されていると、どこか一つでも認証情報が漏れれば、他システムへの「横展開」によって連鎖的に被害が広がるリスクがあります。
ステップ2：フィッシング耐性のある認証へ移行
従来の「パスワード ＋ SMS／メールによるワンタイムコード」といった方式から、よりフィッシング耐性の高い認証方式へ、優先度の高いシステムから順に切り替えます。
- パスキーの導入
FIDO2規格に基づいたパスキーでは、サービスごと（ドメインごと）に公開鍵／秘密鍵のペアを生成し、秘密鍵はユーザーのデバイス内に留まります。 - 認証時には、ブラウザやOSが実際のアクセス先のドメイン情報を含めたチャレンジに対して署名することで、フィッシングサイトでの再利用リスクを大幅に低減できます。
- 多要素認証（MFA）の必須化
少なくともシングルサインオン（SSO）の入口や、重要度の高いシステムには、生体認証や認証アプリ（TOTP、プッシュ通知など）を用いたMFAを必須にすることが推奨されています。
参考：New NIST guidance on passkeys: Key takeaways for enterprises（AAL2 / フィッシング耐性MFA）
ステップ3：シングルサインオン（SSO）による統合管理
個々のSaaSや社内システムごとにバラバラに設定・運用するのではなく、「GMOトラスト・ログイン」のようなSSO（IDaaS）サービスをハブとして導入し、統一ポリシーのもとで認証を集中管理する方法が現実的です。
このようなIDaaSを活用すれば、パスキー認証、IPアドレス制限、アクセス制御、ログ監査などを一括で適用でき、個別サービスごとの設定ミスや抜け漏れを減らしやすくなります。
参考：GMOトラスト・ログイン 各種機能
参考：パスキー認証（FIDO2）について - GMOトラスト・ログイン
参考：企業向けIDaaS「GMOトラスト・ログイン」、FIDOパスワードレス認証リリース（プレスリリース）
レガシーシステムはどう扱うべきか
古いシステムもすべてパスキー対応に改修する必要がるのか？
すべてのシステムを即座にパスキー対応へ改修する必要はありません。
GMOトラスト・ログインのようなSSOサービスを「ゲートウェイ」として活用し、まずはSSOの入口をパスキーやMFAで強化することで、レガシーシステムへのアクセス経路を安全にラップする方法が現実的です。
そのうえで、重要度や改修容易性を踏まえ、段階的に個別システム側の認証方式を見直していくアプローチが推奨されます。
終わりに：リスクを「ゼロ」にするのではなく、着実に減らす
パスワードそのものが即座に「悪」になるわけではありませんが、弱いパスワードや使い回しのパスワードが多くの侵害で悪用されているのは事実であり、パスワードに過度に依存しない設計が求められています。
FIDO2／パスキーやフィッシング耐性のあるMFA、SSO／IDaaSの活用は、初期侵入リスクの「相当な部分」を現実的なコストで減らすための有力な選択肢です。「自社の環境で何から着手すべきかわからない」という場合は、まずはパスキーやMFAに対応したSSO／IDaaSを試用し、自社ユーザーの使い勝手と運用イメージを具体化するところから始めるのが近道です。
GMOトラスト・ログインでは、パスキー（FIDO2）対応を含む各種機能を試せるトライアルが提供されています。自社にフィットするかどうかを検証する場として活用してみてください。