How to Migrate Developer ID G2 Certificates? 2026 Mac Signing Acceptance

Deadline: Apple says the original Developer ID Certification Authority expires on February 1, 2027.
Fastest safe fix: Verify the certificate issuer, then handle Mac apps and .pkg installers separately; replace affected identities and re-sign affected installer packages before the deadline.

This guide is for independent developers distributing Mac apps outside the Mac App Store, release teams shipping installer packages, and CI/CD engineers maintaining macOS signing pipelines.

Last updated October 28, 2026. Facts checked against Apple’s expiration announcement, certificate replacement guidance, and Developer ID documentation.

Start with the artifact, not the certificate name

A Developer ID migration is not a blanket instruction to re-sign every product. First identify the certificate authority that issued the signing certificate. Then classify each release artifact as a Mac app, a .pkg installer, or both. Apple’s guidance gives these artifacts different treatment when the old authority expires.

An existing Mac app that was signed with a secure timestamp and notarized can continue to work under the conditions in Apple’s expiration announcement. That does not mean every old certificate remains valid for new signing. Certificates issued by the expiring authority should not be used for future signing, and affected installer packages must be re-signed with replacement credentials before the deadline.

For new releases, the practical decision is:

• If the signing certificate chains to the old Developer ID Certification Authority, replace it with a G2 certificate before signing the next release.
• If an existing app has Apple’s required secure timestamp and notarization, do not re-sign it solely because the intermediate authority is expiring.
• If a .pkg was signed with an affected Developer ID Installer certificate, create and verify a replacement package before February 1, 2027.

This distinction is central to Developer ID G2 certificate migration. Treating a signed app and its installer as interchangeable can cause unnecessary work on one side and leave a distribution failure on the other.

Independent developers: identify the issuer reliably

An independent developer should begin with the certificate, not an assumption based on its visible name. Apple’s Developer ID documentation describes the relevant certificate types, including Developer ID Application and Developer ID Installer. The type tells the developer what the identity is for; it does not, by itself, prove which authority issued it.

Check the certificate in two places:

• In the Apple developer account, review the Developer ID certificates and their details.
• On the Mac used to sign releases, open Keychain Access and inspect the certificate’s issuer and certificate chain.
• If the certificate is available to command-line tools, inspect the code-signing identities on the signing Mac and confirm which identity the release process selects.

The key detail is the issuer. A familiar identity label or an expiration date is not enough to establish whether the certificate belongs to the affected chain. Use Apple’s Developer ID intermediate certificate guidance to compare the authority information, and consult the certificate replacement instructions when the identity needs replacement.

A local check is only useful if it reflects the signing environment used for distribution. A developer may have a G2 certificate in a personal keychain while an automated release still selects an older identity from a build machine. Record the certificate issuer and the keychain or signing environment where it was checked. Then compare that record with the identity used by the actual release job.

Important: A replacement certificate does not retroactively change the signature on an already-built package. The package must be signed again with the replacement Developer ID Installer identity, and the resulting artifact must be tested as a new deliverable.

Mac software teams: separate application and installer acceptance

The release owner should inventory the actual products customers download. A release may include a directly distributed app, a disk image, a signed package, or a package that installs the app. The certificate change affects these items differently, so a single “release signed” status is not a sufficient acceptance record.

The risk labels are operational judgments, not Apple ratings. They reflect the impact of shipping an unchecked artifact: package installation is directly exposed to the stated migration deadline, while an already notarized app meeting Apple’s conditions is not automatically subject to the same re-signing requirement.

For each release, use this acceptance order:

• Confirm the artifact type and the certificate identity used to sign it.
• Replace an affected certificate through Apple’s process and make the replacement identity available to the authorized signing environment.
• Re-sign the affected app or .pkg as required by its artifact type.
• Submit for notarization when the release workflow and Apple’s requirements call for it; do not treat notarization as a substitute for using the correct signing identity.
• Verify the signature and test a fresh installation using the actual distributed artifact.

Apple’s notarization guide explains the notarization process, while its signing and notarization troubleshooting guidance is useful when a new artifact fails validation. The migration question is narrower than a full notarization redesign: preserve the existing release flow where it remains valid, and change the signing identity and artifact handling where the authority change requires it.

For Mac installation package signing, test the .pkg from the same path a user will use. A successful build or signature inspection does not confirm that the package installs correctly in the target release scenario. Capture the artifact’s identity, notarization result where relevant, and installation outcome so another release owner can reproduce the acceptance decision.

CI/CD engineers: validate the new identity outside production

A CI job can keep using an old identity even after the team has created a G2 certificate. This happens when signing configuration points to a fixed identity name, a specific keychain, or a secret that has not been refreshed. A certificate’s presence on a machine is not proof that the pipeline selected it.

Start by tracing the signing path rather than changing production jobs immediately. Identify the build machine, keychain reference, signing identity setting, and any release scripts or secrets that determine which certificate is used. Compare that configured identity with the issuer shown in the certificate. Where Apple’s command-line tools are used, follow Apple’s signing documentation and keep the certificate, private key, and keychain handling within the team’s approved credential process.

Next, use an isolated release task to sign a representative artifact with the replacement identity. Check the resulting signature, confirm the intended certificate chain, and validate the output using the same notarization and delivery steps as the real release. Apple’s code-signing certificate technical note explains certificate-chain and timestamp behavior. Apple also documents customizing a notarization workflow, which can help teams adapt validation without assuming every pipeline uses the same sequence.

Do not make the production change based only on a green build. The isolated task should produce a distributable artifact that passes the team’s acceptance checks. If the pipeline cannot show which identity signed the output, fix that observability gap before changing the release identity. Otherwise, a successful run may conceal a fallback to the old certificate.

For teams that have not documented their Mac build environment, a remote Mac support environment can be considered for signing and release validation, provided the team separately confirms that its certificate and private-key handling requirements can be met. This is an environment option, not evidence that a particular signing setup or credential workflow is supported.

Migration questions release owners need to resolve

How can a team tell whether its certificate uses the old Sub-CA?

Inspect the issuer and certificate chain in the developer account and on the Mac that performs signing. The identity’s display name and expiration date alone do not identify the issuing authority. Compare the certificate details with Apple’s replacement guide and its intermediate-certificate information. Then confirm that the CI job selects the same identity that was inspected.

What is the difference between a G2 certificate and an older certificate?

The relevant difference is the issuing authority and resulting certificate chain. “Developer ID Application” and “Developer ID Installer” identify the intended use of an identity; they do not, on their own, establish whether it chains to the old authority or G2. Check the issuer and compare it with Apple’s Developer ID intermediate certificate information.

Can an affected .pkg still be installed after the deadline?

Apple’s stated action is to re-sign affected installer packages with a replacement certificate before February 1, 2027. Teams should not rely on a package merely because it installs in a current test. Create a replacement package, validate its signing identity, and test installation from the distribution channel. Keep the original artifact identifiable so users and support staff do not confuse it with the accepted replacement.

Do both the Mac app and its installer need re-signing?

No blanket re-signing rule applies to every existing artifact. Apple says previously notarized Mac software with a secure timestamp can continue to work under the conditions in its announcement. A .pkg signed with an affected Developer ID Installer certificate has a separate replacement and re-signing requirement. Assess the app and installer independently, even if they ship in one release.

Team owners: set responsibilities and a rollback condition

A team lead should assign ownership by artifact and system. The developer who controls the account can verify certificate details and obtain a replacement. The release owner can identify customer-facing apps and packages. The CI engineer can locate signing references and validate the pipeline. One person can hold more than one role, but each check needs a named owner and a recorded result.

Use this migration checklist:

• [ ] List every shipped app and .pkg, including artifacts still available from download pages or update channels.
• [ ] Record the signing identity and issuer used for each deliverable.
• [ ] Mark which existing apps have a secure timestamp and notarization status that meets Apple’s stated conditions.
• [ ] Request or configure a replacement certificate for each affected signing role.
• [ ] Test the new identity in an isolated signing task before editing the production release job.
• [ ] Re-sign affected installer packages and validate installation from the customer-facing distribution path.
• [ ] Update the release documentation with the identity, artifact, validation result, owner, and rollback condition.
• [ ] Retain a known-good release path until the replacement artifact has passed the team’s acceptance checks.

The rollback condition should be specific: if the new package fails signature validation, notarization where required, or installation testing, stop the release rather than silently reverting to the affected identity. Escalate the certificate or packaging failure and keep the last accepted deliverable available only where its continued use is consistent with Apple’s guidance.

G2 does not remove normal certificate lifecycle work. Teams must still track each replacement certificate’s own validity period and renew it as required. The CA transition and certificate expiration are separate operational events; completing this migration is not a reason to stop monitoring certificate status.

Choose the next step from the release risk

The safest sequence is to inventory issuers and shipped artifacts now, then test the replacement identity before the deadline rather than leaving the check to the final release window. A team with a documented signing Mac and a reproducible CI pipeline can usually keep its current environment and change only the affected identity and package steps. A team without a suitable macOS signing and installation-test environment has an additional constraint: it cannot fully validate a Mac release using a Linux-only build host.

A remote Mac can provide a macOS environment without purchasing another physical machine, but it is not automatically the right choice for every team. Teams with continuous, stable signing workloads or requirements for physical interfaces may prefer a dedicated local Mac. For temporary migration work, cross-version testing, or a release validation window, compare the team’s access and credential requirements with the available ArmMacs rental plans before deciding. The useful comparison is whether the environment can support the team’s approved signing workflow, not whether remote access alone guarantees a valid release.

Developer ID G2 certificate migration is complete only when the issuer is verified, each artifact has been treated according to Apple’s distinction, and the replacement deliverable passes the team’s real acceptance path. Start with the certificate inventory; then use a controlled CI release to prove the app or package that customers will actually receive.

Frequently asked questions