SCS評価制度の多要素認証要件をMicrosoft 365で満たす設定手順｜常時MFA・パスワード8文字・端末ロックの対応方法

• SCS評価制度の要求事項を読んだら『常に多要素認証を使用すること』とあった。うちは一部のユーザーにしかMFAを設定していない
• SMS認証でも大丈夫？ 認証アプリじゃないとダメ？ パスワードは何文字必要？
• Microsoft 365でどこをどう設定すれば、★3の認証要件を満たしたと言えるのか分からない

SCS評価制度★3の評価基準81件のうち、ID・認証・アクセス制御に関するものは33件あり、最も件数が多い分野です。

なかでも多要素認証（MFA）は「重要な機密情報を扱うクラウドサービスでは常に使用する」と明確に定められており、Microsoft 365を業務の中心に置く企業にとっては最初に確認すべき要件になります。

この記事では、★3の認証関連の評価基準を原文どおりに整理したうえで、Microsoft 365（Microsoft Entra ID・Intune）でそれぞれを満たすための設定手順と、評価に備えて残しておく証跡をまとめました。

読み終える頃には、自社のMicrosoft 365環境で★3の認証要件をどこまで満たしているか、何を追加設定すべきかが判断できるようになります。

SCS評価制度★3では、重要な機密情報を取り扱うクラウドサービスにアクセスするすべてのユーザーと管理者に対して、常に多要素認証を使用することが求められます。

あわせて、認証要素の組み合わせ、パスワードの長さ、端末のロック条件についても具体的な数値が定められています。

多要素認証（MFA）とは、パスワードのような「知識情報」に加えて、スマートフォンやセキュリティキーのような「所有情報」、指紋や顔のような「生体情報」など、異なる種類の要素を2つ以上組み合わせて本人確認を行う認証方式のことです。

IPAが公開している★3の評価基準のうち、認証に関わる主な項目を整理します。

評価基準No.	求められる内容	数値・条件
4-1-3-1	すべてのユーザーID・管理者IDをIDごとの認証情報で認証する	共有IDでの認証は不可
4-1-3-2	重要な機密情報を扱うクラウドサービスへのアクセスに常にMFAを使用する	ユーザー・管理者とも対象
4-1-3-3	認証要素を2種類以上組み合わせる	知識・所有・生体・その他から2種類以上
4-1-3-4	MFAの知識情報として使うパスワードの長さ	8文字以上
4-1-4-1	PCログオン・スマートデバイスのロック解除の試行制限	10回以上失敗でロック、または試行間隔の延長
4-1-4-2	PCログオン・スマートデバイスのロック解除に使うパスワードまたはPIN	6文字以上
4-1-5-2	推測されやすい単語のパスワード設定を禁止するルール	社内ルールとして策定
4-1-5-3	パスワード認証の保護対策	MFAまたは10回失敗でロック＋8文字以上。どちらも不可なら英大小文字・数字を含む10文字以上

★3のMFA要件（4-1-3-2）の対象は、重要な機密情報を取り扱うクラウドサービスです。

社内のすべてのシステムにMFAを入れることまでは求められていません。

ただし、Microsoft 365は法人メール・ファイル共有・チャットを担うため、ほとんどの企業で「重要な機密情報を扱うクラウドサービス」に該当します。

また、対象はユーザーだけでなく管理者も含まれ、「常に」使用することが条件なので、社内ネットワークからのアクセスだけMFAを免除する運用は要件を満たしません。

なお★4では、クラウドサービスに加えてインターネット経由で社内システムにアクセスする場合などにも対象が広がります（4-1-3-5）。

本記事は★3の範囲に絞って解説します。

評価基準4-1-3-3は、認証要素を「知識情報」「所有情報」「生体情報」「その他の情報」の4分類に分け、このうち2種類以上を組み合わせることを求めています。

分類	例（評価基準の記載）	Microsoft 365での該当例
知識情報	ID・パスワード	Entra IDのパスワード、Windows Hello のPIN
所有情報	ワンタイムパスワード、証明書	Microsoft Authenticator、FIDO2セキュリティキー、パスキー
生体情報	指紋、顔、虹彩、静脈	Windows Hello の顔・指紋認証
その他の情報	IPアドレス	条件付きアクセスのネームドロケーション

評価基準の注記では、メールアドレスや電話番号にワンタイムパスワードを送信する方式や、スマートフォンへの認証要求を利用する方式も「所有情報」に含まれるとされています。

つまり★3の基準上はSMS認証も認証要素として認められます。

ただし、Microsoftは2027年2月にMicrosoft 365のSMS認証を廃止する予定です。

いまSMSでMFAを運用している企業は、★3対応と同時にAuthenticatorアプリやパスキーへ移行しておく必要があります。

廃止の内容と移行手順はMicrosoft 365のSMS認証廃止と代替手段の解説記事にまとめています。

Microsoft 365のSMS認証が使えなくなる？2027年2月廃止の発表内容と代替手段・移行手順を解説

Microsoftから、多くの企業に関わる重大な発表がありました。 Microsoft Entra ID（Microsoft 365のID基盤）が提供してい...

設定に入る前に、Microsoft Entra管理センターで「誰がMFAを登録済みか」「MFAは強制されているか」を確認します。

★3は書類確認による評価のため、この確認結果がそのまま現状把握の証跡になります。

①Microsoft Entra管理センターにサインインし、「認証方法」→「ユーザー登録の詳細」を開く

②ユーザーごとの「多要素認証に対応」「登録された方法」の列を確認し、未登録ユーザーを洗い出す（一覧はCSVでダウンロード可能）

③「概要」→「プロパティ」で「セキュリティの既定値群」が有効かどうかを確認する
※条件つきアクセスを使用している場合は、セキュリティの規定値群を有効化することはできません。

④「条件付きアクセス」→「ポリシー」でMFAを要求するポリシーが存在するか、有効になっているかを確認する
※Entra ID Premium P1 以上のライセンスがない場合、条件つきアクセスを使用することはできません。
※ポリシー名は任意で設定できるため、環境によって異なります。

WITHWITの支援現場では、「MFAは導入済み」と認識されていた企業でも、確認すると管理者だけが登録済みで一般ユーザーは任意登録のままだったケースが少なくありません。

★3は「常に使用すること」を求めるため、登録率だけでなく「強制されているか」を必ず確認してください。

MFAを強制する前に、ユーザーが使える認証方法を「Microsoft Authenticator」「パスキー（FIDO2）」「Windows Hello for Business」に揃え、SMSと音声通話は無効化します。

この順番で進めると、強制後に「登録できる方法がない」という問い合わせを防げます。

①Microsoft Entra管理センターで「認証方法」→「ポリシー」を開く

②「Microsoft Authenticator」を有効にし、対象を「すべてのユーザー」、認証モードは「すべて」または「プッシュ」にする。

③構成タブを開いて、「プッシュ通知に番号の一致が必要」が既定で有効になっていることを確認する。

④「パスキー（FIDO2）」を有効にし、対象を「すべてのユーザー」にする。

⑤セキュリティキーを使う場合は、構成タブを開き「セルフサービス設定を許可」をオンにする

⑥「SMS」と「音声通話」は対象を絞るか無効にする。すでに利用中のユーザーがいる場合は、Authenticatorへの移行期間を設けてから無効化する

⑦「一時アクセスパス」を有効にしておくと、スマートフォンを紛失したユーザーや新入社員の初回登録に使える

Microsoft Authenticatorとは
スマートフォンにインストールして使うMicrosoftの認証アプリのことで、サインイン時のプッシュ通知に表示された番号を入力する「番号の一致」方式が既定になっています。

パスキー（FIDO2）とは
フィッシングに強い公開鍵暗号ベースの認証方式で、セキュリティキーやスマートフォンに保存して使います。

セキュリティキーの登録手順はFIDO2セキュリティキーをパスキーとして登録する手順の記事で画面付きで解説しています。

FIDO2セキュリティキーをMicrosoft 365にパスキーとして登録する手順【画面付き】｜FIDO2とは・パスキーとの違いも解説

SMS認証の廃止が発表されて以降、「フィッシング耐性のある認証方法」としてFIDO2セキュリティキーに注目が集まっています。 しかし、いざ手元に届いたキーを...

MFAの強制には、全プランで使える「セキュリティの既定値群」と、Business Premium以上で使える「条件付きアクセス」の2つの方法があります。

どちらも★3の「常にMFAを使用する」要件を満たせますが、例外設定や管理者向けの強化ができる条件付きアクセスが推奨です。

項目	セキュリティの既定値群	条件付きアクセス
利用できるプラン	全プラン（無料）	Business Premium・E3・E5（Entra ID P1）
MFAの対象	全ユーザー・全管理者（例外なし）	ポリシーで自由に指定
緊急用アカウントの除外	不可	可能
管理者への強い認証の要求	不可	認証強度で「フィッシング耐性MFA」を指定可能
レガシー認証のブロック	自動	ポリシーで設定

セキュリティの既定値群とは、Microsoftが推奨する基本的な保護をワンクリックで有効にできる設定のことで、全ユーザーにMFA登録を必須にし、レガシー認証をブロックします。

①Microsoft Entra管理センターで「概要」→「プロパティ」→「セキュリティの既定値群の管理」をクリックする

②「有効」にして保存する

セキュリティの既定値群と条件付きアクセスは併用できず、条件付きアクセスを使う場合は既定値群を無効にする必要があります。

例外を設けたい場合や、管理者だけに強い認証を求めたい場合はBusiness Premiumへの移行を検討してください。

条件付きアクセスとは、ユーザー・場所・デバイスなどの条件に応じてサインイン時の要求を制御するEntra ID P1の機能のことです。

★3対応では、次の3つのポリシーを作るのが基本構成です。

1. すべてのユーザーにMFAを要求する:
   対象「すべてのユーザー」、クラウドアプリ「すべてのリソース」、許可の制御「多要素認証を要求する」。緊急用アカウントは除外する
2. 管理者にフィッシング耐性MFAを要求する:
   対象「管理者ロール（グローバル管理者・Exchange管理者など）」、許可の制御「認証強度を要求する」→「フィッシング耐性MFA」。パスキーまたはWindows Hello for Businessが必要になる
3. レガシー認証をブロックする:
   条件「クライアントアプリ」で「Exchange ActiveSync クライアント」と「その他のクライアント」を選び、許可の制御「アクセスのブロック」

ポリシーは「レポート専用」モードでまず作成し、サインインログで影響を確認してから「オン」に切り替えます。

緊急用（break-glass）アカウントは、MFAポリシーから除外したうえで、長いパスワードを施錠保管し、サインインがあったらアラートを出す運用にします。

この除外の根拠と管理手順は文書化しておくと、★3の評価時に説明しやすくなります。

Microsoftは制度とは別に、管理ポータルへのサインインにMFAを必須化しています。

2024年10月以降、Azureポータル・Microsoft Entra管理センター・Microsoft Intune管理センターへのサインインでMFAが順次必須になり、2025年2月以降はMicrosoft 365管理センターにも拡大されました。

管理者アカウントのMFAは、★3の要件（4-1-3-2）とMicrosoftの必須化の両方で求められると考えてください。

Entra IDのクラウドアカウントは既定でパスワードが8文字以上（最大256文字）、スマートロックアウトは10回の失敗でロックされるため、★3の4-1-3-4と4-1-5-3の数値要件は既定のままで満たせます。

追加で設定するのは、推測されやすい単語の禁止と社内ルールの文書化です。

1. パスワードの長さ（4-1-3-4）:
   Entra IDの既定ポリシーが8文字以上なので、クラウドのみの構成では追加設定は不要。オンプレミスのActive Directoryと同期している場合は、AD側のグループポリシーで最小8文字以上を設定する
2. 推測されやすい単語の禁止（4-1-5-2）:
   Entra管理センターの「保護」→「認証方法」→「パスワード保護」で、Microsoftのグローバル禁止パスワードリストが全プランで自動適用される。Business Premium以上では「カスタム禁止パスワードリスト」に社名・製品名・所在地などを追加できる
3. スマートロックアウト（4-1-5-3）:
   同じ「パスワード保護」画面で「ロックアウトのしきい値」が既定10回、「ロックアウト期間」が60秒になっていることを確認する
4. 社内ルールの策定と周知（4-1-5-1〜5、4-1-6-1〜3）:
   初期パスワードの変更、使い回しの禁止、安全な保管、漏えい時の変更手順を規程にまとめ、SharePointに掲載して周知する

パスワードの定期変更は★3の評価基準では求められていません。

MFAを強制したうえで、漏えいの疑いがあるときに速やかに変更する手順（4-1-6-2）を整える方が要件に沿っています。

漏えい時は、Microsoft 365管理センターのユーザー画面から「パスワードのリセット」と「すべてのセッションからサインアウト」を実行します。

評価基準4-1-4は、PCのログオンとスマートデバイスのロック解除について「10回以上失敗でロック」「6文字以上のパスワードまたはPIN」を求めています。

Intune（Business Premium以上）のポリシーで全端末に配布します。

1. Windows Hello for BusinessのPIN長:
   Intune管理センターの「エンドポイント セキュリティ」→「アカウント保護」でWindows Hello for Businessのポリシーを作成し、「PINの最小長」を6以上に設定する。顔・指紋認証を有効にすると生体情報も認証要素として使える
2. Windowsのロックアウト:
   「デバイス」→「構成」→「設定カタログ」で「デバイスのロック」カテゴリを開き、「デバイスのパスワード失敗の最大試行回数」を10に設定する
3. iOS／Android:
   「デバイス」→「コンプライアンス ポリシー」でパスコードを必須にし、最小長を6に設定する。あわせて「構成」のデバイス制限プロファイルで「デバイスをワイプするまでのサインイン失敗回数」を10に設定する
4. 配布後、「レポート」→「デバイスのコンプライアンス」で準拠状況を確認し、非準拠端末をフォローする

Windows Hello for Businessとは、PINや生体情報でWindowsにサインインする仕組みで、PINは端末のTPMに紐づくため他の端末では使えません。

Windows Helloとの違いはWindows HelloとWindows Hello for Businessの違いを解説した記事で詳しく説明しています。

「Windows Hello」と「Windows Hello for Business」は何が違う？仕組みとセキュリティの決定的な差を解説

社内のセキュリティ管理を担当されている皆様にとって、パスワード管理は永遠の課題ですよね。 そこで注目されているのが、Windowsに標準搭載されている生体認...

MFAを全ユーザーに強制すると、共有メールボックス、複合機やスキャナのメール送信、外部ゲスト、緊急用アカウントで問題が起きやすくなります。

それぞれ★3の要件と両立する扱い方があります。

つまずきポイント	起きること	対処
共有メールボックス	共有IDでサインインしようとしてMFAに引っかかる	共有メールボックスのサインインを無効にし、個人IDから権限でアクセスする（4-1-1-2にも適合）
複合機・業務システムのメール送信	基本認証が使えずSMTP送信が失敗する	OAuth対応の機器はモダン認証へ、非対応はSMTPリレー（コネクタ）や送信専用の仕組みに切り替える
外部ゲストユーザー	取引先のゲストにもMFAが要求される	条件付きアクセスでゲストを対象に含めるか、テナント間アクセス設定で相手組織のMFAを信頼する
緊急用アカウント	MFA障害時に管理者が締め出される	MFAポリシーから除外し、長いパスワードを施錠保管。利用時のアラートを設定
スマートフォンの紛失・機種変更	Authenticatorが使えずサインインできない	一時アクセスパスを発行して再登録。紛失時は登録済みの方法を管理者が削除
退職者	個人のスマートフォンに認証方法が残る	退職時に「サインインをブロック」し、認証方法を削除してからアカウントを削除

例外を設けた場合は、「なぜ例外にしたか」「代わりにどう保護しているか」「誰が承認したか」を記録します。

★3は書類確認による評価なので、例外そのものより、例外が管理されていることを示せるかが重要です。

★3の評価は書類確認で行われるため、設定画面のスクリーンショットとエクスポートしたレポートを評価基準の番号ごとに保管しておきます。

評価基準	証跡の例	取得場所
4-1-3-2（常時MFA）	条件付きアクセスポリシーの設定画面、または既定値群が有効な画面	Entra管理センター > 条件付きアクセス／プロパティ
4-1-3-2（登録状況）	ユーザー登録の詳細のCSV（全員がMFA対応）	Entra管理センター > 認証方法 > ユーザー登録の詳細
4-1-3-3（認証要素）	認証方法ポリシーの一覧画面	Entra管理センター > 認証方法 > ポリシー
4-1-3-4・4-1-5-3	パスワード保護の設定画面（しきい値10）、既定ポリシーの説明	Entra管理センター > 認証方法 > パスワード保護
4-1-4-1・4-1-4-2	Windows Hello for Businessポリシー、設定カタログ、コンプライアンスポリシーの画面と準拠レポート	Intune管理センター
4-1-5・4-1-6（ルール）	パスワード規程、周知メールや投稿の記録、確認回答	SharePoint / Teams / Forms

証跡はスクリーンショットに取得日を入れ、SharePointに評価基準番号ごとのフォルダを作って保管すると、翌年の更新（★3は有効期間1年）でも同じ手順で差分だけ更新できます。

★3の認証以外の要求事項をMicrosoft 365でどこまで満たせるかは、81件すべてを分類した以下の記事で確認できます。

SCS評価制度★3はMicrosoft 365で対応できる？評価基準81件の対応表と足りないライセンスを解説【2026年9月時点】

2026年3月に経済産業省が制度構築方針を公表して以来、Microsoft 365を利用する中小企業から「SCS評価制度に向けてセキュリティを整えたい」とい...

---

MFAを全社に強制した直後は、「Authenticatorの通知が来ない」「新しいスマホで登録できない」といった問い合わせが一時的に増えます。

Microsoft 365支援のプロが、現場で実際に寄せられるよくある質問と解決策を厳選してまとめた「トラブルシューティング大全」をご用意しました。

▼資料ダウンロードはこちら 『社内からの「これどうやるの？」を9割削減する Microsoft 365 トラブルシューティング大全』

---

• ★3の認証要件は、重要な機密情報を扱うクラウドサービスへの常時MFA（4-1-3-2）、認証要素2種類以上（4-1-3-3）、パスワード8文字以上（4-1-3-4）、端末は10回失敗でロック・PIN6文字以上（4-1-4）
• Microsoft 365では、認証方法ポリシー→MFA強制（既定値群または条件付きアクセス）→パスワード保護→Intuneのロック設定の順で進めると要件を満たせる
• Entra IDのパスワード8文字以上とスマートロックアウト10回は既定のままで要件に適合する
• SMS認証は★3の基準上は認められるが、2027年2月に廃止予定のためAuthenticatorやパスキーへ移行する
• 共有メールボックス・複合機・緊急用アカウントなどの例外は、管理されていることを文書と証跡で示す

認証要件はMicrosoft 365の設定で完結する項目が多く、★3対応の中で最も早く成果が見える分野です。

まずは「ユーザー登録の詳細」で現状を確認するところから始めてみてください。

---

セキュリティ対策と業務効率化を両立した企業の事例をご覧になりませんか？

MFAやデバイス管理の強化を進めながら、現場の使いやすさを損なわずに定着させた企業はどのように進めたのか気になる方も多いはずです。

そんな疑問をお持ちでしたら、ぜひ弊社の「中小企業の導入成功事例【厳選10選】」をご覧ください。

▼成果の出る Microsoft 365 活用法とは？中小企業の導入成功事例集をダウンロードする

---

• 要求事項・評価基準｜IPA
• SCS評価制度の詳細情報｜IPA
• SCS評価制度に関する注意喚起｜経済産業省
• 必須の Microsoft Entra 多要素認証 (MFA) を計画する｜Microsoft Learn
• セキュリティの既定値群｜Microsoft Learn
• 条件付きアクセスの概要｜Microsoft Learn
• Microsoft Entra パスワード保護｜Microsoft Learn
• スマート ロックアウト｜Microsoft Learn
• Microsoft Entra ID のパスワード ポリシー｜Microsoft Learn
• Intune の Windows Hello for Business 設定｜Microsoft Learn
• Policy CSP - DeviceLock｜Microsoft Learn