Disable Wake for Network Access

What the Wake for Network Access disabler does

This Automox Worklet™ disables Wake for Network Access on macOS endpoints by setting the womp parameter to 0 in the system power management database. The Worklet reads the current value with pmset -g, and if womp is enabled it runs pmset -a womp 0 to clear the flag across every power profile.

Wake for Network Access (the macOS name for Wake-on-LAN over the built-in Ethernet or Wi-Fi adapter) lets another host on the local network bring a sleeping Mac back online with a magic packet. The feature predates modern remote-management tooling and is rarely needed on a fleet that uses MDM, Automox, or any cloud-managed agent. Leaving it enabled creates a wake path that bypasses screen lock, FileVault unlock prompts, and any conditional-access gate sitting in front of the OS login.

The pmset change is persistent. It survives reboots, sleep cycles, and software updates, and it applies to all three pmset profiles (AC power, battery, and UPS) because of the -a flag.

Why disable Wake for Network Access on macOS endpoints

Wake for Network Access is a recurring CIS Benchmark for macOS finding (Control 2.5.1 in the CIS macOS Sonoma and Ventura benchmarks) and shows up in NIST 800-53 SC-7 (Boundary Protection) audits when reviewers ask which services can bring an endpoint out of an unattended state. An attacker on the same broadcast domain can send a magic packet to wake a sleeping Mac, then attempt to log in, sniff resumed connections, or trigger any wake-driven service such as Remote Login (SSH), Screen Sharing, or Remote Management. The exposure widens on shared Wi-Fi (guest networks, conference centers, co-working spaces) where any client on the SSID can reach broadcast traffic.

The womp flag is one of the values that quietly comes back after a hardware change, a Migration Assistant restore, or a user toggling the Power options pane in System Settings. Running this Worklet on a weekly Mac policy catches the re-enabled state on the next evaluation, before it shows up in a CIS 2.5.1 audit or an opportunistic wake against a sleeping laptop.

How Wake for Network Access disabling works

1. Evaluation phase: The evaluation script runs pmset -g and parses the line beginning with womp using grep and awk to extract the numeric value. If the value is 1, the script echoes "Wake for network access enabled. Moving to remediation..." and exits with code 1, which Automox interprets as non-compliant. If the value is 0 or absent (older Macs without a wake-capable adapter), the script echoes the disabled state and exits 0 with no remediation queued.

2. Remediation phase: The remediation script repeats the pmset -g check, and when womp is still 1 it runs pmset -a womp 0. The -a flag writes the setting to the AC, battery, and UPS profiles in a single call, so the endpoint cannot fall back to a wake-enabled profile after a power-source change. The script then exits with the pmset return code, and the next policy evaluation confirms the new state.

Wake for Network Access enforcement requirements

• macOS 10.13 (High Sierra) or later (pmset womp is consistent across this version range and every newer release through Sonoma and Sequoia)

• Root privileges for the Automox agent (the default agent context already meets this; pmset -a requires sudo when run interactively)

• Access to /usr/bin/pmset, which ships with the macOS base install and is not removed by hardening profiles

• No MDM configuration profile that pins com.apple.MCX.PowerManagement with Wake on LAN set to true; an MDM-pinned value re-applies on every check-in and overrides the Worklet

• FixNow compatible: schedule on a recurring policy for continuous enforcement, or invoke from FixNow to clear a specific endpoint immediately

Expected pmset state after remediation

After remediation, pmset -g returns womp 0 on the endpoint, and the System Settings > Battery > Options pane (or Energy Saver on older macOS releases) shows "Wake for network access" unchecked. A magic packet sent to the Mac's MAC address from another host on the LAN no longer wakes the system; the endpoint stays in its current power state (sleep, hibernate, or off) until a local user, a scheduled wake event, or a USB peripheral wakes it.

Validate the change by running pmset -g | grep womp on the endpoint; the output should be a single line reading womp 0. For audit evidence, capture the full pmset -g output with the policy run identifier and store it alongside the Automox activity log entry. The Worklet's evaluation phase will report the endpoint as compliant on every subsequent run, and only flips back to non-compliant if an administrator (or a configuration profile) re-enables womp.