GitHub EMU Users Appearing as Ghosts: How to Check the June Deletion Incident
An offboarded employee’s old issues now show a ghost author, and the recent audit log shows no deletion. How do you confirm whether the June incident hit that account?
- The June incident left some Enterprise Managed Users appearing as ghosts in historical activity.
- Identify affected accounts through the specified deletion events, not the display name alone.
- Restoring a suspended record does not reactivate an offboarded user.
Use the account type and deletion event to identify the incident
GitHub’s October 23 notice describes a June SCIM deprovisioning fault affecting Enterprise Managed Users. Some accounts were deleted rather than left suspended with their identifying information obscured. Issues, pull requests and audit logs consequently showed ghost users.
GitHub’s test for impact is a user.delete event for a managed account during the stated window. The company says it restored the expected suspended records in October and requires no action from enterprise owners. This is a repair to historical identity records, not an instruction to provision replacement accounts.
Specify dates: June is outside the default view
The enterprise audit log documentation distinguishes retention from the initial view. Ordinary audit events are retained for 180 days, but only the past three months appear by default. On October 26, the June incident therefore requires an explicit date range.
An enterprise owner can narrow the search with this example, constructed from GitHub’s action and date filters:
action:user.delete created:2026-06-01..2026-06-13Check that returned events concern managed accounts. An empty recent-events screen is not the same as an empty search covering the incident. Likewise, the word “ghost” alone does not identify the cause of an account’s disappearance.
SCIM distinguishes restoring access from retaining a record
Under normal deprovisioning behavior, the managed account is suspended rather than deleted. Whether that account can later be reinstated depends on the request GitHub receives from the identity provider.
| Deprovisioning type | Enterprise access | Reinstatement |
|---|---|---|
| Soft | Suspended | Possible through SCIM in supported circumstances. |
| Hard | Suspended | The account cannot be reinstated. Returning users need a newly provisioned account. |
Do not use a historical-record repair as the procedure for returning an employee to work. The person’s access request and the enterprise’s need to retain activity attribution are separate tasks.
A retained account record does not preserve every repository
The current SCIM documentation says hard deprovisioning deletes user-owned repositories while retaining resources such as comments. Account-record retention is therefore not a promise that a personal namespace repository will survive offboarding.
For an offboarding check, separate the deprovisioning type, attribution on issues and pull requests, and user-owned repository handling. Use the dated audit query to establish incident impact, then apply the relevant SCIM rules to access and repository questions.