Discover and remediate ungoverned developer platform accounts
Implementation Effort: Medium – Auditing every GitHub and Azure DevOps roster, then migrating, converting, or removing accounts, is a multi-step effort coordinated with platform and identity owners. User Impact: Medium – People behind orphaned or external accounts must move to governed identities or lose access, so the affected subset needs advance communication. Lifecycle Stage: Govern
Overview
Audit the membership rosters of every GitHub organization and Azure DevOps organization to identify accounts that do not map to a Microsoft Entra ID principal, then migrate, convert, or remove them.
Start by auditing your accounts: In Azure DevOps, compare the users list against your connected Microsoft Entra ID tenant. In GitHub Enterprise Cloud, use the audit log and Microsoft Entra ID SCIM provisioning logs to identify accounts created outside the governed identity flow. Once identified, evaluate each account individually. Some should be migrated to Enterprise Managed Users for human access or replaced with workload identities — GitHub Apps for GitHub automation and Microsoft Entra service principals or managed identities for Azure DevOps and Azure deployments — and others should be removed entirely.
Even after an organization integrates its developer platforms with Microsoft Entra ID, legacy local accounts and standalone identities often persist. These are accounts created before the Microsoft Entra ID integration, service accounts with platform-native credentials, bot accounts that were never linked to a managed identity, or personal GitHub accounts that developers linked to the organization before Enterprise Managed Users was adopted. Each of these accounts operates outside the enterprise identity perimeter. They do not honor Conditional Access policies, cannot be subject to access reviews, and will not be disabled when an employee offboards through HR-driven lifecycle workflows. For threat actors, these orphaned accounts are high-value targets because compromising one yields access that is invisible to the organization's security monitoring.
Partner and external collaboration is a common source of ungoverned accounts and deserves explicit attention. When a partner organization contributes to your code, the answer is not to add the partner's personal account as an outside collaborator — that creates exactly the kind of identity this task exists to remove. Instead, bring external contributors in through governed external identity: Microsoft Entra External ID B2B collaboration so the guest is represented by an Entra principal in your tenant, or Enterprise Managed Users where the platform supports managed guest collaborators. Governed external access can then be subject to Conditional Access, time-bound through access reviews and Privileged Identity Management, scoped to least privilege on only the repositories the partner needs, and automatically de-provisioned when the engagement ends. Treat any external contributor who is not represented by a governed Entra identity as an account to remediate, the same as an internal orphaned account.
Leaving unmanaged accounts in place undermines every upstream identity investment. Conditional Access, MFA, and PIM are only effective when there is no path around them.