NISTのパスワードポリシーとは？文字数・複雑さ・定期変更の要件をSP 800-63B（2025年版）で解説

社内のパスワードルールを「NISTに合わせて見直すように」と指示され、ではNISTが実際に何を定めているのかを確かめようとしている方は少なくありません。90日ごとの変更、記号や数字の混在を必須にするといった従来の運用は、いまのNISTの考え方とは大きく異なります。

基準となるのは、米国国立標準技術研究所（NIST）が公開するデジタルアイデンティティガイドライン「SP 800-63B」です。2025年7月に公開された最新版（SP 800-63B-4）では、パスワードの長さ・複雑さ・変更頻度に関する要件が改められ、それぞれが「必須（SHALL）」なのか「推奨（SHOULD）」なのかも規範語で示されています。

本記事では、まず従来のルールとNIST新基準を一覧表で対比し、各要件を必須／推奨の別まで含めて1つずつ解説します。あわせて、根拠となる文書と版、日本企業が従う必要があるのか、自社のパスワードポリシーをどう見直すかまでを整理します。

【比較表】従来のパスワードルールとNIST新基準

はじめに、多くの社内規程で使われてきた従来のルールと、NIST SP 800-63B-4（2025年版）が定める要件を項目別に対比します。各項目について、NISTが「必須（SHALL）」としているか「推奨（SHOULD）」としているかも示します（規範語の意味は後述します）。

※NIST SP 800-63B-4（2025年7月）の各要件に基づく。規範語（SHALL／SHOULD）の意味は本文で解説します。多要素認証（MFA）行はパスワード自体ではなく認証方式全体に関わる要件で、詳細は記事後半で解説します。

出典・参考資料（1件）

• 出典：NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management, Sec. 3.1.1.2（パスワード要件）／Sec. 2・3.2.5（認証保証レベル・フィッシング耐性）｜NIST（2025年7月）

NISTが定めるパスワード要件を1つずつ解説

ここからは、上の表の各行が実際にどう定められているかを1つずつ見ていきます。NISTは要件ごとに「SHALL（必須）」「SHOULD（推奨）」といった規範語を使い分けているため、社内規程に落とすときは必須と推奨の別を取り違えないことが重要です。NIST自身の定義（SP 800-63B-4 第1.1節）にもとづくと、各規範語の意味は次のとおりです。

• SHALL／SHALL NOT（必須／禁止）：厳守すべき要件で、逸脱は認められません。
• SHOULD／SHOULD NOT（推奨／非推奨）：推奨される（または避けるべき）ものの、必須ではありません。
• MAY（任意）：実装してもしなくてもよい選択肢です。

本記事で扱うのはパスワード自体の要件（SP 800-63B-4 第3.1.1.2節）が中心です。NISTはこのほかにも、ログインの失敗が続いたときの試行回数の制限（レート制限）など、認証全体に関わる要件を定めています。自社規程を確定する際は、原典もあわせて確認してください。

出典・参考資料（1件）

• 参考資料：NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management｜NIST

最小の長さ：単一要素なら15文字以上（必須）

パスワードだけで認証する場合は15文字以上、多要素認証の一要素として使う場合は8文字以上が必須です。これは推奨ではなく「SHALL」で定められた要件です。従来広く使われてきた「8文字以上」は、単一要素認証では新基準を満たしません。

Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length. Verifiers and CSPs MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length.

出典：NIST SP 800-63B-4, Sec. 3.1.1.2｜NIST

最大の長さ：64文字以上を許容すべき（推奨）

NISTは、システム側が「少なくとも64文字まで」のパスワードを許容すべき（SHOULD）としています。これは「64文字を上限にせよ」という意味ではなく、長いパスフレーズを使いたい利用者を妨げないための推奨です。短い上限を設けている社内システムは、見直しの対象になります。

複雑さ（記号・数字の混在）：強制してはならない（禁止）

大文字・小文字・数字・記号の混在を強制するルールは、新基準では禁止（SHALL NOT）です。長さを確保することが優先され、文字種の構成ルールは課さないのが原則になりました。

Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

出典：NIST SP 800-63B-4, Sec. 3.1.1.2｜NIST

定期変更：要求してはならない（禁止）、ただし漏えい時は変更（必須）

一定期間ごとの変更を利用者に強制することは禁止（SHALL NOT）です。ただし「一切変更しなくてよい」わけではなく、認証情報が漏えいした証拠がある場合は変更を強制しなければならない（SHALL）と、同じ条文でセットで定められています。

Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.

出典：NIST SP 800-63B-4, Sec. 3.1.1.2｜NIST

使える文字：ASCII・空白・Unicodeを受け入れるべき（推奨）

印刷可能なASCII文字・空白・Unicode文字を受け入れるべき（SHOULD）とされています。Unicodeは1つのコードポイントを1文字として長さを数え、入力されたパスワードは切り詰めずに全体を照合しなければならない（SHALL）とされています。

あわせて、パスワードマネージャーの利用を許可することが必須（SHALL）、貼り付け（コピー＆ペースト）の許可は推奨（SHOULD）です。長いパスフレーズを現実的に運用するための条件が整えられています。

出典・参考資料（1件）

• 出典：NIST SP 800-63B-4, Sec. 3.1.1.2（使える文字・パスワードマネージャー・貼り付け）｜NIST

NISTがパスワードマネージャーの利用を認めている一方で、企業で使わせる際には安全性や選び方が気になるところです。管理アプリに潜むリスクと、法人で選ぶときの確認ポイントは次の記事で整理しています。

ブロックリスト照合：漏えい・よくあるパスワードを拒否（必須）

パスワードの設定・変更時に、漏えい実績のあるパスワード・よく使われるパスワード・辞書語などを集めたブロックリストと照合することが必須（SHALL）です。サービス名や利用者名などの文脈に関係する語も対象で、該当した場合は別のパスワードを選ばせ、拒否した理由も示す必要があります。

When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.

出典：NIST SP 800-63B-4, Sec. 3.1.1.2｜NIST

回復方法：パスワードヒント・秘密の質問は禁止

認証されていない人でも見られるパスワードのヒントを保存すること、パスワード設定時に「最初のペットの名前は？」のような秘密の質問（知識ベース認証／KBA）を使わせることは、いずれも禁止（SHALL NOT）です。推測や調査で突破されやすいためで、再設定の手段としても使えません。

出典・参考資料（1件）

• 出典：NIST SP 800-63B-4, Sec. 3.1.1.2（ヒント・知識ベース認証の禁止）｜NIST

根拠はSP 800-63B-4（2025年版）｜Rev.3から何が変わったか

これらの要件の根拠は、NISTのデジタルアイデンティティガイドライン「SP 800-63」です。SP 800-63はいくつかの文書で構成され、本人確認（登録）を扱うSP 800-63A、認証を扱うSP 800-63B、認証連携を扱うSP 800-63Cに分かれています。パスワードの要件を定めているのは、このうちのSP 800-63Bです。

引くべき最新の文書は、2025年7月に公開されたSP 800-63B-4（改訂第4版）です。前版はSP 800-63B Rev.3（2017年6月公開、2020年3月更新）で、新版はこれを置き換えています。「最新版」と曖昧に書かず、版番号と発行年で確認するのが安全です。

注目すべきは、複雑さの強制と定期変更に対する姿勢が「推奨しない」から「禁止」へと強まった点です。Rev.3では、これらは「SHOULD NOT（推奨しない）」と書かれていました。

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).

出典：NIST SP 800-63B Rev.3, Sec. 5.1.1.2｜NIST（2017年）

新版（Rev.4）では、これらが前述のとおり「SHALL NOT（禁止）」に変わりました。推奨から要件へと格上げされたことになります。

あわせて、単一要素認証の最小長が「8文字以上」から「15文字以上」へ引き上げられ、Rev.3で「memorized secret（記憶シークレット）」と呼ばれていた用語も「password」に改められています。この版の変更点はNISTが変更履歴（Change Log）として公開しています。

出典・参考資料（2件）

• 出典：NIST SP 800-63B-4（Publication History・Appendix E Change Log）｜NIST（2025年7月）
• 出典：NIST SP 800-63B Rev.3, Sec. 5.1.1.2｜NIST（2017年）

なぜ複雑さの強制・定期変更をやめるのか

社内で方針を変える際は、「なぜ従来のルールをやめるのか」を説明できることが欠かせません。NISTは、複雑さの強制が期待したほど効果を上げていない一方で、使い勝手と記憶しやすさへの悪影響は大きい、と説明しています（この説明は参考情報として位置づけられています）。

Humans have a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. … However, analyses of breached password databases reveal that the benefit of such rules [composition rules] is less significant than initially thought, and the impacts on usability and memorability are severe.

出典：NIST SP 800-63B-4, Appendix A（Strength of Passwords）｜NIST

具体例としてNISTは、password を使いたい利用者に大文字と数字を求めると Password1、さらに記号を求めると Password1! のように、予測しやすい改変に流れやすいことを挙げています。定期変更についても、強制するとパスワードの作り方がパターン化し、かえって弱くなるという問題が指摘されています。

この考え方は日本の公的機関の案内とも一致します。総務省は「国民のためのサイバーセキュリティサイト」で、流出の事実がない限り定期変更は不要だと明言しています。

なお、利用するサービスによっては、パスワードを定期的に変更することを求められることもありますが、実際にパスワードを破られアカウントが乗っ取られる等のサービス側から流出した事実がない場合は、パスワードを変更する必要はありません。むしろ定期的な変更をすることで、パスワードの作り方がパターン化し簡単なものになることや、使い回しをするようになることの方が問題となります。

出典：安全なパスワードの設定・管理｜総務省 国民のためのサイバーセキュリティサイト

日本企業はNISTに従う必要があるのか

NIST SP 800-63Bは、もともと米国連邦政府機関向けのガイドラインです。日本の民間企業に対して法的な強制力があるわけではありません。ただし、国際的に参照される事実上の標準として扱われており、日本の公的機関のガイドラインや動向にも反映されています。

デジタル庁は、行政手続等での本人確認に関するガイドライン（DS-511）のなかで、米国連邦政府向けのSP 800-63が2025年に全面改定されたことに触れています。そのうえで、日本独自の「当人認証保証レベル」をレベル1〜3で定義しており、これはNISTの認証保証レベル（AAL）と同じ考え方に立っています。

レベル 3 ……多要素認証を必須とし、さらにフィッシング耐性をもつ認証手法を全ての利用者が利用することを必須とすることで、厳格な耐性を確保する。
レベル 2 ……多要素認証を必須とし、さらにフィッシング耐性をもつ認証手法を希望する利用者が選択的に利用できるようにすることで、標準的な耐性を確保する。
レベル 1 ……単要素認証により、簡易的な耐性を確保する。

出典：DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン｜デジタル庁

金融分野でも動きがあります。金融庁は、フィッシングによる不正送金・不正取引の被害増加を受けて、フィッシング耐性のある多要素認証の導入などを盛り込んだ監督指針・事務ガイドラインの改正を進めています。対象は銀行・信用金庫・信用組合・労働金庫・証券会社とされています。

金融機関を騙ったフィッシングによる不正送金・不正取引被害が増加しているため、金融庁ではフィッシング耐性のある多要素認証の導入等を盛り込んだ監督指針・事務ガイドラインの改正を実施しています。

出典：フィッシング耐性のある多要素認証等に係る官民一体・業界横断的な広報について｜金融庁

このように、NIST自体に日本企業への強制力はないものの、「長さを重視し複雑さの強制や定期変更をやめ、フィッシング耐性のある多要素認証へ進む」という方向性は、総務省・デジタル庁・金融庁の動きとも足並みがそろっています。自社ポリシーをNISTに合わせて見直すことは、国内の動向とも整合する判断だといえます。

NIST基準に合わせてパスワードポリシーを見直すチェックリスト

ここまでの要件を、自社の既存ポリシーと突き合わせて改定するための確認項目として整理します。従来の設定をそのまま残していないか、1つずつ確認してみてください。

従来設定から見直す項目

• 最小文字数：単一要素認証なら15文字以上に引き上げる（多要素認証と併用するなら8文字以上）。「8文字」のままになっていないか
• 最大文字数：64文字以上を許容する。短い上限を設けていないか
• 複雑さの強制：大文字・数字・記号の混在を必須にする設定を外す
• 定期変更：一定期間での強制変更を廃止し、漏えいが確認されたときに変更させる運用へ切り替える
• ブロックリスト照合：漏えい済み・よく使われるパスワードを拒否する仕組みを導入する
• 秘密の質問・ヒント：本人確認や再設定での利用をやめる
• パスワードマネージャー・貼り付け：利用を許可する（禁止設定を外す）

Active Directory／Microsoft Entra ID での実装の当たり

Windows環境では、Active Directoryのきめ細かなパスワードポリシー（Fine-Grained Password Policy）を使うと、利用者グループごとに最小文字数や変更の扱いを設定できます。漏えい済み・弱いパスワードの拒否（ブロックリスト照合に相当）は、Microsoft Entra ID（旧Azure AD）のパスワード保護機能で実現できます。

たとえば、最小文字数や変更の扱いはFGPPの設定項目で対応づけられます。漏えい済み・弱いパスワードの拒否は、Microsoft Entra Password Protectionのグローバル／カスタム禁止パスワードリストで実現できます。具体的な設定手順・適用範囲・必要なライセンスは、各製品の公式ドキュメントで確認してください。

出典・参考資料（2件）

• 参考資料：Advanced AD DS Management Using Active Directory Administrative Center（Fine-grained password policies）｜Microsoft Learn
• 参考資料：Password protection in Microsoft Entra ID｜Microsoft Learn

パスワードの先へ：多要素認証・パスキーで守る

NISTの新基準をたどると、行き着く先は「パスワードを強くする」だけでは不十分だというメッセージです。NIST自身が、パスワードに頼りきらず、フィッシング耐性のある多要素認証やパスキーへ進むことを求めています。

認証保証レベル（AAL1〜3）とは

SP 800-63Bは、認証の強さを認証保証レベル（AAL：Authentication Assurance Level）としてAAL1〜3の3段階で定義しています。AAL1は単一要素でも許容されるレベル、AAL2は2つの異なる認証要素が必要なレベル、AAL3はフィッシング耐性があり秘密鍵を取り出せない認証器を使う最も高いレベルです。

重要なのは、AAL2以上ではフィッシング耐性のある認証手段を少なくとも1つ提供することが必須（SHALL）とされている点です。

Verifiers SHALL offer at least one phishing-resistant authentication option at AAL2, as described in Sec. 3.2.5.

出典：NIST SP 800-63B-4（Authentication Assurance Levels）｜NIST

フィッシング耐性のある認証の代表例が、FIDO2／WebAuthn規格に基づくパスキーや、物理的なセキュリティキーです。これらは秘密鍵を端末やキーの内部に保持し、正規のサイト以外には反応しないため、パスワードを盗んでなりすます攻撃に強いという特徴があります。ここでは、パスワードに頼らない認証を実現する2つのアプローチとして、国産のID基盤と物理セキュリティキーのサービスを紹介します。

1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）

CloudGate UNOは、株式会社インターナショナルシステムリサーチが自社開発するクラウド型のID基盤（IDaaS）です。シングルサインオン（SSO）やアクセス制限とあわせて、FIDO2（パスキー）によるパスワードレス認証を提供し、パスワードに頼らないログインへ移行できます。

パスキー認証は全プラン・全ユーザーで無制限に利用でき、物理セキュリティキー（YubiKeyなど）やWindows Hello・Touch ID／Face IDといった端末の生体認証にも対応します。

FIDOアライアンスには2014年に加盟、2019年5月にFIDO2準拠のパスワードレス認証を提供開始しており、フィッシング耐性のある認証に早くから取り組んできた国産サービスです。IP制限や時間帯制限などのアクセス制限も標準で備え、デバイス証明書による端末制限もオプションで利用できます。

パスワードに頼らない認証への移行は、情報システム部門の運用負担にも関わります。提供元のインターナショナルシステムリサーチは、カタログの独自インタビューで導入後の変化を次のように述べています。

2. YubiKey as a Service（株式会社インターナショナルシステムリサーチ）

YubiKey as a Serviceは、Yubico社の物理セキュリティキー「YubiKey」を、法人向けにサブスクリプション型で提供するサービスです。株式会社インターナショナルシステムリサーチがYubico社との契約に基づいて日本で提供しています。

YubiKeyはFIDO2／WebAuthnに対応した物理トークンで、秘密鍵とPINがキーの内部にとどまり外部へ送信されないため、フィッシングに強い認証を実現します。NISTが最も高いAAL3で想定する「取り出せない鍵を持つフィッシング耐性のある認証器」に相当する認証手段です。

買い切りではなく運用費として導入でき、毎年契約数の25%分の予備キーや、導入・運用を支援する担当者の付帯が特徴です。スマートフォンを業務で使えない現場でも利用できる点も、物理キーならではの利点です。ただし、利用には最低200ユーザーからの契約が必要です。

実際にどのような現場で物理キーが選ばれているのか、提供元のインターナショナルシステムリサーチは、カタログの独自インタビューで次のように説明しています。

ここで取り上げたのはパスワードレス認証を実現する2つのサービスですが、認証アプリ・SMS・生体認証なども含めて多要素認証（MFA）全体から自社に合うものを選びたい場合は、認証方式・料金・タイプ別の選び方を一覧した次の記事が役立ちます。

まとめ

NIST SP 800-63B-4（2025年版）は、パスワードの要件を「長さを重視し、複雑さの強制と定期変更はやめる」方向へ大きく変えました。単一要素認証なら15文字以上を必須とし、文字種の混在の強制と定期変更を禁止する一方で、漏えい済みパスワードのブロックリスト照合を必須にしています。各要件が必須（SHALL）か推奨（SHOULD）かを区別して読み取れば、社内規程へもそのまま落とし込めます。

そして新基準の先にあるのは、パスワードだけに頼らず、フィッシング耐性のある多要素認証やパスキーへ進むという方針です。日本でもデジタル庁や金融庁が同じ方向に動いており、自社の認証をどう強化するかは、パスワードポリシーの見直しと合わせて検討する価値があります。

よくある質問（FAQ）

Q. NISTのパスワードポリシーとは何ですか？

A. NISTのパスワードポリシーとは、米国国立標準技術研究所（NIST）がデジタルアイデンティティガイドライン「SP 800-63B」で定める、パスワードの長さ・複雑さ・変更頻度などに関する要件のことです。最新版はSP 800-63B-4（2025年7月公開）で、「長さを重視し、記号や数字の混在の強制や定期的な変更は課さない」という、従来の社内ルールとは大きく異なる考え方を示しています。

Q. NISTのパスワードポリシーでは、パスワードは何文字以上にすべきですか？

A. パスワードだけで認証する場合は15文字以上、多要素認証の一要素として使う場合は8文字以上が必須（SHALL）です。さらにシステム側は、少なくとも64文字までの長いパスワードを許容すべき（SHOULD）とされています。従来広く使われてきた「8文字以上」は、単一要素認証では新基準を満たしません。

Q. NISTのパスワードポリシーでは、パスワードの定期変更は一切しなくてよいのですか？

A. 一定期間ごとの変更を利用者に強制することは禁止（SHALL NOT）ですが、パスワードが漏えいした証拠がある場合は変更を強制しなければなりません（SHALL）。「一切変更しない」のではなく、期限による自動失効をやめ、漏えいを検知したときに変える運用へ切り替えることが求められています。

Q. パスフレーズとは何ですか？

A. パスフレーズとは、複数の単語をつなげた、長くても覚えやすいパスワードのことです。NISTが記号や数字の混在ではなく長さを重視するようになったことで、短く複雑な文字列よりも、こうした長いパスフレーズのほうが安全で実用的だと考えられています。パスワードマネージャーの利用が許可されている（必須）ことも、長いパスフレーズを現実的に運用しやすくしています。

Q. 既存の「8文字・90日ごと変更」ルールのままだと問題がありますか？

A. NISTに法的な強制力はないため直ちに違反になるわけではありませんが、単一要素認証での「8文字」は新基準（15文字以上）を満たさず、「90日ごとの強制変更」は新基準が禁止する運用にあたります。最小文字数を引き上げ、定期的な強制変更を廃止して漏えい時のみ変更する運用へ切り替えるなど、見直しの対象になります。

Q. 日本の企業もNISTのパスワードポリシーに従う必要がありますか？

A. NIST SP 800-63Bはもともと米国連邦政府機関向けのガイドラインで、日本の民間企業への法的な強制力はありません。ただし国際的な事実上の標準として扱われ、総務省・デジタル庁（DS-511）・金融庁の動向とも「長さを重視し、複雑さや定期変更の強制をやめ、フィッシング耐性のある多要素認証へ進む」という方向性で足並みがそろっています。

自社ポリシーをNISTに合わせて見直すことは、国内の動向とも整合する判断です。

Q. NISTのパスワードポリシーはどの文書で確認できますか？

A. パスワードの要件は、NISTのデジタルアイデンティティガイドラインのうち認証を扱う「SP 800-63B」で定められており、引くべき最新版はSP 800-63B-4（改訂第4版、2025年7月公開）です。前版のSP 800-63B Rev.3（2017年公開）はすでに置き換えられているため、「最新版」と曖昧にせず、版番号と発行年で確認するのが安全です。

Q. Active DirectoryやMicrosoft Entra IDでNIST基準のパスワードポリシーは設定できますか？

A. Windows環境では、Active Directoryのきめ細かなパスワードポリシー（Fine-Grained Password Policy）で最小文字数や変更の扱いを、Microsoft Entra ID（旧Azure AD）のパスワード保護機能で漏えい済み・弱いパスワードの拒否（ブロックリスト照合）を実現できます。

具体的な設定方法と対応範囲は、各製品の公式ドキュメントで確認してください。

Q. NISTはパスワードを長くすれば多要素認証やパスキーは不要としていますか？

A. いいえ。NISTはパスワードを強くするだけでは不十分だとし、フィッシング耐性のある多要素認証やパスキーへ進むことを求めています。認証保証レベルAAL2以上では、フィッシング耐性のある認証手段を少なくとも1つ提供することが必須（SHALL）とされており、パスワードポリシーの見直しとあわせて、認証方式そのものの強化を検討する価値があります。

多要素認証・パスキー対応サービスの資料を一括チェック

MCB FinTechカタログでは、フィッシング耐性のある多要素認証・パスキー・セキュリティキーに対応したサービスの最新資料を無料で一括請求できます。認証方式や対応規格、導入の進め方を横並びで比較できます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。