What To Do When Your Developer ID Certificate Expires in 2027: 2026 Migration Checklist

A release check shows an older Developer ID identity, or an upcoming installer build still uses the existing certificate.

Fastest fix: Check the certificate’s issuer and expiry in the developer account first. If it chains to the expiring Sub-CA, plan to sign affected .pkg installers with a new certificate before February 1, 2027; previously signed, notarized Mac apps with a secure timestamp do not need to be re-signed solely because of this expiry. Use a new certificate for future app updates. Apple’s expiry announcement sets out these boundaries.

This checklist is for developers distributing standalone macOS apps with Developer ID Application, teams shipping Developer ID Installer .pkg packages, and small teams maintaining local or remote Mac release machines.

Last updated October 2, 2026; checked against Apple’s October 1, 2026 announcement, certificate creation guidance, and certificate impact documentation. Check those sources again if Apple revises its guidance.

Developer ID certificate expiry in 2027: verify the issuer, not just the name

The certificate’s product label alone does not show whether it is affected. The relevant check is the certificate’s issuing chain and expiry in the developer account. Apple says its original Developer ID Certification Authority, or Sub-CA, expires on February 1, 2027, and certificates it issued stop working on that date. Apple’s announcement and intermediate certificate guidance are the references for this deadline.

How can a team tell whether a Developer ID certificate was issued by the old Sub-CA? Compare the certificate’s details in Certificates, Identifiers & Profiles with Apple’s description of the affected intermediate certificate. Record the issuer and expiry shown in the account. Do not infer the issuer from an identity’s display name, a saved certificate filename, or the fact that a build succeeded previously. Apple’s certificate overview explains that the effects depend on the certificate and how it is used.

For a local check, inspect the signing identities available to the build account:

security find-identity -v -p codesigning

The command lists identities available to that user’s keychain. It is useful for confirming that a signing identity is present, but it does not replace checking the issuer and expiry in the developer account. An identity appearing in this list does not, by itself, prove that it is the right replacement identity or that a release artifact uses it.

For an exported app, inspect its signature details:

codesign -dv --verbose=4 /path/to/App.app 2>&1

Review the authority and timestamp information in the output alongside the account record. Keep the output with the release evidence, but remove account details or other sensitive information before sharing it.

• A matching identity name is not sufficient evidence. Confirm the issuing chain and expiry in the account.
• A new certificate is not sufficient evidence of migration. Confirm that the real build account can use the identity and its private key.
• A successful past release is not proof of future installability. Validate the actual app or installer that will be distributed.

App updates and installer packages have different expiry outcomes

The key release decision is the artifact type. Apple distinguishes between already-released Mac software and installer packages signed by an affected certificate. The developer should not apply the .pkg deadline to every existing app.

The expiry date and package-install boundary come from Apple’s announcement. The continued operation of existing signed, notarized Mac software depends on the secure timestamp condition Apple describes; it is not a blanket assurance for every app or every distribution format.

Which existing Mac apps are affected by the old intermediate certificate expiry? For the expiry decision, distinguish a Mac app from an installer package. Apple says an existing Mac app that is signed, notarized, and has a secure timestamp can continue to work. That does not mean a future update can keep using the affected certificate, or that an installer package signed by it has the same outcome.

Does an already notarized app need to be signed again? Not solely because of this expiry, if it was signed and notarized with a secure timestamp. Keep the original release evidence and verify that the distributed app is the artifact covered by that evidence. A new version is a separate release: sign that update with the new Developer ID Application identity and assess its notarization requirements independently. Replacing a certificate does not automatically mean that an already released app must be notarized again.

The secure timestamp is a signing property, not the notarization result itself. Keep the two checks distinct. Apple’s Developer ID signing guidance describes the distribution context, while its code-signing certificate technical note explains certificate and signature details.

First acceptance check: match the certificate type to the artifact

Developer ID Application and Developer ID Installer are different signing identities used for different distribution artifacts. A migration can appear successful while still using the wrong identity for one release target.

• Developer ID Application is the identity to assess for signing a Mac app distributed outside the Mac App Store.
• Developer ID Installer is the identity to assess for signing a .pkg installer.
• Notarization is a separate assessment and record. Do not treat a successful signature check as proof that notarization succeeded.
• A secure timestamp is evidence associated with a signature. Do not use “notarized” and “timestamped” as interchangeable labels.

Apple’s Developer ID certificate creation instructions explain the available certificate types and creation process. During creation, review the intermediate certificate options against Apple’s current instructions. The correct choice can depend on the certificate path and the tooling used; it should not be copied from an unrelated setup guide without checking compatibility.

Older Xcode versions may have different certificate-creation or signing behavior. Confirm compatibility using Apple’s current instructions for the specific toolchain in the release environment. Avoid upgrading or changing certificate options based only on assumptions about what an older project requires.

For a package, inspect the actual signed installer:

pkgutil --check-signature /path/to/Installer.pkg

Save the output with the package’s release record. This check helps establish which signing certificate is attached to the file. It does not establish that the package installs correctly in the intended environment or that the release channel is ready to distribute it.

Second acceptance check: confirm the new identity includes its private key

A certificate file without the corresponding private key cannot perform the expected signing operation. The certificate and private key must be available to the account that runs the build, not merely to the person who created the certificate.

Run security find-identity -v -p codesigning as the actual build user. Confirm that the expected identity appears there. Then sign a release candidate using the project’s established process and inspect the result with codesign or pkgutil, depending on the artifact.

For a remote Mac, repeat the checks in the account and session used by automation. A certificate visible in an administrator’s login keychain may not be available to a CI job running under a separate account. A build that works only after an interactive user unlocks a keychain is not yet a reliable unattended release process.

Keep the migration evidence limited to what is needed:

• Certificate type, issuer, expiry, and the account record used to confirm them.
• The build account’s identity-list output, with sensitive account details removed.
• The final artifact’s signature inspection result.
• The notarization result or record, when notarization applies.
• The release task and build environment associated with those checks.

Never include private keys, reusable credentials, or secrets in logs, issue reports, or shared release notes. Apple’s certificate creation documentation is the reference for creating the replacement identities. Its common notarization issues guide is relevant if notarization itself fails, but certificate expiry should not be misdiagnosed as a notarization error.

Third acceptance check: prove the real release path still works

A certificate appearing in the account does not prove that an artifact has migrated. The acceptance target is the actual app update or installer produced by the release process.

Use this order of checks, adapting the commands to the project’s existing signing and notarization workflow:

1. Inventory distributed artifacts. List released Mac apps and .pkg files, then identify which signing identity each one uses. Prioritize installers signed by a certificate whose issuer matches Apple’s affected Sub-CA.
2. Confirm the account record. Check issuer and expiry in Certificates, Identifiers & Profiles. Save a redacted record or release note that allows another maintainer to repeat the decision.
3. Create the correct replacement identity. Create Developer ID Application for app updates and Developer ID Installer for packages that need that identity. Follow Apple’s current certificate creation and intermediate certificate instructions.
4. Verify keychain access as the build account. Run the identity-list command in the same account used by the local build or remote automation. Confirm that the corresponding private key is available without exporting it into logs or source control.
5. Build and sign a release candidate. Produce the app update or installer through the normal release workflow. Do not substitute a manually signed sample if the production pipeline uses different settings.
6. Inspect the artifact. Use codesign for the app or pkgutil --check-signature for the package. Compare the signer with the expected replacement identity.
7. Complete release-specific validation. For an app, verify the signature, notarization record, and timestamp evidence where applicable. For a .pkg, test installation in the intended release environment and confirm that the publication channel delivers the tested file.
8. Record the decision. Mark each artifact for continued use, future signing with the replacement certificate, or re-signing and revalidation before the deadline. Tie each decision to evidence rather than to a certificate-creation date.

The package rule is particularly important: Apple states that .pkg files signed by affected certificates cannot be installed from February 1, 2027. A team maintaining packages should schedule signing and installation acceptance before that date, rather than waiting for a release window that leaves no time to correct a failed package. Apple’s expiry announcement is the source for the deadline; the actual account record determines whether a specific certificate is in scope.

When must an affected Developer ID Installer package be re-signed? Before February 1, 2027, if it is signed by the affected certificate and is expected to remain installable after that date. Re-signing is not complete until the resulting package has been checked and accepted through the intended distribution path. Do not infer user-side behavior beyond Apple’s stated installation boundary without testing the actual package.

Decision rules for release owners

Use these rules to turn the inspection results into an action, rather than treating every certificate in an account as an emergency:

• Issuer confirmed as the expiring Sub-CA; artifact is a .pkg: arrange replacement signing and complete installation acceptance before the stated deadline.
• Issuer confirmed as the expiring Sub-CA; artifact is an existing signed, notarized, timestamped app: preserve its release evidence. Do not re-sign it solely because of the expiry.
• A future app update uses the affected identity: migrate the update to a new Developer ID Application identity and verify the resulting artifact.
• Issuer is unknown or account evidence is incomplete: pause the impact decision. Resolve the certificate record before changing production signing.
• The identity is present but the private key is unavailable to the build account: fix keychain access or the release environment before calling the migration complete.
• A new package passes signature inspection but has not been installed through the intended path: keep the package in acceptance testing; the signature check alone does not validate installation.

For teams maintaining a remote release machine, a remote Mac build and signing environment can keep the signing account and macOS toolchain separate from a developer’s daily workstation. That arrangement still requires controlled keychain access, credential handling, and artifact validation; remote access does not remove those responsibilities. Teams comparing recurring access costs with a dedicated machine can review Mac rental pricing, then weigh it against local hardware ownership and the need for physical access.

Keep the release environment controlled during migration

Certificate changes often expose environment assumptions that were already present: a signing identity may exist only in one user’s keychain, automation may invoke a different account, or a release script may select an old identity by name. These are not reasons to rework every project. They are reasons to verify the production path rather than rely on a developer workstation’s successful build.

For a small team, keep separate acceptance records for the app and package workflows. A Mac app update should identify its Developer ID Application signer and notarization result. A package release should identify its Developer ID Installer signer and installation acceptance. If a project produces both artifacts, passing one workflow does not validate the other.

The account of record should also reflect who can rotate or revoke signing assets and who can recover a release if the usual build host is unavailable. Store procedures and non-secret evidence where the team can retrieve them. Do not store private keys or reusable credentials in a repository merely to make a remote build easier.

A remote Mac is useful when a team needs a consistent macOS signing host without maintaining another local machine. It is not automatically the best fit for continuous, high-volume workloads that need a dedicated, permanently controlled machine, or for workflows requiring physical interfaces. Compare those constraints with the cost and maintenance of local hardware before moving the release process.

The practical outcome is artifact-specific: keep qualifying existing Mac apps intact, migrate future app updates to the replacement identity, and re-sign affected installer packages before Apple’s deadline. A remote Mac can make the release environment available without buying another Mac, but the migration is complete only when the correct identity, private key, signature, notarization evidence where applicable, and installation result have all been verified.