macOS Gatekeeper: How to Open a Blocked App and Safely Run a Prevented Installer
Learn how to open a blocked app on macOS: use System Preferences > Security & Privacy to unlock Gatekeeper, approve the installer, and run the app safely.
macOS will sometimes prevent an app or installer from launching, showing an alert that the software “can’t be opened” or is from an “unidentified developer.” This behavior is Gatekeeper at work: macOS’s built‑in system that enforces code signing, notarization and quarantine flags to reduce malware and accidental installs. When you need to run a legitimate installer that macOS has blocked — for example, an internal tool, a legacy app, or a third‑party utility you’ve verified — there are safe, supported ways to approve and open it. This article explains why macOS blocks certain software, walks through GUI and command‑line methods to override those blocks, describes the checks you should perform before overriding Gatekeeper, and outlines implications for developers and IT teams responsible for distributing software.
Why macOS blocks some apps
macOS applies several protections to downloaded software. Gatekeeper checks an app’s code signature, looks for developer IDs issued by Apple, and, for newer releases, verifies that the app has been notarized by Apple’s automated scanning service. When an app comes from an unidentified developer, lacks a valid signature, or carries a quarantine flag set by the browser or Mail app, macOS will show a warning and prevent the app from opening by default. This behavior reduces the chance that users will unknowingly run malware, but it also catches legitimate installers that haven’t been signed or notarized.
Another common trigger is the quarantine attribute attached to files downloaded from the internet. macOS attaches a metadata tag (com.apple.quarantine) that tells the system to treat the file as incoming from an external source; when you attempt to run or mount that file, Gatekeeper steps in. For installers distributed internally or for older software that developers haven’t re-signed, the result is a blocked installer even when the package is safe.
When it’s appropriate to override Gatekeeper
Overriding macOS protections should not be routine. Before you explicitly allow a blocked app, verify its provenance:
- Download from the vendor’s official website or your organization’s distribution server, not from an unknown mirror or file‑sharing site.
- Confirm checksums or signatures if the developer provides them (SHA‑256 or similar).
- Contact the developer or your internal IT if the app is an internal tool.
- Inspect the package contents if you know how, or run it in a sandbox or virtual machine first if possible.
Common, legitimate scenarios for permitting a blocked installer include enterprise software deployed outside the App Store, developer tools you built locally, older legacy apps that predate notarization requirements, and third‑party utilities from trusted vendors that haven’t updated their signing. If you can’t confirm the source, don’t bypass Gatekeeper — seek verification or use an isolated test environment.
Approve an app quickly using System Preferences
For many users the simplest, supported approach is the System Preferences route. If macOS blocks an installer after you double‑click it, follow these steps:
- Attempt to open the installer so macOS records the block.
- Open the Apple menu and choose System Preferences (or System Settings on newer macOS releases).
- In System Preferences, select Security & Privacy.
- In the Security & Privacy pane, click the General tab.
- Click the lock icon and authenticate with your administrator password to unlock controls.
- Look for a message that the app or installer was blocked and click Open Anyway.
- Re‑open the installer and confirm when the dialog asks if you want to open it.
This workflow preserves Gatekeeper’s logging while giving you an explicit approval path. It’s the recommended path for end users because it is auditable and reversible: it creates a local record in Security & Privacy and avoids changing system‑wide security settings.
Use the Control‑click (right‑click) Open option for a faster override
A quicker way to allow a single app without changing broader settings is Control‑clicking (or right‑clicking) the app icon in Finder:
- Control‑click or right‑click the blocked app or installer.
- Choose Open from the context menu.
- A dialog appears warning that the app is from an unidentified developer; click Open to run it.
This method lets you bypass Gatekeeper for that single launch while leaving other protections in place. It’s useful for occasional safe overrides and is often quicker than navigating to Security & Privacy settings.
Command‑line methods for power users and administrators
Power users and IT administrators sometimes need scriptable methods to approve or distribute apps. The following Terminal techniques are common; use them with care and only when you understand the security implications.
-
Remove the quarantine attribute (affects only the file you target):
xattr -d com.apple.quarantine /path/to/App.app
This command deletes the quarantine metadata so Gatekeeper won’t treat the app as an externally downloaded file. It’s effective for single apps or installers you’ve verified. -
Add a file to Gatekeeper’s allow list using spctl:
sudo spctl –add /path/to/App.app
spctl (the SecAssessment policy subsystem) can mark a specific app as allowed. Use this on managed machines when you’ve vetted the software. - Re‑enable or disable Gatekeeper (not recommended for general use):
sudo spctl –master-disable
sudo spctl –master-enable
Disabling Gatekeeper entirely exposes the system to risks and is rarely appropriate outside tightly controlled environments.
When using Terminal commands, be precise about paths and test on a non‑production machine if possible. Logging and change control are important when administrators apply these commands across multiple devices.
Handling disk images, PKG installers and mounted volumes
Many macOS installers arrive as .dmg disk images or .pkg packages. Gatekeeper’s behavior is the same in that the mounted package may be blocked until allowed. For .dmg files:
- Mount the .dmg by double‑clicking.
- If the installer on the mounted volume is blocked, follow the System Preferences or Control‑click methods to open it.
- After installation, unmount the disk image and remove the .dmg file to avoid reintroducing the quarantine flag if you rerun it later.
For .pkg installers you may see an immediate dialog: “Installer can’t be opened because Apple cannot check it for malicious software.” Proceed to Security & Privacy and choose Open Anyway, then run the installer after authenticating.
Troubleshooting when ‘Open Anyway’ does not appear
Sometimes the Security & Privacy pane does not show the “Open Anyway” option even after macOS blocked the app. If that happens, try the following:
- Move the app to a different folder (for example, move it to Applications) and try the Control‑click Open method again.
- Re‑download or re‑mount the installer, then attempt to open it once so macOS registers the event and surfaces the approval option.
- Run xattr to examine quarantine attributes:
xattr /path/to/file
If com.apple.quarantine is present, remove it with xattr -d as above. - Check that the app path you’re approving matches the exact path macOS blocked; duplicates or renamed files can confuse the UI.
- Restart the Mac if Security & Privacy is not updating — sometimes a system restart clears transient state.
- For stubborn cases, use spctl to evaluate what policy prevented execution:
spctl -a -vv /path/to/App.app
The command prints details that can help you identify missing signatures or entitlements.
If you manage a fleet of Macs and users run into this frequently, consider centralizing the fix through MDM policies or internal notarization workflows.
Notarization, code signing, and developer responsibilities
Developers and distributors control whether their apps trigger Gatekeeper. Apple’s requirements around code signing and notarization mean that properly signed and notarized apps generally open without intervention. Key practices for developers include:
- Sign your app with an Apple Developer ID certificate prior to distribution.
- Submit the app for notarization so Apple’s automated service scans it and vouches for it to Gatekeeper.
- Keep signing certificates current and renew them before expiration.
- Provide checksums on download pages so users can independently verify integrity.
- Use installer packaging best practices and avoid bundling unnecessary executables that may trip security scanners.
For developer tools, CI/CD pipelines often include signing and notarization steps. For enterprises, building an internal signing and distribution pipeline or using MDM to distribute signed packages reduces friction for employees while retaining security controls.
Enterprise distribution and MDM strategies
Organizations that distribute software to many Macs should avoid ad‑hoc user overrides. Instead:
- Use an MDM (mobile device management) solution to push trusted apps and configuration profiles.
- Whitelist internal developer certificates or specific bundles using MDM policy so end users aren’t required to bypass Gatekeeper manually.
- Configure system images with pre‑installed apps when appropriate.
- Monitor logs and implement central auditing to track which devices have exceptions applied.
These approaches scale better than instructing users to modify Security & Privacy settings or run terminal commands, and they maintain a consistent security posture across an organization.
Security trade‑offs and operational considerations
Allowing a blocked installer carries risk. Social engineering and trojanized apps are the most common threats, so guarding the approval process is essential. When you permit a blocked app:
- Limit the scope: prefer per‑app approvals rather than disabling Gatekeeper globally.
- Keep records of who approved what and why, particularly in teams using shared admin credentials.
- Combine Gatekeeper overrides with endpoint security tools that scan for known malware and enforce runtime protections.
- Educate users about phishing and verifying vendor sites; many malicious installers masquerade as legitimate software updates.
For businesses, the decision to permit an app should balance operational needs with compliance requirements. In regulated environments, documented change control and technical review of any exceptions are necessary.
Developer and ecosystem implications
Gatekeeper and notarization have pushed macOS developers toward modern signing practices. For developers, that means updating build pipelines, implementing notarization steps, and monitoring distribution channels. For the wider software ecosystem it creates a higher bar for trustworthiness but also introduces distribution friction for small vendors and open‑source projects.
Tools in adjacent ecosystems — CI/CD platforms, developer tools, automation software, security suites and MDM solutions — often provide integrated support for signing and notarizing builds. By adopting those tools, teams can reduce friction for users while staying within Apple’s security model.
Looking ahead, Apple’s tightening of runtime and distribution policies could further change how installers are packaged and delivered. Developers should plan for continued automation of signing and notarization steps, and IT teams should consider MDM or internal package repositories to streamline safe distribution.
macOS’s Gatekeeper is a valuable defense that prevents many accidental and malicious installs, but when you must run a blocked, legitimate installer there are safe, documented ways to do so: prefer the Security & Privacy “Open Anyway” workflow or the Control‑click Open option for single approvals; use Terminal tools like xattr and spctl only when you understand the implications; and, for organizations, manage exceptions centrally through MDM and signing practices. As the platform evolves, expect additional refinements to notarization and distribution that will continue to push developers and IT teams toward automated, auditable signing and delivery pipelines — reducing the need for manual overrides while preserving user safety.
