<style> .pp-hero{padding:clamp(24px,5vw,46px);border-radius:24px;background:linear-gradient(130deg,#0f172a,#1e40af 55%,#0f766e);color:#fff}.pp-hero h2{color:#fff}.pp-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.pp-card{padding:18px;border:1px solid #bfdbfe;border-radius:16px;background:#eff6ff}.pp-card strong{display:block;color:#1d4ed8;font-size:1.3rem}.pp-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:10px;margin:22px 0}.pp-step{padding:16px;border:1px solid #99f6e4;border-radius:15px;background:#f0fdfa}.pp-step b{display:block;color:#0f766e}.pp-table{overflow-x:auto}.pp-table table{min-width:690px;width:100%;border-collapse:collapse}.pp-table th,.pp-table td{padding:11px;border:1px solid #cbd5e1;text-align:left;vertical-align:top}.pp-table th{background:#dbeafe}.pp-note{padding:18px;border-left:5px solid #f59e0b;border-radius:12px;background:#fffbeb;margin:20px 0}@media(max-width:720px){.pp-grid,.pp-flow{grid-template-columns:1fr}} </style>

SECURITY / 2026年9月24日発表

「ログイン済み」だけで、高リスク操作を許さない

GitHub EnterpriseのProof of Presenceは、トークン作成やWebhook変更などの直前に、企業のIdPへ戻して本人確認を要求します。盗まれたセッションの悪用を抑える追加層です。

3行要約

• GitHubは2026年9月24日、Enterpriseの高リスク操作に追加の再認証を要求できる「Proof of Presence（PoP）」を公開プレビューで発表しました。
• 発表時点の対象は、Microsoft Entra IDをSAMLまたはOIDCのSSOに使うEnterprise Managed Users（EMU）のEnterpriseです。
• 認証に成功すると、そのブラウザーセッションでは2時間、高リスク操作を続けられます。MFA設定を選んでも、IdP側のポリシー確認が重要です。

背景：有効なセッションが本人とは限らない

ブラウザーのセッションCookieや長期トークンが盗まれると、通常のログイン済み状態だけでは本人と攻撃者を見分けにくくなります。とりわけ新しいトークンの作成、Webhookの編集、組織のセキュリティ設定変更は影響が大きい操作です。GitHubのPoPは、その瞬間に企業のIDプロバイダー（IdP）で再認証を求め、既存セッションだけでは先へ進めないようにします。

何が新しいのか

PoPはGitHubの既存の「sudo mode」を企業向けに拡張します。対象操作を試みるとGitHubがIdPにリダイレクトし、指定した認証要件を満たした後に操作へ戻ります。選択肢は、IdPでの再認証と追加のMFA（多要素認証）です。GitHubの発表は、後者では認証アプリや生体認証など、IdP側で設定した追加要素を要求できるとしています。

対象例はGitHubの発表とsudo modeのドキュメントに基づきます。プルリクエストのマージ前にもPoPを要求する機能は「今後対応予定」で、現時点の対象として数えてはいけません。

管理者向け導入手順

1. Enterpriseが今回の公開プレビュー対象か確認します。9月24日の発表ではEMUとEntra IDの組み合わせに限定されています。GitHubの一般ドキュメントはより広い構成の説明も含むため、実際の管理画面で提供状況を確かめてください。
2. Enterpriseの設定から「Authentication security」を開き、「Proof of presence」で再認証かMFAを選びます。
3. Entra ID側で、求める認証強度、デバイス条件、失敗時の復旧経路を確認します。「再認証」だけではIdPの設定によってパスワードで満たせる場合があります。
4. テスト用アカウントで対象操作を行い、リダイレクト、成功、失敗、期限切れ後の再チャレンジを確認します。

これらはGitHubの設定手順に、導入前の運用検証を加えた編集部案です。IdPの障害時に管理者が作業できなくなる可能性も考え、変更手順と復旧担当を決めておくべきです。

企業・開発者への影響

PoPにより、ブラウザーセッションを持つだけの第三者やエージェントが高リスク設定へ進むことを難しくできます。ただし、正当なユーザーがフィッシングで認証を通してしまうリスクまではなくなりません。またPoPはパスワード・MFA、トークン管理、最小権限、監査ログを置き換えるものではありません。

リスクと限界

• 公開プレビューのため、対象構成や挙動は変更される可能性があります。
• 2026年9月24日の発表はEMU＋Entra IDへ限定しています。すべてのGitHub Enterpriseアカウントで直ちに使えるわけではありません。
• IdP側の条件付きアクセスポリシーが弱ければ、求める本人確認強度にならない場合があります。

今後注目すべき点

対象IdPやアカウント形態の拡大、プルリクエストのマージへの対応、監査イベントと運用上の例外管理が注目点です。正式提供までは管理画面と最新ドキュメントを確認しながら試験導入するのが妥当です。

最終確認日：2026年9月26日

参照元（一次情報）

• GitHub Changelog：Require proof of presence for high-impact actions（2026年9月24日）
• GitHub Docs：Configuring Proof of Presence
• GitHub Docs：Sudo mode