NIST SP 800-63B-4 は、米国国立標準技術研究所（NIST）が2025年7月に最終版を公開したデジタルアイデンティティ・ガイドラインのうち、認証（Authentication and Authenticator Management）を扱う文書です。
パスワードの定期変更や複雑性ルールの見直し、パスキー（FIDO2）の位置づけなど、認証にまつわる要件が2020年版（SP 800-63B-3）から更新されました。
文書番号で検索してたどり着く多くの担当者が知りたいのは、社内のパスワードポリシーにそのまま書き写せる具体的な要件です。パスワードは結局何文字必要か、定期変更は本当に不要か、認証保証レベル（AAL）ごとに何が必須で何が推奨か、といった実務の疑問に答える確定値が求められます。
要約や「長さが重要」という一般論ではなく、15文字・8文字・64文字といった確定した値と、必須（SHALL）か推奨（SHOULD）かの区別が欲しいところです。
本記事では、NIST SP 800-63B-4 が定めるパスワードと認証の要件を、原文の該当節とともに整理します。確認できる要点は次のとおりです。
本記事では、規格が義務づける要件と、それを自社にどう当てはめるかの判断を分けて示します。
本記事が扱うのは認証を定める 800-63B で、身元確認（IAL）は 800-63A、連携（フェデレーション）は 800-63C が別に扱います。
目次
一括ダウンロードする
NIST SP 800-63B-4 のパスワード要件
まず、読者が最も知りたいパスワードの要件を一覧で示します。SP 800-63B-4 では、旧版で「記憶された秘密（Memorized Secret）」と呼ばれていた要素が「パスワード（Password）」に改称され、§3.1.1 以下に要件が整理されています。次の表は、検証者（サービス提供側）とCSP（認証事業者）が満たすべき要件を、値・必須/推奨の別・原文の該当節とともにまとめたものです。
| 項目 | 要件（値） | 必須・推奨の別 | 原文の該当節 |
|---|---|---|---|
| 最低長 | 単要素認証として使う場合は15文字以上、多要素認証の一部として使う場合は8文字以上 | 必須（SHALL） | §3.1.1.2 |
| 最大長 | 64文字以上までを許容する | 推奨（SHOULD） | §3.1.1.2 |
| 文字種の強制（複雑性） | 大文字・小文字・数字・記号の混在を求める構成ルールを課さない | 禁止（SHALL NOT） | §3.1.1.2 / §3.1.1.1 |
| 定期変更 | 定期的な変更を要求しない。侵害の証拠がある場合のみ変更を強制する | 禁止（SHALL NOT）／侵害時は必須（SHALL） | §3.1.1.2 |
| ブロックリスト照合 | 既知の流出・頻出・推測されやすいパスワードを拒否する（照合はパスワード全体を対象とする） | 必須（SHALL） | §3.1.1.2 |
| パスワードマネージャ | パスワードマネージャと自動入力の利用を許可する | 必須（SHALL） | §3.1.1.2 |
| ペースト入力 | 入力時の「貼り付け」を許可する | 推奨（SHOULD） | §3.1.1.2 |
| 回復方法 | パスワード設定時に秘密の質問や知識ベース認証（KBA）を使わせない | 禁止（SHALL NOT） | §3.1.1.2 |
最低長は、原文で次のように定められています。単要素認証と多要素認証の一部とで、必要な文字数が分かれている点が要点です。
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 §3.1.1.2 Password Verifiers｜NIST
定期変更についても、原文では「定期的な変更を要求してはならない」と「侵害の証拠がある場合は変更を強制しなければならない」が1文に併記されています。一律の定期変更は禁止されますが、漏えいが確認された場合の強制変更は必須です。
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 §3.1.1.2 Password Verifiers｜NIST
複雑性ルールと回復方法についても、原文は「課してはならない（SHALL NOT）」という禁止の形で定めています。文字種の混在を強制しないこと、秘密の質問や知識ベース認証をパスワード設定時に使わせないことが、いずれも禁止事項として明記されています。パスワード全体をブロックリストと照合する際は、部分文字列ではなくパスワード全体を対象にする点も要件に含まれます。
出典・参考資料（1件）
検証者（verifier）側の保存・検証要件
ここまでは利用者が入力するパスワードの要件でしたが、SP 800-63B-4 は同じ§3.1.1.2で、サービスを提供する検証者側の保存方法についても要件を定めています。パスワードはオフライン攻撃に耐える形で保存し、適切なハッシュ方式でソルトを付けてハッシュ化しなければなりません（SHALL）。ソルトは最低32ビットとし、ソルト値とハッシュ値の双方を各パスワードごとに保存することが求められます。
さらに、使用したハッシュ方式（コスト係数を含む）への参照を保存し、新しいアルゴリズムやワークファクタへ移行できるようにすべきとされています（SHOULD）。原文は「新しいアルゴリズムやワークファクタへの移行を可能にする」と表現しており、実務ではこれを暗号方式の更新への備えとして扱います。あわせて、検証者だけが知る秘密鍵による鍵付きハッシュや暗号化の追加処理も推奨されています（SHOULD）。
出典・参考資料（1件）
認証保証レベル（AAL1/AAL2/AAL3）の要件
AAL1からAAL3へと、求められる認証の強度は段階的に上がります。まず3段階の全体像は、次のとおりです。
SP 800-63B-4 は、認証の強度を3段階の認証保証レベル（AAL：Authentication Assurance Level）で定めています。どのレベルで何が必須・推奨になるかを、次のマトリクスで示します。各セルの根拠は §2.1〜2.3 の本文にあり、この一覧は原文の要約表（§2.5 Table 1）の構成に沿っています。
NIST はこの Table 1 自体を非規範的な要約と位置づけているため、個々の要件の根拠は本文の該当節で確認してください。
| 要件 | AAL1 | AAL2 | AAL3 |
|---|---|---|---|
| 認証要素 | 単要素または多要素（多要素は推奨） | 多要素認証（2要素）が必須 | 公開鍵暗号を用いる暗号認証器が必須 |
| フィッシング耐性 | 不要 | 選択肢の提供は必須／利用は推奨（連邦機関は利用も必須） | 必須 |
| リプレイ耐性 | 不要 | 必須（1つ以上の認証器） | 必須 |
| 秘密鍵のエクスポート | 許可 | 許可 | 禁止（非エクスポートが必須） |
| 再認証間隔（全体／非活動） | 全体30日以内（推奨・§2.1.3） | 全体24時間以内／非活動1時間以内（いずれも推奨・§2.2.3） | 全体12時間以内（必須）／非活動15分以内（推奨）（§2.3.3） |
| 原文の該当節 | §2.1 | §2.2 | §2.3 |
再認証の時間はいずれも推奨値（SHOULD）で、AAL3の全体タイムアウト12時間のみが必須（SHALL）です。以下では、各レベルの要件を個別に確認します。
AAL1の要件
AAL1は、幅広い認証技術を使った単要素または多要素認証を認めるレベルです。多要素認証の選択肢を用意し、その利用を促すことが推奨されています（SHOULD）。再認証の全体タイムアウトは30日以内が推奨値で、非活動タイムアウトは任意（MAY）とされ、AAL1では必須ではありません。フィッシング耐性とリプレイ耐性は、AAL1では求められません。
AAL2の要件
AAL2では、多要素認証器、または2つの別個の認証要素の組み合わせを使うことが必須です（SHALL）。使用する認証器のうち少なくとも1つはリプレイ耐性を持つ必要があります。フィッシング耐性については、必須と推奨が混在するため、区別して理解する必要があります。
原文では、検証者はAAL2で少なくとも1つのフィッシング耐性認証の選択肢を提供しなければなりません（SHALL offer）。一般の利用側はその利用を促すべきとされ（SHOULD encourage）、連邦機関は職員・委託先・パートナーに利用を要求しなければなりません（SHALL）。
選択肢を用意すること自体は必須、一般の利用の強制は推奨、連邦機関での利用は必須、という三層構造です。「AAL2はフィッシング耐性が推奨」とだけ理解すると、提供自体が必須である点を取りこぼします。
Verifiers SHALL offer at least one phishing-resistant authentication option at AAL2, as described in Sec. 3.2.5. Federal agencies SHALL require their staff, contractors, and partners to use phishing-resistant authentication to access federal information systems. In all cases, verifiers SHOULD encourage the use of phishing-resistant authentication at AAL2 whenever practical since phishing is a significant threat vector.
出典：NIST SP 800-63B-4 §2.2.2 Authenticator and Verifier Requirements｜NIST
再認証の全体タイムアウトは24時間以内、非活動タイムアウトは1時間以内がいずれも推奨値です。
AAL3の要件
AAL3は、フィッシング耐性を備えた非エクスポートの秘密鍵を持つ暗号認証器の使用を求める、最も強いレベルです。認証器は非エクスポートの秘密鍵を持ち、フィッシング耐性を提供し、公開鍵暗号を用いて検証者の侵害から認証の秘密を守ることが、いずれも必須（SHALL）です。認証プロトコルはリプレイ耐性を持つ必要があります。
再認証の全体タイムアウトは12時間以内が必須で、非活動タイムアウトは15分以内が推奨値です。
秘密鍵を同期できる認証器（後述する同期型パスキー）は、鍵のエクスポートを前提とするため、AAL3では使えません（SHALL NOT）。AAL3には、秘密鍵を端末外に出さないデバイス束縛型の認証器が必要です。
フィッシング耐性認証とは（該当・非該当の分類）
AAL2・AAL3の要件で中心となるフィッシング耐性認証について、SP 800-63B-4 の定義と、どの方式が該当するかを確認します。
原文では、フィッシング攻撃は旧版で「検証者なりすまし（verifier impersonation）」と呼ばれていたものと同じであり、フィッシング耐性とは、利用者の注意深さに頼らずに、認証の秘密や有効な認証器の出力を偽の検証者へ渡さないようにするプロトコルの能力だとされています。
重要なのは、フィッシング耐性には単要素または多要素の暗号認証が必要であり、認証器の出力を手入力する方式はフィッシング耐性とみなされないと明記されている点です。手入力では、その出力が認証中のセッションに結びつかないためです。
Phishing resistance requires single- or multi-factor cryptographic authentication. Authenticators that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated.
出典：NIST SP 800-63B-4 §3.2.5 Phishing Resistance｜NIST
フィッシング耐性の該当・非該当
原文は、方式ごとにフィッシング耐性の有無を示しています。耐性がある方式と、原文が明示的に「フィッシング耐性なし」とする方式を整理すると、次のようになります。原文は方式を「ワンタイムパスワード（OTP）」「アウトオブバンド（out-of-band）」といった類型で記述しており、SMS認証・認証アプリ（TOTP）・プッシュ通知といった具体的な製品名はこれらの類型に当てはめて判断します。
- フィッシング耐性あり： FIDO2/WebAuthn（パスキー）、クライアント証明書（PIV/CACなど、米政府の職員向け本人認証カードで使われる方式）。原文は、FIDO2が使うWebAuthnを検証者名のひも付けによる耐性の例、PIV/CACをチャネルのひも付けによる耐性の例として挙げています。
- フィッシング耐性なし： パスワード、ルックアップシークレット、アウトオブバンド認証（SMSなど）、ワンタイムパスワード（認証アプリのTOTPを含む）。これらは原文で明示的に「フィッシング耐性なし」とされています。プッシュ通知による承認も、認証の出力が認証中のセッションに結びつかないため、フィッシング耐性は備えません。
出典・参考資料（1件）
同期型パスキーとデバイス束縛型のAALでの扱い
パスキーには、複数の端末へ秘密鍵を同期できる同期型と、秘密鍵を1つの端末や物理デバイスから出さないデバイス束縛型があります。SP 800-63B-4 は、両者をAALで区別しています。
同期できる認証器は、鍵をエクスポートできることを前提とするため、条件を満たせばAAL2での認証に使えますが、AAL3の非エクスポート要件には違反するとされています。鍵を同期する基盤（sync fabric）内の認証鍵へのアクセスは、AAL2相当の多要素認証で保護しなければなりません（SHALL）。
一方、秘密鍵を端末外に出さないデバイス束縛型のFIDOセキュリティキーなどは、AAL3の要件を満たせます。同期型パスキーはAAL2まで、デバイス束縛型はAAL3まで、と整理できます。
旧版（SP 800-63B-3, 2020年）からの主な変更点
文書番号で調べる担当者が気にするのは、どの版の話かという点です。SP 800-63B-4 は、2020年3月公開の旧版（SP 800-63B、いわゆる Rev.3）を置き換える最終版で、公開は2025年7月31日です。主な変更点は、原文の付録E（Change Log）で公式に確認できます。付録Eに挙げられた項目から、認証に関わる主な変更を抜き出すと次のとおりです。
- 「記憶された秘密（memorized secrets）」の名称を「パスワード（passwords）」に変更した。
- 単要素として使うパスワードの最低長を引き上げた（§3.1.1.2）。
- AAL3について、「ハードウェアベースの認証器」ではなく「非エクスポートの暗号認証器」を求める形に変更し、必要なFIPS 140（米国の暗号モジュール認証）の検証レベルを引き下げた（§2.3.2）。
- 同期可能な認証器（同期型パスキー）の要件を追加した（§3.1.7.4・付録B）。
- フィッシング耐性認証器の定義を追加し、要件を更新した（§3.2.5）。
- 認証器の秘密の非エクスポート性に関する節を新設した（§3.2.13）。
- 利用者が管理するウォレットによる認証の要件を追加した（§3.1.7.3）。
同期型パスキーがAAL2で使えるようになった点と、フィッシング耐性認証の定義が明文化された点は、Rev.4で特に実務への影響が大きい変更です。身元確認（IAL）は SP 800-63A-4、連携（フェデレーション）とデジタルウォレットの連携部分は SP 800-63C-4 が扱い、本記事が扱う 800-63B-4 とは別の文書になります。
出典・参考資料（2件）
【補足】国内のフィッシング耐性認証の動き
NISTは米国の標準ですが、フィッシング耐性認証を求める動きは国内の制度にも及んでいます。ここで扱うのは日本の制度であり、前述のNISTの規定とは別物として参照してください。
金融庁は2025年10月15日に「金融商品取引業者等向けの総合的な監督指針」の一部を改正し、同日から適用しました。改正後の指針は、ログイン・出金・出金先口座の変更など重要な操作時に、フィッシングに耐性のある多要素認証を実装し必須化することを求めています。その例として、パスキーによる認証と、PKI（公開鍵基盤）をベースとした認証が挙げられています。
これは金融商品取引業者等（証券会社など）を対象とした指針であり、全業種への一般的な義務ではありませんが、フィッシング耐性認証を求める方向性はNISTと一致しています。
出典・参考資料（2件）
一括ダウンロードする
自社の認証強化への落とし込み
ここからは、確認した要件を自社の認証にどう反映するかを整理します。やるべきことは、大きく「パスワードポリシーの更新」と「AAL2・AAL3に引き上げるためのフィッシング耐性認証の導入」の2つに分かれます。
パスワードポリシー更新と認証強化の進め方
パスワードポリシーは、本記事のパスワード要件の表を基準に見直せます。最低長を単要素15文字・多要素併用8文字に設定し、一律の定期変更を廃止し、流出・頻出パスワードのブロックリスト照合を導入する、という3点が核になります。これらはNISTが規定として定める内容です。一方で、「どの業務にどのAALを適用するか」は規定そのものではなく、自社のリスクに応じた当てはめの判断になります。
一般の業務はAAL2相当、特権的な操作や高リスクの操作はAAL3相当を検討する、といった整理は実務上の目安であり、NISTの要件として固定されているわけではありません。
AAL2・AAL3に引き上げる鍵になるのが、フィッシング耐性認証の導入です。前述のとおり、フィッシング耐性を備えるのはFIDO2/WebAuthn（パスキー）やクライアント証明書で、手段は「同期型パスキーに対応したID基盤」と「デバイス束縛型のFIDO物理キー」の2系統に大きく分かれます。
同期型パスキーはAAL2まで、デバイス束縛型の物理キーはAAL3まで対応できるため、求めるレベルに応じて使い分けます。次に、この2系統に対応するサービスを紹介します。各系統を横断して多要素認証の製品を広く比較したい場合は、カテゴリ全体の比較記事もあわせてご覧ください。
AAL2・AAL3に対応するフィッシング耐性認証サービス
多要素認証（MFA）システムおすすめ17選を徹底比較｜認証方式・料金・タイプ別の選び方
ID とパスワードだけのログインは、もはや「鍵をかけていない」のと同じ状態に近づいています。攻撃者は流出したパスワードのリストを使い回し、本物そっくりの偽サイトで認証情報を抜き取り、正規利用者になりすまして社内システムやクラウドサービスへ侵…
以下は、ここで紹介するフィッシング耐性認証サービスの比較表です。
| サービス名 | CloudGate UNO | YubiKey as a Service |
|---|---|---|
| 系統（提供形態） | 同期型パスキーに対応した クラウドID基盤（IDaaS） | デバイス束縛型の物理セキュリティキー （サブスクリプション提供） |
| 対応認証規格 | FIDO2/WebAuthn（パスキー） 生体認証（Windows Hello・Touch ID/Face ID） OTP・認証アプリ | FIDO2/WebAuthn・FIDO U2F スマートカード/PIV OpenPGP・OATH（TOTP） |
| フィッシング耐性認証 | ● | ● |
| 対応AAL（目安） | AAL2相当 （同期型パスキー） | AAL3まで対応 （デバイス束縛型） |
| パスワードレス認証 | ●全プラン・全ユーザー無制限 | ●物理キーで実現 |
| SSO・アクセス制限 | ●SSO・ID管理・アクセス制限を標準提供 | △CloudGate UNO等のID基盤と組み合わせ |
| スマホなしでの利用 | △物理キー・PCの生体認証なら可 | ● |
| 初期費用 | 要問い合わせ | 要問い合わせ |
| 月額費用 | 税抜400円〜/ユーザー （税込440円・Standard Plus） | 要問い合わせ （200ユーザー〜、3年/5年契約） |
| 無料トライアル | 30日間 | 公式記載なし （導入前に実機検証） |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNO は、株式会社インターナショナルシステムリサーチが自社開発するクラウド型のID基盤（IDaaS）です。シングルサインオン（SSO）を軸に、多要素認証、パスキー（FIDO2）によるパスワードレス認証、アクセス制限、ID管理を1つのプラットフォームで提供します。
ID基盤自体は同期型パスキーによるパスワードレス認証でAAL2相当を満たし、FIDO2の物理セキュリティキーを組み合わせれば、束縛型キー側がAAL3の非エクスポート秘密鍵の要件を担います。認証保証レベルに応じて段階的に強化できるため、認証ポリシーの更新に取り入れやすい構成です。
パスキーによるパスワードレス認証はすべてのプランで無制限に利用でき、同社は2019年からFIDO2準拠のパスワードレス認証を提供してきました。認証方式は、FIDO2対応の物理キーのほか、Windows HelloやTouch ID/Face IDといった端末の生体認証、自社の認証アプリにも対応します。
アクセス制限は、端末・場所・時間の3軸で細かく設定でき、特定の拠点や時間帯に限ってアクセスを許可するといった運用が可能です。料金は、SSO・多要素認証・ID管理を含むStandard Plusが1ユーザー月額400円（税込440円）からで、30日間の無料体験が用意されています。
本記事で確認したとおり、SMS認証やワンタイムパスワードはNISTの定義ではフィッシング耐性認証に含まれません。同社はこの点について、現場での実感を次のように述べています。
当社が採用しているパスキーのパスワードレス認証は、フィッシング攻撃に対して非常に強い耐性を持ちます。SMS認証やワンタイムパスワードなどの一般的な多要素認証を突破する攻撃手法が顕在化する中、より安全な認証環境を提供します。
2. YubiKey as a Service（株式会社インターナショナルシステムリサーチ）
デバイス束縛型でAAL3まで対応したい場合の選択肢が、YubiKey as a Service です。これは、Yubico社の物理セキュリティキー「YubiKey」を法人向けにサブスクリプション型で提供するサービスで、株式会社インターナショナルシステムリサーチがYubico社とのパートナー契約に基づき日本で提供しています。
秘密鍵をデバイス内に保持するハードウェアトークン型の認証で、FIDO2/WebAuthnによるフィッシング耐性のある認証を実現します。
対応規格は、FIDO2/WebAuthnに加え、FIDO U2F、スマートカード/PIV、OATHのワンタイムパスワードなどにわたります。買い切りではなく運用費で導入でき、契約期間中のキー種類の変更、毎年契約数の25%分の予備キー提供、導入・運用支援が付帯します。
全社員へのスマートフォン支給が難しい環境や、派遣社員・外部委託先の認証、建設現場のように端末の持ち込みが制限される現場でも、物理キーで強固な多要素認証を展開できます。契約は最低200ユーザーから、3年または5年で、料金は個別見積もりです。
物理キーによる認証強化の意義を、提供元はパスワードレスへの移行という観点から次のように語っています。
フィッシングやランサムウェアの被害が増えている中で、すべてが認証で解決するわけではありませんが、認証というのは家でいう玄関のようなところです。ここのセキュリティをがっちり強化することで、被害を大幅に低減できると考えています。今はパスワードが漏れているのが当たり前という世界ですので、パスワードを使わないパスワードレス認証への移行は極めて有効な対策となります。
ここで紹介したパスキー対応ID基盤・FIDO2物理キーのほかに、本記事でフィッシング耐性ありに分類したクライアント証明書（PKI）も、AAL2・AAL3へ引き上げる認証手段の選択肢です。すでに証明書基盤を運用している場合や、端末やサーバーの認証とあわせて整えたい場合は、クライアント証明書発行サービスの仕組み・料金も検討材料になります。
まとめ
NIST SP 800-63B-4 は、パスワードの要件を「長さ重視・定期変更は侵害時のみ・複雑性ルールは課さない・ブロックリスト照合」に整理し、認証保証レベル（AAL）ごとにフィッシング耐性やリプレイ耐性の必須・推奨を定めています。特にAAL2では、フィッシング耐性認証の選択肢を提供すること自体が必須である点が要注意です。
フィッシング耐性を備えるのはFIDO2/WebAuthn（パスキー）やクライアント証明書で、同期型パスキーはAAL2まで、デバイス束縛型の物理キーはAAL3まで対応します。
自社の認証を見直す際は、パスワードポリシーを要件に合わせて更新したうえで、AAL2・AAL3に引き上げるためのフィッシング耐性認証を検討するのが実務的な進め方です。パスキー対応のID基盤や物理セキュリティキーの導入を検討する場合は、資料を取り寄せて比較してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. NIST SP 800-63B-4とは何ですか？
A. NIST SP 800-63B-4は、米国国立標準技術研究所（NIST）が2025年7月に公開した、認証（Authentication and Authenticator Management）を定めるデジタルアイデンティティ・ガイドラインの最終版です。パスワードの要件、認証保証レベル（AAL1〜AAL3）、フィッシング耐性認証などを規定しています。
身元確認（IAL）は SP 800-63A-4、連携（フェデレーション）は SP 800-63C-4 が別の文書として扱います。
Q. NIST SP 800-63B-4 は旧版の SP 800-63B-3 とどう違いますか？
A. NIST SP 800-63B-4は、2020年の旧版（SP 800-63B-3）を置き換える最終版で、単要素パスワードの最低長の引き上げ、同期型パスキーのAAL2での承認、フィッシング耐性認証の定義の新設などが、認証に関わる主な変更点です。あわせて「記憶された秘密（memorized secrets）」の呼称が「パスワード（passwords）」に変わりました。
変更点の一覧は原文の付録E（Change Log）で公式に確認できます。
出典・参考資料（1件）
Q. NIST SP 800-63B-4 の SHALL（必須）と SHOULD（推奨）はどう違いますか？
A. SHALLは守らなければならない必須要件、SHOULDは特段の理由がない限り従うべき推奨要件を指します。あわせてSHALL NOTは禁止事項、MAYは任意を表します。本記事では各要件にこの区別を明示しており、たとえば単要素パスワード15文字以上はSHALL（必須）、最大64文字以上の許容はSHOULD（推奨）、文字種の混在を強制する複雑性ルールはSHALL NOT（禁止）です。
社内ポリシーに落とす際は、まずSHALLの項目を確実に満たすことが出発点になります。
Q. NIST SP 800-63B-4 ではパスワードは何文字必要ですか？
A. NIST SP 800-63B-4のパスワード最低長は、単要素認証として使う場合は15文字以上、多要素認証の一部として使う場合は8文字以上が必須（SHALL）です。最大長は64文字以上までを許容することが推奨（SHOULD）とされ、大文字・小文字・数字・記号の混在を求める複雑性ルールは課してはならない（SHALL NOT）とされています（§3.1.1.2）。
長さを確保したうえで複雑性ルールを外すのが、Rev.4の基本方針です。
出典・参考資料（1件）
Q. NIST SP 800-63B-4 ではパスワードの定期変更は本当に不要ですか？
A. NIST SP 800-63B-4は、一律の定期的なパスワード変更を要求してはならない（SHALL NOT）と定める一方、漏えいの証拠がある場合は変更を強制しなければならない（SHALL）としています。廃止されるのは「期限が来たら全員が変更する」という一律運用であって、侵害が確認された場合の強制変更は必須です。原文では両者が§3.1.1.2に1文で併記されています。
出典・参考資料（1件）
Q. NIST SP 800-63B-4 では、SMS認証や認証アプリ（TOTP）はフィッシング耐性認証に該当しますか？
A. SMS認証やワンタイムパスワード（認証アプリのTOTPを含む）、プッシュ通知による承認は、NIST SP 800-63B-4ではフィッシング耐性認証に該当しません。認証器の出力を手入力する方式は、その出力が認証中のセッションに結びつかないためです（§3.2.5）。フィッシング耐性を備えるのは、FIDO2/WebAuthn（パスキー）やクライアント証明書（PIV/CACなど）の暗号認証です。
出典・参考資料（1件）
Q. NIST SP 800-63B-4 の AAL2 でフィッシング耐性認証は必須ですか、推奨ですか？
A. NIST SP 800-63B-4のAAL2では、検証者がフィッシング耐性認証の選択肢を提供すること自体は必須（SHALL offer）、一般の利用側での利用の促しは推奨（SHOULD）、連邦機関での利用は必須（SHALL）という三層構造です。「AAL2はフィッシング耐性が推奨」とだけ理解すると、選択肢の提供自体が必須である点を取りこぼします（§2.2.2）。
Q. 同期型パスキーは NIST SP 800-63B-4 の AAL3 で使えますか？
A. 同期型パスキーはAAL3では使えず、使えるのはAAL2までです。複数の端末へ秘密鍵を同期できる方式は鍵のエクスポートを前提とするため、非エクスポートの秘密鍵を求めるAAL3の要件に違反します（SHALL NOT）。AAL3には、秘密鍵を端末外に出さないデバイス束縛型のFIDOセキュリティキーなどが必要です。
同期鍵の基盤へのアクセスは、AAL2相当の多要素認証で保護することが求められます（§2.3・付録B）。
多要素認証（MFA）システムの料金・資料を一括チェック
MCB FinTechカタログでは、パスキー対応のID基盤やFIDO2物理キーなど、フィッシング耐性認証に対応した多要素認証サービスの最新資料を無料で一括請求できます。対応する認証規格や料金体系を比べて、自社の認証強化に合うサービスを検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
