When auditing accounts on a system six months post-release, a familiar sight almost invariably emerges: vendor members granted access during development, who have long since left the project, remain able to log in to production admin consoles. There is no sign of abuse. Simply put, nobody revoked them.
This is less a vendor failure than a structural one. Granting access is a quick decision made during development, whereas revoking it is nobody's job. When access is granted, there is a clear rationale that "work stops without this," but when it comes time to revoke it, no one generates the impetus to act. Consequently, privileges linger.
A state where standing privileges are taken for granted
In many workplaces, access permissions are designed under the assumption that "a person holds them as long as they are assigned to the role." Privileges are tied to roles and removed upon departure. While logical in theory, this approach harbors two practical pitfalls.
First, the event of departure is never notified to anyone. Roster changes within a vendor team are not reflected in the client's management ledger. As long as the contract continues, staff turnover changes nothing on the surface.
Second, the scale of standing privileges does not match the actual frequency of use. Direct production database access might only be needed during incident investigations. Yet access is maintained 365 days a year for something required only a few times annually. To an attacker, that account remains a permanently open doorway all year round.
How the same issue arises with non-human IDs like service accounts and API keys was addressed in We revoked departed employees' accounts, but.... Here, the focus is on human accounts, particularly accounts belonging to external personnel.
From "holding continuously" to "granting on demand" — Just-in-time access
The mindset that flips this dynamic is just-in-time access (JITA). Under normal circumstances, nobody holds production privileges. When a need arises, access is requested, reviewed, and granted on a time-limited basis according to approval. Once finished, it expires automatically.
As a large-scale example, HubSpot published a case study on redesigning this mechanism. The company handles over 5,500 access requests per business day, approving roughly 5,100 of them. The remainder are rejected for reasons such as lack of an associated ticket or falling outside the individual's role scope (HubSpot Redesigns JITA Authorization with Rule Engine Architecture — InfoQ).
Rather than the sheer volume, the consistent rejection rate is what merits attention. Under standing privileges, all 400 of those requests would have gained access unchecked. Moving to per-request reviews stopped unjustified access on the spot.
What HubSpot redesigned was the structure of the evaluation logic itself. Moving away from layered conditional branches to evaluating independent rules as a directed acyclic graph, they ensured that which rules triggered a specific outcome could be audited after the fact. As access control grows complex, being able to explain "why access was approved" becomes essential.
Where small and mid-sized teams should start
This is not about building infrastructure to handle 5,500 requests. Let us focus strictly on what a company of several dozen employees can start doing tomorrow.
Not trying to make everything JIT is the first critical fork in the road. Making every permission request-based overwhelms operations, ultimately creating nothing more than an empty, rubber-stamp approval button. Target scope must be narrowed.
| Target | Can it remain as standing privileges? | Rationale |
|---|---|---|
| Direct connection to production databases | Switch to on-demand | Low usage frequency, maximum impact scope |
| Payment and billing admin consoles | Switch to on-demand | Directly tied to money, highly sensitive even for read-only access |
| Admin features containing customer personal data | Switch to on-demand | Heavy accountability in the event of a breach |
| Staging environments and log inspection | Standing is acceptable | Frequently used, limited impact |
| Source code repositories | Standing is acceptable (offboarding procedures still required) | Used routinely |
Shifting just these three categories to on-demand grants structurally eliminates the most dangerous permissions left behind and forgotten.
Existing tools are sufficient for the mechanism itself. If your cloud IAM offers time-bound role assignment features, use them. If not, even running a ledger-based process of "request → approval → grant → manual revocation upon expiration" is far better than standing privileges. Automation can be added later; shifting to an on-demand operating model comes first.
Three things clients should establish
When external vendors are involved, this operational model will not function unless established within contracts and standard operating procedures.
- Who approves requests? A stakeholder on the client side, or the vendor team lead? Leaving this ambiguous results in de facto self-approval
- How long until access expires? "Until work is complete" is not an expiration. Specify concrete durations like 8 hours or 1 business day
- Who preserves the records, and for how long? Ensure who accessed production, when, and for what purpose can be explained later to business partners or auditors
The third point proves valuable not only when incidents occur, but also when demonstrating that no incident has taken place. Being able to answer immediately, "Zero people have standing production access; there were seven temporary grants over the past three months, all tied to incident tickets," is a sign of trustworthiness in itself.
The issue of long-lived tokens remaining in vendor build environments was examined in What npm and GitHub Actions countermeasures reveal, while determining who receives internal administrative privileges and to what extent was explored in Administrative privilege delegation and least privilege.
Building emergency escape hatches in advance
Systems of this type typically break down in the middle of the night during an incident. The approver is asleep, access cannot be granted, and response grinds to a halt. Once this happens, teams lose faith and move to secure permanent standing access.
Therefore, decide how the system will fail ahead of time. Provide an emergency escape route allowing access when approval is unavailable, offset by mandatory post-incident review. Usage is logged, and justifications must be provided the following business day. Rather than trying to seal off every bypass, creating a bypass whose use is always visible is the practical approach.
What to verify first
Before evaluating new tools, simply counting how many people can currently enter your production environment is plenty. Opening cloud IAM or the user list in your admin console takes only a few minutes.
If you find individuals who have not logged in for the past six months mixed in, that is your starting point. Retaining privileges without using them indicates permissions held not out of business necessity, but simply because there was never an occasion to revoke them.
If you are looking to audit access privileges including vendors or formalize these agreements in maintenance contracts, GleamHub offers consultations on development, AI, and automation. Because the optimal setup varies depending on requirements, we provide customized quotes. Please reach out via Contact Us.
Sources
- HubSpot Redesigns JITA Authorization with Rule Engine Architecture — InfoQ
- Building Observable Access Control at Scale: A Rule Engine Approach to JITA — HubSpot Product Blog
- Just-In-Time (JIT) Access Guide — Netwrix
- Beyond the buzzwords: why JITA, not JITP, delivers true Zero Standing Privilege — SGNL
