macOS employs a rigorous security architecture built upon code signing and application entitlements. Every legitimate application on a modern Mac is cryptographically signed by the developer and assigned specific entitlements—permissions that dictate whether the app can access the camera, use the microphone, or interact with kernel frameworks. Occasionally, due to aggressive antivirus scanning, incomplete software updates, or manual tampering, an application’s digital signature becomes corrupted. When this happens, macOS instantly revokes the application’s entitlements, causing it to crash on launch or silently fail when attempting to access hardware. To diagnose and repair these security anomalies, administrators must master the macOS codesign command-line utility.
Understanding Application Signatures and Entitlements
When an application is launched, the macOS Gatekeeper and AMFI (Apple Mobile File Integrity) subsystems verify the cryptographic hash of the application bundle against its embedded signature. If even a single byte within the .app bundle has been altered after the developer signed it, the hash mismatch triggers a security violation. Consequently, macOS strips the application of all its entitlements, neutralising it.
Verifying a Broken Signature
If an application repeatedly crashes with a Namespace CODESIGNING error in the system logs, or if it constantly prompts for microphone access but fails to record audio, you should immediately verify its signature.
Open the Terminal and use the codesign utility with the verify (-v) and verbose (-v) flags, pointing it at the application bundle:
codesign -vv -d /Applications/ExampleApp.appIf the application is healthy, the output will return valid on disk and satisfies its Designated Requirement. If the application has been corrupted, the utility will return a fatal error, such as:
ExampleApp.app: code object is not signed at all
ExampleApp.app: a sealed resource is missing or invalidThe “sealed resource is missing” error is the most common. It indicates that a file inside the application’s Contents/Resources/ directory was deleted or modified after the application was compiled and signed.
Dumping Application Entitlements
Sometimes the signature is mathematically valid, but the application is missing a specific permission required to function on a newer macOS version. You can extract and read the application’s XML entitlement payload using the --entitlements and --display flags:
codesign -d --entitlements :- /Applications/ExampleApp.appThis command outputs the raw plist structure. You can review this output to verify if the developer actually included the necessary entitlement (e.g., com.apple.security.device.camera). If the entitlement is missing from the compiled app, no amount of troubleshooting will grant the app camera access; the developer must release an update.
Repairing Broken Signatures via Ad-Hoc Signing
If a critical enterprise application has a corrupted signature (perhaps modified by a necessary internal management script) and refuses to run, you cannot regenerate the original developer’s cryptographic signature without their private key. However, you can force macOS to trust the modified application by replacing the broken signature with a local, ad-hoc signature.
Ad-hoc signing recalculates the cryptographic hash of the modified bundle and signs it using the Mac’s local identity. While this breaks the chain of trust to the original developer, it satisfies the local AMFI subsystem, allowing the application to launch.
To strip the broken signature and apply an ad-hoc signature, use the force (-f) and sign (-s -) flags:
sudo codesign --force --deep --sign - /Applications/ExampleApp.app--forcetells the utility to overwrite any existing, corrupted signature data.--deepensures that any nested frameworks or helper tools inside the application bundle are also recursively signed.--sign -(with a hyphen) instructs the utility to use an ad-hoc identity rather than looking for an Apple Developer Certificate in your Keychain.
After running this command, verify the application again using codesign -vv. It should now report as valid. While ad-hoc signing is a powerful troubleshooting technique to restore functionality, it should be treated as a temporary workaround until a clean, officially signed installer can be deployed to the endpoint.