Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Technology / AI SaaS |
| Cloud Environment | AWS (4 accounts), EKS clusters, databases |
| Team Size | ~150 users (~100 Engineering, ~10 DevOps, ~20 CS) |
| Approver Before | 1 DevOps lead (single dependency for all access) |
| Request Volume | Multiple daily requests from Engineering, DevOps, CS |
| Identity Provider | Google Workspace → AWS IAM Identity Center |
| Communication | Slack |
| Cloudanix Scope | Cloud Console JIT, Kubernetes JIT, Database JIT |
The Situation: One Person Holding the Keys to Everything
In most growing DevOps teams, there’s a moment where access management crystallises around a single person. Not by design — by gravity. Someone reliable starts handling access requests. Others learn to go to them. Over time, that person becomes the only one who knows how to grant access, who should have access, and where the permission boundaries are.
For this AI SaaS company, that person was the DevOps lead. Every access request — regardless of sensitivity, environment, or urgency — funneled through one individual:
- An engineer needing read-only access to development logs? DevOps lead approves.
- A Customer Success team member needing production console access for a client issue? DevOps lead approves.
- A DevOps engineer needing elevated permissions for infrastructure maintenance? DevOps lead approves.
- An engineer at 2 AM dealing with an incident in their timezone while the DevOps lead sleeps? Engineer waits.
The DevOps lead spent significant time each day on access reviews. The mental load was constant. And the security implication was clear: when one person is the bottleneck, people work around the bottleneck. Broad permissions get pre-granted. Service accounts get shared. “Temporary” elevations become permanent because the revocation request goes back through the same chokepoint.
The Core Challenge
All access governance depended on one person’s availability and judgment. This created latency for requesters, burnout for the approver, and workarounds that undermined the security model. The organisation needed to distribute approval authority without losing the governance the single approver provided.
Where the Gaps Were
The Approver’s Day: A Study in Interruption
The DevOps lead’s typical day included:
- Morning: 4–6 access requests from the overnight queue (engineers in other timezones). Review each, approve/deny, execute the IAM changes manually.
- Midday: 3–4 real-time requests coming through Slack. Context-switch from infrastructure work to review access needs, then switch back.
- Afternoon: Follow-up requests (extensions, scope changes), plus the need to revoke morning grants that should have expired hours ago.
- Evening: Requests from engineers working late or in earlier timezones starting their day.
Conservative estimate: 10–15 access decisions per day, each requiring context (who’s asking, what do they need, is it appropriate, which account, which role). At 5–10 minutes per decision including the IAM action, this consumed 1–2.5 hours of focused time daily — on a task that wasn’t the DevOps lead’s primary job.
Latency Compounds Into Workarounds
When the approver is in a meeting, on a call, or focused on infrastructure work, access requests queue. The wait time creates pressure:
- Moderate urgency: Engineers wait 30–60 minutes. Frustrating but manageable.
- High urgency (incidents): Engineers need access now. Waiting 30 minutes during a production incident isn’t an option. So they find alternatives: shared credentials, asking a colleague who already has access to “just run this command,” or using service account tokens that weren’t meant for human use.
- Low urgency but time-sensitive: A CS team member who needs access for a client demo in 20 minutes can’t wait for a ticket to be reviewed. They escalate directly, adding interruption pressure to the approver.
Each workaround is a security event. Shared credentials, unaudited actions through another person’s session, service accounts used for human access — these are the consequences of a system that makes legitimate access slower than illegitimate access.
No Risk Differentiation
The single-approver model treats all requests equally. Read-only access to a development account and administrator access to production went through the same person, at the same speed, with the same review depth. This is simultaneously:
- Too slow for low-risk requests. An engineer checking logs in dev doesn’t need human approval. But they wait in the same queue as production admin requests.
- Too fast for high-risk requests. When the approver is overwhelmed with volume, high-risk requests get the same 30-second review as low-risk ones. The approval becomes a rubber stamp rather than a security decision.
- Unscalable. As the team grows from 150 to 300 users, the request volume doubles. One person cannot meaningfully review 25+ access decisions per day while doing their actual job.
Knowledge Concentration Risk
The single approver accumulated knowledge about the access model that no one else had:
- Which permission sets are appropriate for which teams.
- Which accounts are sensitive and require extra scrutiny.
- What the historical access patterns look like (who normally needs what).
- Where the edge cases are (shared accounts, cross-team resources, temporary projects).
If that person left the organisation, the institutional knowledge about access governance left with them. There was no codified policy — just one person’s judgment applied consistently.
The Cloudanix Solution: Distributed Governance with Tiered Policies
Cloudanix JIT replaced the single-approver model with a distributed governance system where:
- Low-risk access auto-approves — no human in the loop.
- Moderate-risk access routes to team-level approvers — distributed across multiple people.
- High-risk access requires escalated approval — with the scrutiny it deserves.
The DevOps lead’s judgment didn’t disappear. It was codified into policies that enforce the same decisions automatically — freeing the person while preserving the governance.
Auto-Approval for the 60% That Never Needed a Human
The majority of access requests were predictable and low-risk:
- Engineering team requesting ReadOnly access to development accounts.
- DevOps requesting their standard operating roles in non-production.
- CS team accessing their designated read-only views.
These requests followed the same pattern every time: engineer from group X asks for role Y on account Z, and it’s always approved. The approval was a formality — human time spent confirming what policy would have confirmed instantly.
Cloudanix auto-approval configuration:
- Engineering group + ReadOnly/SecurityAudit roles + Development account = auto-approve, max 4 hours.
- DevOps group + Developers_Editor role + Non-production accounts = auto-approve, max 8 hours.
- CS group + designated view roles + designated accounts = auto-approve, max 2 hours.
These policies encode the DevOps lead’s historical decisions. The same access that was always approved is now always approved — instantly, without waiting, and without consuming anyone’s time.
Team-Level Approvers for Moderate Requests
For access that warrants a human decision but doesn’t need the most senior person:
- Engineering lead approves elevated access for engineers in their team (edit access in staging, specific production namespaces).
- DevOps team members (not just the lead) approve standard operational requests.
- CS lead approves non-standard access for their team.
Multiple approvers at this tier means:
- Requests are handled by whoever is available — no single bottleneck.
- First-to-approve clears the request. No waiting for a specific individual.
- Coverage spans timezones naturally when approvers are distributed globally.
Escalated Approval for the 10% That Matters Most
High-risk access still gets the scrutiny it deserves:
- Production administrator access.
- Cluster-admin on production Kubernetes clusters.
- Cross-account roles with broad permissions.
These route to the senior DevOps lead (or their delegate) with full context: who’s requesting, what they want, why they need it, and how long. The volume at this tier is low enough (a few per week, not per day) that each decision gets proper attention.
Codifying Judgment Into Policy
The most valuable outcome isn’t speed — it’s that the DevOps lead’s institutional knowledge is now captured in configuration:
- Group → Account → Role mappings define what each team can request.
- Auto-approval rules define what’s always safe to grant without human review.
- Approval routing defines who reviews what and at what escalation level.
- Duration caps define maximum access windows per role and environment.
- Boundary enforcement prevents requests outside policy — an engineer can’t even request a role they’re not eligible for.
If the DevOps lead leaves tomorrow, the access governance model continues functioning. The policies enforce the same decisions, the same routing, the same boundaries. Onboarding a replacement means training them on the policy system, not rebuilding institutional knowledge from scratch.
Platform Impact
| Metric | Before (Single Approver) | After (Distributed JIT) |
|---|---|---|
| Approver load | 10–15 decisions/day, one person | ~2 escalated decisions/week for senior approver |
| Time to access (low-risk) | 15–60 min wait | Instant (auto-approved) |
| Time to access (moderate) | 15–60 min wait | Under 5 min (first available approver) |
| Time to access (high-risk) | 15–60 min wait | Under 15 min (dedicated attention, low volume) |
| Workaround frequency | Regular (shared creds, pre-granting) | Near zero (legitimate path is fastest path) |
| Bus factor for access governance | 1 person | Codified in policy, survives personnel changes |
| Risk differentiation | None (all requests equal) | Three tiers with appropriate scrutiny |
The Principle: Make the Legitimate Path Faster Than the Workaround
The single-approver model failed not because of bad intent but because it made legitimate access slower than illegitimate access. When waiting 45 minutes for approval is the “right” way, and asking a colleague to share their session is the “fast” way, people choose fast. Especially during incidents.
Cloudanix JIT inverts this:
- Auto-approval for low-risk access is literally instant. There is no faster path — legitimate or otherwise.
- Distributed approval for moderate access is faster than finding a workaround because the approver pool is wide and the notification is real-time.
- High-risk access is the only tier where waiting is expected — and at that tier, the wait is appropriate and the volume is low.
When the compliant path is also the fastest path, compliance happens naturally. People don’t work around JIT because JIT is faster than the workaround.
Running All Access Through One Person?
If your access governance depends on a single person’s availability and judgment — and you’ve seen the workarounds that creates when they’re unavailable — Cloudanix JIT distributes that governance into tiered policies: auto-approval for the routine, distributed approvers for the moderate, and escalated review for the critical. Same governance, no bottleneck.
Book a Free Assessment to see how tiered approval policies map to your team structure and access patterns.
Related Resources
- Still Manually Granting Cloud Access? Here’s Why Your Security & Productivity Are Suffering
- PAM for Credential Management, Password Rotation, and More in the Cloud
- Implementing JIT Access in AWS, Azure & GCP: Complete Guide
- Mastering Third-Party Access with a Just-in-Time Approach
- Migrating from Chaotic IAM to Streamlined Role-Based Just-in-Time Access
