Apple announces the original Developer ID Sub-CA expires on February 1, 2027

What happened on 2026-10-01

On 2026-10-01, Apple Developer News published "Upcoming expiration of Developer ID Certification Authority (Sub-CA)" (date as shown on Apple's page). The notice said the original Developer ID intermediate authority expires on February 1, 2027, and certificates issued by it stop working on that date. Apple asked developers to find certificates expiring on or before that day in Certificates, Identifiers & Profiles and to create replacements from the current Developer ID Certification Authority (G2). G2 is valid until 2031, but the certificates it issues expire annually and must be renewed each year. Developers on Xcode 11.4 or earlier should update first and choose the G2 Sub-CA when prompted. For distribution, Apple separated two cases: from that date, .pkg installers signed with an affected certificate will no longer install and should be re-signed beforehand, while previously signed and notarized Mac software with a secure timestamp keeps working. Future updates should use the new certificate and include a secure timestamp.

What it means for a defender's threat model

For obfuscated or hardened Mac apps, signing is usually the last pipeline step, and a certificate rotation is easy to treat as paperwork. It does touch real engineering boundaries. First, build scripts that select a signing identity by certificate hash or a fixed identity string must be updated. Second, if your app includes its own signature-integrity check that pins the old certificate fingerprint, a legitimate update signed under G2 could be rejected by your own logic; checks based on the Team ID and designated requirement usually survive rotation better, but confirm that by testing. Third, Apple treats .pkg installers differently from notarized apps, so teams still offering older installer downloads need a separate plan. Be honest about the limits as well: a signature proves origin and integrity, not confidentiality. A new certificate does not make the binary any harder to analyze.

Checks on your own builds

Work through your own artifacts in order. Inspect shipped builds with codesign -dvvv or pkgutil --check-signature to see whether the intermediate is the old Developer ID CA or G2, and record the leaf certificate's expiry date. Search build scripts, notarytool configuration and CI keychains for certificate hashes or identity names. If your app checks its own signature, confirm that the check relies on the Team ID and designated requirement rather than a pinned fingerprint. Then run the full sequence with the new certificate: hardening, signing, notarization, stapling and installation. Verify the Gatekeeper result on a clean machine and run a functional regression pass on the hardened build. Finally, set a reminder for the annual renewal that G2-issued certificates require.

Your checklist

• Use codesign / pkgutil to see whether shipped artifacts chain to the old Developer ID CA
• Check whether your app's own signature check pins an old certificate fingerprint
• Re-run signing, notarization and install tests with a G2 certificate and re-sign .pkg files still offered