From standing admin to on-request access, one system at a time

The fastest way to fail with just-in-time access is to try to do everything at once: switch off every administrator, route every request through a new tool, and hope engineers cope. The programmes that work move one system and one team at a time, prove that access arrives quickly, and only then take the old standing rights away. Ninety days is enough to do that properly for a first slice of the estate, and to show the board numbers that moved.

This post is a plan for those ninety days with InsightKeys. It is written for the security leader who owns the programme and the platform lead who will run it. The phases are a guide, not a contract; smaller organisations will move faster, larger ones will repeat the middle phases team by team.

The plan at a glance

Illustrative timing. The dates are placeholders; the sequence is what matters.

Two principles run through the whole plan. First, add the fast path before removing the old one: nobody loses standing access until they have used on-request access successfully. Second, start agents cautious and raise their autonomy on evidence: every agent can be set from L1 Draft to L4 Act, and the right setting in week two is rarely the right setting in week ten.

Days 1–15: install the broker and discover

The broker is the only part of InsightKeys that runs in your network, and the only part that holds a credential able to change permissions. Today it runs with docker run or Docker Compose; CloudFormation, Terraform and Helm packaging is planned. It connects out over HTTPS, so no inbound firewall change is needed. Enrolment uses a single-use token, and the broker generates its own signing key, which never leaves it.

Discovery produces the first useful artefact of the programme: a list of standing access with risk, last use and a proposed action. In the demo organisation used in our screenshots, it found eight open items — four standing administrators, an escalation path through a CI deployer role, two roles unused for more than ninety days, and a database login with superuser rights that had never been used. Share your list with system owners now. It is the baseline the board report will compare against.

Days 15–40: move the first team

Choose the first team carefully. The best candidate owns an important production system, feels the pain of slow access today, and has a lead willing to be the example. A payments or core platform SRE team is often a good fit. Avoid starting with the team whose access is most politically sensitive; start where success will be visible and quick.

Build the catalogue for that team’s system: the resources, the entitlements (read, write, admin), the ceiling of each — the widest permission it may ever grant — and the owner. Then write a small number of access flows. The demo organisation’s flows are a reasonable template:

Turn requests on for the team in the console, Slack and the CLI. Keep the agents cautious at first. The least-privilege scoper and the risk agent default to L3 (act and tell, can be pulled back); the session watch defaults to L2 (asks before acting); the standing-access cleanup agent defaults to L1 (drafts only). For the first weeks, consider holding automatic approval back even where the score is low, so that the team and security can read a few dozen scored requests and agree the scores look right.

Days 40–60: let low risk flow

Once the scores look right, let low-risk requests through without a person. The default threshold is 30 or below, and only where a flow allows it; step-up second factor is asked at 55 and above; two approvers at 75 and above. These are starting points. Look at a month of real requests and adjust, in Settings, where the scores do not match the team’s judgement — the weights are yours.

Enrol step-up at the same time. Each requester and approver registers an authenticator app or uses a Duo push, so the second factor is ready the first time a risky request needs it. Put approvers on Slack, so a request that needs the resource owner reaches them where they already are. Then watch two numbers: the share of requests approved automatically, and the median time to access. If the first is near zero, approvers will tire; if the second is measured in hours, engineers will find another way.

Days 60–80: retire standing admin

This is the step that reduces risk, and the one most programmes postpone. By now the first team has used on-request access for several weeks and knows it works. Return to the discovery list and work through that team’s standing access, one line at a time.

The standing-access cleanup agent prepares a proposal for each line: convert this administrator to on-request access, accept this role as a justified exception, or remove this unused role. A person agrees each one with the owner. Lines with long-unused access are the easiest wins — in the demo, a standing administrator unused for 118 days and an emergency account unused for 200. Lines used daily usually turn out to be automation and need least-privilege work rather than conversion. Escalation paths, such as a CI role that can pass a privileged role to a new function, deserve their own conversation with the platform team.

Days 80–90: prove it

Close the first ninety days with the two things auditors and boards most want to see. First, a prepared access review for the first team’s production scope: standing access plus grants from the last ninety days, each line pre-filled with last use, uses in ninety days and a recommendation. The reviewer decides; removals go through the broker. Second, an evidence export of grants and reviews to InsightAssure or as CSV, so the record is in your compliance tooling rather than only in ours.

Then report upward. Keep it short: standing administrators on the first system, before and after; median time to access for low-risk and approved requests; the share approved automatically; and what the first review removed. Name the next team and the next system.

What can slow you down

The more common delays are organisational. Owners who will not name an approver, a senior engineer who asks to keep administrator rights “for now”, a review that slips because nobody owns it. Each of these is a decision, and each should have a named person and a date. The programme sponsor’s most useful job in the first ninety days is to make those decisions happen.

Keep reading