Okta Super Admins - Part 4: The Okta Admin Downgrade Path

How to reduce Okta Admins down to normal users

This is part 4 of a series on Okta Super Admins. Part 1 asked, ARE You Eligible for Okta Super Admin? Part 2 explained that, You Don’t Need So Many Super Admins. Part 3 showed How to ID Super Admin Activity.

Better Solutions Than This

Let’s start by acknowledging that having JIT admin access, checking separate (named) Super Admin accounts out of vault and various other modern ways of managing high-level access are better than a manual process.

However, many IT teams are still forced to manage permissions manually due to factors beyond their control; budget for secrets management, time, knowledge, priorities etc.

Pragmatism & Predictability

If you’re without the new-school, whizz-bang tools allowing JIT admin access then consider a pragmatic approach to descoping admin permissions. A predictable downgrade path is one way to do just that.

Benefits of a Known Downgrade Path

Reducing admin scope can become a constant battle as your Okta tenant grows. As you find yourself granting admin permissions, openly publicise that admin access will be reevaluated and removed based on consistent criteria. It should be clear to those with elevated access, what the next step to lowering their access is and when this is likely to happen.

Making the downgrade path well known makes it easier for Super & non-Super admins to reason about, reducing time spent debating who should be downgraded and why — if the user doesn’t meet the requirements to keep their current level of elevated access, downgrade them to the next step in the path.

Documenting, publicising and generally leaning on this kind of policy also makes it easier to take action without informing the user being downgraded. They’re being downgraded for a reason that’s well-known and so shouldn’t be surprised when the downgrade happens. Getting into a conversation with each admin your downgrading is a guaranteed to waste time and result in fewer necessary downgrades happening, due to social factors.

Usage Based Downgrading

For manual processes, Oktually recommends downgrading based on admins who aren’t using their access over time-based downgrading.

Start by accepting that if a user is making use of their admin permissions, then for some reason they do have a need for them. If you’d rather that admin wasn’t an admin, it’s on you to make a change somewhere that stops their need for the access. As an added benefit, the users who aren’t using their admin permissions shouldn’t even notice when you downgrade them.

To contrast with time-based downgrading, consider how likely it is that you wouldn’t grant access again once the original access period has finished. If it’s not really in your power or interest to say no, asking someone re-request access again after a given period is a waste of time.

Example Downgrade Path

Rather than repeat the documentation here, refer to the docs for Oktually’s Admin Downgrade Tool for a fleshed out example of how a downgrade path can look.