メインコンテンツへスキップ

Configure Conditional Access policies for developer platform access

Implementation Effort: Medium – Extending existing Conditional Access baselines with GitHub and Azure DevOps-specific policies requires coordination between identity and DevOps platform owners. User Impact: Medium – Developers accessing GitHub and Azure DevOps will face new device, location, and risk-based sign-in requirements, so that subset of users is affected. Lifecycle Stage: Govern

Overview

Configure Microsoft Entra ID Conditional Access policies for your GitHub and Azure DevOps environments to ensure only trusted users, devices, and sign-in conditions can access developer platforms.

This task assumes the Identity and Devices pillars have already defined enterprise Conditional Access baselines. This task extends those baselines with DevOps platform-specific settings.

Developer platforms such as GitHub and Azure DevOps are high-value targets because they provide direct access to source code, secrets, CI/CD pipelines, and deployment credentials. When these platforms are accessible from any device, any location, and without adaptive risk evaluation, a single compromised developer credential can give a threat actor the ability to inject malicious code, exfiltrate intellectual property, or pivot into production environments.

For GitHub Enterprise Managed Users: Configure OIDC with Microsoft Entra ID and use your IdP's Conditional Access Policy support for interactive access.

For GitHub with Personal Accounts: Use GitHub SAML single sign-on, token policies, and IP allow lists as complementary controls. Microsoft Entra ID Conditional Access applies to interactive sign-in, not to Git operations performed with long-lived PATs or SSH keys.

For Azure DevOps: Use its native Microsoft Entra ID integration to apply Conditional Access policies, including device compliance and phishing-resistant MFA requirements. Also govern personal access tokens by limiting scope and lifetime, disabling PAT creation where possible, restricting SSH where feasible, and reviewing OAuth or application connection policies. Use named locations for location-aware controls. If you use risk-based Conditional Access policies or Microsoft Entra ID Protection signals, those capabilities require Microsoft Entra ID P2.

For automation: Conditional Access applies to user sign-ins to the GitHub or Azure DevOps application. CI/CD automation should use least-privileged service principals or managed identities with OpenID Connect / workload identity federation where possible, and evaluate Conditional Access for workload identities separately where required. Avoid PAT-based automation wherever possible.

Enforcing adaptive access controls on developer platforms supports Verify explicitly, since every sign-in is evaluated against user, device, and risk signals before access to source code, pipelines, and deployment credentials is granted.

Reference