Signing files do not decide app ownership
Buyers often treat 'are the certificates and profiles included' as the first acceptance test for an account with a live app. That order is off. Ownership comes from the app record in App Store Connect, its Bundle ID and the account's Team ID. Certificates and profiles are signing tools: if lost, they can be recreated, and holding them proves nothing about owning the app. Confirm the app record exists under the account first, then look at signing.
Check the app record, Bundle ID and Team ID first
Ask the seller to show items you can cross-check: the app name and Bundle ID in App Store Connect, the current version status (on sale, removed or otherwise), and the Team ID and account type (individual or organization) in the developer portal. The Bundle ID must match the live app exactly, and the Team ID must belong to this account. If the app was moved in from another account, ask whether the transfer fully completed and no pending state remains. Exact fields and screens depend on Apple's portal at the time.
Distribution certificates: can they be rebuilt, not who holds the private key
An Apple Distribution certificate needs its private key, usually exported as a .p12, to sign on a given Mac. The previous owner's key may not be handed over, and that is not itself a red flag. A missing or unusable certificate can be revoked and recreated inside the account, and the version already live on the App Store stays up. What you need to know is whose certificates exist, whether CI or contractors still use them, and what breaks if one is revoked. Certificate counts are capped, so check Apple's current limits and do not let anyone mass-revoke for a tidy handover.
Provisioning profiles regenerate; the enabled capabilities matter
A profile combines an App ID, a certificate and, for development or Ad Hoc builds, devices. If it expires or breaks, you regenerate it in the portal. What deserves checking is the capability list on the App ID: push notifications, Sign in with Apple, associated domains, App Groups, in-app purchase. If one is missing, new builds can fail at signing or at runtime. Have the seller export or screenshot the capability list and compare it against what the live app really uses.
What sits outside certificates: push keys and third-party credentials
The most common handover failure is push suddenly stopping. Servers typically use an APNs auth key (.p8), downloadable only once at creation. If a backend still uses the old key and someone revokes it, push breaks immediately. The same applies to Sign in with Apple keys, server notification settings for in-app purchases, and third-party SDK credentials tied to a Team ID or Bundle ID. Before ordering, ask which servers use these today, whether they continue after handover, and who handles the switch.
Pre-order checklist and when to stop
Check in this order: account type and Team ID, app record and Bundle ID, live version status, existing certificates and who uses them, App ID capabilities, who uses push and sign-in keys, and whether agreements, banking and tax status look normal. Pause if the seller cannot show the app record, if the Bundle ID or Team ID does not match, if there were recent rejections, removals or unresolved appeals that go unmentioned, or if anyone claims that handing over a certificate equals handing over the app. Membership status, fees and review behavior change over time, so treat Apple's current pages as the authority.
FAQ
Can I still update the app if the seller will not share the .p12 private key?
Usually yes. With proper account access you can create a new distribution certificate, regenerate profiles and sign updates with it. Just confirm that no other build system depends on the old certificate.
Does revoking a certificate take a live app off the App Store?
Generally no. The version already on the App Store stays available. What breaks is new builds and automation that rely on that certificate. Enterprise in-house distribution works differently and needs separate checks.