BtoB EC多要素認証の導入設計ガイド

◆監修・編集責任者　小園 将隆　2026年8月25日

B2B EC-COLUMN

知識・所持・生体の組み合わせで発注者本人を確かめる、それがBtoB ECの多要素認証である

BtoB ECの多要素認証とは、知識情報（パスワード等）・所持情報（スマホ等）・生体情報（指紋・顔等）のうち複数を組み合わせる仕組みです。取引先の発注者が、登録済みの本人であることを確かめるために用います^*1。導入の要点は全機能への一律適用ではありません。機能ごとにリスクの影響度を評価し、必要な保証レベルに見合う認証方式・回復手段・再認証の間隔を組みで設計することにあります。

3つの要素（知識情報・所持情報・生体情報）の定義

知識情報は本人だけが知っている情報で、パスワードや暗証番号が該当します。所持情報は本人だけが持っているモノに関する情報で、スマートフォンやICカード、USBセキュリティキー等が該当します。生体情報は指紋や顔などの身体的特徴で、これら3種類のうち異なる2種類以上を組み合わせて認証することを多要素認証と呼びます^*1。

「当人認証」「身元確認」「権限管理」は別物である

当人認証とは、ログイン時に「今アクセスしている人が、登録済みの本人かどうか」を確かめる行為です。これに対し身元確認は、アカウント登録時に「実在する人物・法人かどうか」を確かめる行為です。権限管理（認可）は「本人だと確認できた人が、どこまでの操作を許されているか」を定める仕組みです^*1。3つは目的が異なるため、認証を強化しても権限設計の不備は解消しません。

BtoB ECで守る対象は、取引先別価格・与信枠・発注権限である

BtoB ECの多要素認証が守るべき対象は、一般消費者向けECとは異なります。取引先ごとに異なる掲示価格、与信枠、発注できる金額の上限、支払条件の変更権限など、なりすましによって書き換えられると取引そのものに影響する情報が中心です。この違いが、次章で述べる機能単位の保証レベル判定の出発点になります。

導入は「入れるかどうか」ではなく、機能ごとの保証レベル判定から始まる

デジタル庁が2025年9月30日に制定したDS-511は、行政手続を対象にした標準ガイドラインであり、民間のBtoB ECに直接適用される規範ではありません^*1。ただし、当人認証保証レベルという枠組みは、機能ごとにリスクを評価してから認証方式を決めるという設計手順として参照できます。ここでは、その枠組みをBtoB EC設計の考え方として用います。

当人認証保証レベルは3段階で定義される

DS-511はリスクの影響度に応じて、当人認証保証レベルを3段階に分けています^*1。

多要素認証が必須になるのはレベル2以上、フィッシング耐性が全利用者必須になるのはレベル3である

上表のとおり、多要素認証そのものが必須になるのはレベル2からです。レベル3では、さらにフィッシング攻撃への耐性を全利用者が持つ手法に限定されます^*1。BtoB ECでは、この境界線を意識して機能ごとにレベルを割り当てることが設計の出発点になります。なおDS-511は、対策基準はあくまで基準であり、同等の脅威耐性を確保できる場合は他の手法等により代替してもよいとしています^*1。

BtoB ECの機能にレベルを割り当てる

DS-511そのものはBtoB ECの機能を対象にしていないため、以下はガイドラインの枠組みを参考にした設計上の例示です。商品閲覧のような読み取り中心の機能はリスクの影響度が相対的に小さく、レベル1〜2の対象と考えられます。一方、発注の確定や支払条件・与信枠の変更、管理者による権限設定の操作は、なりすましによる影響が大きくなります。レベル2以上、特に管理者操作はレベル3に相当する設計が妥当です。

可視化したコストを自社の機能一覧に当てはめて確かめるには、無料相談で要件を整理するのが近道です。

認証方式は、フィッシング耐性があるかどうかで仕分ける

NISTは、SP 800-63B-4を2025年7月に公開しました。NISTは米国国立標準技術研究所（National Institute of Standards and Technology）の略称です。この文書はフィッシング耐性を認証方式の評価軸として定義しています^*2。米国連邦政府機関向けのガイドラインであり、日本の民間企業を直接拘束するものではありません。以下では、必須を意味するSHALLと推奨を意味するSHOULDを区別して示します。

フィッシング耐性とは、利用者の注意力に頼らずに認証情報の詐取を防ぐ性質である

NISTはフィッシング耐性を「利用者の注意力に依存せずに、認証の秘密情報や有効な認証出力が、偽の検証者へ渡ることを防げる能力」と定義しています^*2。利用者が検索エンジン経由で偽サイトに誘導された場合でも、秘密情報が漏れないかどうかが評価の基準です。

公開鍵認証（パスキー／WebAuthn）がフィッシングに強い理由は、資格情報がオリジンに紐づくためである

パスキー等のWebAuthn（Web Authentication）は、公開鍵暗号を用いた認証方式です。W3Cは2026年5月26日に候補勧告スナップショット「WebAuthn Level 3」を公開しました。この文書によれば、公開鍵資格情報はRelying Party（認証を要求する側のサービス）ごとにスコープされます。その資格情報には、当該Relying Partyに属するオリジンからしかアクセスできません^*5。偽サイトのオリジンでは資格情報自体が利用できないため、フィッシングによる詐取が成立しにくくなります。

SMS・音声によるワンタイムパスワードは、SIMスワップ等のリスク指標を確認したうえで使う

SMSや音声で送るワンタイムパスワードは所持情報の一種ですが、フィッシング耐性は持ちません。NISTは、認証出力を人が手で入力する方式について、フィッシング耐性があるとみなしてはならない（SHALL NOT）と定めています^*2。手入力では、その出力が認証対象のセッションに結びつかないためです^*2。デジタル庁DS-511も、ワンタイムパスワードはリアルタイム中継型のフィッシング攻撃への耐性を有さない点に留意が必要だとしています^*1。NISTは、公衆交換電話網（PSTN）経由でワンタイムパスワードを送る前に、リスク指標を考慮することを推奨（SHOULD）しています^*2。指標として挙げられているのは、端末の交換・SIMの変更・番号の移転・その他の異常な挙動です^*2。あわせて、すべての利用者が別の種類の認証器を使える状態にしておくことを必須（SHALL）としています^*2。DS-511は、SMS等でワンタイムパスワードを送る方式のリスクを3点挙げています^*1。SIMスワッピング攻撃により携帯電話番号を不正に奪取されること、第三者によってSMS等の認証代行が行われること、携帯電話番号の再割り当てにより別人に届くことです^*1。採用にあたっては、これらのリスクを受容できるか個別のリスク評価が必要だとしています^*1。NIST側でも、PSTNを用いた帯域外認証は「制限付き認証器（restricted authenticator）」に位置づけられています^*2。現時点で指定されているのはこの1種類だけで、採用する組織がリスクを評価・理解・受容することが前提になります^*2。

方式別の比較

導入設計は5つの工程で進める

ここまでの保証レベル判定と方式選定を、実際の導入作業に落とし込む工程は5つです。DS-511は本人確認手法の検討プロセスを一度きりの作業ではなく、継続的な評価と改善を含む一連の流れとして示しています^*1。

①対象機能の洗い出しとリスク影響度の評価

まず、閲覧・発注・支払条件変更・管理者操作など機能を洗い出し、なりすましが起きた場合の影響度を評価するところから始めます。影響度の大きさが、次工程の保証レベル判定の入力になります^*1。

②保証レベルの判定と認証方式の決定

評価した影響度に基づき、機能ごとに保証レベルを判定し、レベルに見合う認証方式を決定します。レベル2以上の機能で多要素認証が前提になる点^*1は、前章の表①で示した基準そのものです。

③認証器の登録 — 取引先アカウント発行時に紐づける

決定した認証方式の認証器を、利用者と紐づけて登録する手順を定めます。身元確認プロセスの一環として登録するのが一般的ですが、アカウント回復用の追加登録や、故障時の再登録についても、この段階で手順化しておく必要があります^*1。

④盗難・紛失時の登録解除とアカウント一時停止をあらかじめ定める

認証器の盗難や紛失が起きた場合に備え、利用者からの報告を受けて登録を解除し、アカウントを一時停止する対応をあらかじめ定めます。報告受付時には、第三者によるなりすまし報告を想定した本人確認の手順^*1も、あわせて検討しておきましょう。

⑤継続的な評価と改善

導入後も、認証方式の評価と改善に必要な情報を運用期間中に収集し、収集した情報に基づいて改善措置を講じることが求められます^*1。新しい脅威や技術動向に応じて保証レベルの判定自体を見直す運用が前提になります。

アカウント回復の強度が、多要素認証の実効性を決める

認証方式をどれだけ強化しても、回復手段が弱ければ、そこが新たな攻撃の起点になります。DS-511は、アカウント回復の手段を攻撃の起点とされることを防ぐため、採用している当人認証手法と同等以上の強度の手法を選ぶべきだと明記しています^*1。

回復手段は、採用している認証方式と同等以上の強度にする

パスキーのようにフィッシング耐性の高い方式を採用しても、回復手段だけをSMSやメールのような弱い経路に頼ることがあります。この場合、攻撃者は認証そのものではなく回復経路を狙います。強度を揃える発想が、回復手段の設計における前提です。

代表的な4手段の比較

連絡先の乗っ取りを前提に、報告受付時の本人確認を設計する

リカバリーコードの必要時発行を採用する場合、攻撃者が連絡先そのものを乗っ取り、コードを不正に窃取するリスクが残ります^*1。認証器の紛失報告を受け付ける窓口でも同様に、報告者が本人かどうかを確認する手順を、回復設計とセットで用意しておくことが欠かせません。

セッションと再認証の時間設計で、ログインしっぱなしを止める

ログインしたままの状態を放置しないための時間設計も、保証レベルごとに基準が異なります。NIST SP 800-63B-4は、セッションのタイムアウトを「全体タイムアウト」と「非アクティブタイムアウト」の2種類に分けて規定しています^*2。

再認証には全体タイムアウトと非アクティブタイムアウトの2種類がある

全体タイムアウトは、認証または前回の再認証から数えた利用可能な期間の上限です。非アクティブタイムアウトとは、利用者からの操作が一定期間無かった場合にセッションを終了させる基準^*2を指します。

保証レベル別の時間の目安

AAL3だけが「12時間以内」を必須（SHALL）として定めている点に注意が必要です。AAL1・AAL2の数値は推奨（SHOULD）であり、事業者の判断で調整する余地が残されています^*2。

倉庫・現場の共有端末をどう扱うか

倉庫や店舗の共有端末で発注業務する場合、非アクティブタイムアウトを短くしすぎると業務が止まり、長くしすぎると離席中に他者が操作できる状態が残ります。共有端末を使う機能ほど、保証レベルの判定と時間設計をセットで見直す必要があります。

法人アカウントでは、会社の実在性と担当者の紐づけまで設計に含める

BtoB ECの取引先アカウントは個人ではなく法人等の名義で発行されることが多く、個人向けの身元確認とは異なる考え方が必要になります。DS-511は、法人等の手続における身元確認の考え方を別紙2でまとめています^*1。

法人の実在性は「法人番号・商号又は名称・本店所在地」の基本3情報から確認する

DS-511別紙2は、法人等の実在性確認で収集する属性情報について、「法人等の基本3情報」を基本とすることが考えられる、としています^*1。基本3情報とは、法人番号・商号又は名称・本店又は主たる事務所の所在地です^*1。別紙2は手法の一例を示すものであり、収集項目を一律に義務づけるものではありません^*1。法人等の実在性確認、申請者個人の身元確認、両者の紐づきの確認という3段階を踏むことが、法人向け設計の骨格になります。

代表者以外の担当者は、委任の確認まで含めて紐づける

申請者個人が法人の代表者でない場合は、法人と申請者個人の紐づきを確認する工程が必要です^*1。BtoB ECでは、発注担当者が代表者本人であるケースは少なく、委任や代理の実態を踏まえて紐づけの手順を設計することが欠かせません。

なりすまし発注が起きた場合の責任の所在は、事前合意の有無で整理が変わる

経済産業省は令和7年2月に「電子商取引及び情報財取引等に関する準則」を改訂しました。この準則は、なりすましによる意思表示の効果が本人に帰属するかという論点をⅠ-3で整理しています^*4。本人確認の方式について事前合意がない場合は、原則として本人に効果は帰属しません。一方、継続的取引でIDやパスワードによる本人確認の方式が事前に合意されている場合は、原則として本人に効果が帰属するとされています^*4。準則は、契約自由の原則の下、事業者間取引のように対等な当事者間で本人確認の方式について合意した場合には、原則としてその効力が認められるものと解されるとしています^*4。ただし定型約款の個別条項として合意される場合は、内容によっては不当条項として合意内容から排除されることがあるとされています^*4。準則は法令の解釈を示す文書であり、個別事案の結論は事実関係によって変わります。ここでは、取引先との契約で本人確認の方式を事前に合意しておくという論点があることを示すにとどめます。

導入でつまずくのは、取引先の端末事情と社内の合意形成である

認証方式を技術的に選定できても、実際の導入では別の壁にぶつかります。DS-511も、スマートフォンの所有を前提とする手法を採用する場合、スマートフォンを持たない利用者への対応を検討すべきだと注意を促しています^*1。

スマートフォンを前提にしない代替手段を用意する

取引先の担当者全員がスマートフォンを業務利用できるとは限りません。事業目的の遂行や公平性の観点から、スマートフォンを持たない利用者が存在する場合の対応を、認証方式の選定と同時に検討する必要があります^*1。物理的なセキュリティキーや、既存の業務端末で完結する認証アプリなど、代替手段の候補をあらかじめ用意しておくことが実務上重要です。NISTも、電話の受信環境が整わない利用者が存在することを前提に、すべての利用者が別の種類の認証器を利用できる状態の確保を必須（SHALL）としています^*2。代替手段の用意は、運用上の配慮ではなく設計要件として扱われているということです^*2。

経営への説明材料は、IPAの脅威動向と自社の資産の重なりで作る

独立行政法人情報処理推進機構（IPA）は、2026年1月29日に「情報セキュリティ10大脅威2026」を公表しました。組織編の順位は、1位がランサム攻撃による被害、2位がサプライチェーンや委託先を狙った攻撃、3位がAIの利用をめぐるサイバーリスクです。8位はリモートワーク等の環境や仕組みを狙った攻撃となっています^*3。IPAは、複数の脅威にまたがる事案もあるため、各自の環境に照らし、選出された脅威については極力もれなく対策するよう求めています^*3。順位の高低だけで対策の要否を決める使い方はできません。取引先アカウントはサプライチェーン上の接点であり、社外からのアクセスという性質も持つため、この2つの項目に接続して経営への説明材料を作ることができます。なお、組織編には「不正ログイン」という単独の項目は無く、これは個人編の項目である点に注意が必要です^*3。

費用と工数の見立て

認証方式の切り替えには、既存の受発注システムとの連携確認や、取引先への周知・切り替え作業が発生します。工数は、既存システムの連携方式と取引先の数によって幅が出るため、一律のレンジでは示せません。個別の要件整理を通じて見立てることになります。内製で対応する場合は、認証プロトコルの実装知識、既存の基幹システムとの連携知識、運用ルールの整備という複数領域の知識が必要です。外部パートナーに要件整理を依頼する場合との差は、この複数領域を自社内で束ねられるかどうかにあります。

まとめ：BtoB EC多要素認証の設計を進める3つの判断軸

本稿では、BtoB ECの多要素認証を、保証レベルの判定から方式選定、アカウント回復、時間設計、法人アカウント特有の論点まで整理しました。要点は3つに集約できます。第一に、機能ごとのリスク影響度を評価してから保証レベルを判定すること。第二に、フィッシング耐性を軸に認証方式を仕分け、回復手段の強度をそれに揃えること。第三に、取引先の端末事情と社内の合意形成という運用面の壁を、導入設計の初期段階から織り込むことです。この順序で着手すれば、自社の要件定義を具体的に進められる状態になります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

SMSのワンタイムパスワードだけでは不十分ですか

影響度が高い機能では不十分になり得ます。SMSによるワンタイムパスワードはフィッシング耐性を持たない方式であり、採用にあたってはSIMスワッピング等のリスクを個別に評価する必要があります^*1*2。保証レベル3に相当する管理者操作などでは、フィッシング耐性を持つ方式を全利用者に必須とする設計が求められます^*1。

全機能に多要素認証をかけるべきですか

一律にかける必要はありません。DS-511の枠組みでは、影響度が「低位」の機能は単要素認証も許容範囲とされています^*1。商品閲覧のような読み取り中心の機能と、発注確定や支払条件変更のような機能を区別し、機能ごとに保証レベルを判定することが基本の考え方です。

取引先がパスキーに対応していない場合はどうすればよいですか

スマートフォンの所有や対応デバイスを前提にできない利用者向けに、代替の認証手段をあらかじめ用意することが必要です^*1。認証アプリによるワンタイムパスワードなど、既存端末で完結する方式を代替候補として設計に含めておきます。

多要素認証と権限管理（認可）は何が違いますか

多要素認証は「今アクセスしている人が本人かどうか」を確かめる当人認証の仕組みです。権限管理（認可）は、本人だと確認できた人がどこまでの操作を許されているかを定める仕組みで、両者は別の設計対象になります^*1。

1. *1　出典：デジタル庁「デジタル社会推進標準ガイドライン DS-511　行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（2025年9月30日）　https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/12cb1a6c/20250930_resources_standard_guideline_identityverification_01.pdf
2. *2　出典：NIST「NIST SP 800-63B-4　Digital Identity Guidelines: Authentication and Authenticator Management」（2025年7月）　https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf
3. *3　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」（2026年1月29日）　https://www.ipa.go.jp/security/10threats/10threats2026.html
4. *4　出典：経済産業省「電子商取引及び情報財取引等に関する準則」（令和7年2月）　https://www.meti.go.jp/files/900015316.pdf
5. *5　出典：W3C「Web Authentication: An API for accessing Public Key Credentials – Level 3」（候補勧告スナップショット、2026年5月26日）　https://www.w3.org/TR/webauthn-3/