## **【詳細解説】NIST SP 800-63のパスワード要件とパスキー（FIDO2）への移行**
2025.12.23
生成AIにより原案作成
中山 加筆訂正
### **1\. エグゼクティブサマリー**
米国国立標準技術研究所（NIST）が策定する「デジタルアイデンティティガイドライン（NIST Special Publication 800-63）」は、米国連邦政府機関向けの技術要件として出発しながらも、現在では世界中の民間企業、金融機関、および重要インフラにおけるアイデンティティ管理（IAM）の事実上の国際標準として機能している。現在、その最新版であるRevision 4（以下、SP 800-63-4）の策定プロセスが進行しており、デジタル認証のランドスケープにおける劇的な変化を反映した大幅な改訂が行われている 1。
本報告書は、NIST SP 800-63-4（ドラフト版を含む最新情報）に基づき、組織が遵守すべき推奨要件を網羅的に分析するものである。特に、ユーザーからの問い合わせの核心である「パスワード（メモライズドシークレット）」および「FIDO2/パスキー（同期可能な認証器）」に関する規定について、その技術的背景、セキュリティ上の含意、および実装戦略を詳述する。
SP 800-63-4への移行は、単なるパラメータの調整ではない。それは、「複雑なパスワードと定期的変更」という従来のドグマ（教義）を完全に否定し、「フィッシング耐性」と「ユーザー体験（UX）の公平性」をセキュリティの根幹に据える哲学的な転換である 1。本稿では、これらの要件がなぜ導入されたのかという背景（Why）と、具体的にどのように実装すべきか（How）を、15,000語規模の深度で徹底的に解説する。
### **2\. デジタルアイデンティティモデルの構造的変革**
#### **2.1 xAL（保証レベル）の分離とリスク管理の進化**
NIST SP 800-63シリーズの最大の特徴は、アイデンティティ保証を単一のレベル（Level of Assurance: LOA）で評価する従来のモデルを廃止し、3つの独立したコンポーネントに分離した点にある 1。Revision 4ではこの構造が維持されつつ、各レベルの定義が現代の脅威ランドスケープに合わせて厳格化および柔軟化されている。
| 保証カテゴリ | 定義とSP 800-63-4における焦点 |
|:---- |:---- |
| **IAL (Identity Assurance Level)** | **身元確認レベル**。 実世界の存在（個人）がデジタルIDと正しく紐付いているかの確度。Rev 4では、リモートでの身元確認（Remote Identity Proofing）が正式にIAL2の要件を満たすものとして整理され、公平性（Equity）への配慮が義務化された 1。 |
| **AAL (Authenticator Assurance Level)** | **認証保証レベル**。 ログインしようとしているユーザーが、正当なID所有者であるかの確度。フィッシング耐性がAAL2/AAL3の主要な差別化要因となり、同期可能なパスキーの扱いが明確化された 1。 |
| **FAL (Federation Assurance Level)** | **連携保証レベル**。 IDプロバイダ（IdP）とリライングパーティ（RP）間で受け渡されるアサーション（証明情報）の信頼性。Rev 4では「ユーザー管理型ウォレット（User-Controlled Wallets）」がモデルに統合された 1。 |
#### **2.2 リスク管理への新たなアプローチ**
SP 800-63-4では、単に高い保証レベルを選択することが正解とはされていない。組織は「デジタルアイデンティティリスク管理（DIRM）」プロセスを通じて、ミッションへの影響、財務的損失、そして個人のプライバシーや公平性への影響を総合的に評価し、適切なxALを選択しなければならない 1。
特に重要なのは、過剰なセキュリティ要件がユーザーを排除してしまうリスク（例：生体認証が使えない障害者や、スマートフォンを持たない層への配慮）が、セキュリティリスクと同等に扱われるようになった点である 5。
### **3\. メモライズドシークレット（パスワード）の完全なる再定義**
パスワード、すなわちNIST用語における「メモライズドシークレット（Memorized Secrets）」に関する要件は、長年セキュリティ業界を支配してきた「常識」を覆すものである。攻撃者の手法が、パスワードの推測（ブルートフォース）から、ソーシャルエンジニアリング、フィッシング、そしてクレデンシャルスタッフィング（リスト型攻撃）へと高度化したことに対応し、防御策も根本的に変更された。
#### **3.1 「複雑性」から「長さ」へのパラダイムシフト**
かつて推奨された「大文字、小文字、数字、記号を混在させる」という複雑性要件は、SP 800-63-4において明確に\*\*「課してはならない（SHALL NOT）」\*\*要件へと変更された 8。
##### **3.1.1 科学的根拠：エントロピーと人間工学**
複雑性ルールが廃止された背景には、人間行動学的な理由がある。人間に対して記号や数字の混在を強制すると、多くのユーザーは「Password123\!」のように、予測可能なパターン（末尾に数字と記号を追加、先頭を大文字にする等）を採用する傾向がある。これは攻撃者にとって既知のパターンであり、実質的な探索空間（エントロピー）を広げる効果が薄いことが研究により明らかになっている 10。
一方で、パスワードの「長さ」は、総当たり攻撃に対する耐性を指数関数的に高める。NISTは、覚えにくく短い複雑なパスワードよりも、覚えやすく長い「パスフレーズ（Passphrase）」の使用を推奨している。
##### **3.1.2 具体的な長さ要件**
SP 800-63-4における長さの要件は以下の通り厳格に定義されている。
| パスワードの用途 | 推奨/必須要件 | 解説とインサイト |
|:---- |:---- |:---- |
| **多要素認証の一部として使用** | **8文字以上** 9 | 別の要素（OTPやFIDOなど）がある場合の最低ライン。 |
| **単要素認証として使用** | **15文字以上** 8 | 単一の防御壁として機能する場合、8文字では現代のGPUによる解析に対して脆弱であるため、15文字以上が必須（SHALL）とされた。これは多くの組織にとってポリシー変更を迫る重要なポイントである。 |
| **システム生成（一時パスワード等）** | **6文字以上** 9 | ランダム性が担保されている場合の最低長。 |
| **最大文字数の許容** | **64文字以上** 8 | システムは、ユーザーが非常に長いパスフレーズを設定することを妨げてはならない。最低でも64文字まで許容すべきである。 |
#### **3.2 パスワードライフサイクル：定期変更の終焉と「侵害検知」**
企業のセキュリティポリシーの代名詞であった「90日ごとのパスワード変更」は、SP 800-63-4において**推奨されない慣行**として完全に否定された 4。
##### **3.2.1 定期変更の弊害**
定期的な変更を強制されると、ユーザーは古いパスワードの一部だけを変える（例：Winter2024 \-\> Spring2025）等の安易な変更を行い、結果としてパスワード強度が低下する「変更疲れ」を引き起こす。また、パスワードを付箋に書いて貼るなどの危険な行動を誘発する 12。
##### **3.2.2 新たな必須要件：侵害パスワードリストとの照合**
定期変更を廃止する代わりに、検証者（Verifier）には新たな義務が課される。それは、ユーザーがパスワードを設定または変更する際に、**既知の侵害されたパスワードリスト（Blacklist）と照合すること**である 9。
* **メカニズム:** Have I Been Pwnedなどのデータベースや、ダークウェブから流出したパスワードリストを使用し、ユーザーが設定しようとしているパスワードが既に攻撃者に知られているものでないかを確認する。
* **強制変更の条件:** 侵害の証拠（リストへの合致や、不審なログイン試行）が検知された場合にのみ、パスワードの変更を強制すべきである。
#### **3.3 ユーザーインターフェース（UX）とユーザビリティ要件**
NISTは、ユーザビリティの向上がセキュリティ向上に直結すると考えている。使いにくいシステムは、ユーザーによる回避策（シャドーITや脆弱なパスワードの使い回し）を招くからである。
##### **3.3.1 ペースト（貼り付け）機能の強制許可**
検証者は、パスワード入力フィールドにおける「貼り付け（Paste）」機能を許可しなければならない（SHOULD permit/support） 10。
* **意図:** パスワードマネージャーの使用を促進するためである。パスワードマネージャーが生成するランダムで強力なパスワード（例：Xy7\#b9\!zL2...）を手入力することは困難であり、ペースト禁止はその利用を阻害する最大の要因となる 12。
##### **3.3.2 パスワード表示オプション**
入力中のパスワードをマスク（●●●）するのではなく、ユーザーの選択により平文で表示するオプション（「目」のアイコンなど）を提供すべきである（SHOULD offer） 10。
* **意図:** これにより、入力ミスを確認するためのストレスを軽減し、特にモバイルデバイスや複雑なパスフレーズ入力時のユーザー体験を向上させる。また、周囲に誰もいない安全な環境であれば、表示して確認することはリスクではないと判断されている。
#### **3.4 サーバーサイドの保存要件：暗号学的アジリティ**
検証者がパスワードを保存する際の要件も、計算機能力の向上に合わせて強化されている。
* **ハッシュ化とソルト:** パスワードは決して平文で保存してはならず、また可逆暗号化してもならない。必ずソルト（32ビット以上）を付加した上で、一方向ハッシュ関数を用いて保存する必要がある 15。
* **ストレッチング（コストファクター）:** ハッシュ計算には、PBKDF2、Argon2、Bcryptなどの、計算コストを調整可能なアルゴリズムを使用し、ハードウェア性能の向上に合わせてイテレーション回数（コスト）を定期的に見直す必要がある 14。
* **ペッパー（Keyed Hashing）の推奨:** 通常のソルト付きハッシュに加え、検証者のみが知る秘密鍵（ペッパー）を用いた計算（HMAC等）を追加で行うことが推奨される。この秘密鍵は、ハッシュデータベースとは物理的・論理的に分離されたハードウェア（HSM等）に保存されるべきである 15。これにより、データベースが流出しても、ペッパーが守られている限り総当たり攻撃は困難となる。
### **4\. 認証保証レベル（AAL）の詳細分析と要件マトリクス**
SP 800-63-4では、認証プロセスにおける強度と信頼性をAAL1からAAL3の3段階で定義している。特にFIDO2/パスキーの導入に伴い、AAL2とAAL3の要件区分がより技術的に詳細化されている。
#### **4.1 AAL1：単要素認証（Single-Factor Authentication）**
* **概要:** 最低限の保証レベル。リスクが低い、または個人情報を含まないシステム向け。
* **要件:**
* **認証要素:** 「記憶（パスワード）」、「所持（物理トークン）」、「生体（バイオメトリクス）」のいずれか一つでよい。
* **パスワード:** 前述の通り、単要素で使用する場合は**15文字以上**が必要 8。
* **暗号化:** 連邦政府機関の場合、検証者はFIPS 140 Level 1準拠の暗号化を使用しなければならない 17。
* **再認証:** 30日ごとの再認証が推奨される 8。
#### **4.2 AAL2：多要素認証（Multi-Factor Authentication） \- 推奨ベースライン**
* **概要:** ほとんどの商用サービス、企業の一般業務、機密情報を扱うシステムにおける標準的な目標レベル。SP 800-63-4では、フィッシング耐性のある認証手段（パスキー等）を「オプションとして提供すること」が強く推奨されている 1。
* **要件:**
* **認証要素:** 2つの異なる認証要素（記憶＋所持、所持＋生体など）の証明が必須。
* **リプレイ攻撃耐性:** 必須（Required）。OTPやFIDOなどがこれを提供する。
* **認証意図（Authentication Intent）:** ユーザーが認証操作を意識的に行ったことの証明（ボタン押下や生体スキャン）が必要 19。
* **パスワード:** MFAの一部として使用する場合、8文字以上で可。
* **FIDO2/パスキー:** **「同期可能な認証器（Syncable Authenticators）」の使用が可能**。ただし、ユーザー検証（User Verification）を行うことで、単一のデバイスで「所持」と「生体/知識」の2要素を満たす必要がある。
* **再認証:** 12時間ごとの再認証が推奨される 8。
#### **4.3 AAL3：ハードウェアベースの多要素認証**
* **概要:** 国家機密、防衛、極めて高額な金融取引、重要インフラ制御など、最高レベルのリスク対策が必要な領域。
* **要件:**
* **認証要素:** 2つの異なる認証要素に加え、**ハードウェアトークン**の使用が必須。
* **フィッシング耐性:** **必須（REQUIRED）**。FIDO2/WebAuthnまたはPIV/CACカードなどが該当する。
* **検証者なりすまし耐性:** 必須。
* **非エクスポート性（Non-exportability）:** 秘密鍵はハードウェア内の保護された領域（Secure Element, TPM等）に生成・保存され、外部への出力が物理的に不可能でなければならない 17。
* **FIDO2/パスキー:** **「同期可能なパスキー」は使用禁止（SHALL NOT use）**。秘密鍵がクラウドへ同期（エクスポート）される性質が、AAL3の非エクスポート要件に抵触するためである 8。デバイスバウンド（同期不可）なFIDOセキュリティキーのみが許可される。
* **FIPS認定:** FIPS 140 Level 1（物理セキュリティLevel 3推奨）以上の認定を受けたモジュールが必要 17。
### **5\. FIDO2、パスキー、および同期可能な認証器の革命**
NIST SP 800-63-4における最大の技術的革新は、Apple、Google、Microsoftなどが推進する「パスキー（Passkeys）」を「同期可能な認証器（Syncable Authenticators）」として定義し、その位置づけを明確化した点にある。
#### **5.1 同期可能な認証器（Syncable Authenticators）の定義と承認**
従来、NISTは「秘密鍵の複製」に対して慎重な姿勢を崩さなかった。しかし、Rev 4では、ユーザビリティ（デバイス紛失時の復旧容易性）とセキュリティ（パスワード撲滅）のバランスを考慮し、鍵をクラウド（Sync Fabric）経由で同期する手法を公式に認めた 6。
* **定義:** 認証鍵を「同期ファブリック（Sync Fabric）」と呼ばれるクラウドストレージに複製し、同一ユーザーの他のデバイスに伝搬させる機能を持つ認証器 20。
* **AAL2への適合:** 適切に要件を満たす同期可能な認証器は、**AAL2**として認定される 1。これは、企業や政府機関がパスキーを広範に採用するための「お墨付き」を与えたに等しい。
#### **5.2 AAL2適合のための技術的要件（Appendix B詳細）**
パスキーが単に「便利」なだけでなく、NIST基準のセキュリティを満たすためには、以下の厳格な要件（SP 800-63B Appendix B）をクリアする必要がある 6。
###### **5.2.1 Sync Fabric（クラウド）の保護要件**
パスキーの秘密鍵を保管するクラウド側（Apple iCloud, Google Password Manager等）には、極めて高い安全性が求められる。
* **暗号化:** 鍵は転送・保存される際、最低112ビット以上の強度を持つ鍵で暗号化されなければならない。推奨としては、ユーザーが管理する秘密（パスワードやPIN）に依存する形で暗号化されるべきである（例：iCloud KeychainのE2EE） 6。
* **アクセス制御:** Sync Fabricへのアクセス自体が、**AAL2相当の多要素認証**で保護されていなければならない 6。つまり、パスキーを同期するGoogleアカウントやApple ID自体に、強力なMFAがかかっていることが前提条件となる。
* **鍵のローカル操作:** 認証時の署名操作は、必ずデバイスローカルで行われなければならない。クラウド上で署名代行を行ってはならない 6。
###### **5.2.2 WebAuthnフラグの解釈と実装**
サービス提供者（RP）は、FIDO2/WebAuthnプロトコルから返されるメタデータ（フラグ）を正確に解釈し、リスク判断を行う必要がある 6。
| フラグ | 名称 | 意味とNIST要件 | インサイト |
|:---- |:---- |:---- |:---- |
| **UP** | User Present | ユーザーの存在（タッチ等）。 | 必須。マルウェアによる自動操作を防ぐ「認証意図（Authentication Intent）」の証明となる。 |
| **UV** | User Verified | ユーザー検証（生体/PIN）。 | **推奨（Preferred）**。このフラグがtrueの場合、認証器は「所持＋生体/知識」の2要素として扱われる。falseの場合、単なる「所持」要素（単要素）として扱われるため、別途パスワード等が必要になる 15。 |
| **BE** | Backup Eligible | 同期可能か。 | 認証器が同期機能を持っているかを示す。AAL3システムでは、このフラグがtrueの認証器を拒否するポリシーを実装できる。 |
| **BS** | Backup State | 同期されたか。 | 実際に鍵が同期状態にあるかを示す。リスクスコアリングに使用可能。 |
#### **5.3 エンタープライズにおける管理とAttestation**
企業が従業員にパスキーを使用させる場合、「個人のパスキー」と「企業のパスキー」の混同が課題となる。NISTは以下の管理策を提示している。
* **エンタープライズ構成証明（Enterprise Attestation）:** 認証器が組織の管理下にあるデバイスで生成されたことを証明する機能（Attestation）を利用し、私物デバイスや未認可の同期ファブリックの使用を制限すべきである 6。
* **MDMによる制限:** 連邦政府機関等の高度な要件下では、同期可能な認証器を使用するデバイス自体をMDM（モバイルデバイス管理）で制御し、鍵の同期先を組織が認可したアカウントに限定することが求められる 6。
### **6\. フェデレーション（連携）とデジタルウォレット**
認証だけでなく、認証結果をシステム間で共有するフェデレーション（Federation）に関しても、SP 800-63-4は重要な拡張を行っている。
#### **6.1 ユーザー管理型ウォレット（User-Controlled Wallets）**
従来、フェデレーションはIdP（Identity Provider）とRP（Relying Party）の直接通信（SAML, OIDC）が主であった。Rev 4では、モバイル運転免許証（mDL）やVerifiable Credentials（検証可能なクレデンシャル）を格納する「ユーザー管理型ウォレット」がモデルに組み込まれた 1。
これにより、ユーザーはIdPに毎回問い合わせることなく、自身のウォレットから属性情報（年齢、資格等）を提示できるモデル（FALの一部）が定義されている。
#### **6.2 FAL（Federation Assurance Level）の構造**
FALは、アサーション（SAMLレスポンスやIDトークン）の保護強度を規定する。
* **FAL1:** アサーションへの署名（Signed Assertion）。IdPが発行したことの証明。
* **FAL2:** アサーションの暗号化（Encrypted Assertion）。RP以外が内容を盗み見れないようにする。
* **FAL3:** ホルダーオブキー（Holder-of-Key）証明。アサーションを持参したユーザーが、そのアサーションに紐付く秘密鍵を実際に持っていることを証明する 5。これにより、アサーションの奪取（Bearer Token盗難）によるなりすましを防ぐ。
### **7\. 公平性（Equity）とユーザー体験の統合**
SP 800-63-4の特筆すべき点は、技術要件の中に「社会正義」的な観点が深く組み込まれていることである。
#### **7.1 生体認証におけるバイアスの排除**
顔認証などの生体認証技術は、特定の人種、肌の色、年齢層に対して認識精度が低い（False Reject Rateが高い）という問題が指摘されてきた。NISTは、アイデンティティ証明（IAL）および認証（AAL）において、特定の人口統計学的グループに対して不当に機能しない技術を選定・評価することを求めている 5。
#### **7.2 代替手段の提供義務**
すべてのユーザーがスマートフォンや生体認証を利用できるわけではない。公平性の観点から、特定の最新技術（例：顔認証のみ）を強制し、それを利用できないユーザーをサービスから排除することは許されない。組織は、同等の保証レベルを持つ代替手段（例：ハードウェアトークン、または特別対応窓口）を必ず用意しなければならない 5。
### **8\. 戦略的移行ガイド：レガシーからモダンへの道筋**
NIST SP 800-63-4への準拠は一朝一夕には達成できない。組織は、現在のパスワード依存モデルから、フィッシング耐性のあるモデルへ段階的に移行する必要がある。
#### **8.1 移行のロードマップ**
1. **即時対応（パスワードポリシーの緩和と監視強化）:**
* 定期変更を廃止する。
* 複雑性要件を撤廃し、長さチェック（最低15文字/8文字）へ切り替える。
* パスワード入力時のペースト許可と表示オプションを実装する。
* **最も重要:** 侵害パスワード検知システム（Breach Detection）を導入する。これがなければ定期変更廃止はリスクとなる。
2. **AAL2への移行（パスキーの導入）:**
* WebAuthn対応の実装を開始し、パスキー（同期可能）をログインのオプションとして追加する。
* SMS OTPなどの脆弱なMFAから、パスキーまたはアプリベースのOTPへの移行を促す。
3. **AAL3/フィッシング耐性の強制（高リスク層向け）:**
* 管理者や特権IDに対しては、YubiKeyなどのデバイスバウンドキー（FIDO2 Security Key）を強制し、AAL3相当の保護を適用する。
#### **8.2 レガシー認証の扱い**
従来のパスワードハッシュ（MD5やSHA-1等）が残っている場合、ユーザーが次回ログインしたタイミングで、透明性を持って新しいアルゴリズム（Argon2, PBKDF2）へ自動的に移行（Re-hashing）する仕組みを実装すべきである 15。また、認証ログを分析し、レガシープロトコルによるアクセスを段階的に遮断していく計画が必要である。
### **9\. 結論**
NIST SP 800-63-4は、デジタルアイデンティティの管理において、「形式的なコンプライアンス」から「実効性のある防御」への転換を迫るものである。
**パスワード**に関しては、ユーザーを苦しめるだけの無意味なルール（複雑性と定期変更）を撤廃し、数学的に強固な「長さ」と、運用的に強固な「侵害検知」に焦点を絞った。これは、セキュリティとユーザビリティがトレードオフではなく、相互補完関係にあることを示している。
**FIDO2/パスキー**に関しては、同期可能な認証器をAAL2として認めることで、マスマーケットにおけるフィッシング耐性認証の普及に道を開いた。これは、セキュリティ専門家が長年夢見てきた「パスワードレス社会」への現実的な架け橋となる。一方で、AAL3における「非エクスポート性」の維持は、国家安全保障レベルのセキュリティには妥協がないことを示している。
本ガイドラインは、CISOやセキュリティアーキテクトに対し、単にツールを導入するだけでなく、システム全体の設計思想を「ゼロトラスト」と「ユーザー中心」へ再構築することを求めている。SP 800-63-4の推奨事項に従うことは、現代のサイバー脅威に対する最も堅牢な盾となるであろう。
---
*本報告書は、NIST SP 800-63-4（Public Draftおよび関連資料）に基づき作成された専門的な分析レポートです。実装に際しては、常にNISTの公式リポジトリ（csrc.nist.gov）で最新の確定情報を確認することを推奨します。*
###### **引用文献**
1. NIST SP 800-63-3 & 63-4: Digital Identity Guidelines \- HYPR Blog, 12月 23, 2025にアクセス、 [https://blog.hypr.com/nist-sp-800-63-3-digital-identity-guidelines-review](https://blog.hypr.com/nist-sp-800-63-3-digital-identity-guidelines-review)
2. NIST SP 800-63 Digital Identity Guidelines, 12月 23, 2025にアクセス、 [https://pages.nist.gov/800-63-4/](https://pages.nist.gov/800-63-4/)
3. NIST SP 800-63-4: The Future of Digital Identity is Here — And Intercede is Ready, 12月 23, 2025にアクセス、 [https://www.intercede.com/nist-sp-800-63-4-the-future-of-digital-identity-is-here-and-intercede-is-ready/](https://www.intercede.com/nist-sp-800-63-4-the-future-of-digital-identity-is-here-and-intercede-is-ready/)
4. NIST SP 800-63 Digital Identity Guidelines-FAQ, 12月 23, 2025にアクセス、 [https://pages.nist.gov/800-63-FAQ/](https://pages.nist.gov/800-63-FAQ/)
5. NIST SP 800-63-4 Is Coming — Are Your Assurance Levels Ready? \- ID Dataweb, 12月 23, 2025にアクセス、 [https://www.iddataweb.com/2025-nist-guidelines/](https://www.iddataweb.com/2025-nist-guidelines/)
6. Syncable Authenticators \- NIST Pages \- National Institute of Standards and Technology, 12月 23, 2025にアクセス、 [https://pages.nist.gov/800-63-4/sp800-63b/syncable/](https://pages.nist.gov/800-63-4/sp800-63b/syncable/)
7. NIST Revises Digital Identity Guidelines | SP 800-63-4 | CSRC, 12月 23, 2025にアクセス、 [https://csrc.nist.gov/News/2025/nist-revises-digitial-identity-guidelines-sp-800-6](https://csrc.nist.gov/News/2025/nist-revises-digitial-identity-guidelines-sp-800-6)
8. NIST Special Publication 800-63B, 12月 23, 2025にアクセス、 [https://pages.nist.gov/800-63-4/sp800-63b.html](https://pages.nist.gov/800-63-4/sp800-63b.html)
9. NIST Password Guidelines: What You Need to Know \- Netwrix, 12月 23, 2025にアクセス、 [https://netwrix.com/en/resources/blog/nist-password-guidelines/](https://netwrix.com/en/resources/blog/nist-password-guidelines/)
10. NIST Special Publication 800-63B, 12月 23, 2025にアクセス、 [https://pages.nist.gov/800-63-3/sp800-63b.html](https://pages.nist.gov/800-63-3/sp800-63b.html)
11. 2022-2023 NIST 800-63b Password Guidelines and Best Practices \- Specops Software, 12月 23, 2025にアクセス、 [https://specopssoft.com/blog/nist-800-63b/](https://specopssoft.com/blog/nist-800-63b/)
12. NIST Password Guidelines: 2025 Updates & Best Practices \- StrongDM, 12月 23, 2025にアクセス、 [https://www.strongdm.com/blog/nist-password-guidelines](https://www.strongdm.com/blog/nist-password-guidelines)
13. NIST Password Guidelines 2025: New Requirements for Dallas Businesses \- ITECS, 12月 23, 2025にアクセス、 [https://itecsonline.com/post/nist-password-guidelines](https://itecsonline.com/post/nist-password-guidelines)
14. NIST SP 800-63B-4 Second Public Draft, Digital Identity Guidelines, 12月 23, 2025にアクセス、 [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.2pd.pdf](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.2pd.pdf)
15. NIST.SP.800-63B-4.pdf, 12月 23, 2025にアクセス、 [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf)
16. Authenticators \- NIST Pages \- National Institute of Standards and Technology, 12月 23, 2025にアクセス、 [https://pages.nist.gov/800-63-4/sp800-63b/authenticators/](https://pages.nist.gov/800-63-4/sp800-63b/authenticators/)
17. Authentication Assurance Levels, 12月 23, 2025にアクセス、 [https://pages.nist.gov/800-63-4/sp800-63b/aal/](https://pages.nist.gov/800-63-4/sp800-63b/aal/)
18. NIST SP 800-63-4 second public draft, Digital Identity Guidelines, 12月 23, 2025にアクセス、 [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-4.2pd.pdf](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-4.2pd.pdf)
19. Incorporating Syncable Authenticators Into NIST SP 800-63B: Digital Identity Guidelines, 12月 23, 2025にアクセス、 [http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf)
20. NIST Special Publication 800-63-4, 12月 23, 2025にアクセス、 [https://pages.nist.gov/800-63-4/sp800-63.html](https://pages.nist.gov/800-63-4/sp800-63.html)
21. FIDO Government Deployments and Recognitions \- FIDO Alliance, 12月 23, 2025にアクセス、 [https://fidoalliance.org/fido-government-deployments-and-recognitions/](https://fidoalliance.org/fido-government-deployments-and-recognitions/)
22. NIST SP 800-63B-4 2pd | PDF | Authentication | National Institute Of Standards And Technology \- Scribd, 12月 23, 2025にアクセス、 [https://www.scribd.com/document/856480727/NIST-SP-800-63B-4-2pd](https://www.scribd.com/document/856480727/NIST-SP-800-63B-4-2pd)
23. NIST.SP.800-63-3.pdf, 12月 23, 2025にアクセス、 [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf)