※ この記事は、Retirement of Direct Exchange ActiveSync Certificate-Based Authentication by End of 2026 の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。
Exchange ActiveSync (EAS) の証明書ベースの認証 (CBA) を Exchange Online に直接行う方式の廃止を発表します。2026 年末までに、直接的な CBA 接続のサポートを終了します。その日以降、CBA を使用する EAS クライアントは Microsoft Entra ID を介して認証を行う必要があります。クライアント証明書を直接 Exchange Online に送信することはできなくなります。
即時適用として、新しいテナントがレガシー フローを使用できないようにブロックを展開し、最初から Entra ID フローのメリットを享受できるようにします。
重要: この変更は、Outlook Mobile やオンプレミスの Exchange Server など、他の Exchange Online の認証シナリオには影響しません。この変更は、Exchange Online に対して CBA を使用する Exchange ActiveSync (EAS) クライアント (ネイティブの組み込みモバイル メール アプリなど) に固有のものです。この廃止は、Exchange Online におけるレガシー認証パターンの排除によるセキュリティ強化の継続的な取り組みの一環です。
なぜ直接 EAS CBA を廃止するのか？
EAS の証明書ベースの認証は、組織がパスワードなしでモバイル デバイスのアクセスを許可するための方法として導入されました。クライアント証明書を使用して、高度にセキュアなパスワードレスのサインイン体験を提供します。CBA では、各ユーザーはテナントのルート証明機関によって検証された証明書を持ち、その証明書の公開キーを使用した TLS ハンドシェイクによって認証を行います。つまり、秘密キーやパスワードがネットワーク上で送信されることはなく、基本認証よりも安全な代替手段を提供します。この構成に関するこれまでのガイダンスはこちらにあります。
しかし、現在の Exchange への直接的な EAS CBA の実装はレガシー認証方式と見なされています。現在のフローでは、ユーザー証明書は MDM 構成中にモバイル デバイスにプッシュされます。ユーザーが EAS に接続してメールを同期する際、Exchange が証明書を受信し、後続のすべての処理と検証を自ら行います。
この設計には重大な懸念があります。クライアント自体が標準の OAuth アクセス トークンを取得しないため、最新の認証プラクティスから逸脱しています。また、Exchange は内部的な高権限メカニズムに依存してデータにアクセスします。さらに、Microsoft Entra ID はクライアントと Exchange Online 間の直接的な証明書ベースの認証を「レガシー認証」の一形態として分類しており、レガシー認証をブロックする条件付きアクセス ポリシーによってブロックされます。これにより、管理者はレガシー認証をすべてブロックするか、CBA を含めてすべて許可するかの二択を迫られることになります。
新しいモデルでは、他のクライアント アプリと同様に、EAS クライアントが Microsoft Entra ID に対して直接証明書ベースの認証を行うことが求められます。提案されるセキュアなフローは次のとおりです。
クライアントは検証のために証明書を Microsoft Entra ID に送信し、Microsoft Entra ID が証明書を検証して OAuth アクセス トークンをクライアントに返します。
その後、クライアントはこの OAuth トークンを Exchange Online に提示して認証を行います。
証明書認証を完全に Microsoft Entra ID に移行することで、管理者は特定のプロトコルに対する例外なく、すべてのクライアント アクセスに対して最新のセキュリティ制御とポリシーを統一的に適用できます。
この変更は、Exchange Online の認証スタックを最新化する継続的な取り組みの一環でもあります。過去数年間で基本認証などの旧式の認証方式を段階的に廃止し、最近では専用の ActiveSync CBA エンドポイント (マルチテナント向けの outlook-cba.office365.com、DoD 向けの outlook-dod-cba.office365.us、GCC-High 向けの outlook-cba.office365.us) を導入しました。これにより TLS 1.3 のサポートを追加し、セキュリティと信頼性を強化しています。Entra ベースの CBA を要求することは、この取り組みにおける次の論理的なステップであり、レガシー認証の排除における最後の残りのギャップの 1 つを解消するものです。
影響を受けるかどうかの確認方法
Exchange ActiveSync CBA を使用しているか Entra ベースの CBA を使用しているか不明な場合、確認する方法がいくつかあります。
まず、モバイル デバイス管理 (MDM) 構成を管理している担当者に確認してください。認証タイプが OAuth ではなく Certificate に設定されている場合、この構成を使用している可能性があります。
もう 1 つの方法は、Entra のサインイン イベント ログを確認することです。Exchange CBA を使用するリクエストは、クライアント アプリが「Exchange ActiveSync」として表示され、認証の詳細に証明書が使用されていることが示されます。以下は、Entra のサインイン ログ レポートでのフローの表示例です。
認証方法として「Certificate」が表示されます。
今後 1 週間以内に、Exchange CBA を使用しているテナントに対してこの変更に関するメッセージ センター投稿を送信する予定です。投稿が送信された後、この記事を更新します。
CBA 認証は意図的に構成する必要があるものであり、組織で構成していない場合、この廃止の影響は受けません。
Entra ベースの CBA への移行方法
Exchange ActiveSync で CBA を使用してモバイル デバイスのセキュリティを強化してきた組織があることを理解しています。スムーズな移行を確保するため、管理者は 2026 年末の期限よりも十分前に、デバイスを新しい Entra ID ベースの CBA 方式に移行する計画を今すぐ開始することをお勧めします。Entra CBA と EAS CBA の PKI および CA のセットアップは基本的に同じであるため、移行は簡素化されるはずです。以下は、移行を成功させるための主要な手順と考慮事項です。
- Microsoft Entra CBA をテナントで有効にする: 証明機関 (CA) が Microsoft Entra ID で構成されていることを確認します。少なくとも 1 つの CA と中間 CA が構成されている必要があり、各ユーザーは信頼された PKI から発行された証明書にアクセスできる必要があります。また、各 CA にはインターネットに公開された URL から参照可能な証明書失効リスト (CRL) が必要です。Microsoft は ドキュメントで Entra CBA のセットアップに関する詳細なガイダンスを提供しています。
- ユーザー証明書の準備: 各ユーザーのクライアント証明書に正しい ID 情報が含まれていることを確認します。Exchange ActiveSync クライアントでは、証明書にユーザーの Exchange Online でのルーティング可能なメール アドレスが含まれている必要があります。Subject Alternative Name (SAN) フィールドの Principal Name または RFC822 Name の値に含まれている必要があります。Microsoft Entra ID は RFC822 Name の値をディレクトリのプロキシ アドレス属性にマッピングします。詳細はこちらを参照してください。現在の証明書が直接 EAS CBA に使用されていた場合、この要件を既に満たしている可能性が高いですが、証明書の SAN にユーザーのメール アドレスが含まれていることを確認してください。
- デバイス構成の更新: モバイル デバイスが Entra ID に対して証明書認証を行う方法を計画します。多くの場合、デバイスのメール プロファイルや MDM/Intune デバイス構成プロファイルの更新が必要になる場合があります。新しいフローでは、変更をサポートするためにサードパーティのクライアント ベンダーとの連携が必要になる場合があります。クライアント証明書を使用した Entra (Azure AD) 認証の有効化に関する具体的な手順については、モバイル デバイスまたはメール アプリのベンダーにお問い合わせください。この機能が構成されると、ユーザーはサインイン時にパスワードを入力する代わりに、証明書の選択プロンプトが表示されます。
- テストと監視: 広範な展開の前に、パイロット グループのデバイスとユーザーで新しい Entra CBA ログイン フローをテストすることをお勧めします。Entra ID のサインイン ログと Exchange ActiveSync デバイス レポートを監視して、レガシー CBA 方式を引き続き使用しているデバイスを特定してください。古い方式を使用しているユーザーに積極的に連絡し、更新された構成への移行を支援してください。
- 廃止のタイムライン: 計画にあたっては 2026 年末の期限を念頭に置いてください。サービスの中断を避けるため、この日付よりも十分前に移行を完了することをお勧めします。その間、直接影響を受けるテナントにはメッセージ センターを通じて詳細を共有し、移行をサポートするためにドキュメントを必要に応じて更新します。
まとめ
直接 Exchange ActiveSync CBA を引き続き使用しているお客様には、Entra ベースの CBA への移行計画を今すぐ開始することを強くお勧めします。Microsoft Entra の方式は、証明書ベースでフィッシング耐性があり、パスワード不要という点で同等かそれ以上のセキュリティを提供するうえ、最新の認証エコシステムやセキュリティ制御との統合がはるかに優れています。この変更は、すべての Exchange Online 接続が最新のセキュリティ標準に準拠することを確保し、不必要な昇格された権限を持つ内部的な高権限トークンへの依存を排除することで、組織のデータを保護するのに役立ちます。
認証インフラストラクチャへの変更が困難であることを理解しているため、この移行のために 2026 年末まで長い猶予期間を設定しています。この期間を通じてガイダンスとサポートを引き続き提供します。これらのセキュリティ改善の導入にご協力いただきありがとうございます。共に、すべてのお客様にとって、より安全でセキュアな Exchange Online エクスペリエンスを実現しましょう。ご質問や Entra CBA のセットアップに関するサポートが必要な場合は、Microsoft サポート (Entra / Identity) またはアカウント チームにお問い合わせください。この移行をできるだけスムーズに進められるよう、サポートいたします。