※本記事にはアフィリエイト広告（PR）を含みます。
「パスワードは90日ごとに変更」「大文字・小文字・数字・記号を必ず混在」——情シス担当なら一度は設定した、あるいは今も運用しているルールではないだろうか。だが、この「定期変更」と「複雑さの強制」という組み合わせは、最新のガイドラインではむしろ推奨されなくなっている。
定期変更を強制されたユーザーは、末尾の数字を1つ増やすだけで済ませがちになる。複雑さを強制されたユーザーは、覚えられずに付箋へメモしたり、複数サービスで使い回したりする。ルールは守られているように見えて、実態としては脆弱になる——という逆効果が各種の調査・分析で指摘されてきた。
本稿では、NIST SP 800-63Bなど最新のガイドラインや、IPA・総務省の公開情報をもとに、パスワード運用の考え方の更新点と、パスワードマネージャー・多要素認証（MFA）・パスキー（FIDO2）の位置づけを整理する。ガイドラインは今後も改訂され得るため、あくまで執筆時点の情報として参照してほしい。
なぜ「定期変更・複雑さ強制」が見直されたか
NISTの認証ガイドライン「SP 800-63B」は、2017年公開の版の時点で、パスワードが漏洩したという証拠がない限り、検証者（サービス提供側）が定期的な変更を強制すべきではないという考え方を示していた。2025年7月に最終版が公開された改訂「SP 800-63-4」では、この方向性がさらに明確になっている。パスワードのみで認証する場合は最低15文字、多要素認証と組み合わせる場合でも最低8文字を求める一方、定期変更は求めず、漏洩の証拠がある場合にのみ変更を求めるとしている。大文字・小文字・数字・記号の混在を課すような複雑さのルールも、課すべきではないとされた。
背景には、定期変更や複雑さの強制が、推測されやすいパターン化や使い回しをかえって助長してきたという知見がある。これらのルールは総当たり攻撃を主な脅威として設計されたものだが、実際の侵害の多くはフィッシングや、他サービスから漏洩した認証情報を使った不正ログインが原因であり、そこにはほとんど効果がなかった、という整理だ。
日本国内でも見直しは進んでいる。総務省の「国民のためのサイバーセキュリティサイト」は、NISTのガイドラインと、内閣サイバーセキュリティセンター（NISC）の「インターネットの安全・安心ハンドブック」を根拠に挙げ、「パスワードを複数のサービスで使い回さない（定期的な変更は不要）」と明記している。一方でIPA（情報処理推進機構）は、不正ログイン対策として「できるだけ長く」「複雑で」「使い回さない」ことを推奨しており、複雑さそのものを明確に不要とはしていない。自組織の規程がどちらの考え方に近いか、一度確認しておくとよいだろう。
いま推奨される考え方：長さ・使い回さない・漏洩チェック
各ガイドラインに共通する要点は、次の3つに集約できる。
- 複雑さより長さを優先する。ランダムな文字列でも、無関係な単語をつなげたパスフレーズでもよく、短く複雑な文字列より長く単純な文字列のほうが総当たり攻撃への耐性が高い。
- サービス間で使い回さない。1つのサービスから漏洩した認証情報を使って別サービスへのログインを試す攻撃が実被害の主因であり、使い回しをやめるだけでリスクの大部分を遮断できる。
- 定期変更ではなく漏洩の有無で判断する。漏洩の通知や、既知の漏洩リストとの一致が分かった時点で、スケジュールに関係なく直ちに変更する。
漏洩チェックについては、パスワードマネージャーや一部のブラウザに、既知の漏洩データと照合する機能が組み込まれていることが多い。これを有効にしておけば、「定期的に変える」代わりに「漏洩したら変える」という運用が現実的に回るようになる。なお、パスワードのヒントをシステム側に保存する運用も、推測の手がかりになり得るため避けたい。
パスワードマネージャーの活用
長く、使い回さないパスワードを何十個も覚えるのは非現実的だ。ここで現実的な解になるのがパスワードマネージャーである。ブラウザやOSに標準搭載されているものから、1PasswordやBitwardenといったカテゴリの専用アプリまで選択肢は幅広いが、役割はどれも同じで、サービスごとに長く複雑なパスワードを自動生成し、暗号化して保管し、ログイン時に自動入力する。
選ぶ際に見ておきたい点
利用者が覚える必要があるのは、マネージャー自体を開くための「マスターパスワード」1つだけになる。これは長く、他では使っていない一意のものにし、可能であればマネージャー自体にもMFAを設定したい。マスターパスワードが漏れれば保管中のすべての認証情報に影響するため、従来以上に慎重に扱う必要がある。
組織として導入する場合は、運営事業者側も平文を復号できないゼロ知識型の暗号化設計になっているか、退職者のアカウント無効化や安全な共有機能などの管理者機能があるか、既存のID管理基盤やシングルサインオン（SSO）と連携できるかも確認しておきたい。ブラウザの保存機能だけで済ませている組織も多いが、共有端末や端末紛失時のリスクを踏まえ、組織としての方針は別途定めておいたほうがよい。
MFAとパスキー（FIDO2）
多要素認証（MFA）の基本
多要素認証は、「知識情報（パスワードなど本人しか知らない情報）」「所持情報（スマートフォンやセキュリティキーなど本人しか持たない物）」「生体情報（指紋や顔など）」のうち2つ以上を組み合わせて認証する仕組みだ。パスワードが1つ漏れても、それだけでは不正ログインが成立しなくなる。
ただし、MFAにも強度の差がある。SMSで届く確認コードは何もないよりはよいが、SIMスワップや、精巧なフィッシングサイトによるリアルタイムの中継で突破される事例が知られている。認証アプリが生成するワンタイムパスワード（TOTP）はSMSより堅牢だが、フィッシングサイトに誘導されコードごと盗まれるリスクは残る。よりフィッシング耐性が高い方式として位置づけられているのが、次に説明するパスキー（FIDO2）だ。
パスキー（FIDO2）の仕組み
パスキーは、FIDOアライアンスとW3Cが策定したFIDO2・WebAuthnという標準に基づく認証方式だ。サービスに登録する際、端末側で公開鍵と秘密鍵のペアを生成し、秘密鍵は端末のセキュアな領域から外に出ることがなく、サービス側には公開鍵だけが登録される。ログイン時は、端末の画面ロック解除（生体認証やPINなど）で本人確認したうえで秘密鍵によりその場限りの署名を行い、サービス側は公開鍵でその署名を検証する。
この仕組みにより、パスワードのような「サーバーに送る共有の秘密」自体が存在しなくなるため、サーバー側からの漏洩という経路がなくなる。加えて、認証情報がログイン先のドメインに紐づけられているため、見た目そっくりのフィッシングサイトに誘導されても、そのサイト用の正しい署名は生成されない。対応サービスはまだ限定的なため、当面は対応済みのサービスから順にパスキーへ移行し、それ以外はMFAを必須にするという段階的な進め方が現実的だ。
組織で運用する際のポイント
ガイドラインの考え方を自組織へ落とし込む際は、次の点を順に見直すとよい。
- 社内規程の文言を点検する。定期変更の規定や、複雑さを長さより優先する記述が残っていないか確認し、撤廃する場合は漏洩時の即時変更ルールと、漏洩済み・脆弱なパスワードを拒否する仕組み（ブロックリスト）をあわせて用意する。
- MFAを必須化する。管理者アカウント、リモートアクセス、メール、クラウドの管理コンソールなど影響範囲の大きいものから優先し、SMSより堅牢な方式を選ぶ。
- 組織としてパスワードマネージャーを用意する。個人任せの使い回しやメモ書き運用を防ぐため、承認済みツールと利用ルールを明示する。
- 侵害を前提とした手順を整える。漏洩の疑いが生じた際、対象アカウントの強制パスワードリセットとセッション無効化を迅速に行える手順を、平時から用意しておく。
あわせて、なぜルールを変えるのかを利用者に説明する場も設けたい。「セキュリティが緩くなった」という誤解を防ぐには、定期変更をやめる代わりに漏洩監視とMFAで守るという設計思想を伝えることが欠かせない。パスキーの導入は、対応サービスの拡大状況を見ながら、まずは管理者アカウントなどリスクの大きいところから小さく試すのが現実的だろう。
パスワードマネージャーを自分で検証したい場合、VPSにセルフホスト型を立てて挙動を試す方法もあります。学習用の隔離環境として便利です。
まとめ
パスワード運用の考え方は、「頻繁に変える」「複雑にする」から、「十分な長さを確保する」「使い回さない」「漏洩したら直ちに変える」へと軸足を移している。そのうえでパスワードマネージャーが長く一意なパスワードの管理を現実的にし、MFA、とりわけフィッシング耐性の高いパスキー（FIDO2）が認証そのものの強度を底上げする、という組み合わせが現実的な着地点になる。
ルールを厳しくすることよりも、正しい運用を利用者にとって「やりやすい」形で用意することのほうが、結果的にセキュリティレベルを底上げする。本稿で紹介した基準は執筆時点のものであり、各ガイドラインは今後も改訂され得るため、制度設計の際はNIST・IPA・総務省などの一次情報を都度確認してほしい。
最終更新：2026年7月
