Prefer an App Store Connect API key wherever your tools support it. It is a revocable, role-scoped credential made for automation, while an Apple ID password drags in two-factor workarounds and a person's full access. Use a team key with the narrowest role that still lets the lane do its job.
The two ways CI can authenticate
The fastlane documentation describes the history. Its tools have long used an Apple ID with username and password and a cookie-based web session. The docs say to use API key authentication when you are able to, and list the benefits: no 2FA needed, better performance, a documented API and increased reliability.
An API key is a .p8 private key file plus a key ID and an issuer ID, which together are used to create a JSON Web Token for authorization. The fastlane example sets a token duration, and the documented maximum is 1,200 seconds, so the token is short-lived even though the key is not.
Compare the options
| Question | Apple ID and password | API key |
|---|---|---|
| Two-factor handling | Needs pre-generated sessions or app-specific passwords | Not needed |
| Tied to a person | Yes | Team key: no. Individual key: yes |
| Scope | Everything that user can do | The role you pick |
| Revoking | Change the password and sessions | Revoke the key |
| Tool support | Broadest | Most tools, but not all |
On that last row, the fastlane table of supported tools shows API key support for most actions, but not for every one. For example, it lists produce as partial and pem as not supported. Check your lanes before switching.
Team key or individual key
The documentation recommends a Team key and states it is required for any provisioning-related API access. The two types differ:
- Team keys have access to all apps, with levels set by the selected role.
- Individual keys take the access and roles of the associated user, and cannot use provisioning endpoints, sales and finance data, or the notary tool.
An individual key tied to a person is also a bus factor problem: when that person leaves, the pipeline can break.
Setup steps that protect you
- Create the key from the Users and Access area under the Integrations tab. If you do not see the tab, you lack permission and an account holder must grant it.
- Choose a role for the task at hand, not a default of the highest one.
- Download the
.p8immediately. The docs say it cannot be downloaded again after the page is refreshed. - Put the file contents, key ID and issuer ID into your secret manager as separate entries.
- Load them on the job only for lanes that talk to the store.
- Rotate on a schedule and whenever someone with access leaves.
What not to do
If you must keep an Apple ID for a legacy tool, give it its own shared account and not a person's login, use app-specific passwords where the docs say they are needed, and never commit the password into the repo or Fastfile. The fastlane CI page lists the variables for these cases, and our post on fastlane variables to treat as secrets covers them.
Where Safeguard fits
Safeguard does not issue or store store credentials. It inventories the open source your app ships with SBOM and dependency scanning, and its policies can gate a release. Try the free scan.
Quick check
Can I get production release rights from a team key?
That depends on the role you select when creating it. Pick the least permissive role that works.
Is the API key safer just because it avoids 2FA?
Not by itself. It is safer when you also scope the role, keep the file in a secret manager and rotate it.
Sources
Last reviewed: 19 October 2026.
