Apple has announced that the original Developer ID Certification Authority (Sub-CA) expires on February 1, 2027. Any Developer ID certificate issued by that authority will stop working on that date, and installer packages signed with an affected certificate will no longer install.
If you distribute Mac software outside the Mac App Store, this affects you directly. Here is what changed, who needs to act, and exactly what to do before the deadline.
What changed
Developer ID certificates are what let you sign Mac apps and installer packages for distribution outside the App Store. Those certificates are issued by a certification authority, and the original Sub-CA that signed many long-lived Developer ID certificates has a hard expiration date: February 1, 2027.
Two consequences follow:
- Certificates issued by the old Sub-CA stop working on February 1, 2027.
.pkginstaller files signed with an affected certificate will no longer install starting that date.
There is one important exception: Mac apps that were previously signed and notarized with a secure timestamp keep working. Gatekeeper validates the notarization ticket against the timestamp, so already-distributed apps are not broken by the authority expiring. The problem is concentrated in installer packages and in any future signing you do with the old certificate.
Apple’s replacement path is the current authority, Developer ID Certification Authority (G2). Note the trade-off: the G2 authority itself is valid until 2031, but certificates it issues expire annually and must be renewed every year. That is a shift from the longer-lived certificates some developers hold today.
Who is affected
You are affected if any of the following is true:
- You hold a Developer ID certificate that expires on or before February 1, 2027 and was issued by the old Sub-CA.
- You distribute installer packages (
.pkg) signed with such a certificate. These will stop installing on February 1, 2027. - You plan to sign or re-sign Mac software after the deadline and would otherwise reach for the old certificate.
You are largely in the clear if your Mac apps were already signed and notarized with a secure timestamp — they keep working. You still need a new certificate for future builds and updates, but there is no emergency for already-shipped apps.
Developers still building on Xcode 11.4 or earlier need to update Xcode before creating a new certificate, so factor that in if you maintain a legacy project.
What you need to do
-
Check whether you’re affected. Open Certificates, Identifiers & Profiles and look for Developer ID certificates expiring on or before February 1, 2027. To confirm which authority issued a certificate, follow Apple’s guidance in Replacing Developer ID certificates issued from the previous Sub-CA — the authority is recorded in the certificate details, so don’t rely on the expiration date alone.
-
Update Xcode if needed. If you’re on Xcode 11.4 or earlier, update to a newer version before generating your replacement certificate.
-
Create a new certificate from G2. Generate a Developer ID certificate from the current authority, Developer ID Certification Authority (G2). Remember that G2-issued certificates expire annually, so put a renewal on your calendar now — this becomes a yearly task.
-
Select the G2 Sub-CA when prompted. When Xcode or the certificate process asks for a Developer ID Certificate Intermediary, choose G2 Sub-CA. Picking another option can issue a certificate that also expires in 2027, which would put you right back in this position.
-
Re-sign your installer packages. Any
.pkgsigned with an affected certificate will fail to install after February 1, 2027. Re-sign all packages with your new certificate before that date, and re-upload or re-distribute the updated installers wherever users download them. -
Plan signing for future app updates. Already-notarized apps with a secure timestamp need no action. But for every future update, sign with your new certificate and include a secure timestamp when notarizing. If your build scripts hard-code the old certificate’s name or hash, update them now so the next release doesn’t fail.
A practical addition: after re-signing, verify your packages with
pkgutil --check-signation YourInstaller.pkg
and confirm the signer chain resolves to the G2 authority before you ship.
Key dates
- February 1, 2027 — The original Developer ID Certification Authority (Sub-CA) expires. Certificates issued by it stop working, and
.pkgfiles signed with an affected certificate will no longer install.
FAQ
Will my already-shipped Mac apps stop working?
No, as long as they were signed and notarized with a secure timestamp. Apple states that previously signed and notarized Mac software keeps working with no action needed. The hard break applies to installer packages signed with an affected certificate and to any new signing done with the old certificate after the authority expires.
Why do G2 certificates expire every year?
The G2 authority is valid until 2031, but the certificates it issues expire annually and must be renewed each year. This is a deliberate property of the new chain, so build certificate renewal into your annual release process rather than treating it as a one-time migration. Set a reminder well before your certificate’s expiration date so a lapsed certificate never blocks a release.
What happens if I pick the wrong intermediary when creating my certificate?
When prompted for a Developer ID Certificate Intermediary, you must select G2 Sub-CA. Apple warns that choosing another option may issue a certificate that also expires in 2027 — meaning you’d have to repeat this entire migration within months. If you’re unsure which you selected, check the certificate’s chain in Keychain Access or Certificates, Identifiers & Profiles before you re-sign anything with it.