Apple Developer ID Certificate Expiry: What Mac Developers Must Replace

Direct answer: Apple’s original Developer ID Certification Authority expires on February 1, 2027. Mac apps that were already signed, notarized and given a secure timestamp will keep working, but affected .pkg installers will no longer install after that date. Developers using certificates from the old authority should create G2 replacements before the deadline and use the new certificates for future signing and updates.

Apple’s October 1 notice separates application continuity from installer continuity. That distinction matters: the deadline does not mean every previously distributed Mac app suddenly stops launching, but it can break an old installer package when someone tries to install it after the cutoff.

Will Mac apps stop working when Apple’s old Developer ID authority expires?

Not if the app was previously signed and notarized with a secure timestamp. Apple says that software will continue to work after the original authority expires. A secure timestamp lets macOS evaluate the signature at the time the software was signed, rather than treating the certificate’s later expiration as an automatic failure.

Future releases are different. Developers must sign future updates with a current certificate and include a secure timestamp when submitting the software for notarization. Apple’s notice concerns Developer ID distribution outside the Mac App Store; it does not announce a matching February 1 deadline for Mac App Store apps.

Which Developer ID certificates need replacement before February 1, 2027?

Apple says certificates expiring on or before February 1, 2027 are likely affected, but the expiration date alone is not conclusive. The reliable check is the issuer recorded on the developer’s own certificate.

1. Open Certificates, Identifiers & Profiles and review Developer ID Application and Developer ID Installer certificates.
2. In Keychain Access, select the certificate being used for signing and expand Issuer Name.
3. If the issuer’s Organizational Unit is Apple Certification Authority, Apple says the certificate came from the previous Sub-CA and should be replaced.
4. If the Organizational Unit is G2, the certificate came from the current Sub-CA and does not need replacement for this specific migration.

Apple warns developers to inspect their own Developer ID certificate, not the separate Developer ID Certification Authority entry in Keychain Access. The authority entry can also show Apple Certification Authority in its chain and is not the certificate that an account holder replaces.

Will old signed Mac installer packages still install after the deadline?

No, not when the .pkg was signed with an affected certificate. Apple says those packages will no longer install starting February 1, 2027. The package must be signed again with a current Developer ID Installer certificate before the deadline.

This installer rule is narrower than a claim that all old Mac software fails. An application bundle and the installer package that delivers it have separate signing roles. A previously signed and notarized app with a secure timestamp can remain valid even though an old affected installer package must be replaced.

How can developers replace an affected Developer ID certificate?

Apple’s replacement guide requires the Account Holder role and documents separate workflows for the two certificate types:

• Developer ID Application signs Mac applications distributed outside the Mac App Store.
• Developer ID Installer signs installer packages. Replacing one type does not replace the other.

1. Sign in to Certificates, Identifiers & Profiles as the Account Holder.
2. Create a new Developer ID Application or Developer ID Installer certificate. Repeat the process if both types are used.
3. When Apple asks for the intermediary, select G2 Sub-CA. Apple says this selection requires Xcode 11.4.1 or later; choosing another option may issue another certificate tied to the authority that expires in 2027.
4. Install the downloaded certificate and update signing systems, build pipelines and package jobs to use it.
5. Test a newly signed app or package before retiring the old workflow.

The G2 certificate authority is valid until 2031, but that does not give each issued Developer ID certificate a multi-year lifetime. Apple says G2-issued certificates are valid for one year and must be renewed annually.

What should a team audit before the certificate migration?

• Every active Developer ID Application and Developer ID Installer certificate, including duplicate names that may hide different issuers.
• CI/CD signing identities, keychains, secrets references and notarization jobs that still select the old certificate.
• Downloadable .pkg files, mirrors and release archives that customers may still install after February 1, 2027.
• Whether current app builds receive a secure timestamp before notarization.
• A rollback-safe test of the replacement certificate before the deadline.

Apple allows a team to hold up to five Developer ID Application certificates and five Developer ID Installer certificates at once. That capacity lets a team create and test a replacement before the affected certificate expires instead of switching every build system at the last moment.

What does Apple’s notice not establish?

• It does not say every old Mac app will stop launching on February 1, 2027.
• It does not place Mac App Store applications under this Developer ID migration.
• It does not mean a G2-issued leaf certificate remains valid until 2031; Apple says those certificates renew annually.
• It does not allow anyone outside the developer team to inspect private signing keys or replace certificates on the team’s behalf.

The practical deadline is therefore two-part: preserve already shipped application continuity by confirming secure timestamps, and replace affected signing certificates and installer packages before February 1, 2027.

Sources

• Apple Developer: Upcoming expiration of Developer ID Certification Authority (Sub-CA)
• Apple Developer: Replacing Developer ID certificates issued from the previous Sub-CA