Your JIT Access Program Is Probably a Break-Glass Program

02:47

Checkout latency on the payments service crosses the alert threshold at 02:41. Auto-remediation retries and fails. At 02:47 the on-call engineer is paged, VPN’d in, and staring at a dashboard telling her the deploy that shipped twelve hours ago is the likely cause.

She has read access to production. She needs write access to roll it back.

So she files the access request. It routes by policy to the named service owner, who is asleep in a timezone seven hours behind. The secondary approver was configured when the team was structured differently and left the company in March. 

The request sits. The error budget does not sit.

What happens in minute three

You already know what happens in minute three. She uses the break-glass account.

Or the shared admin credential in the team vault that four people have. Or she messages the platform engineer who kept standing production access after the migration two years ago and asks him to run it for her. And it works: the rollback lands, latency recovers, the incident closes at 03:20, everyone goes back to sleep.

Nobody files a report about the access path. It was the fastest safe route and she took it. That is what good engineers do under pressure, and I would not want an engineer who did otherwise.

This is the pattern I find in nearly every environment I walk into: a just-in-time program that looks healthy on the dashboard, running alongside an undocumented parallel path that carries the access that actually matters. The dashboard measures the requests that went through the system. It has no visibility into the ones that went around it.

If you want a single question to open your next access review with, use this one: what share of privileged actions last quarter were performed through an identity that JIT never touched?

JIT does not fail at 2 AM. It fails on a Tuesday afternoon.

The emergency is where you notice the failure. It is not where the failure is manufactured. That happens in the unremarkable volume - hundreds of routine requests a week - through three modes I see again and again.

1. Approval theater. When a manager approves one hundred percent of requests, at a median of under thirty seconds, from a phone, that is not a control. It is a log entry with a name attached. It will pass the audit. It will stop nothing. And it is not the manager’s fault: they are handed a group name, a requester and a button, with no way to judge whether the entitlement is appropriate and no time to go and find out.

2. The missing return path. I recently wrote an access-control addendum for a client defining the approval chain for privileges granted outside standard group permissions: the employee’s manager, then the technical owner of the system, then the data protection officer where customer data was in scope. Careful, defensible, exactly what an auditor wants to see.

Their security team came back with one comment that mattered more than anything in my draft: what is the flow for taking it back?

That question is the whole game. Almost every organization specifies the grant path in detail and treats revocation as an afterthought - a calendar reminder, a quarterly review, a good intention. Temporary access with no engineered expiry is standing access with a better origin story, and it compounds: this is exactly where entitlement sprawl comes from, one reasonable exception at a time. Fixing the emergency grant while leaving the return path undesigned means you have optimized the intake of a system with no drain.

3. The long tail. Your identity platform covers the twenty applications with clean SCIM connectors. Privilege lives in the other two hundred: the homegrown internal tool, the legacy ERP module, the vendor portal with three shared logins, the on-prem system that predates your SSO. That is not a coverage gap at the edges. In most organizations it is the majority of the exposure, and it is precisely where conventional automation has never been able to reach.

Why rules engines cannot close this

Here is the frustrating part. The information needed to decide that 02:47 request correctly already exists inside the organization. It is in the on-call rotation, the HR system, the calendar, the incident record, the ticket, the commit history, the project channel.

A rules engine simply cannot read any of it. It can evaluate whether the requester’s role matches an entitlement. It cannot evaluate: this person is the paged on-call for this specific service, on an active Sev-1 opened eleven minutes ago, asking to revert a change her own team shipped.

That is context blindness, and it forces a binary. Write policy loose enough to be useful and you over-grant. Write it tight enough to be safe and you get routed around at 02:47. Most organizations end up with both at once - restrictive policy plus an informal bypass - which is strictly worse than either.

Ten seconds is roughly how long an experienced IAM lead who knows the organization would need for that request. Here is what they would read in those ten seconds, and what none of it exists as a rule:

•    Who is actually on the hook. The on-call rotation, not the org chart. The org chart says who manages her. The rotation says why she is awake.

•    Whether there is a real event behind the request. An open Sev-1 on the same service, opened before the request, is a completely different signal from a quiet request at the same hour.

•    Who can approve right now. The named owner is asleep. The incident commander is active in the channel. Availability is a first-class input, and no static workflow has it.

•    Blast radius. She deploys to this service most weeks. This is inside her existing scope, not a lateral move into someone else’s.

•    The gap between what was asked for and what is needed. She requested admin on the account. Reverting one deployment needs far less than that. Very often the correct answer is not yes or no, but narrower.

•    The return condition. Not a duration someone guessed at, but an event: when the incident closes, this ends.

The same night, with a digital employee in the loop

The part that does not fit on a vendor slide

I would be doing you a disservice if I stopped there. This category is worth evaluating - I think it is the most substantive shift in identity management in a decade. Evaluate it as a CISO, though, not as a buyer of convenience.

The agent is a privileged identity. Anything that can grant production access is among the most powerful principals in your environment. It needs scoped credentials, its own non-repudiable audit trail, and its own line in your user access review. If you cannot answer who reviews the reviewer, you are not ready to deploy it.

Do not learn from your rubber stamps. If a system takes signal from historical approval behavior and your historical approval rate was one hundred percent yes, you have not automated judgment. You have automated its absence, and made it faster. Baseline the quality of your current decisions before you scale them.

Set the autonomy line explicitly, by risk tier. Recommend, decide, and execute are three different mandates, and the distance between them is where your risk appetite actually lives. Write it into policy. Read access to a reporting tool and write access to a payments database do not belong in the same tier.

Assume the auditor’s question. "Who approved this, and on what basis?" now has a non-human answer, and that answer has to be legible to someone who does not work in security - and reproducible, so that the same inputs yield the same decision. This is where ISO 42001 stops being a badge and starts being useful: an AI system making access decisions sits inside your AI governance scope, not only your IAM scope. Very few organizations have connected those two programs. It will start showing up as an audit finding.

Keep a human accountable. Not in the loop on every request - that defeats the purpose - but accountable for the policy, the exceptions and the outcomes. You can delegate the work. You cannot delegate the accountability, whatever the architecture diagram says.

How you will know it worked

Not by ticket volume. By these:

•    Time from request to access, at the median and at the 95th percentile. The tail is where people learn to go around you.

•    Share of privileged actions performed outside the JIT path. This should trend toward zero. If you cannot measure it today, that is your first finding.

•    Break-glass invocations per quarter, each with a written justification attached.

•    Count of standing privileged accounts, tracked monthly. Watch the direction, not the number.

•    Time from expiry condition to actual revocation - and the number of temporary grants older than ninety days.

•    Approval rejection rate. If it is still zero, nothing was fixed. The theater just got a faster stage.

The real problem was never automation

Provisioning was solved years ago. What was never solved is judgment at scale: knowing who should decide, what exactly they should decide, and when it should end - hundreds of times a week, across a fast-moving organization, at 3 AM as reliably as at 3 PM.

That is the work an agentic AI digital employee can genuinely take on, because it can finally read the organizational context that experienced IAM leaders have always used and rule engines never could.

The goal was never faster approvals. The goal is that at 02:47, nobody has a reason to go around you.

‍