When Mac admin rights outlive their timer.

This guide is about Privileges 2.x and was checked against Privileges 2.6.0, released on 17 September 2026. Key names are the ones you set in a configuration profile for the corp.sap.privileges preference domain.

How the timer works

When someone asks for admin, PrivilegesDaemon, which runs with root rights, adds them to the Mac's admin group. The countdown that should take them out again is run by the PrivilegesAgent, a LaunchAgent in the person's own session. SAP's maintainers put it this way: "the revocation of admin rights happens in the user context" (issue #277).

That design is reasonable, and the agent is relaunched if it quits. But it means the thing that ends admin rights runs alongside a person who, for those minutes, can change anything on the Mac.

Six reasons admin rights outlive the timer

1. The timer was never meant to end

An ExpirationInterval of 0 "disables the timeout and allows the user to request permanent administrator privileges." Unless a profile manages the interval, people can pick Never themselves. Renewals extend a grant too: AllowPrivilegeRenewal offers a Renew button before expiry, and from 2.6.0, AutoRenewalProcessPaths renews automatically while a listed process is running. There's no cumulative cap on renewals today; it's an open feature request.

2. The person isn't covered by the timer

With LimitToUser or LimitToGroup set, people outside the limit aren't managed by Privileges at all, so an admin right they hold has no timer. SAP confirmed this is "expected behavior" in issue #277. AutomaticRevocationExcludedUsers (2.5.2+) deliberately exempts accounts from every automatic revocation, which is right for a break-glass account and wrong for anyone else.

3. Something else changed the admin group

If another process adds or removes an admin, Privileges notices but doesn't undo it. A maintainer explained why: "If the admin privileges are changed by another process, Privileges is out of the game… it's a bad idea to change them again" (issue #185). Since 2.3.0, Privileges logs the change on the Mac. From 2.6.0, on macOS 14 or later with the system extension turned on, it logs every change to the admin group along with the process that made it. That record stays on the Mac, where an admin reads it with PrivilegesCLI --history. It raises no alert and sends nothing to a SIEM. Platform SSO set to make users admin at sign-in is one example reported to SAP (issue #185).

4. The person used their admin rights to keep them

This is the one SAP is most direct about. Its FAQ lists what a local admin can do, including "completely removing the Privileges application", "creating a new administrator account or modifying existing user accounts", and "resetting date/time… to try to trick Privileges". A second admin account outlives every timer, because Privileges only manages the account that asked. Persistence through a sudoers.d entry has been reported too (issue #92).

Tamper protection (2.5.0+, below) makes removing or stopping Privileges much harder. SAP is careful about what it promises, though: "we do not expect this mechanism to provide an absolute guarantee against a determined administrator" (issue #280).

5. The grant reported an error but went through

In issue #288 (September 2026), a Privileges 2.6.0 user reported that when the daemon logs Failed to verify group membership, "admin rights are actually granted anyway without the auto-revoke timer." The reporter linked it to directory cache delays on Macs signed in with an Apple Account. There's no release after 2.6.0 yet, so check the issue for a fix before you rely on it. An earlier report with the same symptom, issue #260, was closed because it couldn't be reproduced.

6. The profile didn't apply

Privileges reads managed settings only from corp.sap.privileges. A profile aimed at another domain, such as the daemon's, does nothing and raises no error (issue #274). On a Mac with no managed interval, the person chooses their own, including Never.

Settings that reduce the risk

All of these go in a configuration profile for corp.sap.privileges, deployed through your MDM. SAP's Managing Privileges page documents each one.

Keep LimitToUser, LimitToGroup and the …ExcludedUsers keys for the accounts that genuinely need them, and remember that anyone outside them has no timer.

How to check that admin rights ended

On the Mac, Privileges 2.6.0 adds a 30-day history:

/Applications/Privileges.app/Contents/MacOS/PrivilegesCLI --history --privilege-changes-only

Add --json for machine-readable output. From 2.6.0, the daemon's audit messages are also in the unified log:

sudo log show --predicate 'process == "PrivilegesDaemon" AND subsystem == "com.apple.defaults" AND category == "audit"'

Across the fleet, both of those live on the Mac, alongside the person who held admin. Send events off the Mac with RemoteLogging, and pair each granted event with its revoked event. A grant whose revocation never arrives is the one to look at. Check the admin group itself too: our free Unexpected admins check lists admin accounts that aren't on your permanent list.

What Privileges can't do on its own

SAP's FAQ says that "controls, mitigations, defense-in-depth, reporting, and auditing suitable to each organization's environments and threat models are needed. This is true with or without the use of the Privileges application."

Altiward adds checks against recorded grants, expiry enforcement, findings for unexpected admin membership and a server-side alert when its agent stops checking in. The agent must be running to check and enforce rights; a missing check-in shows a coverage gap rather than its cause. Session evidence covers admin rights and detected account changes. Correlate it with your existing security telemetry to investigate process activity. See how it works.

Sources

• SAP, Managing Privileges and Frequently Asked Questions, Privileges wiki
• SAP, Privileges release notes, 2.3.0 to 2.6.0
• GitHub issues #92, #185, #260, #274, #277, #280, #288