The One-Size-Fits-All Approval Problem
When organizations first implement JIT access, the natural starting point is: every request goes to one approver. Simple, clear, and completely wrong for scale.
The problem surfaces quickly:
- An engineer needs read-only access to check dev logs. Approver reviews, approves. (Was this review necessary?)
- An SRE needs admin access to production during an incident. Same approver, same queue. (Should this have the same review depth?)
- A contractor needs namespace-scoped edit on a staging cluster. Same approver, same process. (Does this need the same person who handles production admin?)
All three requests have different risk profiles. Different blast radii. Different urgency levels. Different consequences if approved inappropriately. But a flat approval model treats them identically — same friction, same latency, same reviewer attention.
Multi-level approval solves this by matching the scrutiny level to the risk level: more levels for higher risk, fewer (or none) for lower risk.
What Multi-Level Means in Practice
Multi-level approval is a hierarchy of approval requirements configured per access type:
Level 0: Auto-Approve (No Human)
- Read-only access to development environments.
- Standard tooling access for on-call roles during declared incidents.
- Policy evaluates the request; access is granted instantly.
Level 1: Single Approver
- Edit access to staging environments.
- Read-only access to production (for most teams).
- One designated approver reviews and clicks Approve/Reject.
Level 2: Multiple Approvers (Quorum)
- Write access to production environments.
- Admin roles on production Kubernetes clusters.
- Two (or more) approvers must independently approve before access is granted.
Level 3: Escalated Multi-Level
- AdministratorAccess on production accounts.
- Cross-account roles with broad permissions.
- First approved by team lead (Level 1), then by security or senior DevOps (Level 2). Both must approve.
The key design principle: between levels, it’s AND (both must approve). Within a single level, it’s OR (first approver to respond approves for that level).
Designing Levels by Risk
The Risk Dimensions
When deciding how many approval levels a request needs, consider four dimensions:
1. Environment Sensitivity
- Development: Low (designed for experimentation)
- Staging: Medium (pre-production, may contain production-like data)
- Production: High (customer-facing, real data, outage potential)
2. Permission Scope
- Read-only: Low (can observe but not modify)
- Edit/Write: Medium (can modify specific resources)
- Admin: High (can modify infrastructure, delete resources, change permissions)
3. Blast Radius
- Namespace-scoped: Limited (one service, one namespace)
- Account-wide: Broad (all resources in an account)
- Organization-wide: Critical (all accounts, all resources)
4. Reversibility
- Easily reversed: Low concern (configuration change, service restart)
- Partially reversible: Medium concern (data modification with backups)
- Irreversible: High concern (data deletion, secret exposure)
Mapping Risks to Levels
| Environment | Permission | Blast Radius | Approval Level |
|---|---|---|---|
| Dev | Read-only | Namespace | Auto-approve |
| Dev | Edit | Namespace | Auto-approve |
| Dev | Admin | Account | Level 1 |
| Staging | Read-only | Any | Auto-approve |
| Staging | Edit | Namespace | Level 1 |
| Staging | Admin | Account | Level 1 |
| Prod | Read-only | Any | Auto-approve or Level 1 |
| Prod | Edit | Namespace | Level 1 |
| Prod | Edit | Account | Level 2 |
| Prod | Admin | Account | Level 2 or Level 3 |
The Adoption Challenge: Multi-Level Without Multi-Friction
The most common concern with multi-level approval: “Won’t this make access even slower? We already have friction problems.”
The concern is valid — but only if multi-level is implemented poorly. Here’s how to avoid the friction trap:
Rule 1: More Levels Only for Genuinely High-Risk Access
Most access requests (60–70%) should auto-approve. Of the remaining, most (25–30%) should be single-level. Multi-level approval applies to the 5–10% of requests that represent genuinely elevated risk.
If you’re requiring multi-level approval for read-only staging access, you’ve over-engineered. If you’re auto-approving production admin access, you’ve under-engineered.
Rule 2: Between Levels Is AND; Within a Level Is OR
If Level 2 requires “two approvers,” that means the first person to approve satisfies Level 2. You don’t need both designated approvers to respond — you need any one of them. This means more approvers at each level increases availability (faster response) rather than increasing friction (more people needed).
Rule 3: Approver Pools Should Be Large Enough for Coverage
For Level 2 approval (production admin):
- Too few (1 approver): Single point of failure. They’re in a meeting? Request waits.
- About right (3–4 approvers): First to respond approves. High availability across timezones.
- Too many (10 approvers): Diffusion of responsibility. Everyone assumes someone else will handle it.
Rule 4: Notifications Are Real-Time, Not Batched
Multi-level approval only adds meaningful latency if notifications are slow. When approvers receive real-time Slack/Teams notifications with one-click buttons, a two-level approval might take 2 minutes total (1 minute per level). If approvals route through email digests, the same flow takes hours.
Rule 5: Level 1 Can Auto-Approve Based on Policy
For requests that need Level 2 approval, Level 1 can sometimes auto-approve based on policy:
- Request: Production edit access for SRE during a declared incident.
- Level 1: Auto-approved (SRE + incident context + production edit = policy match).
- Level 2: Human approval by senior DevOps (confirms the specific action is appropriate).
This means the engineer waits for one human approval, not two — the policy handles the first level automatically.
Real-World Multi-Level Configurations
Configuration A: SaaS Startup (100 engineers)
Level 0 (Auto): Dev/Staging read-only for all groups
Level 1 (Single): Dev/Staging edit, Production read-only
Level 2 (Quorum): Production edit/admin (2 of 4 approvers)Result: Most requests instant. Production access takes under 5 minutes.
Configuration B: FinTech (500 users, regulatory requirements)
Level 0 (Auto): Dev read-only only
Level 1 (Single): Dev edit, Staging read-only
Level 2 (Two): Staging edit, Production read-only
Level 3 (Chain): Production edit → team lead + securityResult: Highly governed. Production access requires 2 serial approvals. Staging is still fast for daily work.
Configuration C: Platform Team (DevOps managing infrastructure)
Level 0 (Auto): All non-prod for DevOps group
Level 1 (Single): Production read/edit for DevOps group
Level 2 (Quorum): Production admin (including cluster-admin)Result: DevOps team moves fast in their normal scope. Admin access (rare, high-impact) gets extra scrutiny.
Handling the Edge Cases
What If an Approver Removes Themselves?
The requestor should not be able to remove required approvers from a level. If all approvers at a level are removed, the request cannot proceed. This prevents social engineering where a requester removes the “strict” approver and keeps the “lenient” one.
What If Both Levels Are the Same Person?
If a senior DevOps engineer is both the Level 1 approver (team scope) and a Level 2 approver (security scope), their single approval should not satisfy both levels. Levels represent independent verification — one person approving at Level 1 doesn’t auto-satisfy Level 2, even if they have authority at both levels.
What About Urgent Requests?
For declared incidents or break-glass scenarios:
- Level 1 can auto-approve based on incident context.
- Level 2 timeout can be reduced (e.g., if no response in 5 minutes, escalate to backup approvers).
- Break-glass policies can temporarily reduce levels (but with enhanced post-access audit).
The key: urgency adjusts the workflow speed, not the governance. Access is still time-bound, still audited, still identity-stamped.
The Measurement: Adoption Under Multi-Level
Multi-level approval succeeds when:
- Auto-approved volume stays at 60%+ of total requests. Most work doesn’t need human review.
- Level 1 response time stays under 5 minutes. Approvers respond from Slack/Teams quickly.
- Level 2 response time stays under 15 minutes. For high-risk access, 15 minutes is acceptable.
- Workaround frequency stays at zero. No one bypasses JIT because multi-level is “too slow.”
- Rejection rate at Level 2 is non-trivial. If Level 2 never rejects, it might not be adding security value.
If multi-level approval drives workaround usage (developers bypassing JIT for speed), the levels are misconfigured — either too many requests are requiring multiple levels, or the approver pools are too small for coverage.
Ready to Implement Risk-Proportional Approval?
If your access approval treats all requests equally — or you’re considering multi-level but worried about friction — the design is straightforward: auto-approve where blast radius is bounded, single-approve where judgment adds value, and multi-approve only where the risk justifies the additional scrutiny.
Learn more about JIT multi-level approval or book a demo to design approval levels for your team structure.
