Apple announced that the old Developer ID Sub-CA expires on February 1, 2027: inventory Developer ID Application and Developer ID Installer certificates, confirm each issuer, prepare G2 replacements, then test them in an isolated Mac CI workflow before a staged production switch. Apple says affected certificates will stop working at the cutoff; already notarized Mac software with a secure timestamp will continue to work, while affected signed packages will no longer install. (Apple’s announcement)

This guide is for release engineers responsible for signing macOS apps or installer packages.
It is also for IT and platform leads managing Mac CI nodes, plus Apple Developer account owners responsible for certificates and private keys.

Last updated October 4, 2026; verified against Apple’s announcement and Developer ID certificate replacement guidance.

Start with a certificate and artifact inventory

Treat this as a chain-of-custody exercise, not a search-and-replace job. A certificate name alone does not establish whether a signing job is affected. You need to connect the certificate’s issuer to the CI identity, the job that uses it, and the artifacts that job distributes.

For each Mac CI node and release workflow, record:

  • The certificate type: Developer ID Application, Developer ID Installer, or another certificate type.
  • The certificate’s issuer and status, captured from the certificate details and the Apple Developer account.
  • The associated team and the account owner responsible for replacement.
  • The keychain or managed credential location, plus which CI service account can access it.
  • The workflow, application target or package, and distribution channel that use the identity.
  • Whether the output is an app, a signed .pkg, or both.
  • The latest successful signing and distribution evidence, including relevant build logs.

Do not put private-key contents, passwords, or exported signing identities in the inventory. Record where the credential is controlled and who is authorized to manage it. Apple’s certificate documentation distinguishes certificate types and their roles; use that documentation and the account record rather than inferring a certificate’s purpose from a filename. (Apple’s Developer ID certificate guidance)

What belongs in the inventory if a workflow uses both app and package signing? Record each signing step separately. An app may be signed with Developer ID Application, while a distributable installer package uses Developer ID Installer. A job that produces both artifacts needs evidence for both identities; one successful signature does not validate the other.

Keep the original certificate, issuer details, and the CI job configuration tied together in the audit record. If you cannot trace an artifact to a certificate and responsible owner, classify that workflow as unresolved rather than assuming it is unaffected.

Check the issuer before deciding what is affected

Use the issuer information to identify certificates associated with the old Sub-CA. Do not decide based only on the certificate’s display name or expiration date. Apple’s replacement guidance explains how to identify affected Developer ID certificates and obtain replacements; apply that procedure to the certificates in the account and on the build nodes. (Apple’s certificate replacement instructions)

Separate the review by certificate type:

  • Developer ID Application: used to sign macOS apps distributed outside the Mac App Store. Check the issuer for every identity used in app signing and release workflows.
  • Developer ID Installer: used to sign installer packages. Check the issuer for every identity used to sign .pkg outputs.
  • Apple Distribution: a distinct certificate type associated with App Store distribution workflows. Do not substitute it for a Developer ID identity or treat it as proof that a Developer ID signing job is covered. (Apple’s certificate type overview)

How can a team tell whether a Developer ID Application or Installer certificate came from the old Sub-CA? Inspect the certificate’s issuer using Apple’s account guidance and compare it with the old Sub-CA identified in Apple’s announcement. Save the result for each identity. If a local keychain contains duplicates, match the certificate and private key to the actual CI identity instead of relying on the certificate’s common name.

Then map the result to the artifact’s status:

  • Already notarized app with a secure timestamp: Apple says it will continue to work after the old Sub-CA cutoff. That does not mean future builds can keep using an affected certificate.
  • Future app updates: plan to sign with the replacement certificate and include a secure timestamp as required by Apple’s current instructions.
  • Signed installer package: Apple says a .pkg signed with an affected certificate will not install after February 1, 2027. Treat every package release path using such an identity as in scope. (Apple’s cutoff and artifact guidance)

Does an already notarized Mac app need to be signed again? Not solely because of this transition, if it was already notarized and has a secure timestamp: Apple says that existing software will continue to work. Future updates are a separate release event, so move their signing workflow to the replacement certificate and verify the timestamp and notarization path before publishing.

Prepare replacement certificates without exposing private keys

Once you have confirmed an affected identity, follow Apple’s current process to request the corresponding replacement type. Replace an Application identity with a Developer ID Application certificate and an Installer identity with a Developer ID Installer certificate. Verify the issuer of the replacement and confirm that it is associated with the G2 Sub-CA before adding it to a production signing workflow. Apple’s replacement page is the authority for the current account steps and certificate requirements. (Apple’s replacement guidance)

Keep private-key handling within the team’s established credential controls. In particular:

  • Generate and protect the private key using the approved process for your Apple Developer account and CI environment.
  • Limit export, storage, and import permissions to the people and service accounts that need them.
  • Avoid copying signing identities into general-purpose build images or shared folders.
  • Record the certificate fingerprint, issuer, owner, keychain location, and access changes without recording secret material.
  • Confirm that the CI service account—not just an administrator’s interactive login—can access the identity.

Before requesting or installing certificates, check Apple’s current guidance for account roles, supported tooling, and any active-certificate limits. Those requirements can change, so do not rely on an old runbook or an assumed quota. Apple’s certificate creation documentation describes the available Developer ID certificate types; its replacement instructions should govern the migration steps. (Certificate creation guidance; replacement instructions)

What should happen if the replacement is not confirmed as G2? Do not point a production job at it. Recheck the certificate details and the current Apple instructions, then resolve the discrepancy with the account owner before continuing. A successful import into Keychain does not prove that the replacement has the required issuer.

Validate both signing paths on an isolated Mac CI node

Use a non-production node or a separate test workflow that cannot publish to customers. Preserve the existing production identity and job configuration while you test the replacement. This lets the team compare behavior and gather evidence without turning the first release attempt into the migration test.

For the app path, run a representative build and verify that:

  • The CI service account finds and uses the intended Developer ID Application identity.
  • The application’s signature validates and identifies the expected signing authority.
  • The app follows the team’s notarization and distribution process.
  • The release artifact includes the required secure timestamp for the applicable workflow.
  • Logs show which identity was used and where the notarization process completed or failed.

Apple’s notarization preparation guidance covers the signing and submission prerequisites for macOS software. Use it alongside the current team workflow; a local signature check alone does not establish that a distributed app has passed the full notarization and release path. (Apple’s notarization preparation guidance)

For the package path, use a representative .pkg and verify that the CI service account can sign it with the replacement Developer ID Installer identity. Check the package signature, then test installation in a controlled environment that reflects the team’s supported deployment route. Retain the build log, signature result, and installation evidence. Do not treat the package signing step as validated just because the app portion of the same workflow passed.

How can a team replace Developer ID certificates in Mac CI without interrupting releases? Add the replacement identity alongside the current one in the isolated workflow, select it explicitly for the test job, and run the app and package paths independently. Compare the new job’s signing identity and artifacts with the expected release configuration. Keep production jobs pinned to the existing configuration until both paths pass review and the release owner approves the change.

If notarization fails, diagnose the failure as a separate stage rather than assuming the certificate issuer is the only cause. Check the signing identity, submission credentials, artifact integrity, and Apple’s documented common notarization issues. (Apple’s notarization troubleshooting guidance)

Switch production jobs in controlled batches

Do not rotate every CI job in one change. Begin with a list of affected workflows, named owners, the replacement identity each job should use, and the evidence required for approval. Then move jobs in batches that can be monitored and reversed without relying on the old certificate for new signing.

Use these release gates before expanding a batch:

  • The job uses the intended replacement certificate and the expected CI service account can access it.
  • The app path completes signing, notarization, and distribution checks required by the team.
  • The package path completes signing and installation checks in the team’s controlled test environment.
  • Logs and artifact records identify the certificate used and can be reviewed later.
  • The team has confirmed which remaining jobs still reference the affected identity.

Rollback must restore a known-good workflow configuration, not depend on continuing to sign with an affected certificate after Apple’s cutoff. If a batch fails, stop further migration, return the job to its approved configuration where that remains valid, and investigate the failure before resuming. Do not delete or revoke a certificate simply because one test job has moved; first confirm all consumers and follow Apple’s account guidance.

Decision conditions for the rollout

  • If issuer, artifact, and workflow ownership are all confirmed, prepare the matching replacement and test it in isolation.
  • If the issuer is unclear or the identity cannot be matched to a CI service account, pause that workflow and resolve the inventory gap before requesting production approval.
  • If the app passes but the .pkg install test fails, keep package publishing out of the migrated batch; app validation does not authorize package release.
  • If both artifact paths pass and the evidence is reviewable, move a limited production batch and observe its real release run before expanding.
  • If the team cannot safely test without affecting production, create a separate controlled Mac CI environment or delay the switch until a safe validation path exists.

Close with release evidence and an infrastructure decision

The migration is complete only when the team can show what changed and which release paths were accepted. Keep a review packet containing the affected-certificate inventory, issuer checks, replacement details, access approvals, isolated test logs, app and package acceptance results, production change records, and any rollback decision. The release owner should be able to trace each current signing job to an approved identity without relying on an undocumented keychain state.

What should be in the final release approval? State which Developer ID Application and Installer identities are approved, which workflows use them, whether the app notarization and package installation checks passed, and which unresolved jobs remain blocked. Also record who reviewed the evidence and where the relevant logs and artifact records are stored. This makes the approval actionable for the next release rather than a general statement that “the certificates were rotated.”

A migration can also expose a capacity or isolation problem: production signing may share a node with unrelated build jobs, or the team may not have a safe place to test the replacement in parallel. A self-managed Mac CI node gives the team direct control, but requires the organization to provision hardware, maintain the host, and plan for idle capacity when a short migration or release surge ends. A remote Mac environment can make temporary parallel validation easier to arrange, but it introduces provider, access-control, network, and data-handling questions that must be checked against the team’s security requirements.

If the team needs a temporary or isolated macOS release environment, review RUVCLOUD’s remote Mac environment and assess whether its actual access and isolation arrangements meet the organization’s controls before placing signing material or source code there. For teams comparing a short-term environment with purchasing and operating another Mac, RUVCLOUD’s available plans can be reviewed without assuming a particular configuration or cost. Keep signing keys under the team’s credential policy, and do not use a rented node for production signing until its access model and operational responsibilities have passed internal review.