Disable Root Account Login

What the macOS root login disabler does

This Automox Worklet™ takes the macOS root account off the login window and out of every interactive authentication path on managed endpoints. The root account itself still exists, because launchd, system daemons, and installer packages depend on uid 0. What the Worklet removes is the ability for a human standing at the keyboard, or an attacker with physical or screen-share access, to select root from the login window and authenticate as the superuser.

Mechanically, the script reads the AuthenticationAuthority attribute on /Users/root using dscl . -read /Users/root AuthenticationAuthority. If that attribute is empty, the account is already locked and the Worklet exits clean. If the attribute is populated, the remediation phase runs three dscl writes against the local directory node: delete AuthenticationAuthority, create Password with the value '*', and create UserShell pointing at /usr/bin/false. After remediation, the root account has no authentication mechanism, no usable password, and no shell to drop into.

Apple has historically shipped macOS with root login disabled by default, but the account can be re-enabled by a local admin through Directory Utility, by an MDM payload that sets a root password, or by inherited state on systems imaged from older builds. This Worklet treats the desired state as a baseline rather than a one-time setup step, so every evaluation re-confirms that the root account stays locked even after admin tools, migrations, or directory service changes.

Why hardening root login matters on every Mac

An authenticatable root account is the highest-value local credential on a macOS endpoint. Root bypasses sudo prompts, audit trails, and per-user TCC consent, so a single compromise of that password collapses every other access control on the host. CIS macOS Benchmark control 5.6 codifies the recommendation: disable login as the root user. The same posture appears in NIST 800-53 AC-6 (least privilege) and in the macOS Security Compliance Project profiles used by federal and regulated environments. Leaving root authenticatable is the kind of finding that surfaces in an audit long after the admin who enabled it has moved on.

This Worklet writes directly to the local OpenDirectory node with dscl, clearing the AuthenticationAuthority attribute and locking the password and shell fields on /Users/root. That removes the authentication path the macOS login window, screen sharing, and su rely on. Repeat runs on already-hardened endpoints exit at the evaluation step, and a Mac where someone re-enables root through Directory Utility or dsenableroot surfaces in the activity log at the next evaluation. The result is deterministic fleet evidence for CIS macOS 5.6 rather than a sampled audit walk.

How root account disablement works

1. Evaluation phase: The Worklet runs dscl . -read /Users/root AuthenticationAuthority against the local directory node and captures the result. An empty result means the root account has no authentication method registered, which is the locked state. Any non-empty AuthenticationAuthority means an admin or MDM payload has re-enabled root, so the endpoint is flagged non-compliant and remediation is scheduled. Exit code 0 means the endpoint already meets policy; exit code 1 triggers the remediation script.

2. Remediation phase: The script issues three dscl writes in sequence: dscl . -delete /Users/root AuthenticationAuthority strips the registered authentication methods, dscl . -create /Users/root Password '*' sets the password field to a value that cannot be matched by any input, and dscl . -create /Users/root UserShell /usr/bin/false sets the login shell to a binary that exits immediately with status 1, so even a shell session reached through another path returns no usable prompt. Together the three writes leave root unable to authenticate at the login window, in screen sharing, or through su. The remediation phase does not call dsenableroot -d, because dsenableroot is a higher-level wrapper that does not always produce the cleared AuthenticationAuthority the evaluation phase checks for.

macOS root disable requirements

• macOS endpoint with the Automox agent installed and running as root (the agent default)

• Local directory node available (dscl . -read /Users/root must succeed, which is the standard configuration on managed Macs)

• No active admin or end user workflow that depends on logging in as root at the login window; legitimate elevation should already use sudo from a standard admin account

• FixNow (RunNow) compatible, so the Worklet can be triggered on-demand from the Automox console for incident response or audit prep

• No parameters to configure; the script targets /Users/root by design and does not modify any other local account

Expected macOS root account state after remediation

After remediation, dscl . -read /Users/root AuthenticationAuthority returns no value. The root account is still present in the local directory and uid 0 continues to own system processes, but the account cannot be selected as a login on the macOS login window and cannot be reached via screen sharing, su, or any GUI authentication panel. Subsequent Automox policy evaluations report the endpoint as compliant without applying remediation again, because the evaluation phase finds AuthenticationAuthority empty.

To validate manually on a representative endpoint, run dscl . -read /Users/root AuthenticationAuthority and confirm the attribute is gone, then run dscl . -read /Users/root UserShell and confirm it returns /usr/bin/false. Attempting to switch to root with su root will fail with an authentication error. If a local admin later runs dsenableroot or sets a root password through Directory Utility, the next Worklet evaluation flags the endpoint and the remediation script restores the locked state. The fix is durable across reboots, OS upgrades, and Migration Assistant transfers, because the directory writes target the local node rather than a configuration profile that can be removed.