The News, Explained
On October 23, 2026, GitHub disclosed an error involving enterprise-managed accounts and its restoration work. The error occurred June 1–13; GitHub says it restored affected account records in October. Accounts meant to remain suspended with identifying details obscured were deleted, leaving ghost-user attribution in issues, pull requests—proposed code changes—and audit logs. Source
Enterprise Managed Users, or EMU, are GitHub accounts whose creation, authentication and access are controlled through a company’s external identity system. SCIM is the standard used to pass account-lifecycle changes, such as provisioning or removing access, between systems. This disclosure concerns enterprise accounts managed that way. Source
Normal deprovisioning blocks access while retaining an account record. Obfuscation replaces the recognizable username with an obscured value. GitHub’s documented access-removal options and this incident’s restoration have different consequences: Source
| Case | Access and account records |
|---|---|
| Soft deprovisioning | Access is suspended; reactivation is possible under conditions including the same external identity account |
| Hard deprovisioning | Suspension cannot be reversed; renewed access requires a new account |
| This incident’s restoration | GitHub reports returning account records to their expected suspended, obscured state |
The first two rows describe normal documented behavior; the last describes the incident response. The restriction on reactivating hard-deprovisioned accounts remains in place. Restoring records helps trace earlier activity to its account, while renewed access depends separately on how that account was deprovisioned. Source Source
GitHub reports approximately 12,285 affected accounts across multiple enterprises. Most had already been suspended and hard-deprovisioned; 76 of the affected accounts were active when deleted. The company attributes the error to a processing path introduced June 1 that missed the managed-account check. It disabled that path June 13 to contain the problem. Source
GitHub’s impact criterion combines account type and dates: an enterprise audit log containing a managed-account user.delete event during June 1–13. An audit log records enterprise activity, and this event denotes user deletion. GitHub says it is handling restoration, with no separate remediation action required from enterprise owners. Source
OYOPICK’s Take
Keeping a record of who acted while removing their access supports trust in a collaboration tool. We would read this restoration as recovery of suspended account records and audit traceability. Separately identifying the 76 accounts active at deletion also helps readers distinguish cases by their access state.
We hope a follow-up explains that active subset’s access state after restoration. The current notice gives no separate outcome for that group. Reporting record attribution and access state separately could help administrators compare the recovery with their existing account policies.