There's a lot of energy right now around non-human identity. Service accounts, workload identity, agentic credentials, the machines outnumbering the people ten to one. It's a real problem and I spend real time on it. But while everyone races to govern the robots, I want to make an unfashionable argument: the riskiest, most over-permissioned, most quietly catastrophic identities in your environment are still the humans. And most zero-trust programs fail them not because the architecture is wrong, but because the rollout treats friction as someone else's problem.
If you serve regulated customers — in my case, 1,500+ financial institutions — you already know standing access is the soft underbelly. A breach almost never starts with someone cracking your crypto. It starts with a valid credential doing things it was always technically allowed to do. Zero trust for humans is the answer. But zero trust that triggers a help-desk revolt gets quietly rolled back, and a control nobody can live with is a control you don't have.
The real mechanic: standing access is the liability, not the login
People think the hard part of identity is authentication — proving you are who you say you are. SSO, MFA, phishing-resistant factors. That part is mostly solved, and if you haven't consolidated onto a single identity provider with strong MFA, stop reading and go do that first. It's table stakes.
The hard part is authorization over time. The problem isn't that an engineer can log in. It's that the engineer who needed production database access for a migration eighteen months ago still has it, because revoking access is awkward and nobody wants to be the reason a fix gets blocked at 2 a.m. Access accretes. It never recedes on its own. Every standing privilege is a bet that the credential, the device, and the human behind it will never be compromised — for as long as that grant exists. Multiply that bet across every employee and every system and you've built a balance sheet of risk that grows every quarter.
Least privilege isn't a static map you draw once. It's a flow rate. The goal is to make the default state low-privilege and make elevation cheap, fast, logged, and temporary. That's what just-in-time access actually is: not a new tool, a change in default. You don't have admin. You request it, you get it for the window you need, it evaporates, and the whole thing is recorded. Standing access goes to zero; capability stays high.
Why most JIT rollouts get rejected
Here's where security teams shoot themselves in the foot. They design the elevation flow for the auditor, not for the engineer. The request form has nine fields. Approval routes to a manager who's in a meeting. The grant takes twenty minutes to propagate. So the engineer does the rational thing: they find the one role that still has standing access, or they file a ticket to make their elevated access permanent "to avoid the overhead," and your beautiful JIT system becomes a thin veneer over the same old sprawl.
Adoption is the control. I'll say that again because it's the whole post: if the secure path is slower than the insecure path, you have not implemented a security control, you've implemented a suggestion. The mechanic that makes JIT survive contact with real humans is latency. The time from "I need access" to "I have access" has to be measured in seconds for low-risk grants and minutes for high-risk ones. That means most requests are auto-approved against policy — your job is to encode the policy, not to sit in the approval chain. Reserve human approval for the genuinely sensitive: production data, customer PII, the ability to grant access to others. Tier it. Don't make someone wait for a VP to approve read access to a dev log.
The cloud primitives for this are public and well-understood. AWS gives you IAM Identity Center for SSO and short-lived role assumption, permission sets scoped per account, and STS tokens that expire by design — temporary credentials are the native shape of the platform, not a bolt-on. Break-glass roles for the rare emergency, fully logged and alerted on use. The pattern isn't exotic. The discipline is in defaulting everyone to read-only or nothing, and routing every write through a time-boxed elevation that an engineer can self-serve in the flow of work.
Make the audit trail the byproduct, not the burden
Here's the reframe I'd offer fellow security leaders: JIT done right doesn't just reduce risk, it generates your evidence for free. When access is requested, justified, and granted through a single path, your audit trail writes itself. Who had access to what, when, and why — the question that turns a routine SOC 2 or regulatory exam into a fire drill — becomes a query instead of an archaeology project. I've watched teams spend weeks reconstructing access histories from screenshots and Slack threads. With JIT, that history is the system's exhaust. You're not bolting on compliance after the fact; you're emitting it continuously.
That's also how you fund the program. Don't sell JIT to your executives as "we'll be more secure." Sell it as: standing privileged access goes to near-zero, the next audit costs us a fraction of the last one, and a compromised laptop stops being a path to production. One of those is a feeling. The other three are line items.
So the challenge I'd leave you with: go pull the report on standing privileged access in your environment right now. Not the policy that says what access should exist — the actual grants that do. If that number isn't trending toward zero, you don't have zero trust for your humans. You have a login page in front of a wide-open building. The non-human identities can wait their turn. Your people are the ones holding the keys.
