One important difference between Intel and Apple Silicon Macs is that the latter can’t run unsigned code. Although executable code doesn’t have to be signed using an Apple certificate, or notarized, to run successfully on your M1 model, if there is a problem the error message is likely to confuse.

Instead of pointing out that what you just tried to launch wasn’t adequately signed, Big Sur 11.1 running on an M1 Mac complains that “you do not have permission” and refers you to a system administrator. Click on its Help button, and you’ll be further befuddled: this opens a page in the macOS User Guide which ultimately takes you to instructions on how to change file permissions.

In fact, the code signing error which has occurred is -67062, which indicates that macOS has been asked to run code which isn’t signed at all. It has absolutely nothing to do with permissions.

There’s also a simple workaround in many cases, which you definitely won’t discover if you follow up the misleading notion that this is about permissions. Chances are that the app you tried to run is a Universal App, in which case all you need do is open the Finder’s Get Info dialog and set it to be run following translation by Rosetta 2. This is because M1 Macs won’t run unsigned native (ARM) code, but will still run unsigned Intel code which has been passed through Rosetta’s translation. This is easily verified by taking a Universal App, stripping its signature using codesign, then running it with and without the Open using Rosetta option ticked.

If the app turns out to have just ARM executable code, not Intel, or should you want to run its ARM code despite its lack of a signature, then the best way forward is to sign it with your own ad-hoc signature using codesign – something that doesn’t require a developer account, or a certificate issued by Apple. You will, though, need to be absolutely certain that what you’re about to sign isn’t in the least bit malicious. I’ve explained ad-hoc and personal signing in this article.

When you launch an app from the Finder, this is passed to LaunchServices to handle. Although this starts the process of running the app, it puts that on hold while a whole series of checks are performed on the app. In just over 0.01 second, the LaunchServices daemon lsd calls for a trust evaluation on the code. This quickly returns the -67062 error, following which Apple Mobile File Integrity (AMFI) kills your app before it has even got going, as an “attempt to execute completely unsigned code (must be at least ad-hoc signed)”.

When the code is properly signed, even using an ad-hoc signature, that certificate is checked against any local list of revocations in /Library/Keychains/CARevocation.plist, which by default doesn’t exist. A relatively new subsystem, RunningBoard, then becomes involved and takes over management of your app’s access to resources such as memory and the GPU.

After that, AMFI runs a fuller signature check, LaunchServices fully registers the app in detail, then TCC (the privacy subsystem) gets to work on the app. An XProtect check is run on it, to ensure that it isn’t in its list of known malware signatures. The app’s signing certificate is checked online with Apple’s OCSP service to ensure that the certificate hasn’t been revoked, and any notarization is checked online with Apple’s CKTicketStore. If the app isn’t notarized, this returns an error of 3, but in the absence of a quarantine flag, that’s ignored, and the app is finally run.

Unsigned Intel apps – either those with only Intel code, or Universal Apps which have been set to Open using Rosetta – go through essentially the same sequence, but any code signing error of -67062 is ignored, as allowed by System Security Policy. Differences are best shown in the system policy evaluation result.

An acceptably-signed Universal App then returns a log entry similar to
AppleSystemPolicy evaluation result: 120, allowed, cache, 1611578100
An Intel executable being run using Rosetta translation returns
AppleSystemPolicy evaluation result: 125, allowed, skip-cache, 0
and failed, unsigned ARM code will return
AppleSystemPolicy ASP: Security policy would not allow process: 1197, /Applications/RostrumUU.app/Contents/MacOS/Rostrum
for example.

When you encounter an app which fails to open on an M1 Mac, resulting instead in that misleading alert, you now know what to do.