← Back to notes

Selling an Apple Enterprise Developer Account: What to Check on Account Holder, Two-Factor Auth and Recovery

An enterprise developer account transfer is not a login email change. Account Holder is tied to a legal entity, and two-factor and recovery settings decide who really controls it. Checks to run before you order.

Checklist for an Apple enterprise developer account sale covering Account Holder, two-factor authentication and recovery

There is no such thing as transferring an enterprise account by changing the email

The Apple Developer Enterprise Program is built for legal organizations. Enrollment normally verifies the organization's name, its D-U-N-S number, and that the applicant can act on its behalf. The account belongs to that entity, not to an Apple ID. Changing the login email, phone number or password swaps credentials, not ownership. If the buyer is a different legal entity, the entity usually cannot be changed on the existing account, and the buyer's organization typically has to enroll on its own. What can be done is an Account Holder handover inside the same entity. Rules change, so Apple's current pages and agreements decide, and the seller should say which case applies.

Account Holder decides who signs agreements, renews and manages members

The Account Holder is the person authorized to accept agreements, handle renewal and manage members and roles. It reflects the organization's authorization, not a title that can be passed around freely. Within one entity, the current Account Holder normally starts the transfer from the account, the recipient must already be a team member with authority to act for the organization, and Apple may ask for additional verification. Before ordering, confirm that the Account Holder shown in the portal matches the organization, that the current holder can log in live to show it, and that the recipient's identity and role fit the entity. A screenshot alone is not confirmation.

Trusted devices and phone numbers are the real control point

With two-factor authentication on, verification codes go to trusted devices or trusted phone numbers. If those stay with the seller, the buyer has the account in name only, and the seller may keep receiving codes. Check who controls the Apple ID email domain, who owns the trusted phone number, and which devices are signed in. A sound handover has the new holder trust their own devices first, then remove the old devices and numbers. Requests to turn two-factor off, or to keep forwarding codes to the seller, are not a normal handover. Stop there.

Settle recovery ownership before the handover

If a password is forgotten or trusted devices are lost, Apple's account recovery is a verification process with a waiting period. The length varies and success is not guaranteed. With a recovery key enabled, losing it along with every trusted device can leave no standard path back in. Recovery contacts work the same way. Confirm whether a recovery key exists and who holds it, whether a recovery contact is set and whether it is the seller, and whether backup emails and phone numbers now point to the buyer. If any of these still lead to the seller, there is a recovery route that bypasses the buyer.

Enterprise certificates are for internal distribution, so settle the use case first

The enterprise agreement limits apps to distribution and use within the organization's own workforce. Using an enterprise certificate to distribute to the public, to sign for third parties, or to avoid App Store review breaks the agreement, and when a certificate is revoked every app signed with it stops working. So ask what the account is for. If the goal is App Store release or public distribution, look at an individual or organization developer account instead. If the use is truly internal, the buyer's entity still needs to qualify for the enterprise program, and a working login alone does not show that.

Pre-order checklist and when to stop

Confirm these items one by one: the entity name matches the D-U-N-S record; the Account Holder can log in live; trusted devices, phone numbers and email can move wholly to the buyer; the inventory of certificates, profiles, push keys and MDM configuration; the renewal date and who pays; whether existing apps or internal builds sit under the account. Stop if the seller cannot show the Account Holder in the portal, wants codes to keep going to the seller, cannot explain the account's purpose or the purpose involves public distribution of enterprise certificates, or refuses to put fees, renewal and certificate responsibility in writing. Account status and fees change, so Apple's current pages are the reference.

FAQ

Do existing certificates and apps stop working when the Account Holder changes?

A role transfer by itself does not normally invalidate existing certificates, but list who created each certificate, profile and push key and who may reissue it. After the handover, the new holder should log in and confirm access to those assets before deciding on any reissue.

Can an enterprise developer account be used to publish on the App Store?

No, it is not the right account type. The enterprise program is for internal distribution, and App Store release normally uses an individual or organization developer account. If the app is for the public, change the account type rather than looking for a workaround.