Verifying macOS Installer Authenticity
A macOS installer downloaded through the App Store or Software Update is signed by Apple and verified during download. An installer downloaded from a third-party site, received via file transfer, or stored for an extended period may have been modified or may have had its signature expire. The tools to verify macOS installer authenticity are built into macOS and take under a minute to run: codesign checks the code signature and signing certificate chain, spctl performs a Gatekeeper policy assessment, and for .pkg installers pkgutil --check-signature covers the package signature. This guide covers each tool, what a clean output looks like, and the common failure patterns you might encounter. Part of the how-to section, and the verification concepts here connect to broader security considerations around software supply chain.
Why verification matters
Code signing for macOS installers works as a chain: Apple's root certificate authority signs intermediate certificates, which sign Apple's code signing certificate, which signs the installer. If any link in the chain is broken, missing, or the signed content has been modified, verification fails. A valid signature means the installer was produced by the entity with access to that certificate (Apple, in this case) and has not been altered since signing. It does not verify the content's source independently of the certificate chain.
The practical risk scenario isn't typically a maliciously modified Apple installer — it's an installer redistributed from an unofficial source that has been modified to include additional software, or an old installer with an expired timestamp signature that macOS Gatekeeper rejects. Both are detectable with the tools below.
Verifying with codesign
codesign is the primary tool for examining code signatures on macOS bundles, applications, and disk images.
# Basic verification (checks signature integrity):
codesign --verify --verbose=2 "/Applications/Install macOS Sonoma.app"
# Clean output: "valid on disk" and "satisfies its Designated Requirement"
# More detailed output including certificate chain:
codesign --verify --verbose=4 "/Applications/Install macOS Sonoma.app"
# Look for: Authority=Apple Root CA in the certificate chain
# Show signing details including Team ID:
codesign -dvvv "/Applications/Install macOS Sonoma.app" 2>&1 | head -30
Clean codesign -dvvv output for a genuine Apple installer will show:
Authority=Software SigningAuthority=Apple Code Signing Certification AuthorityAuthority=Apple Root CATeamIdentifier=0000000000(Apple's own Team ID format)
Any deviation — an authority chain that doesn't trace to Apple Root CA, a missing authority, or a TeamIdentifier that isn't Apple's — means the installer is not from Apple.
The most common benign failure is a timestamp signature that has expired. Timestamped signatures record the time of signing in a verifiable way, allowing signatures to remain valid after the signing certificate expires — provided the timestamp was applied before expiry. Very old macOS installers (pre-2019) may have been signed without embedded timestamps, meaning they fail verification on current macOS even though they were genuine at the time. The error message is "code object is not signed at all" or a timestamp validation failure, not an authenticity issue.
Gatekeeper assessment with spctl
spctl queries the Gatekeeper policy engine — the same engine macOS uses when you first open a downloaded application.
# Assess the installer against Gatekeeper policy:
spctl --assess --verbose=4 "/Applications/Install macOS Sonoma.app"
# Clean output: "accepted" and source: "Apple"
# For a .pkg file:
spctl --assess --verbose=4 --type install "/path/to/installer.pkg"
spctl returning source=Apple confirms that the installer's signing authority is in the Gatekeeper approved list for Apple software. A result of REJECTED means Gatekeeper would block opening this file — either the signature is invalid, the certificate has been revoked, or the file doesn't meet notarization requirements.
Notarization checks
Notarization (introduced in macOS 10.14.5 as mandatory for new software, subsequently required for all software) means Apple's notary service has scanned the software and found no malware. Notarized software has a notarization ticket either embedded (stapled) or retrievable from Apple's servers.
# Check if notarization ticket is stapled to the installer:
xcrun stapler validate "/Applications/Install macOS Sonoma.app"
# Clean output: "The validate action worked!"
# Alternative: check notarization via spctl (combines signature + notarization):
spctl --assess --verbose=4 --type execute "/Applications/Install macOS Sonoma.app"
Older macOS installers predating notarization requirements won't have a notarization ticket and will fail xcrun stapler validate — this is expected, not a sign of tampering. Installers for macOS Mojave, High Sierra, and earlier were released before notarization was mandatory. For these, codesign verification remains the appropriate check.
Package installer verification with pkgutil
For .pkg format installers (common for system extensions, standalone packages, and redistributed tools):
# Check package signature:
pkgutil --check-signature /path/to/installer.pkg
# Clean output: Status: signed by a certificate trusted by macOS
# And certificate chain should show Apple-issued certificates
# List package contents without installing:
pkgutil --payload-files /path/to/installer.pkg | head -20
SHA checksum verification
Apple publishes SHA checksums for some software packages through its security advisories. When available, comparing the SHA-256 hash of a downloaded file against the published value confirms no in-transit modification.
# Calculate SHA-256 hash of a downloaded file:
shasum -a 256 /path/to/downloaded-file.dmg
# Compare against Apple-published hash from HT security advisories.
# The comparison must be exact — any difference means the file differs.
Apple does not consistently publish SHA checksums for macOS installer app bundles distributed through the App Store or Software Update — those channels provide their own integrity guarantees. SHA checksums are most useful for standalone package downloads from Apple's support pages (combinedupdate files, firmware updates, Boot Camp drivers) where a canonical hash may be published in a security advisory or update article.
Practical workflow
For a downloaded macOS installer app bundle: run codesign --verify --verbose=2 first for a fast pass/fail; if it passes, run spctl --assess --verbose=4 to confirm Gatekeeper assessment; optionally run xcrun stapler validate to confirm notarization. If any check fails on a file you expected to be genuine, do not proceed — re-download from the official source (App Store or Apple's support downloads page) and repeat the verification.