PCI DSS v4.0.1 では、CDE（カード会員データ環境）に入る非コンソールアクセスのすべてに多要素認証が求められ、2025年3月31日から評価の対象になりました。対象は管理者だけではありません。8.4.1〜8.4.3と8.5.1の違い、二段階認証やパスキーの扱い、アプリの層でかけるときに漏れやすい入り口を、PCI SSC の原文と FAQ をもとに整理しました（2026年10月時点）。
PCI DSS は、カード会員データを守るために PCI SSC（PCI Security Standards Council）が定める基準です。日本では、割賦販売法が求めるカード番号等の管理の実務上の指針の中で、カード会社や決済代行業者などに準拠が求められています。カード情報を扱う会社の情報セキュリティ コンプライアンスでは、中心になる基準の一つです。
PCI DSS v4.0.1 の要件7・8・10と、LOCKED で担える範囲・担えない範囲を対応表にまとめました。 多要素認証とシングルサインオン（LOCKED MSO）を見る →
PCI DSS の多要素認証は、8.4 と 8.5 の4つの要件で決まる
要件8（ユーザーの識別と認証）のうち、多要素認証を扱うのは 8.4 と 8.5 です。8.4 はどのアクセスにかけるかを、8.5 は仕組みをどう作るかを決めています。4つを並べます。
| 要件 | 対象 | 求めること | 評価の対象になった時期 |
|---|---|---|---|
| 8.4.1 | 管理者権限を持つ人の、CDE への非コンソールアクセス | 多要素認証 | v4.0 より前から |
| 8.4.2 | CDE へのすべての非コンソールアクセス | 多要素認証（対象外は3種類） | 2025年3月31日 |
| 8.4.3 | 社外から入り、CDE にアクセスしうる・影響しうるリモートアクセス | 多要素認証 | v4.0 より前から |
| 8.5.1 | 多要素認証の仕組みそのもの | リプレイ攻撃に耐える、迂回できない、種類の違う2つ以上の要素、全要素の成功後に通す | 2025年3月31日 |
表の「非コンソール」は、ネットワークを経由するアクセスを指します。コンソールアクセスは、ネットワークを介さずにケーブルで直接つないだ管理用の接続です（FAQ 1577）。手元のキーボードで操作していても、そのパソコンからネットワーク越しに別の機器へ入るなら、コンソールアクセスには当たりません。
2025年3月31日から、管理者以外も対象になった
v3.2.1 までの多要素認証は、管理者のアクセスと社外からのリモートアクセスが中心でした。v4.0 で新設された 8.4.2 が、対象を CDE に入る全員へ広げています。管理者かどうかは問いません。8.4.2 と 8.5.1 は2025年3月31日まで推奨（ベストプラクティス）の扱いで、それ以降は評価で確かめられる必須の要件です。
2026年10月時点で有効な版は、2024年6月に公開された v4.0.1 です。誤記の修正と説明の明確化にとどまる改訂で、要件の追加・削除はありません。v4.0 は2024年12月31日に廃止されました。次の版に向けては、PCI SSC が2026年6月3日から7月20日まで v4.0.1 への意見を募りました。次の版の名前と時期は、まだ発表されていません。
要素は3種類。同じ種類を2つ重ねても多要素認証にならない
PCI DSS が数える認証の要素は3種類です（要件8.3.1）。パスワードのように知っているもの、トークンやスマートカードのように持っているもの、生体情報のように本人の身体にあるもの。多要素認証は、このうち種類の違う2つ以上を組み合わせます。
パスワードを2回求めても、多要素認証には数えません。同じ種類を2回使うだけだからです。秘密の質問も知っているものの一つで、パスワードと組み合わせても一要素のままです。
パスワードだけで認証するシステムには、90日ごとにパスワードを変えるか、アカウントの状態を動的に分析してアクセスを決める仕組みが要ります（8.3.9）。多要素認証を使うなら、この要件はかかりません。
2026年版 情シスが直面するIDガバナンス5大課題
2026年に情シスが直面するIDガバナンスの5つの主要課題を分析。SaaS増加、リモートワーク常態化、コンプライアンス強化などへの対応策を提示します。
8.4.1・8.4.2・8.4.3 の違いは「誰が、どこから、どこへ」
3つの要件は、アクセスする人と、アクセスの出発点・行き先で分かれています。
8.4.1：管理者の非コンソールアクセス
8.4.1 は、管理者権限のように高い権限を持つ人が、ネットワーク越しに CDE に入るときの多要素認証です。v4.0 より前からある要件です。CDE の外にある対象範囲のシステムでも、管理者のアクセスには多要素認証をかけるよう推奨（Good Practice）されています。
8.4.2：CDE へのすべての非コンソールアクセス
8.4.2 は、管理者に限らず、CDE に入るすべての人のアクセスにかかり、たとえば決済システムの管理画面でカード情報を照会する担当者や、保守を委託した会社の技術者も対象になります。クラウド、ホスティング、社内のアプリ、ネットワーク機器、サーバー、端末といったあらゆる種類のシステムが対象で、Web ブラウザからアプリを使うアクセスも含みます。
例外は3つだけです。
- 自動処理を行うアプリケーションやシステムのアカウント
- 1回の取引のために、一度に1枚のカード番号しか扱えない POS 端末のユーザーアカウント
- フィッシング耐性のある認証要素だけで認証するユーザーアカウント（v4.0.1 で追加）
1つ目のアカウントは対象外でも放っておけません。対話的なログインやパスワードの扱いは、8.6.1〜8.6.3 で別に管理します。なお要件8は、カード会員（消費者）のアカウントには適用されません。EC サイトで買い物をする顧客のログインは、8.4.2 の対象外です。
8.4.3：社外からのリモートアクセス
8.4.3 の対象は、会社のネットワークの外から入ってくるリモートアクセスのうち、CDE にアクセスしうる、または影響しうるものです。従業員に加えて、ベンダー、委託先、サービス提供者、顧客といった第三者も対象です。CDE から適切に区分けされたネットワークだけに入るリモートアクセスなら、8.4.3 の多要素認証は必須になりません。それでも、かけることは推奨されています。
VPN で多要素認証をしても、CDE に入るときにもう一度
8.4.2 と 8.4.3 は別の要件です。片方の多要素認証で、もう片方は代えられません。社外から VPN で社内ネットワークに入るときに一度、社内から CDE に入るときにもう一度。多要素認証は2回です。
テレワーク中の保守担当者が、VPN の多要素認証を済ませたあとは追加の認証なしで CDE のサーバーへ入れる、という構成を考えてみます。8.4.2 は満たせません。社外からの入り口は守れていても、社内から CDE への入り口が一要素のままだからです。
無料で製品資料をお送りしています。CDE への入り口の見直しにお使いください。 製品資料をダウンロードする →
8.5.1：多要素認証の仕組みに求められる4つの条件
8.4 が「どのアクセスにかけるか」を決めるのに対し、8.5.1 は、かけた多要素認証が破られにくく作られているかを問います。条件は4つです。
- リプレイ攻撃（正規の通信を盗み取って送り直す攻撃）に耐えること。対策の例として、セッションごとに一意の識別子や鍵、タイムスタンプ、時間ベースのワンタイムパスワードが挙がっています
- 管理者を含め、誰も迂回できないこと
- 種類の違う要素を2つ以上使うこと
- すべての要素が成功してから、アクセスを認めること
迂回が許されるのは、文書にしたうえで、経営層・管理者層が例外として承認し、期間を限った場合だけです。障害のときに使う緊急用の管理者アカウントで多要素認証を外すなら、この手続きを先に決めておきます。
パスワードの次に二つ目を求める「二段階」の作りでもよい
日本語でいう二段階認証は、認証を2回に分けて行う方式で、ID とパスワードを確かめてから SMS や認証アプリのコードを求める、という作りが典型です。
この作りは認められています。FAQ 1584（2024年9月）の答えは、1つ目の要素が成功したと示してから次の要素を求める実装でも、多要素認証の要件を満たす、というものです。勧める作りとしては、すべての要素がそろうまで成否を返さない方法と、セッションごとに変わる要素（ワンタイムパスワードやフィッシング耐性のある要素）を、パスワードのように毎回同じ要素より先に確かめる方法の2つを挙げています。
古い解説には、二段階の作りは多要素認証にならない、と書いたものがあります。2017年に PCI SSC が出した MFA のガイダンスが、すべての要素を出し終えるまで個々の成否を示さないよう求めていたためです。このガイダンスは2025年8月、新しい「Authentication Guidance」に置き換えられました。
結局のところ、決め手は段階の数より要素の種類です。パスワードと秘密の質問は二段階でも一要素、パスワードと認証アプリのコードなら二要素になります。クレジットカード・セキュリティガイドラインも、二段階認証は2つの段階で違う種類の要素を使う場合に多要素認証にもなりうる、と説明しています。言葉の違いは、二要素認証と二段階認証の違いで図にしています。
フィッシング耐性のある認証は、8.4.2 に限って単独で認められる
v4.0.1 の用語集（付録G）は、フィッシング耐性のある認証を、認証の秘密が正規のシステム以外に渡って使われるのを防ぐよう設計された認証と定義しています。偽サイトや、通信の途中に割り込む攻撃に耐えるのが狙いです。多くは公開鍵暗号を使います。パスワード、ワンタイムパスワード、SMS、マジックリンク（メールで届くログイン用のリンク）は当てはまりません。例に挙がっているのは FIDO2 です。
単独で使えるかは、アクセスの種類しだいです。
| アクセスの種類 | フィッシング耐性のある認証だけでよいか | 根拠 |
|---|---|---|
| 8.4.2（管理者以外の、CDE へのアクセス） | よい。FIDO2 に沿って実装した同期パスキーも含む | 8.4.2 の注記、FAQ 1595（2025年5月） |
| 8.4.1（管理者の非コンソールアクセス） | 不可。別の要素を組み合わせる | FAQ 1596（2025年5月） |
| 8.4.3（社外からのリモートアクセス） | 不可。別の要素を組み合わせる | FAQ 1596（2025年5月） |
一般の担当者が CDE の業務画面に入るだけなら、FIDO2 に沿ったパスキーだけのログインでも 8.4.2 を満たします。管理者は別です。管理者の作業や社外からの接続は危険が大きいため、パスキーにもう一つ要素を足します。FAQ 1596 は、足す要素の例としてパスワード、PIN、生体認証を挙げています。
パスキーを使うときに端末のロック解除で求める PIN や生体認証を、この足す要素として数えてよいか。FAQ はそこまで書いていません。管理者のアクセスをパスキー中心に組むなら、実装を示して QSA（認定セキュリティ評価機関）と確かめてください。FIDO2 に沿っていないパスキーは、8.4.1〜8.4.3 のどれでも追加の要素が必要です（FAQ 1595）。
PCI DSS の多要素認証をどの入り口にどうかけるか、無料でご相談いただけます。 デモ・個別相談を申し込む →
アプリの層で PCI DSS の多要素認証をかけるときの注意
8.4.2 の注記によると、CDE への多要素認証はネットワークの層でかけても、システムやアプリの層でかけてもかまいません。どちらか一方で足ります。CDE のネットワークに入るときに多要素認証をしていれば、その中の各システムへのログインのたびにかけ直さなくてよい、という例も示されています。
SSO の認証基盤（IdP）で多要素認証をかけるのは、アプリの層を選ぶ代表的なやり方です。Web の管理画面や業務システムには入れやすい一方、次の3点で抜けが出やすくなります。
CDE への入り口を、すべて一覧にする
最初に、入り口を数えます。IdP を通らない入り口が残っていないかを確かめるためです。サーバーへの SSH やリモートデスクトップ、データベースの管理ツール、ネットワーク機器の管理画面、クラウドの管理コンソールは IdP の外にあることが多いので、CDE に入る経路を図に起こし、経路ごとに、どの層のどの多要素認証で守っているかを書き込んでいきます。一つでも空欄が残れば、8.4.2 は満たせません。
社内の IP アドレスからのログインには二段階認証を求めない、というルールにも注意が要ります。ネットワークの層で多要素認証をかけていないなら、社内から CDE に入るアクセスが一要素のまま残るからです。この例外は外します。
IdP を迂回できる直接ログインと緊急用アカウント
サービスに ID とパスワードだけで直接ログインできる経路が残っていると、IdP の多要素認証を迂回できてしまいます。8.5.1 が求めるのは、管理者を含めて誰も迂回できないことです。SAML などでのログインを必須にできるサービスは、そうします。できないサービスは、サービス自体の多要素認証を使います。
緊急用の管理者アカウントを残すなら、8.5.1 の例外として文書にし、承認と期限を決めます。使ったら、その記録を必ず確かめます。
IdP も、PCI DSS の対象範囲に入る
v4.0.1 の4章（適用範囲）は、対象範囲に入るシステムの例に、認証サーバー、多要素認証のシステム、クラウドの ID・アクセス管理を挙げています。CDE へのログインを守る IdP も、その一つです。設定、管理者、ログが評価の対象になりえます。10.4.1 は、認証サーバーのようにセキュリティの機能を持つシステムのログを、少なくとも1日1回確かめる対象にしています。
IdP がクラウドサービスなら、提供する会社は第三者のサービス提供者（TPSP）にあたるので、利用する会社は 12.8 にもとづいてサービス提供者を一覧にし、少なくとも12か月に1回、PCI DSS への準拠状況を確かめます。提供する側も 12.9 にもとづき、自社がどの範囲に責任を持つかを書面で認めることになるので、どの要件をどちらが担うかは導入の前に決めておきます。
日本では、PCI DSS 準拠は割賦販売法の「実務上の指針」から求められる
PCI DSS は PCI SSC の基準です。法律ではありません。日本でカード会社や加盟店に PCI DSS 準拠が求められるのは、割賦販売法、経済産業省の監督の基本方針、クレジットカード・セキュリティガイドラインという3段の仕組みを通じてです。
出発点は、割賦販売法の第35条の16です。カード会社、加盟店、決済代行業者などの「クレジットカード番号等取扱業者」に、カード番号等の漏えいなどを防ぐための措置を義務づけていて、その基準は割賦販売法施行規則の第132条が「必要かつ適切な措置」として定めています。法律も省令も、PCI DSS の名前は挙げていません。
経済産業省の「割賦販売法（後払分野）に基づく監督の基本方針」（令和7年9月）は、法令はセキュリティに欠かせない機能だけを定め、手段は各社の工夫に任せる「性能規定」だと説明しています。そのうえで、クレジットカード・セキュリティガイドラインに掲げる措置を実務上の指針とし、その措置か同等以上の措置を講じていれば「必要かつ適切な措置」と認める、としています。
ガイドラインの最新版は、2026年3月に公表された6.1版です。カード会社や決済代行業者などには PCI DSS 準拠を、加盟店には、カード情報を持たない「非保持化」か、持つなら PCI DSS 準拠を、指針対策として求めています。PCI DSS 準拠は、法律の条文が直接求める義務ではありません。法律が求める措置を実務に落とした指針の中にある対策で、非保持化を選んだ加盟店には PCI DSS 準拠までは求められていません。
非保持化した EC 加盟店も、管理画面には二段階認証か多要素認証
ガイドライン6.1版は、EC 加盟店に、カード情報を持つかどうかにかかわらず「脆弱性対策」を求めています（5-2-2-1）。2025年4月から求められている対策です。その一つが、システム管理画面へのアクセスの制限と管理者の ID・パスワードの管理で、IP アドレスの制限、二段階認証か多要素認証、10回以下のログイン失敗でのアカウントのロックが挙がっています。
これは PCI DSS の 8.4.2 とは別の、加盟店向けの対策です。二段階認証も選べますが、2つの段階で違う種類の要素を使ったときにはじめて多要素認証になる、という点は PCI DSS と変わりません。
PCI DSS の多要素認証で、評価の前に確かめること
評価の前に、次の点を確かめます。
- CDE に入る経路を、サーバー、データベース、ネットワーク機器、Web の管理画面、クラウドの管理コンソール、リモートアクセスごとに洗い出したか
- 経路ごとに、ネットワークの層とアプリの層のどちらで多要素認証をかけるかを決めたか。社外から入って CDE に進む経路は2回になっているか
- 要素の種類は違うか
- 管理者のアクセスや社外からの接続で、フィッシング耐性のある認証を単独で使っていないか
- 多要素認証を求めない例外ルールや、サービスへの直接ログインが残っていないか
- 緊急用アカウントなど迂回の例外を、文書・承認・期限つきで管理しているか
- IdP や多要素認証のシステムを対象範囲に入れ、そのログを毎日確かめているか
- クラウドの IdP なら、どの要件をどちらが担うかをサービス提供者と書面で決めたか
- 範囲と方式を QSA とすり合わせたか
LOCKED で、CDE への Web の入り口に多要素認証をかける
LOCKED MSO は、SAML・WS-Federation や代理ログインで LOCKED を通る Web の画面に、ログインルールで二段階認証をかけます。CDE につながる Web の管理画面や業務システムを LOCKED に寄せ、CDE を使う人をグループにまとめて、次のように設定します。
- 二段階目の方式は、パスキーと認証アプリを先に置き、代わりの手段に SMS のリンクを置きます。パスワードと同じ知っているものになる秘密の質問は、方式に入れません。パスキーは、サポートへのお申し込みで使えるようになります
- このグループには、社内の IP アドレスからのログインも含めて二段階認証を求めるログインルールを置きます
- パスワードは12文字以上で英小文字と数字を必須にし、10回の失敗で30分ロックします
- SAML でのログインを必須にできるサービスは必須にして、直接ログインの経路を閉じます
LOCKED の管理画面の操作は監査ログに、利用者のログインは端末ごとの履歴に残り、評価で見せる記録になります。
LOCKED が担えるのは、アプリの層の一部です。サーバーの OS、データベース、ネットワーク機器と VPN へのログインは対象外なので、それぞれの仕組みで多要素認証をかけます。CDE へのログインを LOCKED で守るなら、LOCKED も対象範囲に入る可能性が高いと考えてください。当社はサービス提供者として、12.8・12.9 の管理の対象になります。LOCKED は PCI DSS への適合を保証する製品ではありません。対象範囲と適合の判断は、QSA と行います。
まとめ
2025年3月31日を境に、PCI DSS の多要素認証は、管理者と社外からの接続を守る対策から、CDE に入る全員を守る対策に変わりました。軸は2つです。どのアクセスにかけるか（8.4.1〜8.4.3）と、かけた仕組みが迂回されず破られにくいか（8.5.1）。パスキーのようなフィッシング耐性のある認証は、一般の担当者のアクセスなら単独で認められ、管理者と社外からの接続ではもう一つの要素と組み合わせます。
次に手を付けるのは、CDE に入る経路を一枚の図に起こし、多要素認証のかかっていない入り口を探すことです。空欄が見つかった入り口から、ネットワークとアプリのどちらの層で守るかを決めていきます。
CDE への入り口の洗い出しから多要素認証のかけ方まで、無料でご相談いただけます。 資料請求・デモ依頼はこちら →
参考資料
- PCI SSC：文書ライブラリ（PCI DSS v4.0.1、2024年6月。要件8.3.1・8.3.9・8.4.1〜8.4.3・8.5.1・10.4.1・12.8・12.9、4章、付録G）
- PCI SSC：Just Published: PCI DSS v4.0.1（2024年6月11日）
- PCI SSC：Request for Comments: PCI Data Security Standard (PCI DSS) v4.0.1（2026年6月3日）
- PCI SSC：PCI SSC Releases New Guidance on Authentication and Cryptography（2025年8月26日）
- PCI SSC FAQ 1577：8.4.1・8.4.2 の「コンソールアクセス」の意味（2024年5月）
- PCI SSC FAQ 1584：1つ目の要素の成否を示してから次の要素を求めてよいか（2024年9月）
- PCI SSC FAQ 1595：FIDO2 に沿った同期パスキーと 8.4.2（2025年5月）
- PCI SSC FAQ 1596：フィッシング耐性のある認証だけで 8.4.1・8.4.3 を満たせるか（2025年5月）
- e-Gov法令検索：割賦販売法（第35条の16）
- 経済産業省：割賦販売法（後払分野）に基づく監督の基本方針（令和7年9月）Ⅱ-2-2-5-1・Ⅱ-2-2-5-5
- クレジット取引セキュリティ対策協議会：クレジットカード・セキュリティガイドライン【6.1版】（2026年3月、事務局 日本クレジット協会）4-2・5-2-2-1・用語集