Executive Phone Offboarding Checklist: Controls Beyond the Device

An executive can return a company phone and still retain access to company information. Browser sessions may remain valid, shared folders may still accept a personal identity, recovery numbers may still point to the former employee, and application tokens may continue to work after the device disappears from view. That is why a reliable executive offboarding process starts with identities and services, not with a remote-wipe button.

A public dispute between Apple and OpenAI offers a useful warning without proving the facts of any individual case. In a post dated 3 August 2026, OpenAI presented its account of litigation brought by Apple and described Apple's allegation that a former employee accessed Apple information after leaving. OpenAI disputed Apple's characterisation and argued that the access was residual and known to Apple personnel. Those are OpenAI's claims in an adversarial dispute, not an independent technical finding, a judgment, or evidence that Apple device management failed. The responsible lesson is narrower: organisations should design departure controls so that no employee, manager or administrator has to debate whether access after departure was authorised.

This guide is a security and governance checklist, not legal advice. Legal counsel, HR, information security, records management and system owners should determine the sequence when litigation hold, investigation, privacy law or employment obligations apply.

The control objective

Offboarding is complete only when the organisation can show that:

1. business records have a current corporate owner;

2. the departing person's accounts, sessions and recovery paths have the intended state;

3. managed devices and organisational data are handled under the correct enrolment model;

4. privileged secrets and delegated access have been reviewed;

5. required evidence was preserved before destructive action; and

6. a second readback confirmed that the controls propagated.

Collecting hardware is one task inside that control objective. It is not the objective itself.

Value object: the executive offboarding control sequence

The exact timing will vary, but the order matters. Use this sequence as a runbook skeleton and assign a named owner to every row.

For an immediate or contentious departure, compress the windows rather than reversing the order. Preservation, revocation and verification still need explicit owners.

1. Classify the phone and enrolment model correctly

The phrase “managed phone” is too vague for an operational ticket. Record whether the device is organisation-owned or personally owned, and identify the actual Apple enrolment method and management capabilities in use.

Apple describes User Enrollment as an enrolment method designed for bring-your-own-device programmes. Its deployment documentation says the organisation manages organisational accounts, settings and information while the user's personal account remains outside that administrative scope. That boundary is central to offboarding: an administrator should remove organisational access and managed data using the controls supported by that enrolment, not treat the employee's entire personal phone as corporate property.

Apple documents erase commands separately in its device-management guidance. A full “Erase All Content and Settings” action is a destructive device action and is not available for a device enrolled through User Enrollment. Therefore, “send MDM wipe” is not a universal instruction. The runbook must state the enrolled device class and the precise command that the organisation's device-management service is authorised and technically able to send.

For a corporate device, the organisation may have broader management authority, but it should still preserve required records and verify data transfer before erasure. For BYOD, the policy, consent and enrolment architecture must support removal of organisational data without claiming control over personal content.

2. Build an identity-and-data ownership map

Start with the authoritative corporate identity, then follow every path that can grant or recover access. The map should include:

• SSO and directory accounts;

• email, calendar and delegated mailbox access;

• corporate and personal cloud identities used for sharing;

• code repositories, infrastructure consoles and administrative groups;

• password managers, API keys, app passwords and signing certificates;

• device trust, VPN profiles and endpoint-management records;

• recovery email addresses, phone numbers and backup codes;

• assistants, delegates and shared operational accounts; and

• external collaboration links that do not require the corporate identity.

For each item, record who owns the business information, who can authenticate, who can recover the account and which administrator can verify revocation. A service that contains corporate files under a personal identity is not solved by disabling corporate SSO. It requires a controlled transfer, removal of the share, or another response approved by legal and security.

3. Use NIST as a control catalogue, not a claim about the incident

NIST Special Publication 800-53 Revision 5 is a catalogue of security and privacy controls. It does not report on Apple, OpenAI or any particular departure. Two controls are especially useful when designing the runbook.

AC-2, Account Management, addresses the creation, enablement, modification, disabling and removal of accounts, as well as notifications when users are terminated or transferred. In practice, that means HR status changes must reach the identity and system owners quickly enough for them to act, and shared authenticators must be changed when people leave a group that knows them.

PS-4, Personnel Termination, addresses disabling access, revoking credentials, retrieving organisational property and retaining access to organisational information previously controlled by the departing person. It supports a cross-functional process rather than a device-only checklist.

These controls define categories of work. They do not prescribe one universal sequence for every legal jurisdiction, device type or investigation. The organisation must translate them into its own owners, service inventory, retention rules and verification evidence.

4. Preserve before destructive action

A legal hold, investigation or regulatory requirement may change the order of work. Do not erase a device, delete an account or rotate away the only recoverable key merely because the departure ticket says “urgent.” The case owner should obtain a written decision on what must be preserved, who may collect it, where the evidence will be stored and when access can be restricted.

Preservation does not mean leaving production access open indefinitely. Security and legal teams can often preserve relevant logs or data while restricting interactive access. The important point is that the sequence is approved and recorded, not improvised by the first administrator who sees the ticket.

The same discipline protects personal information. On BYOD, collection should remain within the authorised corporate scope. If business records were mixed with personal material, the response needs counsel and a documented separation method rather than informal credential sharing.

5. Transfer business records without transferring identity

Executive departures often create pressure to keep an account active because documents, contacts, calendars or approvals have no successor. That is an ownership failure, not a reason to preserve the former employee's identity.

Before the final access window, transfer corporate document ownership, shared-mailbox responsibility, calendar administration, repository ownership and approval authority to named corporate identities. Record unresolved matters in a handover register. If later clarification is legitimately required, use an approved contact channel; do not reopen an old account or ask another employee to impersonate the departed user.

Where a service cannot transfer ownership cleanly, export or migrate the business records under an approved process and document the gap as a remediation item. The closing evidence should show both that the new owner can access the required material and that the old identity no longer controls it.

6. Revoke at the service layer

Possession of the phone and state of the service are different facts. Removing a management profile or collecting hardware may not terminate web sessions, OAuth grants, API tokens, application passwords, mail forwarding, delegated permissions or public sharing links.

At T-0, the offboarding coordinator should trigger service-side actions in the approved order. Disable the authoritative account, revoke sessions and refresh tokens, remove trusted devices, invalidate certificates, remove group and role memberships, review delegates and forwarding, and close external shares. Rotate shared or privileged secrets if the departing person knew them or if exposure cannot be ruled out.

Do not rely only on a task being marked complete. Query the identity provider and critical applications after the action. The evidence should state what the system reports now: active sessions, enrolled devices, role memberships, external links and recovery methods.

7. Handle privileged and high-risk departures separately

An executive may also be a board approver, treasury signatory, repository owner or cloud administrator. Privilege changes the blast radius and the evidence required.

For high-risk cases, establish one command channel with legal, HR, security and the business owner. Freeze non-essential changes, capture the authorised evidence set, revoke privileged paths, rotate secrets, inspect recent administrative activity and assign a second reviewer. If the person managed automation or service accounts, identify credentials embedded in deployment systems and scheduled jobs rather than rotating only interactive passwords.

The objective is not to presume misconduct. It is to remove ambiguity and protect both the organisation and the departing person with a controlled, reviewable process.

8. Verify twice and close with a receipt

Revocation can propagate unevenly across identity providers, mobile applications, caches and third-party integrations. Perform an immediate readback and a delayed readback. The second check should be performed by someone other than the person who executed the critical changes when the risk warrants it.

The final receipt should identify the case, authoritative identity, device and enrolment type, systems checked, evidence locations, unresolved exceptions, temporary-control expiries and reviewers. Avoid placing secrets or unnecessary personal data in the receipt. Link to protected evidence instead.

Common failure modes

• “The phone was wiped, so access is gone.” A wipe does not prove that cloud sessions, shares or tokens were revoked.

• “MDM can wipe every phone.” Capability depends on ownership, enrolment and policy; User Enrollment is specifically designed around a BYOD separation boundary.

• “The account is disabled, so the data is safe.” Personal identities, delegated access and public links can bypass the disabled corporate account.

• “Keep the account for handover.” Transfer business ownership to a current corporate identity and use an unresolved-item register.

• “NIST says this exact sequence is mandatory.” NIST provides control objectives; implementation and legal sequencing remain organisation-specific.

• “The OpenAI post proves what happened.” It is one party's published account of a disputed matter and should be labelled as such.

Reader-visible primary references

• OpenAI's 3 August 2026 statement about its dispute with Apple — used only to describe OpenAI's allegations and framing.

• Apple Platform Deployment: User Enrollment and device management — used for the BYOD and management-scope boundary.

• Apple Platform Deployment: Erase devices — used for erase-command terminology and the User Enrollment limitation.

• NIST SP 800-53 Revision 5, Update 1 — used for the status and scope of the controls catalogue.

• NIST SP 800-53 Revision 5 PDF — used for AC-2 and PS-4 control text.

Related VERTU reading

• iPhone vs Android privacy for executives

• Secure smartphone guide for high-net-worth individuals

These links provide adjacent device and privacy context. They do not replace the organisation's legal advice, device-management documentation or service-specific revocation procedures.

Final rule

Executive phone offboarding succeeds when business ownership has moved, identity and service access match the approved state, device actions respect the enrolment model, required evidence has been preserved and a second readback proves the result. If the team cannot produce that evidence, the departure ticket is not complete—even when the phone is back in the drawer.