iOS Signing Certificate Rotation: 2026 CI/CD Checklist

Do not wait for an iOS signing certificate to expire. This week, create the replacement identity through a controlled Apple Developer role, update the affected Provisioning Profiles, verify a real archive-to-upload path on an isolated Mac node, and revoke the old certificate only after the new path is proven. If you suspect private-key exposure, switch to incident response and revoke for containment instead of preserving a convenient build path.

This guide is for:

• Apple Developer account administrators managing signing permissions and certificate ownership.
• Platform engineers maintaining iOS CI/CD, Keychain access, and Mac build nodes.
• Release, security, and engineering leaders approving production cutover, emergency revocation, and audit evidence.

SECTION 01 The rotation decision belongs to five accountable roles

Certificate rotation is not a single developer task. It is a controlled handoff between account administration, CI platform operations, release validation, security approval, and Mac infrastructure.

The most common failure is not certificate creation. It is incomplete ownership. A new certificate may exist in Apple Developer while the private key is missing from one build node, the profile still points to the old identity, or the export step uses a different signing configuration than the archive step.

Use the following role map before anyone changes production credentials.

This division also prevents a risky shortcut: giving a CI machine the credentials of the Account Holder. Apple identifies the Account Holder and Admin as the roles that can create and revoke distribution certificates, while a Developer’s access depends on the permissions granted to that team member. Review the official Apple Developer role and access matrix before assigning the rotation operator.

SECTION 02 Build the certificate asset register before opening Xcode

Start with an inventory that connects each signing identity to a real release path. Do not record only the certificate name. Record the applications, environments, nodes, profiles, and people that depend on it.

A useful register looks like this:

The exact certificate type depends on how your team signs and distributes software. The register should preserve the existing workflow instead of forcing every project into one signing model.

Record at least:

• Certificate common name and fingerprint.
• Apple Developer Team ID.
• Certificate type and expiration state.
• Associated Bundle IDs and App IDs.
• Provisioning Profile names and distribution method.
• Mac node hostname or internal identifier.
• Keychain location and access policy.
• Pipeline or job that selects the identity.
• Human owner and approval owner.
• Whether the old certificate is scheduled for retirement or emergency revocation.

This register is also your audit boundary. If a certificate cannot be linked to a current application, profile, node, and responsible owner, you do not yet know whether it is safe to revoke.

SECTION 03 Separate normal expiration from suspected key compromise

A normal expiration allows a controlled overlap. A suspected private-key compromise does not.

For ordinary rotation, create the replacement identity before the existing one becomes unusable. Update profiles, install the new identity, and validate the entire release path while the old identity remains available for rollback. This reduces the chance that a profile or node problem becomes a production release outage.

For suspected exposure, treat the private key as untrusted. Preserve relevant logs, identify where the identity was stored, determine which applications and teams were affected, and follow your incident process. Do not delay revocation simply because one CI job still depends on the old key.

Apple states that certificates and related account materials are sensitive assets. Apple also warns that anyone who obtains an exported signing identity and its password may distribute software that appears to come from your developer account. Review Apple’s signing identity and certificate security guidance before exporting or importing a .p12 identity.

A rotation plan should therefore use two different approval paths:

SECTION 04 Keep Apple Developer permissions off the build node

The account that creates or revokes a distribution certificate should not be the account configured inside a CI runner.

Apple’s role documentation shows that distribution certificate creation and revocation are controlled by Account Holder and Admin permissions. Those permissions are appropriate for a human approval workflow, not for an unattended Mac build node. The node should receive only the signing material and profile data required for its assigned jobs.

A practical separation is:

• Account Holder or Admin: approves the request, creates or revokes the distribution certificate, and manages profile changes.
• Release owner: confirms the application and distribution purpose.
• CI platform team: installs the identity and updates the pipeline.
• Security owner: reviews access, exposure, and retirement evidence.
• Build node: performs signing only; it does not manage team membership or certificate lifecycle.

Cloud-managed certificates can change the implementation. Apple documents that cloud-managed certificates are associated with the Apple Developer membership and managed remotely. Xcode can use cloud signing for supported distribution workflows, and Apple states that a new cloud-managed certificate is automatically created 90 days before expiration when new signing requests are received. Account Holders and Admins can also initiate rotation, with manual rotation available once the certificate has less than half of its validity duration left, often 180 days. See Apple’s cloud-managed certificate documentation.

That does not make the process ownerless. You still need to identify which jobs use cloud signing, which jobs use local identities, and whether your external CI platform requires a private key in a local Keychain.

SECTION 05 Isolate the new identity in Keychain and on every Mac node

A certificate alone cannot sign an application. The build environment needs the matching private key. Apple notes that a certificate without its corresponding private key cannot be used for code signing. A missing key is a common reason for errors such as “valid private-key/certificate pair” not being found.

Use a dedicated CI Keychain or an equivalent controlled secret environment. Do not place signing identities in public build directories, shared home folders, chat attachments, or unprotected workspace archives.

On each node, verify:

• The certificate fingerprint matches the approved asset register.
• The matching private key is present.
• The CI process can access the key without interactive prompts.
• The Keychain unlocks after a reboot according to your recovery design.
• The profile is installed and belongs to the correct Team and App ID.
• The pipeline selects the intended signing identity.
• Temporary .p12, profile, and password files are removed after import.
• Logs do not print passwords, private-key material, or complete secret paths.
• Old identities are not selected through a stale environment variable or cached profile.

The distribution method matters. A manually exported identity may be required when an external build system needs local signing. Xcode supports exporting a signing identity as a password-protected PKCS#12 file, but that file must be treated as a high-risk secret. Cloud-managed certificates follow a different sharing model and should not be copied into the same workflow without confirming the supported Xcode process.

For a team that needs a controlled Mac environment rather than ad hoc developer hardware, review the VPSNIX Mac service overview and compare it with your existing node isolation model. The relevant question is not simply whether a Mac is available. It is whether you can restrict access, recover the node remotely, and reproduce the same signing checks on every machine.

SECTION 06 Update Profiles as part of the identity change

Replacing a certificate without updating its dependent Provisioning Profiles leaves the release path incomplete.

Apple defines a provisioning profile as authorization for an App ID, app services, and a distribution certificate. An App Store profile contains one distribution certificate. If you replace that certificate, the profile must be regenerated or edited to reference the new identity.

For manually managed profiles, use this sequence:

1. Confirm the new certificate exists in the correct Apple Developer Team.
2. Identify every profile associated with the old certificate.
3. Confirm the App ID and Bundle ID for each profile.
4. Verify entitlements against the project configuration.
5. Select the new distribution certificate.
6. Generate or regenerate the profile.
7. Download the profile through Apple Developer or Xcode.
8. Install it on the intended Mac nodes.
9. Remove stale profiles from the CI selection path.
10. Archive and export the application using the new profile.

Apple’s Provisioning Profile update documentation explains the relationship between the App ID, distribution certificate, and profile. Apple also documents that profiles may need to be regenerated after a certificate is revoked or a profile expires. See the profile editing and regeneration procedure.

Automatic signing can reduce manual profile work, but it does not eliminate verification. You still need to confirm which Team, Bundle ID, entitlements, and identity the CI job actually used. Automatic behavior on one developer Mac is not proof that a non-interactive CI node follows the same path.

SECTION 07 Validate the release path before production cutover

The release owner should test the same sequence that production uses, not merely run a successful compile.

Use an independent validation node or a non-critical branch. The test should cover:

• Clean dependency resolution where applicable.
• Archive creation.
• Code signing with the replacement identity.
• Export with the intended distribution method.
• Entitlement inspection.
• Bundle ID and Team ID verification.
• Artifact installation or upload validation.
• Log review for signing warnings.
• Re-run after a Keychain lock and unlock event.
• Re-run after a node reboot if the node is expected to recover automatically.

The evidence should identify the certificate fingerprint and profile UUID used by the build. A screenshot of a green CI job is weak evidence if it does not prove which identity was selected.

The old certificate remains a rollback asset only until the new path is confirmed. Once the replacement path passes the required checks on all production nodes, security can approve retirement. If one node still uses the old identity, the handoff is not complete.

SECTION 08 Use this role-based rotation checklist

• [ ] Build the certificate asset register with certificate type, fingerprint, Team ID, profiles, Bundle IDs, nodes, and owners.
• [ ] Classify the event as normal expiration, invalid profile repair, unknown ownership, or suspected private-key compromise.
• [ ] Confirm that the request has an Account Holder or Admin approval path.
• [ ] Verify that no CI node stores Apple Developer administrator credentials.
• [ ] Create the replacement certificate or confirm the cloud-managed rotation path.
• [ ] Record the new certificate fingerprint and intended applications.
• [ ] Identify every manually managed Provisioning Profile linked to the old certificate.
• [ ] Regenerate affected profiles with the new certificate.
• [ ] Check App ID, Bundle ID, entitlements, Team ID, and profile status.
• [ ] Install the complete signing identity, including the private key, in the dedicated CI Keychain.
• [ ] Repeat the installation and fingerprint check on every Mac build node.
• [ ] Confirm Keychain unlock, access control, and reboot recovery.
• [ ] Remove temporary identity files and inspect logs for secret leakage.
• [ ] Run archive, sign, export, and upload validation on an independent node.
• [ ] Save build evidence that identifies the certificate and profile used.
• [ ] Test the rollback or failure path before production cutover.
• [ ] Obtain security or audit approval for old-certificate retirement.
• [ ] Recheck profiles after revocation because profiles containing a revoked certificate become invalid.
• [ ] Record the final certificate status, node recovery result, and responsible approvers.

SECTION 09 What changes after revocation?

Revocation has different operational effects depending on the distribution path.

For App Store distribution, Apple states that existing apps on the App Store are not affected by an expired or revoked iOS Distribution certificate if the Apple Developer Program membership remains valid. However, you cannot upload new apps or updates signed with that certificate. This is why an old certificate may be retained during a normal overlap, but must not be retained casually after a private-key compromise.

For internal-use distribution, the impact is more severe. Apple states that users will no longer be able to run apps signed with a revoked or expired iOS Distribution certificate used for in-house apps; a new version signed with a new certificate must be distributed.

Apple also states that Provisioning Profiles containing a revoked certificate become invalid. That means revocation is not the final administrative click. You must inspect affected profiles, regenerate them, reinstall them on relevant nodes, and repeat the signing checks. Review Apple’s certificate support page and the certificate revocation procedure before approving the action.

SECTION 10 Compare three ways to provide the validation Mac

The certificate process may expose an infrastructure gap. You need a node that can be isolated, accessed by the right operators, recovered remotely, and expanded when release work increases.

No option is automatically the cheapest or safest. A production node may be acceptable when you have strong rollback and remote recovery. A standby node is easier to audit but adds idle infrastructure. A temporary remote Mac can be practical when you need an isolated validation environment without buying another physical machine, but you must confirm root access, Keychain recovery, data handling, and operator permissions first.

You can review VPSNIX pricing and rental periods when comparing a temporary validation node with buying and maintaining another Mac. Treat the comparison as a TCO decision: include provisioning time, hardware ownership, backup capacity, repair responsibility, remote access, and the cost of a failed release window.

The existing production approach is often weaker than it appears. A single Mac build machine creates a single failure domain. A developer-owned Mac makes Keychain ownership difficult to audit. A shared office Mac complicates access review and remote recovery. If the team lacks an isolated validation node, short-term Mac rental can provide a cleaner test boundary than modifying the only production machine, provided the security review accepts the environment.

SECTION 11 Final approval should be evidence-based

The rotation is complete only when the next person can reproduce the result from the records.

Your final approval packet should contain:

• The old and new certificate fingerprints.
• Certificate type and Apple Developer Team.
• Role and identity of the creator and approver.
• Affected App IDs and Provisioning Profiles.
• Node-by-node private-key and profile verification.
• Archive, export, and upload evidence.
• Entitlement and Bundle ID checks.
• Keychain access and reboot recovery results.
• Rollback decision and failure owner.
• Revocation status of the old certificate.
• Profile regeneration results after revocation.
• Date and identity of the final approval.

If your current process cannot produce that packet, the risk is not only certificate expiration. It is incomplete ownership of the signing chain.

After completing the checklist, inspect whether your Mac build environment has an independent validation node, full administrative control, remote recovery, and enough capacity for release peaks. If those capabilities are missing, a dedicated remote Mac rented by the week or month can be a reasonable way to add a controlled verification node without committing immediately to another purchased machine.

SECTION 12 FAQ