Developer ID G1 Expires: How to Migrate Mac Installer Signing? 2026

A release pipeline can produce a signed PKG and still leave the team unsure whether its certificate chain will remain valid.

Fastest fix: First confirm whether the signing certificate chains to the expiring Developer ID G1 authority. Then handle the installer package separately from the app: re-sign affected PKGs with the correct G2 identity and verify installation before the deadline.

macOS release owners: use this guide to identify certificates that may be affected.
CI/CD engineers: use it to update signing identities, keychains, and package checks.
Enterprise IT teams: use it to plan an isolated Mac build environment for release validation.

Last updated October 26, 2026; checked against Apple’s October 1, 2026 announcement and its certificate and notarization guidance. Apple says the original Developer ID Certification Authority expires on February 1, 2027, and that affected certificates will stop working then. (Apple’s G1 expiration announcement)

Developer ID G1 expiration and Mac installer signing migration: identify the actual chain

A certificate’s display name or expiry date alone does not establish whether it was issued from G1. Start with the certificate that signed the product, not a similarly named authority entry elsewhere in the keychain. Apple warns that certificates from the previous and current authorities can have identical names; the issuer is the decisive check. (Apple’s certificate replacement guidance)

How can you tell which intermediate certificate issued a Developer ID Installer certificate? In Keychain Access, select the specific signing certificate and expand Issuer Name. Check its Organizational Unit: Apple’s replacement guidance says an entry showing “Apple Certification Authority” identifies the previous Sub-CA, while “G2” identifies the current one. Make sure you inspect the certificate itself, not the separate Developer ID Certification Authority entry.

Apple also recommends reviewing Developer ID certificates in Certificates, Identifiers & Profiles. Certificates expiring on or before February 1, 2027, are likely affected, but the date alone does not prove which authority issued them. Treat it as a way to prioritize review, not as a substitute for checking the issuer.

This boundary matters operationally. Replacing the wrong certificate wastes release time, while failing to inventory a package-signing identity can leave an affected installer in a release channel. Do not extend Apple’s PKG notice into a blanket claim that every old app, every old package, or every Developer ID certificate will fail.

PKG installers and notarized apps need different decisions

Which Mac installers are affected after the G1 expiration? Apple’s stated boundary is .pkg files signed with an affected certificate: those packages will no longer install from February 1, 2027. This is not a statement that every old PKG is affected; check the certificate chain used to sign each package.

Does an already notarized Mac app need to be signed again? Apple says previously signed and notarized Mac software with a secure timestamp will continue working. For future updates, sign with a replacement certificate and include a secure timestamp for notarization. Do not apply that existing-app statement to PKG installers: Apple describes the package impact separately.

The distinction between an app and its installer also affects troubleshooting. An app inside a package may have a Developer ID Application signature, while the outer installer needs a Developer ID Installer signature. Replacing only the app identity does not, by itself, replace the package’s signing identity. Apple documents these as separate certificate types. (Apple’s Developer ID certificate types)

A release team that distributes multiple formats should record them separately in its inventory. For instance, if the same app is delivered inside a PKG and as a standalone app archive, the package check and app check are different acceptance tasks. This is a scope-control measure: it prevents an installer-specific certificate notice from triggering unnecessary re-signing of unaffected artifacts.

G2 selection and CI signing are separate failure points

A new certificate is not automatically the correct replacement. Apple directs teams to select G2 Sub-CA when asked for a Developer ID Certificate Intermediary; choosing another option may issue a certificate that also expires in 2027. Apple also says to update before creating a new certificate when using Xcode 11.4 or earlier. (Apple’s G2 and Xcode guidance)

The certificate type must match the artifact. Developer ID Application signs a Mac app; Developer ID Installer signs a Mac Installer Package. If the team distributes both, Apple says to create a replacement for each type rather than assuming one covers both.

Can a successful CI build prove that the G2 migration is complete? No. A build can pass while the runner still selects a legacy identity, uses a keychain that lacks the intended private key, or produces a package signed by a different identity than the team expects. These are verification gaps to investigate, not proof of a particular Xcode defect. Check the identity and chain in the actual output artifact.

Apple provides commands for verifying signatures and timestamps. For packages, pkgutil --check-signature /path/to/file.pkg reports signature details; for signed code, codesign -dvv /path/to/app displays signature information, including a timestamp when present. Use those checks as evidence, then install the package on a clean test system rather than treating signature inspection alone as a complete release test. (Apple’s notarization troubleshooting and verification guidance)

Common migration costs are easy to miss: certificate ownership and approval may sit with a different account role; build agents can have different keychains; package and app identities are not interchangeable; and release logs or artifacts can expose sensitive signing material if teams print credentials while debugging. Apple’s certificate creation guidance identifies the Account Holder as the required role for certificate creation, so include the responsible owner in the change plan. (Apple’s certificate creation documentation)

A five-check migration and acceptance run

Use this sequence on a representative release pipeline. Keep signing private keys and notarization credentials out of build logs, shell traces, and example configuration. Record identity names, fingerprints where your process uses them, certificate issuer details, and artifact test results in an access-controlled release record.

1. Inventory signing assets. List the Developer ID Application and Developer ID Installer certificates available to each release job. Map each product and distribution format to the identity that actually signs its output. Do not infer the signer from a project setting alone.

2. Confirm the issuer. Inspect each relevant certificate in Keychain Access and record its Organizational Unit. Use the certificate expiry date as a review signal, then confirm the issuer as Apple directs. If a certificate was issued by G1, mark every package signed with it for replacement and testing.

3. Create the right replacement. Create the matching certificate type for each artifact category. When the intermediary choice appears, select G2 Sub-CA. Check Apple’s Xcode guidance before certificate creation if the signing environment uses Xcode 11.4 or earlier.

4. Update the build runner deliberately. Install or import the replacement certificate and its corresponding private key into the keychain used by the CI job. Update the explicit signing identity or controlled signing configuration. Then run a representative build and inspect the output—not only the job’s “success” status.

5. Test the delivered artifact. Run pkgutil --check-signature against the PKG and confirm that the expected Developer ID Installer identity appears. Install that package on a clean Mac test environment and confirm the resulting app launches and behaves as expected. For app code, inspect the signature and timestamp with codesign -dvv; run the team’s normal notarization and distribution checks for the artifact type. Apple documents notarizing macOS software and integrating it into a scripted workflow.

For auditability, save the pipeline run identifier, certificate issuer, signer identity, package signature output, installation result, and notarization result together. Keep the previous passing release as a comparison point, but do not copy its signing credentials into the new job. The goal is to show which identity produced the candidate and that the candidate installed—not merely to show that compilation completed.

This process also separates official requirements from team acceptance policy. The G1 date and affected artifact boundary come from Apple. Which clean test machines, supported operating-system versions, or application-specific launch tests your organization requires is an internal release decision; document it as such rather than presenting it as an Apple mandate.

Choose a validation environment that fits the release risk

A developer workstation can be a quick place to inspect a certificate, but it may not match the CI keychain, permissions, network access, or signing configuration that produces production packages. A shared runner can offer repeatable builds, yet unclear ownership of its keychain or persistent credentials can complicate isolation and incident review. A dedicated physical Mac may be more appropriate for sustained workloads or workflows that need local hardware interfaces.

For a temporary migration rehearsal, the environment should let the team run its own signing and installation checks without mixing test credentials into production release jobs. Before selecting a remote Mac, confirm access method, administrative boundaries, credential handling, and whether the setup matches the team’s security requirements. xcodeops offers remote access to hosted Mac machines through VNC, SSH, or a web console, with root access; teams should still assess whether that model fits their own controls rather than treating it as a security guarantee. For broader planning, see the enterprise Mac CI environment guides and the data privacy information.

If the current approach relies on one developer’s workstation, it can be hard to reproduce; if it relies on an unreviewed shared runner, credentials may be difficult to isolate; and if the only Mac is reserved for production builds, migration testing can compete with release work. For a temporary, isolated verification environment, renting a Mac from xcodeops may give the team a separate real-Mac environment to run its own acceptance tests. For long-running, predictable heavy workloads or workflows requiring physical interfaces, buying and managing an in-house Mac may be a better fit. Teams that need to assess a remote setup before committing can contact xcodeops about an evaluation.

The decision is straightforward: verify the G1 issuer first, migrate affected PKG signing to the correct G2 Developer ID Installer identity, and accept the change only after CI artifacts pass signature inspection and an installation test. Keep the treatment of previously notarized, timestamped apps separate from the package migration.