How to Check If a Mac App Is Signed and Notarized

Quick answer: To check if a Mac app is signed, run codesign -dv --verbose=4 /Applications/AppName.app in Terminal, and to see whether Gatekeeper accepts it and Apple notarized it, run spctl -a -vv /Applications/AppName.app. A valid signature tells you who built the app and that it hasn't changed since; notarization means Apple's automated check found no known malware when the app was submitted, which is not a guarantee that it's safe.

If you have ever wondered whether an unsigned app on Mac is safe to run, the short answer is that it depends, but unsigned apps carry meaningfully more risk than signed and notarized ones. Here is how to check any app on your Mac, what the results mean, and what to do when something looks off.

What Code Signing Actually Means on macOS

Code signing is a cryptographic process. A developer obtains a Developer ID certificate from Apple, then uses it to sign their application binary. The signature serves two purposes: it proves the identity of the developer, and it guarantees the code has not been modified since it was signed.

When you open an app, macOS checks this signature through a system called Gatekeeper. Gatekeeper evaluates whether the app is signed with a valid Developer ID, whether the certificate has been revoked, and whether the binary matches its signature. If any of those checks fail, macOS will either warn you or block the app from running entirely.

Apple's chain of trust works like this: Apple issues the certificate, the developer signs the app with it, and macOS verifies the signature at runtime. If the developer's certificate gets revoked (because they distributed malware, for example), every app signed with that certificate stops being trusted immediately. This is how Apple can remotely neutralize threats even after an app has been installed on your machine.

The Gatekeeper setting in System Settings determines how strict this enforcement is. By default, macOS only allows apps from the App Store and identified developers (those with a valid Developer ID). You can override this on a per-app basis, but doing so bypasses a meaningful security layer.

Signed vs Notarized: What's the Difference?

These two terms get used interchangeably, but they are different, and the distinction matters.

Signed means the developer has an Apple Developer ID certificate and used it to sign the app. This proves identity and integrity, but it does not mean Apple has inspected the contents.

Notarized means the developer submitted the app to Apple's notarization service before distributing it. Apple runs automated security scans on the binary, checks for known malware, validates the code signing, and if everything passes, issues a notarization ticket. This ticket gets stapled to the app so macOS can verify it even offline.

Notarization is a stronger guarantee than signing alone. A signed app tells you who built it. A notarized app tells you who built it *and* that Apple's automated scan found no known malware in it. Since macOS Catalina (10.15), Apple has required notarization for all Developer ID-distributed software, so any recently built app distributed outside the App Store should be both signed and notarized.

If an app is signed but not notarized, it was likely built before Catalina or the developer chose not to submit it. If an app is neither signed nor notarized, Gatekeeper will block it by default.

How to Check If a Mac App Is Signed

There are two ways to check: a quick visual method and a more detailed terminal approach.

Using Finder

Right-click any app in your Applications folder (or wherever it lives) and select Get Info. In older versions of macOS, signed apps would display the developer name under "Obtained from." However, this gives you limited information. For a real assessment, you need Terminal.

Using Terminal

Open Terminal and run:

codesign -dv --verbose=4 /Applications/Example.app

Replace Example.app with the actual app name. This command displays the full signing details, including the signing authority chain, the team identifier, the signing timestamp, and the hash algorithm used.

Key fields to look for in the output:

• Authority: Shows the certificate chain. A properly signed app will show the developer name, then "Developer ID Certification Authority," then "Apple Root CA."
• TeamIdentifier: The developer's unique Apple team ID.
• Timestamp: When the app was signed. If this is missing, the signature may not include a secure timestamp, which is a minor red flag.

To verify the signature is still valid (not corrupted or tampered with):

codesign -v /Applications/Example.app

If the signature is valid, this command produces no output. If something is wrong, you will see an error message explaining the issue.

Checking Gatekeeper Assessment

For the full Gatekeeper verdict, use:

spctl -a -v /Applications/Example.app

This tells you what Gatekeeper would do if you tried to open the app right now. You will see either "accepted" with a source (like "Developer ID" or "Notarized Developer ID") or "rejected" with a reason.

You can also check quarantine flags, which macOS sets on files downloaded from the internet:

xattr -l /Applications/Example.app

Look for the com.apple.quarantine attribute. If it is present, macOS knows the app was downloaded and will apply Gatekeeper checks. If it is absent (because someone stripped it with xattr -d), the app bypassed Gatekeeper entirely, which is worth noting.

Is an Unsigned App on Mac Safe?

Not necessarily dangerous, but definitely higher risk.

Many legitimate open-source tools are unsigned. Developers who do not want to pay for an Apple Developer account (or who philosophically object to Apple's gatekeeping) distribute unsigned apps regularly. Tools like some Homebrew packages, small utilities from GitHub, and niche developer tools often fall into this category.

However, a lot of Mac malware is unsigned, or signed only with a throwaway "ad hoc" signature that names no developer. The reason is simple: getting a Developer ID requires identity verification, and Apple can revoke certificates. Some malware has still carried a real Developer ID until Apple revoked it, which is why a signature alone is not proof of safety.

Think of it as a spectrum:

• Notarized + Signed: Highest trust. Developer is identified and Apple has scanned the binary.
• Signed only: Developer is identified, but Apple has not scanned the binary. Common for older apps.
• Unsigned but known: No cryptographic trust, but you may trust the source (a reputable open-source project, for example).
• Unsigned and unknown: No identity verification, no Apple scan, and you do not know the source. This is where the real danger lives.

The risk is not binary. An unsigned app from a developer you have used for years is different from an unsigned app you found on a random forum. But code signing exists precisely because you should not have to rely on reputation alone. For more on how to evaluate whether your Mac might already be affected by a bad app, see 5 signs your Mac has been compromised.

How to Check All Your Apps at Once

Running codesign and spctl manually on every app in your Applications folder is tedious. You might have fifty or a hundred apps installed, and checking each one individually is not realistic.

CoreLock's Apps screen does this on demand. When you click Re-verify, it checks the code signature and Gatekeeper and notarization status of apps at the top level of /Applications and ~/Applications. It flags unsigned apps and broken or expired signatures, and shows a label for each app rather than a score. It misses apps inside vendor subfolders, and it doesn't detect revoked certificates.

This is especially useful if you have accumulated apps over the years and do not remember where each one came from. The Apps screen surfaces the apps that need attention without requiring you to touch Terminal.

What to Do If You Find an Unsigned App

Do not panic. Finding an unsigned app does not mean you have malware. It means you have an app that has not gone through Apple's verification process, and that warrants a closer look.

Step 1: Identify the source. Do you remember where you downloaded it? Is it from a known developer or open-source project? Check the developer's website and verify you got the app from the official source.

Step 2: Search for it. Look up the app name online. If it is a well-known tool, you will find documentation, reviews, and other users talking about it. If you cannot find any trace of it, that is a warning sign.

Step 3: Check for persistence mechanisms. Malicious unsigned apps often install launch agents, login items, or cron jobs so they can survive a reboot. Check ~/Library/LaunchAgents/ and /Library/LaunchAgents/ for anything unfamiliar. If you are not sure what you are looking at, here is how to find hidden apps on your Mac.

Step 4: Consider alternatives. If a signed and notarized alternative exists for the same functionality, it is worth switching. You get the same tool with a meaningful trust layer added.

Step 5: Evaluate your antivirus coverage. macOS has built-in protections like XProtect, but they are not comprehensive. If you are running unsigned apps regularly, you want something that actively monitors behavior, not just signatures. For a comparison of your options, see XProtect vs third-party antivirus.

Bottom Line

Code signing and notarization are not bureaucratic checkboxes. They are the primary mechanisms macOS uses to establish whether software is trustworthy. Checking your apps takes one terminal command, and the information it gives you is worth the thirty seconds it takes.

If you do not want to run terminal commands on every app individually, CoreLock's Apps screen checks the apps in your Applications folders in one pass and flags anything unsigned or with a broken or expired signature. It doesn't detect revoked certificates.

Your Mac's security is only as strong as the weakest app you have installed. Know what you are running.