Every Okta tenant starts with at least one Super Admin, and most of them end up with several: the person who set it up, the person who replaced them, the security engineer who needed it once for an incident, the break-glass account that everyone knows the password to. Each of those is a full-control credential sitting idle for most of the year. If one is phished, the attacker owns identity for the whole company, which means they own everything behind it.
The fix is well understood in cloud infrastructure: nobody holds admin, people request it when they need it, it expires on its own, and every grant is logged. I built that for Okta. Here is the shape of it.
The request is a Slack command
An engineer who needs to do admin work runs a slash command in Slack with a short reason. The command posts to a Lambda behind API Gateway, which verifies the Slack signature, confirms the requester is in the Okta group that is allowed to elevate, and then adds them to a group that carries the Super Admin role. The whole thing takes about a second. The requester gets a reply saying how long they have.
Putting the request in Slack rather than in a form or a ticket was deliberate. It is where the engineer already is, it is already authenticated through Okta, and every request is visible in a channel that the rest of the team can see. Visibility is a control. Nobody elevates quietly.
Revocation is a timer, not a reminder
The part that makes just-in-time real is that the grant ends without anyone remembering to end it. When the Lambda grants access, it also schedules an EventBridge rule for the expiry time. When that fires, a second Lambda removes the user from the admin group and posts to the same Slack thread that the elevation has ended. If the grant is revoked early by hand, the scheduled rule is cleaned up so it does not fire against a user who is already out.
There is no "extend" button. If someone needs more time they request again, which produces another log entry with another reason. The friction is small and it is the point.
The audit trail answers the question before it is asked
Every elevation produces three records: the Slack message with the reason, the Okta System Log entry for the group membership change, and the Lambda's own structured log line with requester, reason, grant time, and expiry. Those are correlated by a single request ID so that any one of them leads to the other two.
When an auditor asks who had Super Admin during a given week and why, the answer is a query, not a meeting. When the security team sees an admin action in the System Log they can find the Slack thread that explains it in under a minute. And when nobody has elevated for a while, that absence is itself evidence that the role is not being used casually.
The part people underestimate: the audit trail is not for the auditor. It is for the engineer who elevated at 11pm during an incident and wants to be able to show, six months later, exactly what they did and why.
What it took to get there
The automation was the easy part. The harder part was removing the standing grants, because each one belonged to someone with a reason. The approach that worked was to turn the just-in-time path on first, ask people to use it for a few weeks, and only then remove their standing role. By that point they had already proven to themselves that the new path was faster than remembering which account to log into.
The break-glass account still exists. It is the one exception, and it is treated like one: the credential is in a vault with access alerting, it has its own device-trust policy, and its use pages the whole team. It has not been used since the project shipped.
Why this matters beyond Okta
The same pattern applies to any high-privilege role in any system: AWS account admin, GitHub org owner, the MDM's super user. Once the Okta version existed, the pieces were reusable. The request path, the timer, and the log format are the same. Only the grant and revoke calls change.
If you take one thing from this: the goal is not to make admin access hard. It is to make it short, visible, and self-cleaning. Engineers will use a path that is fast. They will route around a path that is slow, and that is how standing admin comes back.