Gaaah - found it. It turned out I needed to download "Developer ID - G2 (Expiring 09/17/2031 00:00:00 UTC)" from https://www.apple.com/certificateauthority/ and open it in KeyChain. Then my other certificate was deemed valid and then I could sign. Thank you to @ibamba in this thread for pointing to solution

Found a solution - credit to ChatGPT. Directly sign the dylib files in Resources files codesign -s YOUR_CERTIFICATE -vvv --deep --timestamp --entitlements entitlements.plist path/to/YOUR_APP_NAME.app/Contents/Resources/*.dylib --force and THEN sign the full prject codesign -s "CERTIFICATE_ID_OR_NAME"  -v --deep --timestamp --entitlements entitlements.plist -o runtime "dist/YOUR_APP_NAME.app" --force Full tutorial: https://sites.google.com/site/petesjunkyard/how-to-turn-your-python-program-into-a-working-macos-app

Thanks for your reply Quinn. In this case, it appears that the problem was entitlements. I had to add the com.apple.security.cs.disable-library-validation entitlement to entitlements.plist in order to have the program not crash when I sign with hardened-runtime (-o runtime). Specifically, before signing, I could run ./dist/EagleEyesScan.app/Contents/MacOS/main And my app would launch. But after signing the main executable with: codesign -s "Developer ID Application: MY_CERTIFICATE" -v --timestamp --entitlements entitlements.plist dist/MY_APP.app/Contents/MacOS/main --force -o runtime ..., my app would crash when trying to run it again with ./dist/EagleEyesScan.app/Contents/MacOS/main After adding com.apple.security.cs.disable-library-validation was added to the entitlements and re-signining with the above command, it works. Re: --deep: every guide I have found online for manually signing bundles from Pyinstaller recommends using it, while acknowledging that you're "not supposed to" - it seems like a case where doing it the right way is complicated enough that people go for the quick and dirty. The code signing process in general has been much more difficult than I expected.