--- title: "パスワード管理のベストプラクティス：NIST SP 800-63B-4の要件と総務省・NISCの推奨、企業ポリシーの決め方" url: "https://www.issoh.co.jp/column/details/13508/" published: 2026-07-11 updated: 2026-10-11 categories: ["セキュリティ"] publisher: "株式会社一創" --- # パスワード管理のベストプラクティス：NIST SP 800-63B-4の要件と総務省・NISCの推奨、企業ポリシーの決め方 パスワード管理の基準は、2025年7月31日にNIST（米国立標準技術研究所）が公開したSP 800-63B-4で大きく変わりました。単一要素で使うパスワードは15文字以上が必須になり、「記号を必ず混ぜる」「90日ごとに変える」といった規則は、求めること自体が禁止されています。一方、日本の総務省のページには「10文字以上・文字種を混ぜるのが好ましい」という記述が残っています。この記事では、NISTの要件と国内の公的な推奨のどこが同じでどこが違うかを示したうえで、個人の手順、パスワードマネージャーの選び方、企業のパスワードポリシーの設定値、パスワードをやめてパスキーへ移す線引きまでを整理します。 ## まとめ：パスワード管理で守る要点と優先順位 パスワードは長さに加えて推測されにくさを確保し、サービスごとに使い分けます。定期変更は求めず、漏洩やフィッシング入力、不審なログインなど、侵害が疑われる場合に変更します。NIST SP 800-63B-4は、単一要素のパスワードに15文字以上、多要素認証の一部として使う場合に8文字以上を求め、文字種の混在の強制と定期変更の強制をどちらも「SHALL NOT（してはならない）」としました。総務省と国家サイバー統括室（旧NISC）も、定期変更は不要で流出時に変えるという点では同じ立場です。 実践の優先順位は次のとおりです。 - パスワードマネージャーで長いランダム文字列を生成し、サービスごとに別のものを使う - メール・金融・クラウドなど乗っ取られると被害が広がるアカウントには多要素認証を足す - 企業は認証基盤の設定を15文字以上・文字種強制なし・定期変更なし・漏洩リスト照合ありに書き換える - パスキーに対応したサービスから順に、パスワード単体のログインをやめていく ## NIST SP 800-63B-4のパスワード要件と2017年版からの変更点 NIST SP 800-63Bは米国連邦政府機関向けのデジタル認証の指針ですが、多くの企業やIDサービスが自社ポリシーの根拠にしています。第4版（Revision 4）は[NISTのCSRCで2025年7月31日に最終版として公開](https://csrc.nist.gov/pubs/sp/800/63/b/4/final)され、2017年に公開され2020年3月に更新された第3版を置き換えました。パスワードの要件は3.1.1節にまとまっています。 ### 単一要素は15文字以上・最大長は64文字以上を許容 [SP 800-63B-4の本文](https://pages.nist.gov/800-63-4/sp800-63b.html)は、単一要素として使うパスワードについて「最低15文字を要求しなければならない（SHALL）」と定めています。多要素認証の一部としてだけ使うパスワードは短くてもよいものの、8文字以上は必須です。上限は「64文字以上を許容すべき（SHOULD）」で、印字可能なASCII文字・空白・Unicode文字の受け付けも推奨（SHOULD）です。Unicodeは1コードポイントを1文字と数えるので、日本語のパスフレーズも長さの要件を満たせます。 長さを優先する理由は計算で確かめられます。ランダムに選んだ場合の組み合わせ数を比べると、英小文字だけの15文字が、記号まで混ぜた10文字を上回ります。 | 文字種（1文字あたりの候補数） | 長さ | 組み合わせ数 | ビット換算 | | --------------- | ---- | ----------- | ----- | | 英大文字・小文字・数字（62） | 8文字 | 約2.2×10の14乗 | 約47.6 | | 英大小・数字・記号（95） | 10文字 | 約6.0×10の19乗 | 約65.7 | | 英小文字のみ（26） | 15文字 | 約1.7×10の21乗 | 約70.5 | | 英大小・数字・記号（95） | 15文字 | 約4.6×10の29乗 | 約98.5 | これは文字列をランダムに生成した場合の値です。人が考えた文字列は辞書や置換規則で絞り込まれるため、表ほどの強さはありません。だから長さの確保と並んで、次の項で扱うブロックリスト照合が必須になっています。 ### 文字種の混在と定期変更を「求めてはならない」へ格上げ 第4版は、文字種の混在などの構成ルールを課すことを禁止し（SHALL NOT）、定期的な変更を求めることも禁止しました（SHALL NOT）。認証情報が侵害された証拠がある場合は、変更を強制しなければなりません（SHALL）。混在を強制すると「a」を「@」に置き換える、末尾に「1!」を足すといった予測しやすい変形に流れ、定期変更を強制すると「Spring2025」から「Summer2025」のような小さな変形を繰り返すため、どちらも実効強度を下げます。 2017年版でも同じ方向でしたが、多くは「SHOULD NOT（すべきでない）」の推奨でした。第4版で禁止に変わった項目が、社内規程を見直すときの根拠になります。 | 項目 | SP 800-63B（2017年版） | SP 800-63B-4（2025年7月） | | ---------------- | ------------------- | ------------------------------------- | | 最小文字数 | 利用者が選ぶ場合は8文字（SHALL） | 単一要素15文字・多要素の一部なら8文字（SHALL） | | 文字種の混在の強制 | すべきでない（SHOULD NOT） | してはならない（SHALL NOT） | | 定期変更の強制 | すべきでない（SHOULD NOT） | してはならない（SHALL NOT） | | 侵害時の変更 | 強制する（SHALL） | 強制する（SHALL） | | パスワードマネージャー・自動入力 | 貼り付けの許可を推奨（SHOULD） | マネージャー・自動入力は必須（SHALL）、貼り付けは推奨（SHOULD） | ### ブロックリスト照合・ヒントと秘密の質問の禁止 第4版は、パスワードの設定・変更時に、よく使われる文字列・推測しやすい文字列・過去の流出で出回った文字列を集めたブロックリストと照合することを必須にしています。照合はパスワード全体で行い、一致したら別のものを選ばせ、拒否した理由を利用者に示します。同時に、ログイン試行の回数を制限する仕組みも必須です。 あわせて、未認証の相手に見えるパスワードのヒントを保存させること、「母親の旧姓は」のような秘密の質問（知識ベース認証）をパスワード選択時に促すことも、第3版から禁止され、第4版でも継続しています。秘密の質問の答えはSNSや公開情報から調べられることが多く、パスワードより弱い裏口になるためです。自社サービスの再設定画面に秘密の質問が残っているなら、メールやSMSでの再設定、保存した復旧コードへ置き換える対象になります。 ## 総務省・国家サイバー統括室（旧NISC）の推奨とNISTとの違い 国内で「パスワードの推奨桁数」を調べると、総務省の[国民のためのサイバーセキュリティサイト](https://www.soumu.go.jp/main%5Fsosiki/cybersecurity/kokumin/security/end%5Fuser/general/01/)と、内閣サイバーセキュリティセンター（NISC）が作った「インターネットの安全・安心ハンドブック」に行き着きます。NISCは[2025年7月に改組され、国家サイバー統括室（NCO）](https://www.cyber.go.jp/about/overview/index.html)になり、ハンドブックも[NCOのサイト](https://security-portal.cyber.go.jp/guidance/handbook.html)で公開されています（最新はVer 5.10・2025年3月11日）。 ### 総務省の推奨文字数と文字種の混在 総務省の一般利用者向けページは、安全なパスワードを「最低でも10文字以上の文字数で構成されるある程度長いランダムな英数字の並びとし、パスワード内に数字や記号、アルファベット（大文字、小文字）が混ざっていることが好ましい」と説明しています。覚える必要があるものは、無関係な複数の英単語をつなげ、間に数字列を挟む作り方を勧めています。 定期変更については、同じページで「サービス側から流出した事実がない場合は、パスワードを変更する必要はありません」と明記し、根拠として2017年のNISTのガイドラインとNISCのハンドブックを挙げています。なお、企業の職員向けの[安全なパスワードの設定・管理](https://www.soumu.go.jp/main%5Fsosiki/cybersecurity/kokumin/security/business/staff/06/)のページには10文字という数字はなく、「ある程度長いランダムな英数字の並び」とパスワード管理ツールの利用を勧める記述になっています。 ### NCOのハンドブックは「桁数をできるだけ長く」と定期変更不要 ハンドブックVer 5.10は最小文字数を示していません。第1章では「最近では、桁数をできるだけ長くする方が安全である」としたうえで、数字と英大文字・小文字の組み合わせが8桁では約218兆通り、12桁では約32垓通りになる比較を載せています。第5章1.7節の見出しは「パスワードの定期変更は基本は必要なし。ただし流出時は速やかに変更する」で、企業がルールを定める場合も定期的な変更を求めないことを原則としています。 ### 社内規程の推奨設定：15文字以上・文字種強制なし 3つを並べると、定期変更を不要とし流出時に変える点、使い回しを禁じる点、パスワード管理ツールを勧める点は一致しています。違うのは長さと文字種です。 | 論点 | NIST SP 800-63B-4 | 総務省（一般利用者向け） | NCOハンドブック Ver 5.10 | | ---- | ----------------- | ------------- | ------------------ | | 長さ | 単一要素15文字以上（必須） | 最低10文字以上が好ましい | できるだけ長く（数値なし） | | 文字種 | 混在の強制は禁止 | 混ざっていることが好ましい | 記号を入れるに越したことはない | | 定期変更 | 強制は禁止・侵害時は強制 | 流出がなければ不要 | 基本は不要・流出時は速やかに | | 位置づけ | 認証を提供する側の要件 | 利用者への啓発 | 利用者・中小企業への啓発 | 社内のパスワードポリシーを書くなら、NISTの要件に合わせるのが妥当です。総務省とNCOの文書は利用者に向けた啓発で、「好ましい」「こしたことはありません」という勧めにとどまり、システムに強制する設定値を定めたものではありません。15文字以上を求めれば総務省の10文字は自動的に満たせます。文字種については「混ぜてもよいが、混ぜないと登録できない設定にはしない」と書けば、どちらの文書とも矛盾しません。 ## 個人が今日からやるパスワード管理の手順 ### サービスごとのパスワード分離と使い回し防止 使い回しは、1か所の漏洩から被害を広げます。1つのサービスから漏れたIDとパスワードの組は、別のサービスへ次々に試される（パスワードリスト攻撃、クレデンシャルスタッフィング）ため、1か所の漏洩が全アカウントの乗っ取りにつながります。事業者側の保管の不備でパスワードそのものが漏れた例として、[KDDI系ISPメールのパスワード漏えい](/tech/details/12698/)があります。利用者が強いパスワードを付けていても、使い回していれば漏れた先から広がります。 ### マスターパスワード向けパスフレーズの作成条件 手で入力して覚えておく必要があるのは、パスワードマネージャーのマスターパスワードと端末のログインくらいに絞ります。この1つは、関係のない単語をつなげたパスフレーズにすると、長さと覚えやすさを両立できます。日本語は1語が2〜3文字と短いので、語数ではなく文字数で数えます。たとえば「霧 灯台 珈琲 27 木曜」は空白込みで13文字にとどまり、「霧 灯台 珈琲 二十七 木曜 青い傘」まで足すと18文字になります（例文そのものは使わないでください）。NISTは空白とUnicodeの受け付けを求めているので、対応したサービスなら日本語や空白入りでも登録できます。名前・誕生日・サービス名は入れません。 ### 重要アカウントへの多要素認証の追加 パスワードだけでは、フィッシングで入力させられた時点で破られます。メール、ネットバンキング、クラウドストレージのように、乗っ取られると他のアカウントの再設定にも使われる入口には、第二の要素を足します。要素の違いは[二段階認証・二要素認証・多要素認証の違い](/column/details/13268/)で整理しています。SMSにはSIMスワップのリスクがあります。認証アプリのOTPも中継型フィッシングには耐性がないため、対応しているサービスではFIDO2のセキュリティキーやパスキーを優先し、使えない場合に認証アプリを選びます。 ### 漏洩通知・侵害の疑いを契機とするパスワード変更 定期変更が不要になった代わりに、漏洩したら即座に変える運用が要ります。主要なパスワードマネージャーやブラウザは、保存したパスワードが既知の流出データに含まれていないかを照合し、該当すると警告します。警告が出たアカウントと、同じパスワードを使っていた他のアカウントは変更します。警告がなくても、偽サイトへの入力や不審なログインなど侵害が疑われる場合は、通知を待たずに対応します。 ## パスワードマネージャーの選び方と導入前に決めること NIST SP 800-63B-4は、認証する側がパスワードマネージャーと自動入力の利用を許可しなければならない（SHALL）としています。一方、自動入力APIを使えない場合に備えた貼り付けの許可は推奨（SHOULD）にとどまり、要求の強さが違います。 ### ゼロ知識暗号かどうかと内蔵機能・専用ツールの違い 最初に確かめるのは暗号化の設計です。保管データを利用者の端末側で暗号化し、事業者が復号に必要な秘密を持たない「ゼロ知識」設計なら、事業者のサーバーから読めるのは暗号化されたデータだけです。ただし暗号化データが盗まれれば、マスターパスワードの推測は手元で何度でも試せるため、最後の防御はマスターパスワードの長さと鍵導出の設定になります。事業者が復号できる方式は避けます。過去に侵害を起こしたツールは、その後の再設計と第三者監査の公開状況も判断材料になります。 | 観点 | ブラウザ・OSの内蔵機能 | 専用のパスワードマネージャー | | ------- | -------------- | ---------------- | | 費用 | 無料 | 無料枠と有料（個人・家族・法人） | | 対応環境 | 同じOS・ブラウザの中で強い | OS・ブラウザをまたいで同期 | | 共有・権限管理 | 限られる | 組織共有・権限・監査ログ | | 緊急アクセス | 限られる | 緊急連絡先・管理者による復旧 | 個人で1つのエコシステムに収まるなら内蔵機能で使い回しをなくすところから始め、家族や組織での共有、端末をまたぐ利用が必要になった時点で専用ツールへ移る順番で足ります。 ### マスターパスワードを失ったときの復旧手段 ゼロ知識設計では、事業者がマスターパスワードそのものを取り出すことはできません。アカウントへのアクセスを回復できるかは製品と事前設定によって異なり、[Bitwardenのヘルプ](https://bitwarden.com/help/forgot-master-password/)は、緊急アクセスや組織管理者によるアカウント復旧を手段として挙げています。導入前に、個人は製品が提供する復旧コードや緊急アクセスを確認し、必要な情報を紙などで安全に保管します。組織は管理者による復旧機能の提供条件と事前登録の要否を確認し、手順と権限者を決めておきます。この設計がないまま全社に広げると、1人の失念で業務アカウントが開けなくなります。 ## 企業・大規模組織のパスワードポリシーの設定値 組織では、注意喚起ではなく認証基盤の設定で守らせます。従業員が数千人規模になると、例外の運用や属人的な共有アカウントがそのまま穴になるためです。 ### IDプロバイダの設定目標と製品ごとの制約 社内規程は次の要件を基準に見直し、IDプロバイダでは変更可能な項目を確認します。[Microsoft Entra IDのクラウド専用ユーザー](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-password-ban-bad-combined-policy)では、最小文字数や文字種の要件を任意に変更できません。設定できない項目は差分を記録し、MFAやパスワードレス認証で補います。 | 設定項目 | NIST準拠の値 | 根拠 | | ---------- | --------------------- | --------- | | 最小文字数 | 15文字（MFA必須の環境なら8文字以上） | 3.1.1.2節 | | 最大文字数 | 64文字以上を許容 | 3.1.1.2節 | | 文字種の必須化 | 設定しない | SHALL NOT | | 有効期限（定期変更） | 無期限（侵害時のみ強制変更） | SHALL NOT | | 禁止パスワード | 流出・頻出・社名などと照合 | SHALL | | ヒント・秘密の質問 | 使わない | SHALL NOT | | ログイン失敗 | 試行回数を制限 | SHALL | 「90日ごとに変更・記号必須」の古い規程を残したまま設定だけ変えると、監査で規程違反と指摘されます。規程本文の書き換えを先に済ませ、設定の変更と同じ日に施行します。 ### 自社サービスでパスワードを保管するときの要件 会員登録やログイン機能を持つサービスでは、保管方法が問われます。SP 800-63B-4は、パスワードをソルト付きでハッシュ化して保存すること、ソルトは32ビット以上で、総当たりのコストを上げるパスワードハッシュ方式（コスト係数を持つ方式）を使うことを求めています。新規実装ではArgon2idを優先し、bcryptを使う既存環境では入力長の制約を確認します。[OWASPのPassword Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)はbcryptをレガシー環境向けとし、入力の上限を72バイトとしています。UTF-8の日本語は1文字3バイトなので、24文字前後で上限に達します。ハッシュと暗号化の違いは[ハッシュ化と暗号化の違いとパスワード保管の仕組み](/column/details/13487/)で解説しています。ハッシュ方式や多要素認証の組み込みは後から入れ替えるコストが大きいので、[認証基盤・ID管理システムの開発支援](/service/system/identity/)のように設計段階から専門の支援を受けるのも手です。 ### パスワードマネージャーの全社展開と退職時の失効 規程を配っても、現場が付箋やスプレッドシートに戻れば意味がありません。全社にパスワードマネージャーを配り、共有アカウントは口頭で伝えるのではなくツールの組織共有で権限を管理します。退職時は共有保管庫と各サービスのアクセスを失効させ、退職者が把握していた共有パスワードも変更します。Bitwardenからの組織メンバー削除は共有項目へのアクセスを止める操作なので、各サービスのアカウント停止とは分けて管理します。定期的な権限棚卸しと漏洩レポートの確認も行います。自社サーバーに置く場合の構築手順は[Bitwardenを組織で導入する手順](/tech/details/17356/)にまとめています。 ## ファイル共有のパスワードとPPAPの扱い パスワード付きZIPを添付し、同じメール経路で別にパスワードを送る運用（PPAP）は、経路を盗聴されれば両方が手に入り、受信側のウイルス対策が暗号化された中身を検査できないという弱点を持ちます。政府でも、[内閣府と内閣官房が2020年11月26日にこの方式を廃止](https://www.cao.go.jp/minister/2009%5Ft%5Fhirai/kaiken/20201127kaiken.html)しました。NCOのハンドブックも、ZIPファイルのパスワードはログインパスワードと性質が違う「暗号キー」として扱うよう区別しています。社内標準は、アクセス権と有効期限を設定できるクラウドストレージの共有リンクに寄せるのが妥当です。PPAPをやめる理由と代替手段の選び方、社内ルールの決め方は[脱PPAP：パスワード付きZIPをやめる理由と代替手段の選び分け](/column/details/17450/)で詳しく扱っています。 ## パスワード単体をやめる線引きとパスキーへの移行 ### パスワード単体を許す場面と許さない場面 パスワード単体のログインを許してよいのは、漏れても被害が小さく、他のサービスと使い回していない重要度の低いアカウントだけです。金銭・個人情報・社内システムに届くアカウント、管理者権限、退職時の失効漏れが致命傷になる共有基盤では、パスワード単体を認めない設定にします。「利用者が面倒がる」は例外の理由にしません。多要素認証の方式と耐フィッシング性の違いは[多要素認証（MFA）の3要素と耐フィッシング実装](/tech/details/13314/)が詳しく、ID管理全体の設計は[認証・ID管理（MFA・SSO・OIDC・IDaaS）の違いと選定](/column/details/13631/)で整理しています。 ### パスキーの段階的な導入とパスワード併存時の管理 パスキーはFIDOの公開鍵暗号による認証情報で、利用時に生体認証やPINなどで本人確認を行います。端末固定型のほか、プロバイダーを通じて端末間で同期する同期型があります。認証先のサーバーには秘密鍵を保管せず、認証情報が正規のサイトに結び付いているため、偽サイトへのログインを防ぐ耐フィッシング性があります。移す条件は、利用者の端末が対応していることと、機種変更や紛失時に別の端末やクラウド同期で復旧できることです。仕組みと導入判断は[パスキー認証とは？仕組み・パスワードとの違い](/column/details/15368/)、自社サービスに実装する手順は[パスキー移行の実装手順](/tech/details/17716/)にまとめています。 全サービスが一度に対応するわけではないため、当面は併存します。対応したサービスからパスキーを有効にし、未対応のサービスはパスワードマネージャーの長いランダム文字列と多要素認証で守ります。最終的に覚えて守る対象を、マスターパスワードと端末のロックの2つに絞るのが着地点です。 ## パスワード管理に関するよくある質問 ### NISTのパスワードガイドラインの最新版はどれですか？ 2025年7月31日に公開されたSP 800-63B-4です。2017年版（2020年3月更新）を置き換え、単一要素のパスワードは15文字以上、文字種の混在の強制と定期変更の強制は禁止と定めています。本文はNISTのサイトで公開されています。 ### パスワードは何文字にすればよいですか？ 単一要素で使うなら15文字以上がNISTの要件です。総務省の一般利用者向けページは「最低でも10文字以上」を目安にしていますが、15文字以上にすれば両方を満たします。多要素認証と組み合わせる場合、NISTは8文字以上を認めています。 ### パスワードは定期的に変更したほうが安全ですか？ いいえ。NISTは定期変更を求めることを禁止し、総務省とNCO（旧NISC）も流出がなければ変更は不要としています。変えるのは、漏洩の通知を受けたときや乗っ取りの疑いがあるときです。 ### パスワードマネージャーは危険ではないですか？ 1か所に集める不安はありますが、使い回しや短いパスワードを続けるより安全です。ゼロ知識設計に加え、長く推測されにくいマスターパスワード、多要素認証、製品に応じた復旧手段を確認します。保管データが流出した場合の耐性は、マスターパスワードの強度と鍵導出方式にも左右されます。 ### パスキーがあればパスワードは不要になりますか？ パスキーに対応したサービスでは、パスワードを入力せずにログインできます。ただし未対応のサービスがあり、アカウントの復旧手段としてパスワードが残る場合もあるため、当面はパスワードマネージャーと併用します。 ## 関連記事 - [二段階認証とは？二要素認証・多要素認証との違いと企業の導入判断を解説](/column/details/13268/) - [パスキー認証とは？仕組み・パスワードとの違い・企業の導入判断を解説](/column/details/15368/) - [脱PPAP：パスワード付きZIPをやめる理由と代替手段の選び分け・社内ルールの決め方](/column/details/17450/) - [ハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説](/column/details/13487/) - [ワンタイムパスワードとは？仕組みと種類・企業が選ぶ導入方式を解説](/column/details/13270/) --- 出典: [パスワード管理のベストプラクティス：NIST SP 800-63B-4の要件と総務省・NISCの推奨、企業ポリシーの決め方]()（株式会社一創）