Microsoft Entraが2026年6月、FIDO2パスキーの組織展開を支援する「Registration Campaigns」機能を一般提供開始した。管理者はサインイン時にパスキー登録を促すキャンペーンを設定できるようになり、フィッシング耐性認証の普及に向けた現実的な移行パスが整備された。あわせてLinux向けフィッシング耐性MFAのGA、App Deactivation機能の追加など、ゼロトラスト戦略の土台を固める複数のアップデートが加わった。

パスキー普及の「最後の1マイル」を埋めるRegistration Campaigns

FIDO2パスキーが優れた認証方式であることは広く知られているが、実際の組織展開で最大の壁となるのが「既存ユーザーへの登録誘導」だ。Registration CampaignsはサインインフローのUI内で自然な形でパスキー登録を促せる設計で、強制することなく段階的な普及を後押しできる。

Windows HelloのデバイスバウンドパスキーはMicrosoft Entra参加・登録済みデバイスでなくても利用可能で、生体認証やPINによるフィッシング耐性サインインが実現する。ただしWindowsのインタラクティブコンソールサインインはサポート対象外のため、既存の展開シナリオとの整合性確認は必要になる。

Linux向けフィッシング耐性MFAが一般提供開始

Microsoftのidentity brokerを通じたLinuxデスクトップ向けフィッシング耐性MFAが一般提供（GA）になった。対応ディストリビューションはUbuntu 24.04/26.04およびRHEL 8/9/10で、WindowsとmacOSに続きLinuxも同水準のフィッシング耐性MFAを利用できる環境が整った。

クラウドネイティブな開発環境でLinuxを使うエンジニアが多い日本のエンタープライズ企業にとっては待望のアップデートだ。CI/CDパイプラインやクラウドシェル環境でのMFA強化に直結する。

ガバナンス強化：孤立アカウント検出とApp Deactivation

ガバナンス面でも実用的な機能が複数追加された。

孤立アカウントの自動検出（Discovery Reports） 接続済みアプリケーション内のすべてのアカウント（孤立アカウント含む）を可視化するレポート機能。アクセス権のギャップ特定やアプリケーションオンボーディング支援に活用できる。Microsoft Entra ID GovernanceまたはEntra Suiteが必要。

App Deactivation アプリケーションを削除せずに無効化できる機能。セキュリティ調査中の不審アプリ停止や、設定データを保持したまま一時停止したいケースに対応する。無効化されたアプリは新規アクセストークン取得もサインインも不可になる一方、設定・権限・メタデータは保持される。後からの再有効化も可能で、完全削除と異なり「証跡を残しつつ止める」用途に向いている。

テナント間セキュリティグループ同期 複数のEntraテナントをまたいでセキュリティグループとメンバーシップを同期できる。M&Aや企業グループ内IT統合のシナリオで有効な手段が増えた。

Azure AD B2C移行支援：500万オブジェクト以上の大規模移行に対応

High Scale Compatibility（HSC）モードにより、500万オブジェクト以上を持つ大規模なAzure AD B2Cテナントが、ユーザーの再登録やパスワードリセットなしにMicrosoft Entra External IDへ移行できる。B2CポリシーアナライザーでGA移行準備を評価した上で、アカウントチームと連携して進めることが推奨されている。

パブリックプレビュー：ドメインレスSAML連携と秘密度ラベル

パブリックプレビューに入った機能のうち特に注目したいのが2つだ。

ドメインレスSAML連携 外部ユーザーがメールドメインのマッチングなしに、自社IdP（アイデンティティプロバイダー）の認証情報でサインインできるようになる。従来の制約が緩和され、パートナー企業やサプライヤーとのフェデレーション設計が柔軟になる。

EntraセキュリティグループへのMicrosoft Purview秘密度ラベル M365のラベルポリシーをEntraセキュリティグループにも適用可能になる。ゲストアクセス制御を含むグループ設定のガバナンスをMicrosoft Purviewと統合して管理できる。

実務への影響

パスキー展開を検討している管理者へ Registration Campaignsは強制ではなく「促す」設計のため、ユーザー体験を損なわずに移行を進められる。まずパイロットグループにキャンペーンを設定して登録率を測定し、全展開の可否を判断するアプローチが現実的だ。

Linux環境のセキュリティ担当者へ 対応ディストリビューション（Ubuntu 24.04/26.04、RHEL 8/9/10）を確認し、identity brokerの導入を優先検討すべきだ。開発環境全体でフィッシング耐性MFAを適用できるかどうかは、ゼロトラスト戦略の実効性に直結する。

マルチテナント管理者へ テナント間グループ同期を活用する場合、どのテナントをマスターとして管理するかのガバナンスポリシーを先に決めておくことが重要だ。技術的な機能が整備されても、運用ルールが曖昧なままでは混乱が生じやすい。

筆者の見解

今回のEntraアップデート群を見ると、Microsoftがアイデンティティ基盤に着実にリソースを投じていることが伝わってくる。特にRegistration Campaignsによるパスキー誘導は、「理想の認証方式を現場に浸透させる」という現実的な課題に正面から向き合った実装で、評価できる。

ゼロトラスト戦略においてアイデンティティが土台であることは言うまでもない。生成AIエージェントが組織内で動き始める中、Non-Human Identities（NHI）の管理と人間のアカウント管理を統合的に扱えるプラットフォームの重要性はさらに高まっている。EntraがそのコントロールプレーンとしてAgent IdentityのSponsorship管理まで備え始めているのは、長期的に見て正しい方向性だと思う。

一方で、毎月これだけ多くの機能が追加され続けると、現場のIT管理者が「何から手を付けるべきか」を見失うリスクも出てくる。機能の充実と、それを実際に使いこなすためのドキュメントや移行支援の充実は、必ずしも同じペースでは進まない。Microsoftには機能を増やすことと同じくらいのエネルギーを、その伴走支援に向けてほしいと、長年利用してきた立場から率直に思う。

Linux向けMFAのGA、App Deactivation、テナント間グループ同期——いずれも地味に見えて、実際の現場では「あれ、これできないんだっけ」と困るポイントを埋める機能だ。そういった堅実な積み上げがEntraへの信頼を支えている。

出典: この記事は Microsoft Entra pushes passkeys, tightens identity security の内容をもとに、筆者の見解を加えて独自に執筆したものです。