Apple has just released security updates for macOS Catalina and Big Sur. Yes, you saw that right, macOS 10.15 Catalina and 11 Big Sur.
These are formally macOS Big Sur 11.7.11 and Catalina Security Update 2026-001. Although billed as security updates, these extend the security certificates required by iMessage, FaceTime and Mac activation so they will continue working after January 2027. If you’re still running macOS 10.15 or 11, they’re essential. However, there are no published security fixes for either.
In my review of apps and the validity of certificates used to sign them, I dodged the thorny issue of those apps delivered from the App Store, writing that “their signatures will remain valid as long as the developer remains a member of its Developer Program.” If you care to take a look at some of those apps using Apparency, you’ll discover that many of them have certificates that expired on 7 February 2023 at 00:00:00 GMT. This article explains why, how they should still run, but may not in the future.
As I explained, the general rule for certificates is that, once they have expired by date, they’re no longer valid. However, to ensure that third-party apps and installers can still be used after their expiry, Apple usually includes a trusted timestamp in their signature. Provided the certificate was valid at the time the app or installer was signed, then macOS should accept it as still being valid, as long as it hasn’t been revoked. But App Store apps are different again.
For reasons unknown, Apple doesn’t sign App Store apps with trusted timestamps. As a result, when its certificate expires, that app’s signature should no longer be valid, and macOS should refuse to run it on that basis. What happens in practice is that it turns a blind eye to the certificate expiry, and runs the app regardless.
What you see in the log demonstrates that. At the start of its security checks by Apple Mobile File Integrity (AMFI), securityd discovers that its certificates no longer have “temporal validity”, and fail trust evaluation: 00.701706 com.apple.securityd cert[0]: TemporalValidity =(leaf)[]> 0
00.701753 com.apple.securityd cert[1]: TemporalValidity =(leaf)[]> 0
00.703344 com.apple.securityd Trust evaluate failure: [leaf TemporalValidity] [ca1 TemporalValidity]
Those entries are repeated multiply every time that app’s trust is evaluated, including by TCC. Despite that, the app passes its Gatekeeper evaluation “due to migration”: 00.718197 com.apple.syspolicy.exec GK evaluateScanResult: 2, PST: (path: c97bd5e74b98ed79), (team: 4GXF3JAMM4), (id: (null)), (bundle_id: (null)), 0, 0, 1, 0, 9, 0, 0
00.718213 com.apple.syspolicy.exec Allowing evaluation due to migration: PST: (path: c97bd5e74b98ed79), (team: 4GXF3JAMM4), (id: (null)), (bundle_id: (null))
00.718218 com.apple.syspolicy.exec Updating flags: [private], 513
As with all other apps, a ‘ticket check’ is performed on its CDHashes, first against the local ticket cache, then against records in the CKTicketStore via CloudKit. As App Store apps aren’t normally notarised as well, looking up their ticket in the CKTicketStore should be unsuccessful. In macOS Tahoe at least, there should be no XProtect scan or further checks, and the app should proceed to launch normally.
App Store apps are signed using an Apple Mac OS Application Signing certificate, relying on the intermediate Apple Worldwide Developer Relations Certification Authority, and back to the Apple Root CA. While the latter should expire on 9 February 2035, both the signing certificate and its intermediate have shorter lifetimes:
Older App Store apps should have an intermediate expiry of 7 February 2023, as explained here by Apple, and more recent apps that is likely to be 10 December 2030.
Older App Store apps are likely to have been signed with a certificate that expired on 7 February 2023, while more recent apps are likely to expire on 12 August 2026.
None of this should affect Intel Macs, although we’re likely to see increasing numbers of App Store apps that are Arm-only and won’t run on Intel systems. However, this will become more complicated with the retirement of Rosetta 2 next year.
Apple has stated its intention that full Rosetta translation support will end with macOS 27, although it intends to retain “a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles” beyond that. In practice, that means most x86 apps and command tools will stop working in macOS 28, in the autumn/fall of 2027. Apple silicon Macs will therefore continue to run Intel-only App Store apps until they are upgraded to macOS 28.
Their fallback then is to run Intel-only code in a VM running macOS 27 or earlier, as that will still be able to provide full Rosetta 2 support. Given the performance of code translated by Rosetta, and that of VMs, that’s far better than might appear. There’s one remaining problem with that, though: some App Store apps can’t run in virtualisation, as it doesn’t support connections to the App Store. Some can, and as a matter of interest the five that I used in these tests all do, although not always reliably, but others can’t. I don’t know of any reliable way of testing this other than trying it out.
Summary
macOS security checks ignore the expiry of certificates (including intermediates) used to sign App Store apps, and allow the app to run regardless.
Many App Store apps have expired certificates.
This shouldn’t affect Intel Macs in the future.
Running Intel-only App Store apps is unlikely to be supported from macOS 28 onwards, except for a limited range of unmaintained gaming titles.
Some Intel-only App Store apps might not run in a VM with Rosetta 2 support either.
The general rule with security certificates is that they’re only valid until their expiry date. When the certificate for a website expires, your browser should warn you if you try to connect to that site, and it will normally refuse to make the connection as a result. Thankfully, Apple’s signing certificates generally work differently.
When Apple adopted code signing using certificates that it issues, it recognised that applying that policy would result in apps having expiry dates enforced by their certificates, so applies a different rule. When a developer signs an app using their Developer ID Application certificate, a trusted timestamp is included to verify when that signing took place. Provided the certificate was valid at that time, and hasn’t been revoked since, the certificate is deemed valid by macOS.
The same principle applies to Developer ID Installer certificates used to sign install packages, only for several years they weren’t given trusted timestamps. As a result of that, those old installer certificates were only valid as long as the certificate.
Apple changed that several years ago, since when installer packages have normally been given trusted timestamps, so they now work the same as Developer ID Application certificates, and can still be run successfully after their certificate has expired, provided that it was valid at the time in their trusted timestamp, and hasn’t been revoked since. However, this has only recently been reflected in Apple’s guidance to developers, and is different from the account I gave here last week.
Check validity
Trying to open the app or installer package usually isn’t the best way to check whether its certificates are valid. Although you may sometimes be given an informative explanation, in most cases macOS will simply report the item is damaged and needs to be removed, leaving you in the dark as to what the problem might be.
The best way to check the validity of Apple’s certificates is using Apparency for apps, and Suspicious Package for installer packages. They will provide a detailed explanation of why the signature is valid or not.
Apps
Apps supplied from the App Store are signed not by the developer, but by Apple. According to Apple’s current account, their signatures will remain valid as long as the developer remains a member of its Developer Program.
Apps supplied independently are signed by their developer using their Developer ID certificate issued by Apple. Provided that the app’s certificate was valid at the time it was signed, and that certificate hasn’t been revoked by Apple, that will remain valid indefinitely. The same appears to apply to notarisation, which should remain valid unless Apple revokes it.
Although there’s nothing to stop developers using certificates from third party authorities, macOS doesn’t recognise those and will normally block the app from being run. If you ever come across one, contact its developer and tell them the certificate they’re using is wrong.
Installers
Older installers are likely to have been signed without a trusted timestamp. If that’s the case, they will cease being valid when their certificate expires.
More recent installers should have a trusted timestamp, in which case their signature will remain valid unless Apple revokes their certificate.
Complications
Some certificates, most notably those used by macOS installers and updaters, also rely on the intermediate Apple Worldwide Developer Relations certificate, which underwent a hiatus on 24 October 2019 when an old certificate expired and was replaced by a new one, which expires on 20 February 2030. That expiry will still limit the validity of some old signatures.
Some apps require restricted entitlements, issued by Apple to allow them to access features that are normally not allowed, such as making snapshots and bridge networking in macOS VMs. Although those should expire well into the future, they can rarely have their own expiry problems that could prevent an app from running.
Examples
This old Catalina installer app was signed without a trusted timestamp. Now that its certificate has expired, it’s likely to be unusable.
This macOS update installer package was also signed without a trusted timestamp, its certificate expired in the 2019 hiatus, and it’s now unusable.
This third-party installer package was signed in 2017, but has a trusted timestamp. Even though its certificate expired in May 2017, because it was still valid at the time of the trusted timestamp it should still be deemed valid.
This third-party installer package was only signed last July, but its Developer ID Installer certificate expired the following month. Because its certificate was valid at the time of the trusted timestamp it’s still deemed valid.
This year marks the twentieth anniversary of Apple’s announcement of the introduction of code signing, although it wasn’t unleashed until Mac OS X 10.5 Leopard the following year (2007). I doubt whether there’ll be crowds gathering to celebrate the occasion, but 2026 also marks the parting of the ways for Intel and Apple silicon Macs, as Tahoe is the last version of macOS to run on Intel processors. There have already been rumours that will bring changes to code signing and what code will run on Arm cores.
Apple had long maintained that users would remain able to run unsigned code in macOS, but that changed in November 2020 with the first Apple silicon models. Since then, all executable code run on those new Macs has to be signed. What hasn’t been mandatory is the use of a developer certificate for the signature. Instead, all build systems now sign code using an ad hoc signature by default, when no developer certificate is available. This enables ordinary users to build their own apps and command tools locally, and run them on their own Macs, as many continue to do. The same applies to codeless apps such as Web Apps introduced in Sonoma, which are automatically signed ad hoc by macOS.
Those who develop apps and command tools for distribution to others have been told to sign their code using their developer certificate, then to get it notarised by Apple. Although that’s by no means universal, and there are still a few apps that don’t fit the process well, the great majority of those distributed outside the App Store should now come signed with a developer certificate and notarised.
Unlike some other operating systems, the only developer certificates recognised by macOS are those issued by Apple, but they’re provided free as one of the benefits of its $99 annual subscription to be a registered developer, as are unlimited notarisations.
The next concern for many is what happens when a developer certificate expires. On other systems, certificate expiry can result in apps suddenly becoming unusable, but that isn’t the case with macOS. So long as the certificate was valid at the time it was signed, macOS will recognise it as being valid at any time in the future. This isn’t the case, though, with developer installer certificates, used to sign installer packages: those must be valid at the time of installation, and the same applies to Apple’s own macOS and other installers. That continues to catch out both developers and users.
So as far as Intel Macs are concerned, the arrival of macOS 27 this coming autumn/fall won’t affect their access to apps, provided they’re supplied in Universal format, with x86 code. Many major software vendors have aligned their support period with Apple’s, so those apps should remain fully supported on Intel Macs until Apple’s support for macOS 26 ends in the autumn/fall of 2028. The sting here is that depends on upgrading to Tahoe: stick with Sequoia and that support is likely to end a year earlier, in 2027.
If you’ve switched to Apple silicon, you may be concerned as to when macOS will cease providing Rosetta 2 support for the few remaining apps that aren’t already Universal. Apple has stated its intention that full Rosetta translation support will end with macOS 27, although it intends to retain “a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles” beyond that. In practice, that means most x86 apps and command tools will stop working in macOS 28, in the autumn/fall of 2027.
From then on, if you want to be able to run x86 code using Rosetta 2 translation, that will have to be in a virtual machine running macOS 27 or earlier. For once, the continuing inability of macOS VMs to run most App Store apps should have little or no effect. For installers whose installer certificate has expired, this may be a blessing, as it’s easier and less disruptive to set the clock back in a VM.
Apple has given no warnings, yet, of any changes to requirements for developer certificates, notarisation, or ad hoc code signing to come in macOS 27 or beyond. Given the time required for the adoption of code signing and notarisation, those would appear unlikely in the foreseeable future.
Key dates
All events occur with the autumn/fall release of the new version of macOS.
2026 (this year)
Intel Macs: Tahoe enters security-only support; new versions of some 3rd party products may be Arm-only Apple silicon Macs: first single architecture macOS.
2027
Intel Macs: Sequoia becomes unsupported Apple silicon Macs: full Rosetta 2 support ends.
2028
Intel Macs: Tahoe becomes unsupported; major 3rd party products likely to lose support.
Login
