Removing a Dead iCloud Account on a Pre-T2 Mac

(Mac Pro 2013 / Non-Secure Enclave Macs)


⚠️ Scope

This guide applies only to pre-T2 Macs (e.g., Mac Pro Late 2013).

These machines:

  • Do NOT have a T2 chip
  • Do NOT enforce hardware Activation Lock
  • Store iCloud / Find My bindings in macOS user & system databases

This will remove the local iCloud association without deleting the Apple ID account itself.


🧠 Understanding the Architecture

On pre-T2 Macs:

  • iCloud login state is stored locally in user databases
  • Find My relies on account tokens
  • There is no firmware-level enforcement

Removing the local databases clears the association from macOS.

This does NOT:

  • Delete the Apple ID account
  • Notify Apple servers
  • Remove the device from iCloud.com automatically

✅ Method 1 — Cleanest Way

1️⃣ Create a New Admin Account

System Settings → Users & Groups → Add Admin

Log into the new admin.


2️⃣ Delete the Original iCloud User

From the new admin:

System Settings → Users & Groups
Delete the old user completely
Choose: Delete the home folder

This removes the primary account binding.


✅ Method 2 — Manual Database Removal

If the affected account is itself an administrator, a separate admin account is not strictly required.

While logged into the same administrator account, remove the local iCloud account databases. After removal, log out and back in (or reboot) to force macOS to recreate a clean account state without the previous iCloud binding. This can be also done over SSH with the user logged out.

Replace user with the affected account:

doas rm -rf /Users/user/Library/Accounts
doas rm -rf /Users/user/Library/Application\ Support/iCloud
doas rm -rf /Users/user/Library/Application\ Support/CloudDocs

Removing an Inaccessible iCloud Account from a Pre-T2 Mac

In this case, the Apple ID associated with the Mac became permanently inaccessible due to a chain of events involving loss of a trusted device and subsequent loss of the trusted phone number. When the replacement number was issued, account recovery mechanisms tied to two-factor authentication were no longer accessible. Apple’s automated recovery process was unable to verify identity, and the account was ultimately locked without an available recovery path.

Following this, Apple Support was contacted directly. The guidance provided was that recovery would only be possible if access could be regained to any device already trusted by the Apple ID. Effectively, the instruction was to locate what was described informally as a “golden ticket” — meaning one of the previously authenticated machines capable of approving the password reset request.

This required initiating multiple recovery attempts in accordance with Apple’s prescribed process, with the expectation that a reset approval request would be delivered to a previously authenticated trusted device. During one such attempt, a password reset notification appeared on an employee’s personal Mac that was not believed to be actively associated with the Apple ID at that time. It is possible that the device had been authenticated under the account at some earlier point and later removed, though that status could not be conclusively determined. The notification was declined prior to escalation, which terminated that specific recovery attempt and eliminated what appeared to be the final viable authentication pathway available through standard account recovery procedures.

This created a material operational issue:

  • The Apple ID could not be authenticated.
  • Two-factor verification codes could not be received.
  • The device could not be properly signed out.
  • The organization had no recourse through standard support channels.

At the time the Apple ID was created, sharing a single Apple ID across a small organization was common practice and not explicitly restricted in the way current policies now discourage. The account structure predated more recent Apple security policy changes and stronger enforcement of device-based identity recovery.

Because this Mac Pro (Late 2013) is a pre-T2 system:

  • There is no Secure Enclave.
  • There is no hardware-enforced Activation Lock.
  • The iCloud association exists only at the operating system level.

The objective is not to circumvent ownership protections, but to restore administrative control of hardware that is legitimately owned by the organization, where the associated Apple ID is no longer recoverable due to account lifecycle changes outside the organization’s control.

Removing the local iCloud binding allows:

  • Continued use of owned hardware.
  • Reassignment to a new managed Apple ID.
  • Compliance with updated Apple ID best practices.
  • Or you can install FreeBSD and have fun!

This action is a corrective administrative measure resulting from legacy account configuration and loss of recovery factors, not an attempt to bypass security controls on restricted hardware.