Disable Screen Sharing

What the macOS Screen Sharing disabler does

This Automox Worklet™ turns off the macOS Screen Sharing service on every targeted endpoint. The service is the Apple-branded front end for the VNC protocol, and it is implemented by the com.apple.screensharing launch daemon defined in /System/Library/LaunchDaemons/com.apple.screensharing.plist.

The Worklet checks whether that daemon is already disabled, and if not, it unloads the service with the -w flag so the change persists across reboots. Once it runs successfully, the endpoint no longer listens on TCP 5900, and the Sharing pane in System Settings shows Screen Sharing as off.

Apple Remote Desktop, third-party VNC clients, and Finder's vnc:// handler all rely on the same daemon, so disabling it closes every native VNC entry point in one step. The Worklet does not touch your sanctioned remote-management agent (Jamf, Kandji, Intune for Mac, ScreenConnect, TeamViewer), which runs on its own service path.

Why disable macOS Screen Sharing

Screen Sharing exposes a VNC listener on TCP 5900 with authentication that is only as strong as the local account password policy. CIS Benchmark 2.4.12 explicitly calls for Screen Sharing to be disabled on macOS endpoints, and the control maps to NIST 800-53 AC-17 (Remote Access) and CM-7 (Least Functionality). An enabled VNC service is also a known reconnaissance target for credential-spray tooling, and it provides a remote attacker with full graphical control of the Mac if a session is reused or hijacked.

This Worklet runs launchctl unload -w /System/Library/LaunchDaemons/com.apple.screensharing.plist on every Mac in scope to stop the daemon and persist the disabled state in the system override database. Subsequent evaluations confirm the daemon stays disabled on already-hardened endpoints and surface the handful of Macs that drifted back on through the Sharing pane or a Migration Assistant restore.

How Screen Sharing disablement works

1. Evaluation phase: The Worklet runs launchctl print-disabled system and greps for the literal entry "com.apple.screensharing" => true. If the daemon is already disabled, the script exits 0 and the endpoint is reported compliant. If it is enabled (exit 1), the endpoint is queued for remediation.

2. Remediation phase: The Worklet executes launchctl unload -w /System/Library/LaunchDaemons/com.apple.screensharing.plist to stop the running service and write the disabled state into the system override database. The -w flag makes the change survive reboots without requiring a profile push.

Requirements for disabling Screen Sharing

• macOS 10.13 (High Sierra) or later, including Apple silicon and Intel Macs running Sonoma and Sequoia.

• Automox agent running as root so the launchctl call can write to the system domain.

• No active inbound Screen Sharing or Apple Remote Desktop session, since unloading the daemon terminates any in-flight VNC connection.

• Supported on macOS workstations and macOS Server installations.

• No MDM configuration profile is required. If your fleet is also managed by a profile that enables Screen Sharing, remove that profile or the daemon will reload at next check-in.

• Apple Remote Desktop disabled or paired with this Worklet. ARD enables Screen Sharing as a side effect, so disabling Screen Sharing while ARD remains on will fail to stick. Pair this Worklet with an ARD disablement policy or a kickstart -deactivate -stop step if your fleet has ARD provisioned.

• Mixed macOS versions are supported. The launchctl print-disabled subcommand has been stable since macOS 10.11, so the same evaluation logic works across Big Sur, Monterey, Ventura, Sonoma, and Sequoia without branching.

Expected state after Screen Sharing is disabled

After a successful run, com.apple.screensharing is marked disabled in the system launch domain and does not start on boot. The endpoint stops listening on TCP 5900, sharing -a list no longer shows the Screen Sharing service as active, and the System Settings Sharing pane reports Screen Sharing as off.

To verify out-of-band, run launchctl print-disabled system | grep com.apple.screensharing on a remediated endpoint. The expected output is "com.apple.screensharing" => true, which is what the evaluation script greps for on the next run. From a separate Mac, an attempted vnc://endpoint.example.com connection should fail to negotiate. Re-running the Worklet on the same endpoint exits 0 and reports compliant, which is the steady-state signal you want across the fleet.

The evaluation script returns exit 0 when com.apple.screensharing is already disabled in the system launch domain, and exit 1 when the daemon is still enabled. Automox interprets exit 1 as a remediation trigger, so the remediation script then runs and unloads the service. After remediation, the next evaluation cycle exits 0, which is your confirmation that the change persisted.

An endpoint that stays in exit 1 across multiple cycles usually points to a configuration profile re-enabling Screen Sharing, an MDM enrollment that pushes Remote Management, or a user with admin rights toggling the Sharing pane back on. Cross-reference the Automox activity log with Jamf, Kandji, or Intune for Mac policy assignments to find the source. The CIS Benchmark 2.4.12 audit step is a one-line evaluation, so the Worklet's evaluation output is the same artifact a CIS-CAT scan would produce for that control. If a local admin flips Screen Sharing back on from System Settings, the next evaluation pass catches it and re-remediates, giving you continuous enforcement instead of a one-time fix.