JHegg
June 19, 2026, 12:32pm
1
Hello,
I recently downloaded the latest stable version of slicer for MacOS and updated from a prior version. However, I get the “Cannot be opened because the developer cannot be verified error”.
I am aware that the preview version is known to have this issue, but I couldn’t find a support post of this happening with the stable version. Is this related to it being an update? (I dragged the icon into the Applications folder and I replaced the old one). I’m certain I downloaded the stable version, I downloaded it once and my IT person downloaded it again and we got the same result both times.
IT is reluctant to bypass the verification and use “open anyway” in settings. Is there a reason I’m getting this error, or things I could try to get the verification to read?
Thanks in advance,
Jens
The prior threads on this error are linked below:
Posting on behalf of a user. He apparently installed the latest mac preview, but got this error message after trying to start Slicer.
“Slicer” cannot be opened because the developer cannot be verified. macOS cannot verify that this app is free from malware
What is the proper way to override this?
Hello Slicer Support Team,
I am a Radiation Oncologist (MD, DNB) attempting to use 3D Slicer for my daily clinical cases (1-2 cases/day). I recently moved from an old, basic Windows laptop to a new MacBook Air M5, but the experience has been very difficult and I am unable to use the software.
The primary issues I am facing:
Security/Verification Issues: Upon installation, macOS could not verify the software. I had to manually go into my system settings and select “Open Anyway” just to get t…
pieper
June 20, 2026, 3:18pm
2
Yes, thanks for posting here. This is a known issue we recently became aware of and it’s being tracked here:
opened 08:10PM - 03 Jun 26 UTC
Title: Request: Sign and notarize the macOS application for improved Gatekeeper … and deployment compatibility
Hello Slicer maintainers,
First, thank you for the continued work on Slicer and for making such an important tool available as open source. I am opening this issue as a request to consider signing and notarizing the macOS application builds distributed by the project.
At present, the macOS application appears to be unsigned and/or not notarized by Apple. This creates friction for end users and for organizations that manage Macs at scale, because macOS Gatekeeper treats unsigned or non-notarized software differently from software signed with a Developer ID certificate and submitted to Apple’s notarization service.
Apple’s documentation for distributing macOS apps outside the Mac App Store recommends signing apps with a Developer ID certificate and notes that users gain additional assurance when the Developer ID-signed app is also notarized by Apple:
https://help.apple.com/xcode/mac/current/en.lproj/dev033e997ca.html
Apple’s notarization documentation is here:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
Apple also documents that hardened runtime is required for notarization:
https://developer.apple.com/documentation/security/hardened_runtime
This has a practical impact beyond the first-launch warning. Many managed macOS environments rely on automation tools such as Installomator and AutoPkg to download, validate, package, and deploy third-party applications. When a macOS app is not signed and notarized, it can limit or complicate use with these workflows because administrators cannot rely on normal Gatekeeper trust checks, Developer ID identity validation, or standard deployment verification patterns.
Examples of affected open source Mac admin tooling:
* Installomator: https://github.com/Installomator/Installomator
* AutoPkg: https://github.com/autopkg/autopkg
For institutional, lab, classroom, and managed-device deployments, having a signed and notarized Slicer.app would make the software easier to deploy safely and consistently. It would also reduce user confusion, help avoid security exceptions, and make it easier for Mac administrators to support Slicer in environments with stricter endpoint security policies.
Would the project consider adding Developer ID signing and Apple notarization to the macOS release process?
Possible acceptance criteria could include:
* macOS `.app`, `.dmg`, and/or `.pkg` release artifacts are signed with a valid Developer ID certificate.
* Release artifacts are submitted to Apple’s notary service.
* The notarization ticket is stapled where appropriate.
* The release process includes verification steps such as `codesign --verify`, `spctl --assess`, and notarization status checks.
* The project documentation notes that macOS builds are signed and notarized.
I appreciate that signing and notarization can add complexity to open source release pipelines, especially around certificate management and CI/CD secrets. Even so, this would be a significant improvement for Mac users and for organizations deploying Slicer at scale.
Thank you for considering this request.
There are also workarounds described there.