TL;DR: Temporary, non-privileged access and elevated administrative access need different controls, even when both use JIT and least privilege, according to JumpCloud. The practical lesson is that access governance fails when organisations treat ordinary request workflows and high-risk privileged sessions as the same problem.
At a glance
What this is: This is an analysis of why access requests and PAM are not interchangeable, even though both use JIT and least privilege.
Why it matters: It matters because IAM teams need separate governance patterns for ordinary request workflows and high-risk privileged sessions, or they lose control over auditability, session visibility, and containment.
Context
Least privilege is not a single control pattern. In practice, organisations use different mechanisms depending on whether the access is ordinary, temporary user access or elevated administrative access to critical systems.
JumpCloud’s article draws a clean line between access requests and privileged access management, showing that both can be JIT but should not be governed as the same workflow. That distinction matters for NHI, human IAM, and PAM programmes that try to simplify access governance without flattening risk.
The security gap appears when teams treat all temporary access as equivalent. Standard request workflows can document approval and revocation, but they do not replace vaulting, session monitoring, and brokering for privileged sessions.
Key questions
Q: How should security teams separate IAM and PAM in practice?
A: Treat IAM as the baseline control for identity proofing, routine access, and lifecycle governance, then add PAM for accounts that can change systems, access sensitive data, or escalate risk. The two layers should share policy data but not the same access path. That separation makes privileged activity easier to broker, monitor, and revoke.
Q: Why does least privilege need different controls for admins and regular users?
A: Because the risk is not the same. Regular users need bounded access to complete a task, while administrators can affect infrastructure, data, and security settings. Least privilege for admins therefore has to include credential custody, session monitoring, and brokering, not just approval and revocation. The control objective changes with the blast radius.
Q: What breaks when organisations treat JIT as a single access model?
A: The governance model breaks at the point where temporary access is assumed to be enough for every role. For standard users, JIT can work as an approval and provisioning workflow. For privileged users, JIT without vaulting and session recording leaves reusable credentials and unobserved sessions in place, which undermines the whole purpose of privilege reduction.
Q: When should teams use PAM instead of a normal access request?
A: Use PAM whenever the access path reaches sensitive infrastructure, administrative consoles, or any system where a single session can create broad operational impact. A normal access request is appropriate for routine resource access, but it does not provide the same containment, visibility, or credential protection that privileged work requires.
Technical breakdown
Access requests vs PAM: different control planes for access
Access requests are workflow controls for standard access. They route a request through approval, then grant temporary permissions, often by adding a user to a group tied to a resource. PAM is a higher-assurance control plane for elevated access. It brokers the session, hides raw credentials, and places stronger monitoring around the transaction because the target is a sensitive system and the user’s actions have greater blast radius.
Practical implication: Do not design one access approval path for both ordinary entitlement changes and privileged administration.
Why JIT does not mean the same thing in each model
JIT is a provisioning pattern, not a security outcome by itself. In access requests, JIT means the user receives temporary permissions for a bounded task and those permissions are revoked after use. In PAM, JIT means the administrator receives only the elevated access needed for a specific session, with secrets vaulted and rotated. The control objective changes from convenience and traceable approval to containment, credential protection, and session integrity.
Practical implication: Define what is being provisioned, for whom, and under what audit expectations before calling a workflow JIT.
Least privilege depends on the session type and the target
Least privilege is context-sensitive. For everyday access, the aim is to grant the minimum permission required for a business task. For privileged access, least privilege also includes not exposing reusable credentials, restricting the session path, and recording the command stream. When the target is a database, server, or cloud admin plane, the access mechanism must account for the fact that privilege itself is the asset under protection.
Practical implication: Use session recording, vaulting, and brokering whenever the access path can alter infrastructure or sensitive data.
NHI Mgmt Group analysis
Least privilege is being overloaded when organisations collapse request workflows and privileged sessions into one governance model. The article shows two different identity problems: temporary business access and elevated administrative control. One is about entitlement delivery, the other is about protecting the keys to critical systems. Practitioners should stop treating “JIT access” as a single design pattern and instead govern it by risk class.
PAM is not just stronger access approval, it is a different containment model. Vaulting, rotation, brokering, and session recording exist because privileged access is structurally different from ordinary user access. A request workflow can prove a manager approved access, but it cannot by itself protect the session from credential reuse or post-approval misuse. The practical lesson is that audit trails and credential custody are not interchangeable.
Unified access platforms help only when governance boundaries stay explicit. The presence of one platform for both access requests and PAM does not remove the need for separate control objectives, evidence, and review cycles. Access governance gets weaker when teams assume operational simplicity means security equivalence. Practitioners should map each access path to the control it actually needs, not the control that is easiest to administer.
Identity blast radius is the right named concept here. Ordinary requests primarily reduce over-entitlement, while PAM reduces the blast radius of administrative compromise. Those are related outcomes, but they are not the same governance problem. The implication is that IAM leaders must measure access by impact potential, not by whether a workflow contains an approval step.
From our research library:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Read next: Privileged Access Management Guide
What this signals
Temporary access and privileged access need different governance even when both are delivered just in time. Access reviews, approvals, and auto-revocation help with ordinary entitlement requests, but elevated sessions still need vaulting, brokering, and full session evidence if IAM teams want meaningful control.
Identity blast radius: this is the useful lens for separating access requests from PAM. Request workflows mainly limit who gets access, while PAM limits what an administrator can do and what evidence survives the session. That distinction becomes central when security teams are trying to align Zero Trust architecture with operational reality.
Least privilege fails as a programme slogan when it is not tied to the class of access being granted. Our research shows 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
For practitioners
- Separate request workflows from privileged session governance Use access requests for temporary non-privileged permissions and reserve PAM for administrator, root, and high-impact system access. Map each workflow to its own approval, logging, and revocation model.
- Vault and rotate privileged credentials Keep Windows passwords and SSH keys for privileged accounts in a vault, and rotate them automatically so users never handle reusable secrets directly.
- Require session recording for elevated access Record commands and screen activity for privileged sessions so the audit trail captures what happened after access was granted, not only who approved it.
- Use brokering for sensitive targets Proxy privileged sessions to servers, databases, and web consoles instead of exposing direct credentials or internal network paths to the operator.
- Apply least privilege by access class Review whether a given task needs temporary resource access or elevated administrative control, then set the minimum control set accordingly.
Key takeaways
- Access requests and PAM solve different access problems, even though both can use JIT and least privilege.
- Ordinary entitlement workflows are not a substitute for vaulting, brokering, and session recording on privileged systems.
- IAM teams need separate control objectives for standard users and administrators or they will understate privileged risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on avoiding excess privilege in both ordinary and privileged access paths. |
| NHI-07 — Long-Lived Secrets | PAM vaulting and rotation directly address reusable privileged secrets in this article. | |
| Recommendation — Map each access path to NHI-05 and remove standing privilege wherever JIT is sufficient. Apply NHI-07 to vault, rotate, and retire privileged secrets instead of exposing them to operators. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and custody for privileged accounts align directly to authenticator management. |
| Recommendation — Use IA-5 to govern privileged authenticator issuance, storage, and rotation across admin accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article distinguishes ordinary entitlements from elevated authorizations under zero trust. |
| Recommendation — Apply PR.AA-05 to separate routine access approvals from privileged authorisation controls. | ||
| NIST Zero Trust (SP 800-207) | Least privilege — Least privilege principle | The article is explicitly about least privilege in a zero trust access model. |
| Recommendation — Use least privilege to enforce task-scoped access and limit administrative blast radius. | ||
Key terms
- Access Request Workflow: A structured process for submitting, routing, approving, and tracking access changes. In identity governance, it is more than ticket handling because it can shape who receives access, under what policy, and with what audit evidence. Poorly designed workflows can record decisions without enforcing lifecycle control.
- Privilege Access Management: Privilege Access Management is the discipline of controlling and monitoring elevated access to critical systems and data. It governs how privileged accounts, credentials, sessions, and commands are issued, used, recorded, and revoked, so administrative power is limited, traceable, and aligned to policy, risk, and operational need.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org