Selling an Apple Enterprise Developer Account With Apps: What Signing Materials Must Change Hands

With an enterprise account, the apps are a signing and distribution system, not a store listing

The Apple Developer Enterprise Program is meant for organizations that distribute apps internally. There is no App Store review and no public product page. So an enterprise account sold with apps should include the App IDs (bundle identifiers), IPAs signed by that team's certificate, the provisioning profiles, and a working way for employees to install and update. An account login plus a few IPA files, without the certificate private key and distribution setup, leaves you with packages you cannot update. If the goal is a public App Store release, an individual or organization account is the right type, not an enterprise one.

The private key is not at Apple, it sits on the Mac that created the CSR

Enterprise distribution certificates come from a certificate signing request, and the private key stays in the keychain of the machine that generated it. Apple's portal only holds the certificate. To keep building with the same certificate you need the exported .p12 file and its password. Without it you must issue a new certificate, which is not free of consequences: certificates are limited in number, and revoking an old one stops apps signed with it from launching on devices that already have them. Ask for the certificate's expiry date, whether the private key is backed up, who uses it, and how many times certificates have been revoked.

Team ID and bundle ID are bound, so re-signing under another team creates a different app

An app's identity combines its Team ID and bundle ID. Re-signing the same IPA with a new account's certificate makes the system treat it as another app. Keychain access groups, App Groups, push keys or certificates, and associated domains that depend on the Team ID all need reconfiguring, and users usually have to uninstall and reinstall, which can lose local data. So separate two kinds of delivery: transferring the account with its original Team ID, where the signing chain continues, versus handing over IPAs and source for you to re-sign. The second is not really apps delivered with the account, and should not be priced or risk-assessed as if it were.

Domains, servers and MDM are the parts most often left out of a handover

Internal apps reach devices through MDM or through an HTTPS download page with an itms-services link pointing to a manifest.plist. For MDM, check the platform account, enrolled device scope and the push certificate. For a download page, check the domain registrant, TLS certificate, the server hosting the IPA and who may edit the manifest. None of this lives in the Apple portal, yet it decides whether employees can install and update. List each item with its owner: domain, server, MDM admin, push certificate expiry. If something is missing, the contract should state who supplies it.

Compliance: enterprise certificates are for your own employees, and holder changes follow Apple's terms

The program permits distribution to the organization's own employees only. Using it to reach the public or outside customers is outside scope and can lead to certificate revocation or account termination. Enterprise accounts are also tied to an organization and a D-U-N-S number, so whether changes to the account holder or entity details are allowed, and which documents are required, depends on Apple's agreement and portal at that time. A seller cannot guarantee it verbally. Nothing here involves bypassing verification, hiding associations or falsifying documents; entity changes should go through Apple's official process by people with the authority to do so.

Pre-order checklist and when to stop

Confirm four groups of items. Account: Team ID, status, membership expiry, and control of the holder's contact email. Signing: distribution certificate expiry, the .p12 and password, profile expiry, and how many certificates are already in use. Apps: bundle ID list, IPA versions, source or at least a reproducible project, push and associated-domain settings. Distribution: MDM, domain and server access. A simple test works well: ask the seller to sign a fresh build with the existing certificate and profile before handover, and install it on a test device that launches normally. If they cannot, or if the certificate or profile expires soon with no renewal plan, pause the order. Fees and renewal rules are whatever Apple's portal shows at the time.