Discovery, escalation paths, last-used dates and a reversible conversion

Ask any security leader how many people hold administrator rights in production and you will usually get a number. Ask how they know, and the answer becomes less certain. Admin is granted during migrations, incidents, acquisitions and late-night fixes, and almost never taken away, because removing it carries a risk nobody wants to own: what if something breaks? So it accumulates. The access nobody remembers granting is precisely the access an attacker hopes to find.

This post walks through retiring standing access in the demo organisation, Northwind Labs. Discovery found eight open items, including four standing administrators and one escalation path. We take each one in turn: what it is, how risky it is, and whether to convert it to on-request access, accept it with a reason, or send it to its owner as a proposal.

Why standing privilege is a board-level risk

Standing privilege turns any credential theft into a privileged incident. A phished password or a leaked token on an ordinary account is a nuisance; on an account with AdministratorAccess to the payments environment, it is a reportable breach. The size of the exposure is set not by how many administrators you need, but by how many you have.

There is a compliance angle as well. SOC 2, ISO 27001 and PCI DSS all ask, in their own words, that privileged access is restricted to those who need it and reviewed. Auditors increasingly sample the administrator list and ask for the business reason behind each name. “They were added in 2023 for the migration” is not a reason.

Step 1: discovery finds what exists

Discovery runs through the same broker that grants access, inside the customer’s network. For AWS it reads accounts, permission sets and assignments, and the full IAM authorisation details, then analyses them for administrator access, privilege-escalation paths and unused roles. That analysis is shared with InsightFortify, VerticalServe’s cloud security posture product. For PostgreSQL it reads roles and their privileges; for Kubernetes, role bindings.

At Northwind, the standing-access page summarises the result: 8 open items, 4 administrators, 1 escalation path, 2 unused for more than 90 days. The admin home page shows the same headline: 4 standing admins left.

Discovery is read-only. Finding standing access changes nothing in the estate; it only produces the list. That makes it a safe first step for a security team that wants evidence before it asks any owner to give anything up, and it is often the step that settles the internal argument about whether there is a problem at all. Nobody disputes a list with names, dates and permissions on it.

Step 2: read the list as a risk register

Who	Where	Access	Last used	Risk	Likely answer
alex.ops@	prod-payments	AdministratorAccess	118 days ago	Critical 95	Convert to JIT
breakglass-admin	prod-core	AdministratorAccess	200 days ago	Critical 90	Convert; replace with the break-glass flow
jordan.dev@	eks-prod/payments	ClusterRoleBinding to cluster-admin	45 days ago	Critical 80	Convert to namespace entitlements
insight (service)	payments-db	SUPERUSER, BYPASSRLS, CREATEROLE	Never	Critical 75	Proposal to the owner
ci-deployer (role)	prod-core	iam:PassRole, lambda:CreateFunction, lambda:InvokeFunction	4 hours ago	High 55	Proposal: narrow, keep the pipeline working
priya.sre@	prod-payments	ReadOnlyAccess, always on	1 day ago	Medium 40	Convert to JIT (low-risk reads stay automatic)
legacy-migration (role)	prod-core	s3-all	Never	Medium 40	Convert; it has no users to break

Read the list from two directions at once. The risk score tells you what an attacker would most like to find. The last-used date tells you what will break if you remove it. A line with a high score and an old date is the best trade you will ever make: maximum risk removed, minimum disruption. alex.ops@ with AdministratorAccess on the payments account, untouched for 118 days, is exactly that.

An eighth item, morgan.lead@ with PowerUserAccess, sits further down the same list and follows the same reasoning.

A triage rule that suits most estates. People get on-request access; workloads get narrower permissions.

Step 3: the three answers, line by line

Convert to JIT is the answer for people. Done properly it is two things in order. First, the access is made requestable: an entitlement exists in the catalogue with a ceiling, an owner and a flow. Then the standing assignment is removed, through the broker. The person loses nothing they need; they gain a request box. For alex.ops@, the AdministratorAccess assignment goes, and admin on prod-payments becomes a request under the two-person flow, #30. For priya.sre@, always-on ReadOnlyAccess becomes reads under flow #10, automatic when the risk is low, so Priya’s day hardly changes.

breakglass-admin is a special case of the same answer. It exists for emergencies, and flow #5, break-glass for whoever is on call, covers emergencies without a standing account. Convert it once that flow has been rehearsed.

jordan.dev@ holds cluster-admin through a ClusterRoleBinding on the production cluster. Converted, that becomes namespace-scoped requests: a RoleBinding per grant, to a role scoped to one namespace, removed at expiry.

Proposal is the answer for workloads and for anything where the owner needs to agree. The ci-deployer role was used four hours ago. It is a deployment pipeline, not a person, and it cannot fill in a request form. But it can escalate its own privileges: with iam:PassRole, lambda:CreateFunction and lambda:InvokeFunction, it can create a Lambda function that runs as a more powerful role and invoke it. The proposal is to narrow it, for example restricting which roles it may pass, and the platform team makes that change in their infrastructure code. Similarly, the insight service login on payments-db holds SUPERUSER, BYPASSRLS and CREATEROLE and has never been used. Before removing a service login, confirm with its owner which application, if any, still depends on it.

Accept is a legitimate answer, not a failure. Some standing access is right: a read-only monitoring role, a narrowly scoped service account. Accepting records who accepted it and why, and standing access stays in scope for the next quarterly access review rather than disappearing.

The cleanup agent at L1: drafts, not deletions

The standing-access cleanup agent looks for standing admin, escalation paths, unused roles and database superusers and proposes converting each to on-request access. By default it runs at L1, “Draft”: it prepares the proposal and a person does the work. At Northwind the home page shows 8 agent proposals waiting across all agents.

L1 is the right default for removal. Removing access is the one action in this product most likely to break something, and a person who knows the system should look at each line. As confidence grows, an organisation can move the agent up a level for a narrow class, but nothing forces it to. Every agent action is in the inbox with approve, reject and undo, and in the audit trail.

Whatever the level, the removal itself is done by the broker in Northwind’s network, under a signed instruction, checked against the broker’s local policy. InsightKeys’ servers never hold a credential that can change Northwind’s permissions, including to take them away.

One conversion. The agent drafts; security and the owner decide; the broker removes.

What to report upwards

The board does not need the list. It needs three numbers and their direction: standing administrators in production, identities that can escalate their own privileges, and privileged lines unused for 90 days. At Northwind today those are 4, 1 and 2. A credible programme brings the first two close to zero and keeps the third there, while the share of requests approved automatically shows the business that tighter control did not mean slower work.

Keep reading