A permanent cloud admin role is exposed every hour of every day, even when it is used for minutes a week, and cloud just in time access tools exist to remove that standing privilege without slowing engineers down. This category sits between traditional vault-centred PAM and entitlement analysis: it grants cloud roles, Kubernetes permissions and database access on request, for a fixed time, with approval and an audit trail, then takes them away. This vendor-neutral buyer's guide covers requirements, capability areas, an evaluation criteria table, questions for vendors, red flags and a proof of concept plan. It is for cloud security, platform engineering and identity teams. The JIT Access Guide explains the concepts; the PAM Buyer's Guide covers vault and session platforms, and the CIEM Buyers Guide covers entitlement analysis.
Key takeaways
- Buy for the workflow, not the console. The test is whether an engineer can get scoped production access from the CLI or chat tool in under a few minutes, and whether it disappears on time.
- Native cloud features set the baseline. The major cloud providers offer time-bound role activation with approval and justification; a third-party tool must add cross-cloud consistency, Kubernetes and database coverage, or better workflow to justify itself.
- Grant mechanics matter. Tools that add and remove role bindings, create temporary users or mint short-lived credentials behave very differently under failure, and some break infrastructure as code or resource policies.
- The broker is tier zero. A tool that can grant any cloud role is the most privileged identity you own; its own access, credentials and resilience need the hardest scrutiny.
- Machines and agents need JIT too. Pipelines and AI agents increasingly request privilege; check how the tool handles non-human requesters and approvers.
Define requirements
- Scope of privilege: list the targets: cloud accounts, subscriptions and projects across each provider, organisation-level admin roles, Kubernetes clusters, managed databases, SaaS admin roles and break-glass accounts.
- Standing privilege baseline: count permanent privileged assignments today so you can measure reduction. Entitlement data from CIEM or native analysers helps here.
- Request channels: web portal, CLI, chat tools and ticketing; engineers will bypass anything slower than their current path.
- Approval model: self-approval with justification for low-risk roles, peer or manager approval for production write access, two-step approval for organisation-wide roles, and automatic approval tied to an open incident or change ticket.
- Duration rules: default and maximum grant length per role, early revocation, extension with re-approval.
- Authentication at request: step-up with phishing-resistant MFA at activation, enforced by the identity provider.
- Audit and evidence: who requested what, why, who approved, what was done during the grant, exportable to the SIEM and suitable for access reviews and auditors (NIST SP 800-53 AC-2 and AC-6, CSF 2.0 PR.AA-05).
- Deployment constraints: SaaS or self-hosted, data residency, and how the tool's own cloud permissions are granted.
Capability areas
| Area | What to look for |
|---|---|
| Cloud role elevation | Time-bound assignment of provider roles at account, subscription, project, folder or organisation scope; support for custom roles and condition-scoped grants |
| Ephemeral roles and credentials | Short-lived sessions or credentials rather than permanent group changes where possible; clean removal at expiry and on revocation |
| Kubernetes access | Time-bound RBAC bindings or short-lived kubeconfig credentials per cluster and namespace; works with managed and self-managed clusters. See the Kubernetes RBAC Guide |
| Database access | Temporary database users or brokered connections with scoped grants, removed at expiry; query or session logging |
| Workflow and approvals | Policy-driven routing, multi-level approval, chat and ticket integration, on-call schedule awareness, bulk and emergency paths |
| Discovery and right-sizing | Finds standing privileged assignments and suggests eligible roles from usage; integrates with CIEM data rather than duplicating it |
| Non-human requesters | Pipelines, workloads and AI agents can request scoped, time-limited access through an API with policy checks. See the NHI Authentication Guide |
| Audit and detection | Complete request, approval and grant logs; correlation with provider audit logs; alerts on grants outside policy and on privilege added outside the tool |
| Break-glass | Documented emergency access that works when the tool or identity provider is down. See the Break-Glass Account Guide |
Evaluation criteria
| Criterion | Illustrative weight | What good evidence looks like |
|---|---|---|
| Coverage of your targets | 20% | Every cloud, cluster type and database engine in your estate demonstrated, not on a roadmap |
| Engineer experience | 20% | Median time from request to usable access measured in the PoC; CLI and chat paths that engineers rate acceptable |
| Grant safety and reliability | 15% | Access always removed at expiry, including when the tool is restarted mid-grant; no conflict with infrastructure as code |
| Policy and approval flexibility | 10% | Risk-tiered rules, conditions, ticket and on-call integration expressed as code or configuration you can review |
| Audit and integration | 10% | Logs in your SIEM in a documented schema; evidence pack an auditor accepts |
| Security of the platform | 15% | Least-privilege connector roles, customer-controlled keys or federation instead of long-lived keys, independent assurance reports, tested break-glass |
| Commercials and exit | 10% | Pricing metric you can forecast (users, targets or grants), data export, clean removal of the tool's roles and bindings |
Fix weights before you see any vendor, and adjust them to your context: a single-cloud organisation may weight cross-cloud coverage near zero and native features highly. The Buyer's Guide Methodology and Scoring Template gives a scoring scale and decision record.
Questions to ask vendors
- Exactly how is access granted and removed for each provider: role binding changes, group membership, temporary users or short-lived credentials? What happens to an active grant if your service is unavailable at expiry time?
- How do you avoid conflicts with Terraform or other infrastructure as code that manages the same IAM policies? Do you require non-authoritative resources?
- How do you handle permissions referenced in resource-based policies, key policies and Kubernetes access configuration, where temporary roles or permission sets may not be picked up?
- What permissions does your connector need in our cloud organisation, how are its credentials issued, and can it use workload identity federation instead of stored keys?
- Show a developer obtaining time-bound write access to one Kubernetes namespace and one production database from the CLI, with approval in chat, and show the access removed.
- Can pipelines and AI agents request access through an API, and can a non-human identity ever approve a request? How is that controlled?
- How do you detect privileged access granted outside your tool, so standing privilege does not creep back?
- What evidence do you give auditors, and what independent security assessments of your platform can we review?
- What is the documented break-glass path when your service or our identity provider is down?
Red flags
- A connector that needs organisation-wide owner rights through a long-lived access key.
- Grants implemented as permanent changes that rely on a scheduled job to undo them, with no reconciliation if the job fails.
- Kubernetes or database "support" that is really a shared static credential handed out from a vault.
- No answer on infrastructure as code drift, or advice to stop managing IAM as code.
- Audit logs that only exist in the vendor console, with no export or documented schema.
- Approval flows that cannot distinguish production from development, so everything needs a manager or nothing does.
- Roadmap promises for the cloud or cluster type you rely on most.
Proof of concept
- Pick a representative slice: two cloud accounts or subscriptions in each provider you use, one managed Kubernetes cluster, one managed database and one organisation-level admin role.
- Record the current standing privileged assignments in that slice as the baseline.
- Convert administrators and on-call engineers to eligible access only, with policy tiers for low and high-risk roles.
- Run real tasks for two weeks: incident response, a production change and a database fix, measuring time to access and engineer feedback.
- Test failure: stop or block the tool during an active grant and confirm the access still expires; test break-glass.
- Run your infrastructure as code pipeline during active grants and confirm no drift fights or lost bindings.
- Grant privilege outside the tool and check that it is detected; confirm logs arrive in the SIEM and map to provider audit logs (watch for additional cloud roles, ATT&CK T1098.003).
- Review the connector's permissions and credential handling with your cloud security team, and score against the criteria agreed up front.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for privileged access and cloud identity programmes. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: JIT Access Guide · Cloud PAM and CIEM Guide · PAM Buyer's Guide · CIEM Buyers Guide · Privileged Access Management Guide