2025 年 10 月 23 日
NIST の最新ガイドラインに見る「認証とパスワード」の新常識
~フィッシング耐性のある多要素認証の導入を解説~
各組織のセキュリティ担当者やサービス利用者の中には、パスワードの運用・管理に嫌気がさしている方もいらっしゃるのではないでしょうか?
皆さんがこれまで「常識」と捉えていたパスワードの運用・管理は、NIST(National Institude of Standards and Technology:米国標準技術研究所)の最新ガイドラインである「NIST SP 800-63 Revision 4」によって大きく覆るかも知れません。
本記事では、NIST のデジタルアイデンティティガイドライン「SP 800-63B-4」に基づき、現代におけるパスワードの運用・管理および認証の考え方を最新のセキュリティ対策や国内の動きも交えて解説します。
文字+数字+記号の混在文字は廃止に、PW の「常識」が変わる新ルール
NIST が改定したガイドラインの中では、パスワードの「セキュリティ強度」を評価するうえで、これまで重要視されてきた多くの要素が以下の通り見直されています。
| # | パスワードの要件 | 従来の常識 | NIST 新ガイドライン(SP800-63B) |
|---|---|---|---|
| 1 | 長さ | 8~12 文字 | 単一要素認証:15 文字以上 多要素認証:8 文字以上 |
| 2 | 複雑性 | 大文字、小文字、数字、記号が必須 | 構成ルールは不要 |
| 3 | 変更頻度 | 30~90 日 | 侵害(漏洩)した場合のみ |
| 4 | 回復時 | セキュリティ質問やヒント | 回復コード/URL リンクなどの利用 |
| 5 | 利用可能な文字列 | - | ブロックリストの利用 |
① パスワード長の重要性
パスワードの長さはパスワードの強度を評価する最も重要な要素として NIST では位置づけており、単一要素認証として使用されるパスワードは最低 15 文字、多要素認証※(MFA:Multi-Factor Authentication)と併用する場合は最低 8 文字の長さが必要であるとしています。
- ※
- BLOG:多要素認証(MFA)とは?
また、長いパスワードを利用する場合、手動入力はエラーを起こしやすいため、パスワードを管理・検証するシステムまたはサービスなどにおいては、パスワード入力時のコピペ機能の使用を許容することおよび利用者が長いパスワードを作成することを奨励するため、最大パスワード長を少なくとも 64 文字まで許可することを推奨しています。
② 複雑性要件(混在文字)は廃止
数字、大文字、記号などの異なる文字タイプを組み合わせることを強制するような構成ルールの廃止が求められています。
その理由として、利用者は複雑性ルールが課されると、「password」から「Password1!」のように予測可能な変更を行う傾向があることが挙げられ、予測可能なパスワードは、攻撃者によって推測されやすくなってしまうためです。
③ 定期的なパスワード変更(リセット含む)は不要
定期的なパスワード変更要求は、利用者が以前のパスワードから予測しやすいわずかな変更(例:「Password1」から「Password2」など)を加える原因となり、かえってセキュリティを低下させるため廃止されました。パスワード変更を強制する必要があるのは、認証要素が侵害された(または漏洩した)場合に限ります。
④ パスワードの回復方法
パスワードを忘れてしまった場合、「ヒント」や、知識ベースのセキュリティ質問(例:「最初に飼ったペットの名前?」)を表示させるのは、昨今のデータ侵害の多い世界において不正に回答されやすいため、適切ではありません。
また、パスワードの回復は、電子メール、テキスト、音声、または郵便サービスを通じて送信される回復コードやリンクを通じて行われるべきと記しています。
⑤ ブロックリストの利用
パスワードを管理・検証するシステムまたはサービスなどにおいては、既知の一般的かつ予測可能なパスワードや、辞書に含まれている単語、侵害された実績のあるパスワードをブロックリストへ登録のうえ、利用者にそれらのパスワード登録を拒否するという仕組みが必要です。
NIST が推奨する新しいパスワード運用・管理の常識は、デジタル認証の標準を現代の脅威に対応させるための進化であると言えます。
これらのガイドラインは義務ではありませんが、昨今日本国内でも頻発している認証情報の窃取やブルートフォース攻撃など、中小企業でも無視することのできない攻撃に対抗するための、最も強力なベストプラクティスとして採用することが推奨されます。
NIST が定める認証保証レベルの基準を解説
認証とはサービスへアクセスしようとする利用者が、登録済みの利用者であることを照合するプロセスであり、このプロセスにおいて認証強度を定義しているのが認証保証レベル(AAL:Authenticator Assurance Level)です。
この AAL を NIST では、一定の条件に基づき以下 3 つのレベルに分類しています。
| 種別 | 多要素認証 | フィッシング耐性 | 公開鍵暗号方式 | 秘密鍵の EXP 不可 |
|---|---|---|---|---|
| AAL1 | ▲ | × | × | × |
| AAL2 | ● | 提供:● 利用:▲ |
× | × |
| AAL3 | ● | 提供:● 利用:● |
● | ● |
● : 必須、▲ : 推奨、× : 不要 ※代表的な条件を抜粋
AAL1
利用者アカウントに結び付けられた認証要素を管理しているという基本的な信頼を提供しており、単一要素認証が許容されます。
AAL2
利用者アカウントに結び付けられた、2 つ以上の異なる認証要素(多要素認証 /MFA)に基づき高い信頼を提供し、認証要素の内 1 つはフィッシング耐性のある認証方式※の提供が必須となります。
- ※
- サービス提供事業者のシステム等で " 提供 " できることは必須で、利用者による " 利用 " は推奨
AAL3
利用者アカウントに結び付けられた、2 つ以上の異なる認証要素(多要素認証 /MFA)に基づき高い信頼を提供し、認証方式の全てにおいてフィッシング耐性のある認証方式※を提供 / 利用かつ今回から新たにエクスポート不可な秘密鍵の使用が必須となります。
- ※
- サービス提供事業者のシステム等で " 提供 " かつに利用者の " 利用 " が必須
補足情報
公開鍵暗号方式:利用者が秘密鍵を所有し、秘密鍵の所有を暗号技術で証明することで本人確認を行います。
| 公開鍵暗号を用いた認証方式例 |
|---|
| FIDO2 |
| パスキー |
| クライアント証明書 |
フィッシング耐性:攻撃者に窃取されてしまう可能性があるため、多要素認証が設定されていたとしても、それを突破されてしまうリスクがあります。
| フィッシング耐性の低い認証方式例 |
|---|
| メール /SMS ワンタイムパスワード |
| Authenticator(認証アプリ) |
| プッシュ通知 |
| 絵の組み合わせ |
日本国内におけるフィッシング耐性のある認証方式採用の動き
フィッシング対策協議会が公表しているデータでは、年々フィッシング報告件数が増加しており、2025 年は 1 月~9 月の 9 ヶ月間にも関わらず、2024 年の年間報告件数を超え、200 万件に迫るような勢いとなっています。

フィッシング対策協議会の公開情報をもとに当社が作成
このような状況もあり、フィッシング耐性のある認証方式については、国内においても動きがあります。 これまで多くの金融商品取引業者では機会損失に繋がると考え、単一要素認証を許容していましたが、金融庁が 2025 年 10 月に改訂した「金融商品取引業者等向けの総合的な監督指針※」において、証券会社を含む金融商品取引業者に対し、フィッシング耐性のある多要素認証の提供と利用を義務付けました。
各金融商品取引業者では、従来の ID/ パスワードを用いた認証に加えて多要素認証としてパスキーの導入および計画を進めており、これは NIST の認証保証レベルに当てはめると以下の通り AAL2 を超えているものの AAL3 の要件は満たさないことになります。
| 多要素認証 | フィッシング耐性 | 公開鍵暗号方式 | 秘密鍵の EXP 不可 |
|---|---|---|---|
| ● | 提供:● 利用:● |
● | × |
● :NIST の認証保証レベルに金融商品取引業者の認証強化を当てはめた場合
今回のガイドライン改訂において、AAL3 は「エクスポート不可な秘密鍵の使用が必須」と新たに追加されましたが、多くの金融商品取引業者がフィッシング耐性のある多要素認証として採用を進めているパスキーは、秘密鍵をクラウドを介して複数端末で扱うことができてしまうため、金融庁の定める監督指針は満たすものの、NIST の AAL3 の当該項目の条件は満たしません。

パスキーについては、攻撃者が利用者のクラウドサービスアカウントに不正アクセスし、クラウド同期機能を介して利用者の秘密鍵が攻撃者の端末にコピーされてしまう「パスキーハイジャック」や、端末を物理的に入手し、本人の許可なく生体認証情報(指紋や顔など)を追加登録することで認証を不正に突破する「生体ハイジャック」といった攻撃手法が存在しており、これらは専門的な知識がなくとも容易に行えてしまう特徴があります。
認証保証レベルは、インシデント発生時の影響度や各種法令やガイドラインなどに則して決定していく必要がありますが、今回の金融庁の監督指針を一つの基準として考えると、個人情報を取り扱いかつ経済的損失が生じる場合、AAL2 を超える認証保証レベルを設定しておいた方が安心であると言えます。
秘密鍵をエクスポート不可とさせ AAL2を超える認証保証レベルを容易に実現可能とするクライアント証明書サービス
サイバートラストのクライアント証明書サービスである「サイバートラスト デバイス ID」は、NIST が定める AAL3 の要件の一部である「フィッシング耐性」、「公開鍵暗号方式」、「秘密鍵のエクスポート不可」を満たすことができるため、現在利用しているパスワードなどを用いた認証方式に追加することで容易に多要素認証かつAAL2 を超えた NIST が定める高い認証保証レベルを実現できます。

「サイバートラスト デバイス ID」は、端末固有の識別情報に基づいた端末特定および秘密鍵をエクスポートできない状態でクライアント証明書の配付を行い、クライアント証明書を持つ端末からのアクセスのみを許可することができるため、不正アクセス対策や認証強化のソリューションとして最適です。

「サイバートラスト デバイス ID」では、無償で 1 ヶ月間、10 台までの機器で評価いただけるトライアルキットをご提供しております。「使用感を実際に体験してみたい」、「既存の環境で運用できるか検証したい」などのご要望に、是非ともトライアルを通じてデバイス ID をお試しください。
本記事に関連するリンク
- 多要素認証にワンタイムパスワードの利用禁止?証券口座の乗っ取り被害多発で金融庁指針が改定へ
- Microsoft が多要素認証を回避するフィッシング攻撃 「Adversary-in-the-Middle(AiTM)」について発表
- Microsoft 365 のアカウントを狙う AiTM フィッシングキットがダークウェブで大人気。今からできる対策とは?
- Cisco VPN を標的にしたランサムウェア「Akira」について
- 【Microsoft Entra CBA】発行者とシリアル番号 / サブジェクトを用いてクライアント認証してみた
- 【AWS ALB× デバイス ID】デバイス ID 証明書でクライアント認証してみた










