Standing admin access is on the way out, and access is becoming a request with a timer

For about six years I could type our local admin password from muscle memory. So could a contractor who stopped working with us in 2019.

I do not know whether he still can, because we never changed it. Changing it meant touching machines nobody wanted to touch, on a Saturday, for a benefit nobody could put on a slide.

That is the shape of the problem with a shared local admin credential. If you know it, you have the whole fleet. There is no way to hand one person access for one afternoon, because once they know, they know, and the knowledge leaks in the most ordinary way imaginable: a new technician gets told in their second week, someone reads it off a shoulder, it lands in a runbook that lands in a wiki that becomes a Slack search result. Two years later you cannot honestly answer the question "who has local admin here."

The audit story is worse than the access story. Our logs could tell us local admin had been used on a machine. They could not tell us by whom, and without additional tooling they could not tell us what got done with it.

Architecture, not hygiene

The best sentence I have read on this subject is that standing secrets on endpoints are an architectural problem, not a hygiene problem.

Sit with it for a second, because it reorganizes the whole conversation. Nearly every improvement most of us have shipped in this area has been a hygiene improvement: rotate more often, scope the account tighter, vault the password, alert on use. All real work. None of it touches the actual defect, which is that a credential capable of privileged action is sitting on a laptop that goes to coffee shops.

Endpoints are bad at holding secrets. That is simply what they are: general-purpose machines, physically in the hands of people who are not you, running software you did not audit.

"Just don't give people admin." Tried it. What happens is that people find a way, because they have work to do and admin is standing in front of it. A developer needs a build tool. Someone in marketing needs a driver for a plotter. A colleague in the next row knows the password. The credential ends up on the machine anyway, except now it is there without your knowledge, which is strictly worse than the state you were trying to leave.

"Write a temp-admin script." This one is more seductive because it feels like engineering. A script on the endpoint calls the identity provider's API, adds the user to an admin group, sets a timer, removes them later. Same flaw, wearing a nicer jacket: an API credential capable of granting admin now lives on every laptop in the company. Rotation is manual. Revocation is manual. When somebody leaves, or a machine goes missing, you are back to your Saturday.

One team hit this wall in a particularly clarifying way. Their identity provider, at the time, only issued fully privileged API keys. God mode or nothing. So shipping a temp-admin script would have meant deploying a master key to the entire identity system onto every single laptop, which is the kind of sentence that ends a design review early.

Their reframe: what if we never had to put the key on the endpoint at all.

What that actually looks like, end to end

The mechanism is the interesting part, and it is more approachable than it sounds.

Trust is bootstrapped with a certificate. At enrollment, every Mac receives one. Requests from the on-device script are signed using a secret derived from it, so the service on the other end can establish that a request genuinely came from a managed device rather than from somebody with a terminal and free time. Their next iteration moves from a single fleet-wide certificate to per-device certificates issued through an MDM-integrated CA, so one compromised machine can have its own trust revoked instead of forcing a fleet-wide roll. If you build this, start there.

The user asks for it in one click. A self-service dialog, a button, and a short dropdown of reasons. They began by letting people free-type a justification and offering more granular options, and discovered users only ever needed a handful of basic choices. The rest was decoration.

Two things happen simultaneously. Locally, a script adds the user to sudoers and the local admin group right away, and arms a launchd timer to take it back in 20 minutes. That local grant requires no network, which means somebody on a plane or fighting a hotel captive portal still gets admin. At the same time, the script signs and sends a request to a middleware service. The middleware validates the device certificate, the enrollment status, and the requested scope, then calls the identity provider on the device's behalf using credentials that never leave the middleware's own environment.

Both sides log independently. The on-device component and the identity provider each emit to the SIEM, so the two records can be cross-correlated afterward. A grant that shows up in the middleware's logs with no matching on-device event is either a process failure or somebody obtaining access through a path you did not build. Both are worth a phone call.

Three timers and a reboot

Revocation is where homegrown versions of this tend to rot without anybody noticing, so be unfashionably redundant about it. This build uses three independent layers.

The local launchd timer expires the grant after 20 minutes whether or not anything else on earth is reachable. The identity provider runs its own timer, and more usefully re-asserts "this person is not supposed to have admin" as the default state on every check-in, which catches any case where the local timer failed to fire. An MDM-side check looks for the specific smell of a broken system: you have admin, and your timer expired a long time ago.

A reboot revokes immediately regardless of what any timer believes.

Now the payoff, as plainly as I can put it. If one of these laptops gets fully compromised, the worst thing the attacker can do through this system is grant themselves admin on that one machine, which the legitimate user was already authorized to request. That is a bad day, and it is nowhere near a master key to your identity provider. The distance between those two outcomes is most of what security engineering actually buys you.

The part your manager will care about more than the architecture

They shipped it without an approval gate. On purpose.

Asked directly whether higher-risk actions ought to require someone to approve, the answer was that removing standing admin had already produced enough internal pushback, and they were deliberately deferring the approval layer until the current model settled. Their framing: don't let perfection be the enemy of good, and recognize that each increment costs organizational capital.

I think that is the most useful thing in this whole story, and I say that as someone who has personally killed two good projects by insisting on the complete version of them.

You get a limited number of "everybody has to change how they work" requests per year. Spending one on time-boxed admin and banking the approval workflow for next year is the design working correctly, executed at the speed an organization can actually absorb.

Before you turn this on for the whole fleet

Two warnings, both earned.

The service becomes load-bearing infrastructure the moment you deploy it. Every endpoint has to reach it, from anywhere, at any hour. Public-facing, in other words. That means containerized deployment, DoS protection, real monitoring, and the same uptime expectation you hold for the devices themselves. Keep one scenario in your head: a developer who cannot reach the service, cannot self-elevate, and therefore cannot push a hotfix at 11pm. Bring infrastructure and security in early rather than handing them a finished thing.

Do not reinvent security. Use the libraries that exist for signing, certificate validation, and checksums. Library crypto gets CVE patches. Your clever inline version gets a comment that says "TODO: revisit."

You do not have to build any of this yourself

If reading that made you tired, the good news is that identity providers have been moving the same direction and you can buy most of the shape.

Time-boxed elevated access with a written justification is a standard feature now. Approval chains route through a manager or a team. Results push into Slack or a webhook, grants auto-expire, and there is an audit record of who granted what, when, and for how long. A common configuration is a one-hour AWS admin elevation, requested in a browser, gone before lunch.

One organization running a mostly-Mac fleet gives standard users no persistent local admin at all. Elevation is self-service, defaults to one hour, and requires a written justification that lands with IT. Vague ones get followed up on. That follow-up is the entire enforcement mechanism, and it appears to be sufficient, because people write better reasons when they suspect a human might read them.

On the credential side, LAPS-style tooling replaces the shared password with a unique rotating per-device one that a technician retrieves on demand. Which brings me to my favorite detail in this entire subject. Rotated passwords are so hostile to say out loud that one team built a NATO-phonetic readout into their retrieval tool, then added an alternative generator producing adverb-verb-noun phrases across 48 billion combinations, purely so a technician could read the thing over the phone without fumbling. Somewhere in there is a lesson about designing for the 3am call rather than for the compliance checklist.

One real gap worth naming before you promise your auditor anything: there is no built-in way to require a justification when a technician retrieves a rotated admin password. The tool records that it was viewed, and which API client viewed it. There is no "why did you need this" field, and you will want one.

What we are actually doing here

We spent twenty years treating privilege as a property of a person. You were an admin or you were not, the answer lived in a group somewhere, and it stayed there until you left the company or an audit forced a review.

Access is turning into something closer to a request with a timer on it. You ask, you get it, you lose it again before lunch without particularly noticing.

Technically that is a smaller change than it sounds. Culturally it is a much larger one, because it means nobody is trusted in the ambient, permanent way we used to mean the word. I expected engineers on the receiving end to find that insulting. Mostly it has felt like nothing at all to them, which is the highest compliment infrastructure ever receives.

The contractor from 2019 probably still remembers our old password. It just does not open anything now.