How should security teams implement just-in-time access for Azure identities?

Why This Matters for Security Teams

Just-in-time access in Azure is often treated as a simple privilege reduction exercise, but the real risk is broader: standing permissions accumulate across privileged roles, service principals, and automation paths that are easy to overlook. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which turns “temporary” elevation into a meaningful blast-radius problem if the underlying role is already too broad. That is why JIT must be paired with role scoping, not used as a substitute for it.

Security teams also need to avoid a split model where humans are governed tightly while non-human identities are left on long-lived secrets and permanent entitlements. The OWASP OWASP Non-Human Identity Top 10 frames over-privilege and weak lifecycle controls as core failure modes for NHIs, and that maps directly to Azure environments that rely on Entra ID PIM without extending governance to automation. In practice, many security teams encounter standing privilege and service principal misuse only after an incident has already created an urgent access review, rather than through intentional design.

How It Works in Practice

For Azure identities, effective JIT starts with the identity type and the permission path, not the activation button. Human admins typically use Microsoft Entra Privileged Identity Management to make privileged roles eligible, require MFA, justification, and approval, and activate for a bounded period. That is the easy part. The harder part is ensuring the eligible role itself is narrowly defined, because time-limited access to an overbroad role still produces excessive exposure.

For non-human identities, current guidance suggests treating JIT as ephemeral workload access rather than classic role activation. That means issuing short-lived tokens or credentials per task, binding them to a workload identity, and revoking them automatically when the task ends. In Azure-native terms, teams should prefer managed identities where possible, use role assignments with the smallest practical scope, and move toward policy-as-code for request-time decisions. The security goal is not “who can request access,” but “what exact action can this identity perform, for how long, and under what runtime context.”

• Make roles eligible only after rights are trimmed to the minimum required scope.
• Use time-bound activation for admins, with justification and approval tied to the specific role.
• Prefer ephemeral secrets and workload identity over static client secrets for automation.
• Review whether service principals, pipelines, and scripts inherit the same governance as humans.
• Log activation, token issuance, and privileged action separately so access reviews reflect real use.

This aligns with Zero Trust expectations and with the NHI lifecycle guidance in the Guide to NHI Rotation Challenges, where long-lived credentials are the problem and short-lived, revocable access is the control objective. These controls tend to break down in hybrid Azure environments where legacy apps, shared service accounts, and manual break-glass workflows still depend on static secrets because the access path cannot be cleanly time-boxed.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, requiring organisations to balance stronger blast-radius reduction against user friction and admin response time. That tradeoff is especially visible in Azure subscriptions with many delegated operators, multiple tenants, or application teams that expect always-on access for troubleshooting.

There is no universal standard for this yet, but current guidance suggests three common variations. First, human JIT should use eligible roles plus activation controls and periodic access reviews. Second, workload JIT should use short-lived credentials, managed identities, or federated identity paths instead of persistent secrets. Third, high-risk operations may require separate approval thresholds or scoped break-glass accounts because not every emergency can be handled by the same workflow.

Edge cases matter. Shared service principals used by CI/CD often fail the JIT model unless they are refactored into task-specific identities. Cross-tenant access and vendor automation also create visibility gaps, which is why NHIMG highlights the danger of exposed secrets and privilege escalation patterns in Azure environments. The Azure Key Vault privilege escalation exposure research is a useful reminder that controlling secret access is not the same as controlling effective privilege. For teams building a mature program, the practical test is whether access disappears automatically when the job is done, not whether the role was labeled temporary.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?