Sharing a Purchased Apple Developer Account Across a Small Team

One person holding every credential is the most common failure mode after a purchase. I learned this the hard way when our first App Store release stalled for eleven days because the only person with the Account Holder login was on a flight with no Wi-Fi. Since then, our team of four has treated account access the way we treat production infrastructure: documented, distributed, and auditable. If you are about to Buy Apple Developer Accounts for a small engineering group, the decisions you make in the first week about roles and credential custody will determine whether that purchase becomes a reliable asset or a single point of failure.

This is not a legal or tax discussion. It is the practical, unglamorous work of splitting responsibility across a handful of people so that no vacation, resignation, or lost phone can freeze your releases.

Why a Purchased Account Concentrates Risk

When you register directly with Apple, the original signer usually becomes the Account Holder, and everyone else is added later as an Admin or App Manager. When you acquire an aged, verified, or organization account from a marketplace, that history is compressed. You inherit a structure that was built for one owner, and you may not know exactly which email addresses, phone numbers, or recovery methods are still attached.

That inherited structure is the risk. A single recovery email that nobody on your team controls can lock you out of App Store Connect during a certificate rotation. A phone number belonging to a former owner can intercept a two-factor prompt. The purchase itself is only half the job; the other half is re-architecting access so the account survives personnel changes.

I treat the first week after acquisition as a migration project. We inventory every identity attached to the account, decide who owns each one going forward, and remove anything we cannot verify. This is boring work, and it is the reason we have not had a release blocked by an access problem in two years.

Assigning Roles Before You Hand Out Credentials

Apple’s role model is more granular than most small teams expect. The Account Holder is the root identity: only that person can accept new agreements, manage the membership itself, and change certain legal details. Admin can manage users, certificates, and most App Store Connect functions. App Manager handles app-level metadata and submissions. Developer and Marketing roles are narrower. Finance manages agreements and banking.

For a team of three engineers plus me, we landed on a structure that avoids both over-sharing and bottlenecks. I hold the Account Holder role because someone has to own the legal relationship, and I am the one who signs agreements. One senior engineer is Admin so that certificate and provisioning tasks never wait on me. The other two are App Managers, which gives them everything they need to ship builds and edit metadata without the ability to alter the membership or remove users.

The temptation is to make everyone an Admin because it is faster. Resist it. Every extra Admin is another credential that can be phished, another person who can accidentally revoke a distribution certificate, and another account you must audit when someone leaves. Role assignment is not about trust; it is about blast radius.

Write the role map down somewhere outside App Store Connect. A shared document with names, roles, and the date each person was added takes ten minutes to create and saves an hour of guesswork during an incident.

Credential Custody: Who Holds What, and Where

The Account Holder login is the crown jewel, and it should not live in a personal password manager tied to one person’s phone. We keep ours in a shared vault with a break-glass procedure: two people hold halves of the recovery path, and the vault logs every access. That sounds dramatic for a four-person team, but the alternative is a situation where the only copy of the password is on a laptop that just got stolen.

For everyone else, credentials should be personal, not shared. Each teammate gets their own Apple ID added to the team, with their own two-factor authentication. Shared logins destroy accountability: if a build is submitted at 2 a.m. and something goes wrong, you want to know which human did it. Individual accounts also make offboarding a single removal action instead of a password rotation that touches everyone.

Two-factor authentication deserves its own paragraph. Apple requires it for most account operations, and the recovery path matters more than the second factor itself. Make sure the trusted phone number belongs to a device your team controls, not a former owner’s. If the account came with an unfamiliar recovery email, replace it during the first week. I keep a printed recovery code in a physical safe as a last resort, because cloud-only recovery has a way of failing exactly when you need it.

Certificates and provisioning profiles are a separate custody problem. We keep signing assets in a shared repository with restricted access, and one named engineer owns rotation. When that engineer is unavailable, the Admin can step in. Nobody else needs the private keys.

Offboarding a Teammate Without Breaking Releases

People leave. Sometimes they leave well, and sometimes they leave on a Friday with a laptop they have not returned. Your process should work the same way in both cases.

The moment a departure is confirmed, the Admin removes the person from App Store Connect. This immediately invalidates their access to certificates, metadata, and builds. Next, rotate any shared secrets they could have seen: signing certificates if they had access to the private keys, API keys for any CI integration, and the shared vault entry if they ever viewed it. Then check the account’s user list for anything they added without telling you, which is a real pattern when someone anticipates a departure.

Do not forget the less obvious paths. TestFlight external tester lists, App Store Connect API keys, and any third-party analytics or crash reporting tools connected to the account can all carry access that outlives a removal from the main user list. We keep a one-page checklist of every integration tied to the account precisely so offboarding does not depend on memory.

If the departing person was the Account Holder, the process is heavier. Apple’s own transfer process applies, and it is worth starting it before the person’s last day rather than after. This is the strongest argument for keeping the Account Holder role with someone who is not planning to leave: founders, not contractors.

Audit Habits That Keep the Account Healthy

We run a quarterly review that takes about twenty minutes. We open the Users and Access page and compare it against our role map. Anyone who should not be there gets removed. Anyone whose role has drifted gets corrected. We check that the trusted phone number and recovery email are still ours, that no unknown API keys exist, and that the certificates we think are active actually are.

We also review the account’s agreement status and any pending Apple notices. Missing an agreement renewal is a quiet way to lose the ability to ship, and it is exactly the kind of thing that gets overlooked when everyone assumes someone else is watching.

The audit habit matters more than the audit itself. Teams that review access only after an incident tend to have the same incident twice. Teams that review on a schedule catch drift while it is still cheap to fix. If you bought an aged or organization account from a reseller, your first audit should be unusually thorough, because you are verifying someone else’s history as well as your own.

Questions I Get From Other Small Teams

Can two people share the same Apple ID for the developer account?

Technically yes, and practically you should not. Shared logins break the audit trail, make two-factor recovery fragile, and turn offboarding into a password reset for everyone. Add each teammate as an individual user with their own role instead. It costs nothing and preserves accountability.

What happens to our apps if the Account Holder disappears?

This is the scenario the whole governance model exists to prevent. If the Account Holder is unreachable and no transfer was arranged, recovery becomes a slow process involving Apple support and whatever proof of ownership you can produce. Keep the Account Holder role with someone stable, document the recovery path, and consider a break-glass arrangement so at least one other trusted person can act if needed.

How many Admins should a small team have?

Two is usually right: the Account Holder plus one other. That gives you redundancy for certificate and user management without spreading root-level access across the whole team. Everyone else can ship effectively as an App Manager. If your team grows past ten people, revisit the structure rather than adding Admins by default.

Should we change credentials immediately after buying a used account?

Yes, and not just the password. Replace the recovery email, verify the trusted phone number, review the full user list, revoke unknown API keys, and rotate signing certificates if the previous owner had access to them. Treat the first week as a security migration, not a formality.

None of this is glamorous, and that is the point. A purchased developer account is infrastructure, and infrastructure deserves the same discipline you apply to servers and secrets. Assign roles deliberately, keep credentials with the right people, write down your offboarding steps before you need them, and audit on a schedule. Do that, and the account stops being a liability tied to one person’s phone and starts being a dependable part of how your team ships.