How should security teams implement just-in-time access for AWS accounts without recreating birthright access in another form?

Security teams should make access request driven, time bounded, and tied to specific resources or tasks. Grant the minimum permission needed, require approval from people with operational context, and automatically revoke access when the task ends. The goal is to replace permanent broad roles with short-lived, auditable access that matches actual work.

Why This Matters for Security Teams

Just-in-time access is meant to remove standing privilege, but in AWS it can be recreated quickly if teams simply replace permanent roles with reusable “temporary” access paths. That failure shows up when approvals are too broad, session durations are too long, or the same group can request access repeatedly without meaningful context. NHI Management Group research on The State of Non-Human Identity Security found that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.

The risk is not theoretical. Attackers regularly exploit exposed AWS credentials within minutes, which means any JIT design that behaves like a soft proxy for birthright access gives defenders a false sense of control. The safer pattern is request driven, task scoped, and auditable, with approval tied to operational context rather than job title alone. That aligns with the direction of the OWASP Non-Human Identity Top 10 and NIST’s control emphasis in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams discover that “temporary admin” becomes the new standing privilege only after an incident exposes how easy it was to reuse.

How It Works in Practice

A workable AWS JIT model starts by separating the request path from the entitlement path. Users do not receive broad standing roles. Instead, they request access to a specific account, resource, or break-glass action, and the system issues a short-lived session with only the permissions needed for that task. The approval should reflect operational knowledge, such as service ownership, incident status, or change window, not just ticket closure.

In practice, teams usually combine AWS-native controls with a policy engine and identity source. That means a central workflow can evaluate who is asking, what they need, which account they are targeting, whether the request matches an approved change, and how long the session should live. For stronger boundaries, access should be granted through scoped roles with session tags, then revoked automatically when the task completes or the TTL expires. The aim is to make every session traceable back to a reason, an approver, and an expiration.

• Use separate roles for read-only, operator, and emergency access instead of one broad role.
• Require task-specific approval for production changes, not blanket manager approval.
• Set short TTLs by default and make extensions exceptional, logged, and re-approved.
• Attach session tags or request metadata so audit logs show why access existed.
• Revoke access on task closure, not only on token expiry.

For context on why static or over-reused access paths become exploitable, NHI Management Group’s Guide to NHI Rotation Challenges is a useful companion, and the AWS compromise patterns in Codefinger AWS S3 ransomware attack show how quickly exposed access can be operationalised by an attacker. These controls tend to break down when the same approver can repeatedly grant high-privilege sessions without change control or when access is issued to a shared operator role that never truly disappears.

Common Variations and Edge Cases

Tighter JIT access often increases workflow overhead, requiring organisations to balance fast incident response against stronger privilege discipline. That tradeoff is real, especially for production support, security operations, and cloud engineering teams that need near-immediate access during outages. Current guidance suggests using different paths for normal work and emergency work, because forcing every request through the same approval chain creates pressure to bypass the process.

One common edge case is break-glass access. Best practice is evolving, but the safer pattern is to keep break-glass credentials isolated, heavily monitored, and subject to post-use review rather than using them as a convenience route. Another edge case is automated operators or CI/CD workflows, where JIT should apply to the workload identity itself, not just human users. In those environments, short-lived credentials and explicit scope are more important than human-style approval steps.

Teams should also be careful not to recreate birthright access through group nesting, long-lived permission boundaries, or repeated auto-approval for the same requestor. The operational question is not whether access was “temporary,” but whether it was justified for that session and whether it could have been abused outside the intended task. That matters most in multi-account AWS estates where account sprawl, shared roles, and legacy admin groups make entitlement drift easy to miss.

Related resources from NHI Mgmt Group

• How should security teams implement just-in-time access without leaving standing privilege behind?
• How should security teams implement just-in-time access without creating too much friction?
• How should security teams implement just-in-time access for AWS workloads?
• How should security teams implement just-in-time access without creating new governance gaps?