Changing developer certificates might affect installers next year

Apple is changing the security certificates it provides to developers, and from 1 February 2027 you may find some no longer work as they did, so blocking their use in macOS. This article attempts to explain what is changing, and how that affects developers, and could affect users as well.

All code that’s run in recent versions of macOS must be signed. While it can be ad hoc signed without a proper security certificate, apps and code supplied outside the App Store are now required to be notarised by Apple as well. Notarisation imposes additional requirements, among them signing using a certificate issued by Apple for that purpose, and a trusted timestamp of when the signing took place. The latter is an option when signing using the codesign command tool.

Signed apps

Apps signed using a Developer ID Application certificate, standard for those distributed outside the App Store, with a trusted timestamp enjoy an unusual benefit. Instead of them expiring when their certificate expires, the app can still be installed and run with an expired certificate, provided that certificate was valid at the time of the trusted timestamp. This is essential for users, as it means you can still download and run apps I built, signed and notarised years ago, even though their certificates have expired.

Apple has made two changes to those Developer ID Application certificates: it’s issuing them from a different certification authority (known as a Sub-CA, and referred to in certificates as G2), and those new certificates are only valid for one year, instead of the five years of the past. This shouldn’t affect users, although it means that developers will have an annual task of creating new certificates and switching to them for signing, a chore we could have done without.

Signed Installer packages

There’s another place you’re likely to encounter developer signing certificates, in Installer packages. Those can’t be signed using a Developer ID Application certificate, but require a separate Developer ID Installer certificate, and that has behaved differently in the past.

It used to be that signed Installer packages followed different rules, and their certificates had to be valid when the package was installed. If you tried to install a package whose Developer ID Installer certificate had expired in 2025, then that failed unless you cheated it by changing your Mac’s clock. More recently, Apple changed the rule for packages that had been signed with a trusted timestamp, to match app rules, and allow installation provided that the certificates were valid at the time of the trusted timestamp: “If your certificate expires, users can still install packages that were signed with this certificate as long as the package includes a trusted timestamp.”

Apple has made the same two changes to Developer ID Installer certificates, issuing them from its G2 Sub-CA, and providing certificates that are only valid for one year. For Installer packages that are notarised, and require a trusted timestamp for that, the effects should be the same as for apps, and the burden falls on developers to renew their certificate every year. But it’s not clear whether the same applies to all signed installer packages. This is further confused by Apple warning developers: “Installer packages (.pkg): Starting February 1, 2027, .pkg files signed with an affected certificate will no longer install. Re-sign all packages with your new certificate before this date.”

It may be that on 1 February 2027 we discover the hard way how true that warning might be.

Signed disk images

The final piece of this puzzle is what happens with disk images that are signed using a developer certificate? For this, you’ll want to read the manual for C-Command’s DropDMG (which you should be using anyway), where it’s stated that disk images are signed with Developer ID Application certificates, so presumably follow their rules, and don’t expire when those cease to be valid.

The first of February 2027 could prove an interesting time for many of us.

References

Certificates overview, in Apple’s developer Account Help
TN3161: Inside Code Signing: Certificates
C-Command’s DropDMG Manual, on signing disk images.

4Comments

Add yours

1
Bryan Christianson on October 16, 2026 at 7:13 am
Hi Howard

Little confused as my recently renewed cert has the following:
```
Common Name: Developer ID Certification Authority
Organisational Unit: G2
Organisation: Apple Inc
Not Valid Before: Friday, 2 October 2026
Not Valid After: Wednesday, 17 September 2031
```
I don’t see where I have to renew it again in 12 months.

LikeLiked by 1 person
- 2
  
  hoakley on October 16, 2026 at 7:16 am
  
  You’re looking at the intermediate certificate, which does have that long expiry date, Bryan.
  Look at the details of your certificate there, and you’ll see it expires in 2027.
  Howard.
  
  LikeLike
3

John Woods on October 16, 2026 at 7:22 am

Hi Howard,

A few clarifications if you don’t mind,

1. Do apps not notarised and distributed outside the App Store still have a workaround to launch or simply won’t run?

2. I assume these restrictions don’t apply to locally built code which runs indefinitely without any motorisation, just with adhoc signature?

3. It sounds like despite the change in CA and cert expiry, older apps that have expired certs that were valid will still run and install?

Thanks!

LikeLiked by 1 person
- 4
  
  hoakley on October 16, 2026 at 7:29 am
  
  John,
  1. I have explained how you can run signed but unnotarised code in this article. Nothing alters in that.
  2. This only applies to developer signing certificates. Ad hoc signing doesn’t rely on a certificate.
  3. Yes, as I have explained, the rules for validity when installing and running code haven’t changed.
  Howard.
  
  LikeLike

Signed apps

Signed Installer packages

Signed disk images

References

Share this:

Related