GitHub’s managed-account restoration separates audit recovery from access recovery

What Changed

GitHub says a SCIM deprovisioning path incorrectly deleted managed accounts between June 1 and June 13, 2026. Approximately 12,285 accounts were affected; 76 were active when deleted. Others were mostly already suspended and hard-deprovisioned. The result was ghost attribution in issues, pull requests and audit logs. GitHub disabled the path on June 13 and reports restoring records to their expected suspended and obfuscated state in October. It says owners need take no recovery action. [1]

Why It Matters

Analysis An offboarding record serves two purposes: restricting future access and explaining past work. A successful check of one does not establish the other. Teams that filed an earlier unexplained-attribution incident can now compare that evidence with the vendor’s disclosure, without treating every ghost account as evidence of malicious activity.

For an internal review, keep three columns: the identity provider’s intended account state, the current GitHub state, and the historical attribution that investigators need. Record discrepancies individually. Bulk recreation would make that comparison harder and could introduce a separate access change.

Evidence & Uncertainty

The disclosure identifies affected enterprises through managed-account user.delete audit events in the June 1–13 window. It uses both “restoring” and “restored” wording. BriefSpire has not independently verified any tenant’s recovery; the statement is a vendor account of the incident. [1]

Analysis Priority is Important: the practical task is evidence reconciliation and targeted escalation, rather than an unsupported assumption of a current widespread outage.