社内のパスワードの規則（パスワードポリシー）を見直すとき、「最小で何文字にすべきか」「記号の混在を必須にすべきか」「定期的な変更を求めるべきか」で判断に迷うことは少なくありません。かつて一般的だった「複雑な文字列を定期的に変更させる」という考え方は、近年の公的な指針で大きく見直されています。
本記事では、NIST（米国立標準技術研究所）や総務省・IPA（情報処理推進機構）などが示すいまの推奨設定を、文字数・複雑さ・定期変更といった具体的な項目ごとに整理します。旧来のルールとの違いや、権威ごとの推奨値の差、そして Active Directory や Microsoft 365 など自社の環境への落とし込み方まで解説します。
自社のパスワードポリシーを最新の基準に合わせて見直すための、具体的な判断材料としてご活用ください。
目次
一括ダウンロードする
パスワードポリシーの推奨設定（旧ルールとの対比）
ここからは、いま推奨されるパスワードポリシーの設定値を、これまで一般的だった設定と対比して整理します。見直しの中心は「複雑さよりも長さ」「定期変更の廃止」です。以下の表で、項目ごとの推奨をまず確認してください。
| パスワードポリシーの新旧対比 | 最小文字数 | 最大文字数 | 文字種の複雑さ | 定期変更 | 漏えい・推測されやすいパスワード | 秘密の質問・パスワードのヒント | パスワードマネージャ・貼り付け |
|---|---|---|---|---|---|---|---|
| これまで一般的だった設定 | 8文字程度 | 短く制限することがある | 大文字・小文字・数字・記号の混在を必須 | 90日ごとなど定期的に変更を要求 | 特に制限しない | 本人確認や回復に利用 | 貼り付けを禁止することがある |
| 推奨される設定 | 15文字以上（多要素認証と併用する場合は8文字以上） | 64文字以上を許容する | 文字種の組み合わせは強制しない | 定期変更は求めない（漏えいの証跡があるときのみ変更） | 漏えい・辞書・推測されやすいものをブロックリストで拒否 | 秘密の質問・ヒントは使わない | パスワードマネージャと貼り付けを許可する |
※上記は NIST SP 800-63B-4（2025年8月改定）の要件を中心に整理したものです（本記事の各社情報は2026年11月時点）。各項目の具体値は後述の権威横断の比較表もあわせてご確認ください。
最小文字数は、パスワードだけで認証する場合は15文字以上、多要素認証と組み合わせる場合は8文字以上が目安です。NIST はこの要件を次のように定めています。
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｜National Institute of Standards and Technology
日本語にすると、パスワードだけで認証する場合は最小15文字以上を必須とし、多要素認証の一部として使う場合は8文字以上まで短くしてよい、という内容です。
「SHALL（しなければならない）」は必須要件、最大長を64文字以上許容する点は「SHOULD（すべき）」として示されています。長いパスワードやパスフレーズを使えるようにしつつ、文字種の混在を強制しないのが基本的な考え方です。日本の公的機関である総務省や IPA も、長さを重視し使い回しを避ける方向で同様の案内をしています。
出典・参考資料（3件）
複雑さの強制・定期変更がなぜ非推奨になったのか
ここでは、長く一般的だった「記号を必須にする」「定期的に変更させる」というルールが、なぜ見直されたのかを整理します。社内やセキュリティ会議で方針転換を説明する際の材料になります。
理由は、利用者に厳しいルールを課すほど、かえってパスワードの質が下がるという調査結果にあります。文字種の混在や頻繁な変更を強制すると、利用者は「Password1！」を「Password2！」に変えるような、推測しやすい規則的なパターンに流れがちです。Microsoft は自社のドキュメントでこの点を次のように説明しています。
調査によると、ユーザーに課すほぼすべてのルールによってパスワードの品質が低下します。 長さの要件、特殊文字の要件、パスワード変更の要件はすべて、パスワードを正規化することになるため、攻撃者はパスワードを簡単に推測したり、解読したりすることができるようになります。
出典：パスワード ポリシーの推奨事項 – Microsoft 365 admin｜Microsoft Learn
この考え方に沿って、NIST も文字種の混在を強制するルールを課してはならないとしています。原文でも、他の構成ルール（たとえば異なる文字種の混在を求めること）を課してはならない、という内容が明記されています。記号や数字を使うこと自体は妨げませんが、必須にはしないという整理です。
定期変更についても同様です。NIST は定期的な変更を利用者に要求してはならないとし、変更を強制するのは認証情報が漏えいした証跡がある場合に限るとしています。頻繁な変更が規則的なパスワードや使い回しを招き、安全性をむしろ下げるためです。
出典・参考資料（2件）
権威ごとの推奨値の違い（NIST・Microsoft・総務省・IPA・NISC）
推奨の出どころは一つではありません。米国の NIST、実装側の Microsoft、日本の公的機関である総務省・IPA・NISC（内閣サイバーセキュリティセンター）で、示している数値や粒度に違いがあります。以下の表で、どの機関が何を推奨しているかを整理します。
| 権威ごとの推奨値 | NIST SP 800-63B-4（米国） | Microsoft 365（実装側のガイダンス） | IPA（日本） | 総務省（日本） | NISC（日本） |
|---|---|---|---|---|---|
| 推奨する最小長 | 15文字以上（多要素認証併用時は8文字以上）／最大64文字以上 | 14文字以上を推奨（システム上の必須は8文字） | 15桁程度（英大文字・小文字・数字の組み合わせ） | 具体的な数値の明示なし（長さを重視） | 具体的な数値の明示なし（長いほど安全） |
| 複雑さの強制 | 求めない | 求めない方針 | 必須とはしない（記号の追加は任意） | 規則的・単純な文字列を避ける | 言及なし |
| 定期変更 | 求めない（漏えい時のみ変更） | 有効期限なし（期限切れさせない）を推奨 | 明示なし（サービスごとに別のパスワードを推奨） | 不要（漏えい時は速やかに変更） | 基本は不要（漏えい時は速やかに変更） |
※各機関の公式情報（2026年11月時点）をもとに整理しています。NISC・総務省は最小文字数を数値で明示していないため「数値の明示なし」としています。
最小文字数を数値で示しているのは NIST（15文字）、IPA（15桁程度）、Microsoft（14文字推奨）です。総務省と NISC は具体的な数値を定めず、「長さを重視する」「桁数が多いほど安全」という方向性で示しています。
数値の粒度は分かれますが、どの機関も「長さを重視し、複雑さの強制と定期変更をやめる」という方向で一致しています。自社では、扱う情報の重要度に応じて15文字前後を基準に置くと、各機関の推奨とおおむね整合します。
あわせて、管理者権限を持つアカウントは一般の利用者アカウントより長さや多要素認証を厳しくするなど、アカウントの種別で基準を使い分けると、実態に合ったポリシーになります。
出典・参考資料（5件）
「推奨」はどこまで守るべきか（義務かベストプラクティスか）
自社のポリシーを定めるうえで、これらの推奨がどこまで強制力を持つのかを押さえておくと、社内での合意形成がしやすくなります。結論から言えば、ここで紹介した NIST の基準は、自社が従うべきベストプラクティスであって、日本の民間企業に対する法的な義務ではありません。
NIST SP 800-63B-4 は、米国の連邦政府機関が自らの情報システムで満たすべき要件として書かれたガイドラインです。原文でも、適用対象をネットワーク越しの利用者認証とし、個人情報をオンラインで扱う場合に連邦機関が満たすべき水準を定める形で記述されています。日本の企業がこれに直接拘束されるわけではなく、信頼できる参照基準として自社のポリシーに取り入れる位置づけになります。
日本国内には、パスワードの文字数や変更頻度を一律に定めた法令は見当たりません。実務では、個人情報保護法が求める安全管理措置などの一般的な義務の枠組みのなかで、NIST や総務省・NISC といった公的な指針を参照しながら、各社が自社の基準を定めています。自社サービスの利用者に課すパスワード要件も、こうした指針を根拠に設計するのが一般的です。
出典・参考資料（2件）
複雑さ・定期変更を緩める代わりに必要な守り
複雑さの強制と定期変更をやめる以上、別の手立てでアカウントを守る必要があります。ここからは、推奨にあわせてパスワードポリシーを緩めるときに、代わりに備えておきたい守りを整理します。
多要素認証（MFA）の活用
最も効果が大きいのが多要素認証です。パスワード（知っているもの）に加えて、スマートフォンアプリのワンタイムパスワードや物理セキュリティキー（持っているもの）、生体認証（本人そのもの）を組み合わせます。
前述のとおり、多要素認証と併用する場合はパスワードの最小長を8文字まで緩められます。これは、パスワード単体に頼らない前提があるためです。総務省も、システムが対応していれば多要素認証を積極的に利用するよう案内しています。
どの多要素認証を選ぶかは、認証方式（ワンタイムパスワード・生体認証・物理キーなど）や料金、既存環境との連携のしやすさで変わります。以下の記事で、主要な多要素認証システムを認証方式・料金・タイプ別に比較しています。
多要素認証（MFA）システムおすすめ17選を徹底比較｜認証方式・料金・タイプ別の選び方
ID とパスワードだけのログインは、もはや「鍵をかけていない」のと同じ状態に近づいています。攻撃者は流出したパスワードのリストを使い回し、本物そっくりの偽サイトで認証情報を抜き取り、正規利用者になりすまして社内システムやクラウドサービスへ侵…
漏えい・推測されやすいパスワードのブロックリスト
設定しようとしたパスワードが、過去に漏えいしたものや辞書に載っている単語、推測されやすい文字列でないかを照合し、該当すれば拒否する仕組みです。NIST は、設定・変更時に、よく使われる・推測される・漏えい済みのパスワードを収めたブロックリストと照合することを求めています。
照合は文字列全体を対象とし、拒否した場合は利用者に別のパスワードを選ばせます。長さを確保しても「Password」のような定番の文字列では意味がないため、長さの要件と組み合わせて効果を発揮します。
秘密の質問を使わず、安全な回復手段を用意する
「母親の旧姓は？」のような秘密の質問（知識ベース認証）は、調べれば分かることが多く、安全な本人確認の手段になりません。NIST は、パスワードの作成時に秘密の質問や知識ベース認証を使わせてはならないとし、第三者が見られる形でパスワードのヒントを保存させてはならないとしています。パスワードを忘れた際の回復は、登録済みのメールや電話番号などへ一時的なコードを送る方式に置き換えます。
ハッシュとソルトによる安全な保管・ログイン試行の制限
自社でサービスを運用する場合は、パスワードの保管方法も推奨に含まれます。NIST は、オフライン攻撃に耐える形でパスワードを保存すること、適切なハッシュ方式でソルト（パスワードごとに加えるランダムな値、32ビット以上）を付けて保存することを求めています。
あわせて、総当たり攻撃を防ぐために、ログインの失敗回数に応じてレート制限（一定回数で一時的にロックする仕組み）を設けます。ロックアウトの具体的な回数は製品や運用で異なるため、自社の環境にあわせて決める形になります。
使い回しを防ぎ、パスワードマネージャを許可する
長く複雑でないパスワードでも、サービスごとに違うものを使えば、一つの漏えいが他のサービスへ波及するのを防げます。利用者が多数のパスワードを覚えるのは現実的でないため、パスワードマネージャの利用を前提にします。
NIST は、パスワードマネージャの利用と自動入力を許可すること、入力時の貼り付け機能を使えるようにすることを求めています。貼り付けを禁止すると、かえって短く覚えやすいパスワードを選ばせる結果になりかねません。
法人でパスワードマネージャを導入する場合は、個人向けと違って、部署やチームでの共有管理・アクセス権限・監査ログ・シングルサインオン連携といった業務向けの機能が選定のポイントになります。以下の記事で、法人向けの主要ツールを比較しています。
法人向けパスワード管理ツールおすすめ11選を徹底比較｜共有・監査ログ・SSO連携で選ぶ
業務で使うクラウドサービスやWebシステムが増えるほど、社内で扱うID・パスワードの数は膨れ上がります。Excelファイルや付箋、口頭やチャットでのパスワード共有が常態化し、「誰がどのアカウントを使っているのか把握しきれない」と感じている管…
出典・参考資料（2件）
一括ダウンロードする
環境別の設定の落とし込み（AD・Microsoft 365・自社サービス）
推奨値を決めたら、実際の設定画面に落とし込みます。ただし、環境によって設定できる範囲が異なり、推奨値をそのまま入力できないことがあります。ここでは代表的な3つの環境について、設定可能な範囲と注意点を整理します。
また、外部から提供される SaaS はサービス側のパスワードポリシーに従うため、自社で細かく変更できないことがあります。その場合は、シングルサインオンや多要素認証を組み合わせて守りを補います。
Active Directory（アカウントポリシー・きめ細かなパスワードポリシー）
オンプレミスの Active Directory では、既定ドメインポリシー（グループポリシー）の「パスワードの長さの最小値」で最小文字数を設定できます。注意したいのは、この項目で設定できるのは0〜14文字で、既定値は7文字という点です。
15文字以上を一律の最小長として強制することは、この項目単独ではできません。現実的には、設定できる上限の14文字を最小長にしたうえで、長いパスフレーズの利用を促し、多要素認証を併用して強度を補うのが無理のない進め方です。
ユーザーやグループごとに異なる基準を適用したい場合は、「きめ細かなパスワードポリシー（Fine-Grained Password Policy）」を使います。特定のユーザーやグループに別の長さ・ロックアウトを割り当てられ、特権アカウントだけ厳しくするといった運用に使えます（設定は Active Directory 管理センターや PowerShell から行います）。
最小長として何文字まで指定できるかは環境により異なるため、15文字以上を要件にする場合は設定可能な上限を確認したうえで、不足分はパスフレーズと多要素認証で補います。文字種の複雑さは別項目でオン・オフを切り替えます。
出典・参考資料（2件）
Microsoft 365・Microsoft Entra ID
Microsoft 365 のクラウド専用アカウントでは、Microsoft Entra ID のパスワードポリシーが適用されます。パスワードは8〜256文字で、4種類の文字（小文字・大文字・数字・記号）のうち3種類が必要と定められています。
この長さと複雑さの要件は固定で、管理者が変更できません。つまり、NIST が示す「複雑さを強制しない」をクラウド専用アカウントにそのまま適用することはできない点に注意が必要です。
管理者が構成できるのは、パスワードの有効期限（既定は有効期限なし。2021年より前に作成されたテナントは既定90日）、推測されやすいパスワードを拒否する禁止パスワードリスト、ロックアウトのしきい値（既定は10回失敗で1分間ロック）などです。
Microsoft 自身は最小14文字・有効期限なしを推奨しています。推奨に寄せるには、有効期限をオフにし、禁止パスワードリスト（Entra パスワード保護）とロックアウトで補うのが現実的です。
出典・参考資料（2件）
自社サービスの登録バリデーション
自社で提供するサービスの登録画面では、設定値を自由に決められます。推奨にあわせるなら、最小15文字（多要素認証を併用するなら8文字）を下限とし、文字種の混在は必須にせず、最大長は64文字以上まで許容する形が望ましいといえます。
登録時には漏えい済みパスワードのブロックリストと照合し、貼り付けやパスワードマネージャの自動入力を妨げない実装が望まれます。保存はハッシュとソルトで行い、ログイン試行にはレート制限をかけるとよいでしょう。前の節で挙げた「代わりの守り」を、そのまま実装に反映する形です。
パスワードレス認証・多要素認証を導入できるサービス
ここまで見てきたとおり、これからのパスワードポリシーは「長さを確保し、複雑さの強制と定期変更をやめ、多要素認証やパスワードレス認証で守りを足す」方向に向かっています。こうした守りを自社で実装するには、複数のクラウドサービスのログインをまとめ、パスワードに依存しない認証を導入できるサービスが選択肢になります。
以下は、その代表的なサービスの一例です。認証基盤全体を幅広く比較検討したい場合は、後述の比較記事もあわせてご覧ください。
| パスワードレス認証・多要素認証に対応したサービスの比較 | CloudGate UNO | YubiKey as a Service |
|---|---|---|
| 提供形態 | クラウド型のID基盤（IDaaS） | 物理セキュリティキーのサブスクリプション（法人向け） |
| 主な認証方式 | FIDO2/パスキー、生体認証（Windows Hello・Touch ID/Face ID）、OTP、CloudGate Authenticator | FIDO2/WebAuthn、FIDO U2F、PIV、OpenPGP、OATH（TOTP） |
| パスワードレス認証 | ●全プラン・全ユーザーで無制限 | ●物理セキュリティキーで実現 |
| 多要素認証（MFA） | ● | ● |
| シングルサインオン（SSO） | ● | ×CloudGate UNOと組み合わせ |
| 初期費用 | 要問い合わせ（全プラン別途） | 要問い合わせ |
| 月額費用 | 400円〜/ユーザー（税抜） | 要問い合わせ（200ユーザー〜、3年または5年契約） |
| 無料トライアル | 30日間 | 要問い合わせ（導入前に実機検証） |
| 向いているケース | 複数のSaaSのログインとパスワード管理を一本化したい企業 | スマートフォンを支給しにくい現場や派遣・外部委託先が多い環境 |
| 詳細情報 | 公式資料を見る | 公式資料を見る |
※料金・契約条件は各社の公式情報（2026年11月時点）をもとにしています。最新の内容は各社の公式サイト・資料でご確認ください。
こうしたパスワードに頼らない認証は、シングルサインオンや多要素認証をまとめて提供する ID 基盤（IDaaS）として広がっています。以下の記事では IDaaS の仕組みや選び方、主要サービスの比較を詳しく解説しています。認証基盤全体を比較検討したい方は、あわせてご覧ください。
1. CloudGate UNO（株式会社インターナショナルシステムリサーチ）
CloudGate UNO は、株式会社インターナショナルシステムリサーチが自社開発するクラウド型の ID 基盤（IDaaS）です。シングルサインオン（一度の認証で複数のクラウドサービスへアクセスする仕組み）を中心に、多要素認証、パスキー（FIDO2）によるパスワードレス認証、アクセス制限、ID 管理をまとめて提供します。
同社は2014年に FIDO アライアンスへ参画し、2019年5月にパスキー（FIDO2）準拠のパスワードレス認証の提供を始めています。パスキーによるパスワードレス認証はフィッシング攻撃への耐性が高く、SMS やワンタイムパスワードを突破する攻撃が広がるなかでも破られにくい認証方式です。
このパスキー認証は全プラン・全ユーザーで無制限に利用できます。アクセス制限では、端末・場所・時間の3つの軸でログインを細かく制御でき、情報漏えい対策や労務管理の観点でも使われています。
利用料金は1ユーザーあたり月額400円（税抜）からで、プランは Standard Plus・Enterprise Plus・Smart Pack の3種類が用意されています。初期費用は別途かかり、30日間の無料体験が利用できます（2026年11月時点、公式料金ページ）。オンプレミスからクラウドへ移行し、複数の SaaS を使い始めた企業で、ログインとパスワード管理を一本化したい場合に向いています。
パスワードレス認証に切り替えると、情報システム部門のパスワード関連の運用はどう変わるのか。同サービスを提供する株式会社インターナショナルシステムリサーチは、独自インタビューで導入企業の事例を次のように挙げています。
導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。
2. YubiKey as a Service（株式会社インターナショナルシステムリサーチ）
Yubico 社の物理セキュリティキー「YubiKey」を、法人向けにサブスクリプション型で提供するのが YubiKey as a Service です。株式会社インターナショナルシステムリサーチが Yubico 社とのパートナー契約に基づいて日本で提供しています。
キー本体を買い切るのではなく運用費として導入でき、契約期間中のキー種類の変更、紛失・増員に備える予備キー、導入運用の支援が付帯します。
YubiKey は、パスワードレス認証の中核となる FIDO2／WebAuthn に対応し、FIDO U2F、スマートカード（PIV）、ワンタイムパスワード（OATH）など複数の認証規格に対応します。デバイス内に秘密鍵を保持するため、フィッシングに強い認証を実現できます。
スマートフォンを支給しにくい現場や、派遣社員・外部委託先が多い環境など、アプリによる多要素認証が使いにくいケースで選ばれています。契約は最低200ユーザー・3年または5年からで、料金は構成に応じた個別見積もりです。
前述の CloudGate UNO と同じ会社が提供しており、CloudGate UNO のシングルサインオン・パスワードレス認証と組み合わせて、物理キーによる強固な認証基盤を構築する使い方が想定されています。
なぜパスワードポリシーの見直しにとどまらず、パスワードレス認証への移行が重要になるのか。同社は独自インタビューで、認証そのものの位置づけを次のように説明しています。
フィッシングやランサムウェアの被害が増えている中で、すべてが認証で解決するわけではありませんが、認証というのは家でいう玄関のようなところです。ここのセキュリティをがっちり強化することで、被害を大幅に低減できると考えています。今はパスワードが漏れているのが当たり前という世界ですので、パスワードを使わないパスワードレス認証への移行は極めて有効な対策となります。
まとめ
いまのパスワードポリシーの推奨は、「複雑さより長さ」「定期変更の廃止」が核になっています。具体的には、最小15文字（多要素認証併用なら8文字）・最大64文字以上を許容し、文字種の混在は強制せず、定期変更も漏えい時に限ります。その代わりに、多要素認証・漏えいパスワードのブロックリスト・安全な保管といった守りを備えます。
自社の環境では、Active Directory は既定ポリシーの最小長が14文字までであること、Microsoft 365 のクラウド専用アカウントは長さと複雑さが固定であることなど、設定できる範囲に制約があります。
推奨値と環境の制約を突き合わせ、足りない部分は多要素認証やパスワードレス認証で補うのが現実的な進め方です。パスワードに頼りきらない認証基盤を検討する際は、関連サービスの資料をまとめて比較してみてください。
一括ダウンロードする
よくある質問（FAQ）
Q. パスワードポリシーとは何ですか？
A. パスワードポリシーとは、組織が定めるパスワードの取り扱いルール（最小文字数・複雑さ・変更頻度・使い回しの可否など）をまとめた規則です。Active Directory や Microsoft 365、自社サービスの登録画面などに設定します。近年は NIST や総務省などの指針を参照し、長さを重視して複雑さの強制と定期変更をやめる方向で見直すのが一般的です。
Q. パスワードポリシーで推奨される文字数は結局何文字ですか？
A. 推奨される最小文字数は、パスワードだけで認証する場合は15文字以上、多要素認証と併用する場合は8文字以上です（NIST SP 800-63B-4）。最大長は64文字以上まで許容するのが望ましいとされています。IPA は15桁程度、Microsoft は14文字以上を推奨しており、自社では15文字前後を基準に置けば各機関の推奨とおおむね整合します。
Q. 多要素認証（MFA）を導入していれば、パスワードは8文字でも問題ありませんか？
A. 多要素認証を併用している場合に限り、パスワードの最小長を8文字まで緩めても差し支えありません。パスワード単体に頼らず、スマートフォンアプリのワンタイムパスワードや物理セキュリティキーなど別の要素でも本人確認するためです。逆に、パスワードだけで認証する画面では15文字以上を確保してください。8文字でよいのは、あくまで多要素認証が前提である点に注意が必要です。
Q. パスワードの定期変更は本当にやめてよいのですか？
A. はい。NIST は定期的なパスワード変更を要求してはならないとし、変更を求めるのは漏えいの証跡があるときに限るとしています。頻繁な変更を強制すると、利用者が規則的で推測しやすいパスワードに流れ、かえって安全性が下がるためです。総務省・NISC も定期変更は不要としています。ただし、漏えいが判明した場合は速やかに変更します。
Q. パスワードポリシーで記号や数字の混在（複雑さ）はもう必須にしなくてよいのですか？
A. はい。大文字・小文字・数字・記号の混在を必須とする複雑さの強制は、現在の推奨では不要とされています。複雑さを強制すると「Password!」のようにパターン化した文字列を招き、かえって推測されやすくなるためです。記号や数字を使うこと自体は妨げませんが、必須にはせず、長さ（15文字以上）の確保と、漏えい・推測されやすいパスワードのブロックリスト拒否で補う方が効果的です。
Q. Active Directory で15文字以上のパスワードを強制できますか？
A. 標準のドメインポリシーで「パスワードの長さの最小値」に指定できるのは最大14文字までで、15文字以上を一律に強制することはできません（既定値は7文字）。
15文字相当の強度を満たすには、多要素認証を併用して8文字以上を下限にする、長いパスフレーズの利用を促す、といった運用で補います。ユーザーやグループごとに基準を変えたい場合は、きめ細かなパスワードポリシー（Fine-Grained Password Policy）を使います。
Q. Microsoft 365 のクラウドアカウントで複雑さの強制をオフにできますか？
A. できません。Microsoft 365（Microsoft Entra ID）のクラウド専用アカウントは、8〜256文字・4種類中3種類の文字を必須とする要件が固定されており、管理者が複雑さの強制をオフにできません。
そのため、NIST の「複雑さを強制しない」をそのまま適用することはできません。管理者が構成できるのは、有効期限（既定は期限なし）・禁止パスワードリスト・ロックアウトのしきい値などに限られます。
Q. パスワードポリシーを最新の推奨に見直せば、それだけで安全といえますか？
A. いいえ。パスワードポリシーの見直しは土台にすぎず、多要素認証やパスキー（パスワードレス認証）を組み合わせることが欠かせません。現在の推奨は、複雑さの強制や定期変更を緩める代わりに、別の要素でアカウントを守ることを前提としています。シングルサインオンと多要素認証をまとめた IDaaS や物理セキュリティキーを使えば、パスワードだけに依存しない認証基盤を構築できます。
ID・パスワード管理サービスの料金・資料を一括チェック
MCB FinTechカタログでは、シングルサインオン・多要素認証・パスワードレス認証に対応したサービスの最新資料を無料で一括請求できます。認証方式や料金、対応環境を比べて、自社のパスワードポリシー見直しに合う選択肢を探せます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
