GitHub deleted 12,285 EMU accounts instead of suspending them: lessons for SCIM

GitHub has disclosed an error in its SCIM deprovisioning process that caused some Enterprise Managed User (EMU) accounts to be deleted rather than suspended and obfuscated. The issue occurred between 1 and 13 June 2026 and affected approximately 12,285 accounts across multiple enterprises. Their contributions could appear under a ghost user in issues, pull requests and audit logs.

GitHub says most of the accounts had already been suspended or hard-deprovisioned, while 76 were active at the time of deletion. In October, the company restored the records to the intended suspended and obfuscated state to preserve attribution and audit history. GitHub says no customer action is required.

Breachroad’s conclusion: no required vendor remediation does not mean no risk work for the customer. An organisation should document whether its enterprise was affected, check the completeness of relevant evidence and make sure an employee’s departure or role change results in a predictable state across connected services.

What happened

Enterprise Managed Users lets an organisation manage GitHub identities through an external identity provider. SCIM automates functions including account provisioning and deprovisioning after a user’s status changes.

GitHub explains that a new deprovisioning path failed to check correctly whether the target was an EMU account. It consequently performed a deletion instead of the suspension and obfuscation expected for EMU. The company disabled the problematic path on 13 June, corrected the mechanism and restored the records in October.

Customers can identify possible impact by looking for user.delete events involving EMU accounts in audit logs between 1 and 13 June. GitHub also notes that accounts previously hard-deprovisioned by design cannot be reprovisioned.

Why a ghost in history matters

In everyday work, a ghost entry may look like a user-interface inconvenience. During an investigation, audit or dispute about a production change, however, the lack of a clearly attributable author becomes a business problem.

Pull-request history helps establish who proposed a change, who discussed it and what context informed the decision. Issues record risk acceptance, exceptions, defects and customer agreements. An audit log is meant to connect an action to a controlled identity. When those elements lose their account association, it becomes harder to reconstruct the sequence, assign responsibility and demonstrate that controls worked.

GitHub’s record restoration is intended to rebuild that attribution. Organisations should still verify the result in their own context, particularly if they investigated an incident, exported logs to a SIEM or produced compliance reports containing ghost entries before restoration.

Who and which processes may have been affected

The direct scope is GitHub Enterprise Cloud customers using EMU and SCIM deprovisioning during the specified period. Indirect effects may reach:

• application and repository owners reviewing change history;
• SOC and incident-response teams using exported logs;
• internal audit and compliance when a report predates record restoration;
• HR and IAM if the leaver process treated identity-provider status as the only evidence of access removal;
• legal or product-security teams that depend on reliable attribution of earlier activity.

Not every enterprise using EMU was necessarily affected. The organisation’s audit log is a stronger basis for a decision than the fact that it uses SCIM.

What organisations should check now

1. Search the incident window

Review GitHub Enterprise logs for user.delete events affecting EMU accounts between 1 and 13 June 2026. Preserve the query result, time range, time zone and date of review. If logs are streamed to a SIEM, compare source data with the external copy.

2. Separate account state from activity history

Confirm that relevant accounts are now suspended and obfuscated as expected. Separately verify that earlier issues, pull requests and audit events once again show the intended association. A correct current account state does not automatically guarantee complete history in every export and report.

3. Assess the 76 active accounts in context

GitHub provided an aggregate number of active accounts deleted by the error; that does not mean every organisation owned one of them. If your enterprise was affected, establish whether the account was active and whether deletion disrupted work, an integration or resource access. Record whether the user received a replacement account and whether duplicate identities were created.

4. Revisit earlier investigations and reports

If a ghost entry informed an incident analysis, compliance report or change review between June and October, reassess the conclusion after data restoration. This is not a call to rewrite every report—only those where authorship or attribution could change the outcome.

5. Record the closure decision

GitHub does not require customer-side remediation. Even so, an internal record should state whether the organisation was affected, what evidence was checked and why no further steps are necessary. That trail is more useful than merely marking the vendor notice as read.

Strengthening SCIM and offboarding

SCIM automates an access decision, but it should not be the only source of assurance that the decision took effect. Critical services benefit from controls that confirm:

• the expected account state in both the identity provider and target application;
• removal of sessions, tokens, organisation membership and repository access;
• preservation of required activity history after deprovisioning;
• reconciliation between operations sent by the IdP and accepted by the service;
• handling of errors, retries and unusual delete events;
• a representative leaver test after a material integration change.

IAM owners should understand the distinction between suspension, obfuscation, soft deprovisioning and permanent deletion in each service. These concepts are not universal. The same SCIM command can produce a different business outcome depending on the provider’s implementation.

Questions for GitHub or an implementation partner

When findings are ambiguous, ask for:

• confirmation that a specific enterprise was or was not affected;
• the relevant account identifiers and expected post-restoration state;
• which views, APIs and exports regained author attribution;
• how to distinguish intentional hard deprovisioning from erroneous deletion;
• the restoration date and checks performed after the repair.

Do not request full personal details through a routine support ticket. Identifiers that the organisation can map securely within its own IAM system should be sufficient.

Source facts and Breachroad’s analysis

GitHub confirms the 1–13 June window, approximately 12,285 deleted accounts, 76 active accounts at deletion, the defect in a new deprovisioning path, its disablement on 13 June and the October restoration. The vendor identifies user.delete as the event to check and says customers need not take action.

Independent log verification, review of earlier reports, SCIM outcome controls and offboarding tests are Breachroad recommendations. They belong in an organisation’s privileged access management programme and incident response plan. IAM, HR, IT and security teams can rehearse shared decisions through cybersecurity training for organisations, while an IT security audit can test whether those controls work.

Primary source: GitHub Changelog — Enterprise Managed Users deprovisioning incident.