To update your App Store Connect API key, generate a new key in App Store Connect under Users and Access, in the Integrations section, download its .p8 private key file, which you can only download once, and note the new Key ID and Issuer ID. Then update those three values in your CI or Fastlane secrets, run a build to confirm authentication works, and revoke the old key. The App Store Connect API key is a CI credential, not a key that ships in your app, so it belongs only in your pipeline's secret storage, never in your repository or app bundle. Assign the new key the least-privileged role your automation needs.
Short answer
Create a new key, swap it into your pipeline, verify, then revoke the old one. Per Apple's App Store Connect API documentation, you generate keys under Users and Access in the Integrations section, download the .p8 once, and can revoke a key at any time. Update your CI secrets with the new Key ID, Issuer ID, and .p8 content, and for Fastlane pass them to the app_store_connect_api_key action, per the Fastlane docs. Give the key the minimum role it needs. This credential is a secret that lives only in your pipeline, so keep it out of your repository and app entirely.
What the App Store Connect API key is
The App Store Connect API key is a credential your automation uses to authenticate to Apple's App Store Connect API, for tasks like uploading builds, managing TestFlight, and updating metadata without a password or interactive login. It is made of three parts that work together: an Issuer ID that identifies your team, a Key ID that identifies the specific key, and a .p8 private key file that signs the tokens your tools generate. Your CI system uses all three to prove it is allowed to act on your account.
Two properties matter for updating it. First, the .p8 private key can only be downloaded once, at creation, so if you lose it you cannot retrieve it and must create a new key. Second, the key is a build-time and pipeline credential, not something that runs inside your app, so it never belongs in your app bundle. Keeping these in mind frames every update: you are managing a secret that lives in your CI, and losing or leaking the .p8 means generating a replacement rather than recovering the old one.
When you need to update it
You update the key in a few situations, and knowing which one you are in tells you how urgent it is. The most urgent is a leak: if the .p8 or your key values were exposed, for example committed to a repository, treat the key as compromised and replace it immediately. Losing the .p8 file is another common trigger, since you cannot download it again, so a lost key means creating a new one. Routine rotation for hygiene, and reducing a key's access when it has more permission than it needs, round out the list.
In every case the mechanics are the same: generate a new key, move your pipeline onto it, and revoke the old one. The App Store Connect API key does not silently expire on its own, but the short-lived tokens your tools mint from it do, which is why authentication can appear to break and send people looking to update the key. Distinguishing a genuine need to replace the key from a token or configuration issue saves effort, but when the key itself is leaked, lost, or over-privileged, replacing it is the answer.
How to update it, step by step
Start in App Store Connect under Users and Access, in the Integrations section for the App Store Connect API, and generate a new key. Give it a name you will recognize and assign it a role, then create it. Immediately download the .p8 private key file and store it securely, because this is your only chance to download it, and record the new Key ID shown next to the key and the Issuer ID shown for your team.
Next, put those three values into your pipeline's secret storage rather than any file in your repository. Most CI systems let you store the .p8 content as a secret, often base64-encoded, alongside the Key ID and Issuer ID as separate secrets. Update your build configuration to read the new values, then run a pipeline job that authenticates, such as an upload or a metadata fetch, to confirm the new key works end to end. Only after you have verified the new key should you revoke the old one, so you are never left without a working credential mid-update.
Fastlane integration
If you use Fastlane, the App Store Connect API key plugs in through the app_store_connect_api_key action, which produces the authentication object other Fastlane actions use. You provide it the Key ID, the Issuer ID, and the .p8 key, either as a file path or as the key content, and Fastlane handles generating the short-lived tokens from there. Updating the key in a Fastlane setup means updating those three inputs to the new values.
Keep the inputs in secrets, not in your Fastfile. Store the Key ID, Issuer ID, and the .p8 content as environment variables or CI secrets, and reference them in the action rather than pasting the .p8 into your repository, since committing the key would expose it. A common pattern is to base64-encode the .p8 into a single secret and decode it at runtime. After updating the secret values, run a Fastlane lane that uploads or queries App Store Connect to confirm the new key authenticates, then revoke the old key.
Role and access permissions
When you create the key, you assign it a role, and the right choice is the least privilege your automation actually needs. App Store Connect keys carry the access of the role you give them, so a key used only to upload builds does not need Admin access. Granting the minimum role, such as one sufficient for app management or development tasks rather than full administration, limits the damage if the key is ever exposed, which is the whole point of least privilege.
Match the role to the job. If your pipeline uploads builds and manages TestFlight, assign a role that permits those actions and nothing more; if it only reads data, an even narrower role suffices. Be aware of the difference between a key scoped to specific access and a broader team key, and prefer the narrower option when it covers your needs. When you update a key specifically because the old one had too much access, this is the step that fixes it: create the replacement with a tighter role, move your pipeline to it, and revoke the over-privileged key.
Verify and revoke the old key
Finish the update by verifying the new key and then revoking the old, in that order. Run a pipeline job that actually uses App Store Connect, an upload, a TestFlight action, or a metadata call, and confirm it authenticates and completes with the new key. Verifying before revoking means that if something is misconfigured, your old key still works and you are not locked out of your release pipeline at a bad moment.
Once the new key is confirmed, revoke the old one in App Store Connect so it can no longer be used, which is essential when you are rotating because of a leak. Then check that no copy of the old .p8 lingers, in your repository history, in old CI configuration, or in a build artifact, and scan for it if you are unsure. Revoking the old key and confirming no copy remains closes the loop, leaving exactly one active key that lives only in your secret storage.
Update paths
Matching your reason for updating to the right steps keeps the process clear. The table below pairs situations with actions.
| Situation | Immediate action | Then |
|---|---|---|
| Key leaked or committed | Generate a new key, revoke the leaked one | Rotate CI secrets, scan the repo |
| Lost the .p8 file | Generate a new key, you cannot redownload | Update CI, revoke the old |
| Routine rotation | Generate a new key, swap it in | Verify, then revoke the old |
| Key has too much access | Create a new key with a tighter role | Move the pipeline, revoke the old |
Read the table by your trigger: a leak is urgent and pairs with a repo scan, while rotation and least-privilege changes follow the same generate, verify, revoke sequence.
Rotation checklist
Working through the steps in order updates the key without breaking your pipeline. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Generate a new key | Users and Access, Integrations, least-privilege role | [ ] |
| Save the .p8 | Download once and store securely | [ ] |
| Update CI secrets | New Key ID, Issuer ID, and .p8 in the pipeline | [ ] |
| Verify in CI | Run a job that authenticates to App Store Connect | [ ] |
| Revoke the old key | Only after the new key is confirmed | [ ] |
| Confirm no copies | No .p8 in the repo, app, or artifacts | [ ] |
The order that matters most is verify before revoke, so a misconfiguration never leaves your release pipeline without a working key.
Scan for leaked CI secrets
Because a .p8 or its values can slip into a repository or a build, and because this credential should live only in secret storage, confirming it has not leaked is worth doing after any update. A secret in git history or an artifact is exposed even when it is gone from your current files, so verification is part of the job.
A scanner like PTKD.com analyzes your app build and reports issues such as leaked keys, embedded secrets, and insecure data storage by severity, mapped to OWASP MASVS, so a credential that wrongly ended up in the shipped app is flagged. To be clear about the boundary: PTKD scans the app you ship, not your CI configuration, so pair it with a repository secret scanner to catch a .p8 committed to git. Together they confirm the key lives only where it should, in your pipeline's secret storage.
What to take away
- Update the App Store Connect API key by generating a new one under Users and Access in Integrations, saving the .p8 once, and recording the new Key ID and Issuer ID.
- Swap the new Key ID, Issuer ID, and .p8 into your CI or Fastlane secrets, verify with a real authentication job, and only then revoke the old key.
- For Fastlane, pass the three values to the app_store_connect_api_key action from secrets, never from a committed file, base64-encoding the .p8 if needed.
- Assign the least-privileged role your automation needs, and update the key with a tighter role when the old one had too much access.
- Keep the key only in secret storage, never in your repo or app, and scan the build with a tool like PTKD.com plus a repo scanner to confirm no copy leaked.
