Three different items: verify membership, clean up members, rebuild certificates
Sellers often bundle these into a single promise of a full handover, but they are different things. Membership status is a current fact you check, not something delivered. Team members are an access surface that should end up containing only people you recognize. Certificates are signing credentials, and Apple stores only the certificate, never the private key, so an old certificate is worth little to a buyer. Listing the three separately in your acceptance checklist works better than asking for everything.
Membership status: check four fields, not just whether login works
Being able to sign in to developer.apple.com does not mean the membership is active. Check that the membership is within its term, the expiry date, the auto-renew setting, whether the account is individual or organization, and the Team ID. If membership lapses, live apps may be removed from the App Store and new builds cannot be submitted, though the exact rules are whatever Apple's pages and agreements say at that time. Also confirm who the Account Holder is, since agreements, renewal and some settings can only be handled by that role. Whether an account can be transferred under Apple's current terms is worth asking the seller before you order, not after.
Team members: the usual risk is nobody knowing who still has access
Aged accounts often carry former employees, contractors or people who have long since left. In App Store Connect under Users and Access, go through each person: role (Admin, App Manager, Developer or a read-only role) and whether the email belongs to someone known. Admin and above can manage users and certificates, so they carry the most risk. Also check the API keys under Integrations. They are separate from passwords and may keep working after a member is removed, so revoke and recreate them. The Apple Account email, phone number and trusted devices used for two-factor verification should be replaced too, or the previous holder may still receive the codes.
Certificates: where the private key lives decides whether the old one is useful
The private key is created in the keychain of the Mac that generated the signing request. Apple's portal lets you download the certificate but not the key. When a seller says the certificates come with the account, the only usable form is an exported .p12 file, and that file contains the private key, so sending it through a chat tool is itself a leak risk. A safer approach is to accept no old private keys and generate new distribution certificates and profiles on your own machine after handover. Old certificates that occupy slots can be revoked, but first confirm the seller's CI, ad hoc distribution or in-progress builds do not depend on them. Apps already live on the App Store are generally not affected by revocation, but verify against your actual account.
Accounts with existing apps: credentials harder to rebuild than certificates
If the account comes with apps, certificates are not the only concern. APNs keys (.p8) can be downloaded only once at creation, so a lost one must be recreated, and the server configuration has to be updated or push delivery stops. Sign in with Apple keys, associated domains, app groups, in-app purchase and subscription setups are all tied to the team. During acceptance, have the seller list the capabilities each app uses and who controls the matching backend. If the backend stays with the seller, agree either to hand it over or to have you rebuild it with time reserved for the switch. Do not discover this on the day you need to ship an update.
A checklist before ordering, and when to stop
Write the acceptance items as things you can check: the Membership page shows active with a clear expiry date; Account Holder login and two-factor verification have been moved to you; the member list contains only confirmed people; App Store Connect API keys are revoked or recreated; certificates are newly created by you rather than relying on old private keys; for accounts with apps, bundle IDs and capability lists are reviewed. Pause if the seller cannot show the real state of the backend, asks for payment before explaining members and credentials, insists you accept a .p12 of unclear origin, or the member list contains an Admin nobody can explain. Fees, review and account rules change, so rely on Apple's pages at the time.