macOS - Security - Enforce Lock Screen on Inactivity

What the macOS inactivity lock enforcer does

This Automox Worklet™ enforces an automatic screen lock on macOS endpoints whenever a logged-in user has been idle past a configured threshold. The Worklet ships two artifacts to every endpoint: a small bash script at /Library/Application Support/Automox/idle_timer.sh that polls HIDIdleTime from IOKit, and a LaunchDaemon at /Library/LaunchDaemons/com.idletimer.axtask.plist that keeps the polling script running across reboots.

The default inactivity threshold is 900 seconds (15 minutes), set through the desired_logout_seconds variable in evaluation.sh and remediation.sh. A second variable, plist_interval, writes the StartInterval value into the LaunchDaemon plist and defaults to 120 seconds. Both values are surfaced at the top of each script so you can match the Worklet to a specific CIS Benchmark, HIPAA, PCI-DSS, or SOC 2 control without editing logic.

Once idle time crosses the threshold, the polling loop calls open -a ScreenSaverEngine, which engages the macOS screen saver and forces the user back through authentication on return. The Worklet does not flip defaults write com.apple.screensaver askForPassword or askForPasswordDelay on its own. Pair it with your existing MDM profile or a separate hardening policy when the CIS 2.5.x control requires an immediate password prompt on wake.

Why enforce an inactivity-based screen lock on Mac fleets

An unlocked Mac left at a desk, in a meeting room, or in a shared workspace is one of the cheapest paths to a data exposure incident. Without an enforced lock, mail, Slack, browser sessions with saved credentials, internal tools, and source code are all open to anyone who walks past. CIS Benchmark 2.5.x for macOS calls for an idle timeout no longer than 20 minutes; HIPAA's 164.312(a)(2)(iii) automatic logoff control and PCI-DSS 8.2.8 (15-minute session inactivity lockout) both point at the same baseline. SOC 2 Common Criteria CC6.1 expects the same control to be evidenced fleet-wide.

Users disable the screen saver because it interrupts a long Zoom presentation, MDM profiles fail to apply on freshly imaged hardware, and new hires arrive with the macOS default 20-minute timer that auditors flag as too loose. The Worklet inspects the idle_timer LaunchDaemon on every evaluation and rewrites the plist plus the helper script when the timeout has been changed or removed, so CIS macOS 2.5.x evidence holds between audit windows instead of waiting for the next screenshot review.

How macOS inactivity lock enforcement works

1. Evaluation phase: evaluation.sh first runs launchctl list | grep idletimer to confirm the polling daemon is registered with launchd. If the daemon is missing, the script exits 1 and remediation is scheduled. When the daemon is present, the script reads the interval value from /Library/Application Support/Automox/idle_timer.sh and the StartInterval integer from /Library/LaunchDaemons/com.idletimer.axtask.plist, then compares both against desired_logout_seconds and plist_interval. Any mismatch (missing file, stale threshold, drifted polling cadence) returns exit 1 and queues remediation; an exact match returns exit 0 and leaves the endpoint untouched.

2. Remediation phase: remediation.sh writes a fresh idle_timer.sh under /Library/Application Support/Automox/ and makes it executable with chmod +x. It then writes the matching LaunchDaemon plist with Label com.idletimer.axtask, the bash interpreter and script path under ProgramArguments, StartInterval set from plist_interval, and RunAtLoad set to true. The script then calls launchctl unload (to clear any stale registration) followed by launchctl load on /Library/LaunchDaemons/com.idletimer.axtask.plist. Once loaded, the polling script reads ioreg -c IOHIDSystem for HIDIdleTime, divides by one billion to convert nanoseconds to seconds, and triggers open -a ScreenSaverEngine when idle_seconds exceeds desired_logout_seconds. Exit 0 indicates the daemon loaded; exit 1 surfaces in Automox activity logs with the failing step in stderr.

Inactivity lock enforcement requirements

• macOS 10.12 (Sierra) or later on Intel or Apple silicon hardware; the script relies only on ioreg, launchctl, and the stock ScreenSaverEngine binary that ship with macOS

• Root privileges for the Automox agent so it can write under /Library/Application Support/Automox/ and /Library/LaunchDaemons/ and call launchctl load on a system daemon

• An existing /Library/Application Support/Automox/ directory (created during agent install); the remediation script writes idle_timer.sh into this path

• desired_logout_seconds in both scripts set to the idle threshold you want to enforce (900 by default, matching the 15-minute baseline used by CIS 2.5.x, PCI-DSS 8.2.8, and most HIPAA security plans)

• plist_interval set to the StartInterval value written into the LaunchDaemon plist (120 seconds is the recommended value and the cadence the evaluation script compares against)

• Separate MDM configuration profile or hardening Worklet for askForPassword and askForPasswordDelay under /Library/Preferences/com.apple.screensaver if your control set requires an immediate password prompt on wake (CIS 2.5.x)

Expected state after inactivity lock enforcement

After remediation, every targeted Mac shows com.idletimer.axtask in launchctl list, with idle_timer.sh present under /Library/Application Support/Automox/ and the matching LaunchDaemon under /Library/LaunchDaemons/. Subsequent evaluations return exit 0 without scheduling further remediation, so the policy goes quiet on compliant endpoints and only surfaces drift.

End users see the screen saver engage once they cross the configured idle threshold, and they re-authenticate before regaining access (assuming askForPassword is set through MDM or your companion hardening policy). To validate manually on a pilot endpoint, run sudo launchctl list | grep idletimer to confirm registration, cat "/Library/Application Support/Automox/idle_timer.sh" to confirm the interval value, and plutil -p /Library/LaunchDaemons/com.idletimer.axtask.plist to confirm the StartInterval integer. The launchctl and plutil reads add up to less than a second on the endpoint, so this policy can sit on the same daily cadence as the rest of your macOS hardening Worklets and keep the CIS, HIPAA, PCI-DSS, and SOC 2 evidence intact between audits.