How JIT Access Works

Just-In-Time (JIT) access is a security model where users receive temporary, time-bound permissions only when they need them, rather than maintaining standing (permanent) access. This page explains the core concepts, request lifecycle, status values, and how the approval workflow operates.

Why JIT Access?

Standing permissions create risk. If a user always has access to production AWS accounts, a compromised credential or accidental action can cause damage at any time. JIT access reduces this risk by:

• Minimizing the blast radius -- Access exists only for the duration it is needed
• Enforcing least privilege -- Users request only the specific permissions required for their task
• Creating an audit trail -- Every access request includes a justification and goes through an approval process
• Enabling accountability -- Approvers review and take responsibility for each grant of access

Core Concepts

Requests

A request is a formal submission by a user to gain temporary access to a specific AWS account with a defined set of permissions. Every request includes:

• Target AWS account -- The account the user needs access to
• Permission set -- Either a pre-defined (standard) set or a custom set built at request time
• Access duration -- How long the access should last (from 1 hour to 1 month)
• Justification -- A written explanation of why the access is needed (minimum 10 characters)

Permission Sets

JIT requests support two types of permission sets:

Type	Description	Approval Path
Standard	Pre-defined permission sets configured by administrators. These include AWS managed policies and/or inline policies.	Single-level: account owner or SSO admin approves
Custom	User-defined permission sets created at request time. The user specifies a name, session duration, managed policies, and optional inline policies.	Two-level: account owner approves first, then an SSO admin gives final approval

info

Custom permission set names are automatically prefixed with JIT- to distinguish them from administrator-managed permission sets.

Request Lifecycle

Standard Permission Set Flow

User submits request
        │
        ▼
    [Pending]
        │
   ┌────┴────┐
   ▼         ▼
[Approved] [Rejected]
   │
   ▼
[Active Session]
   │
   ┌────┴────┐
   ▼         ▼
[Expired]  [Revoked]

1. The user submits a request selecting a standard (pre-defined) permission set.
2. The request enters Pending status.
3. An account owner or SSO admin reviews the request and either approves or rejects it.
4. If approved, an Active Session is created in Prism.
5. The session eventually expires automatically, or an approver may revoke it early.

Custom Permission Set Flow

User submits request
        │
        ▼
  [Pending Owner]
        │
   ┌────┴────┐
   ▼         ▼
[Pending   [Rejected]
  Admin]
   │
   ┌────┴────┐
   ▼         ▼
[Approved] [Rejected]
   │
   ▼
[Active Session]
   │
   ┌────┴────┐
   ▼         ▼
[Expired]  [Revoked]

1. The user submits a request with a custom permission set they define at request time.
2. The request enters Pending Owner status.
3. An account owner reviews the request. If they approve, the request moves to Pending Admin. If they reject, the flow ends.
4. An SSO Admin reviews the owner-approved request and either approves or rejects it.
5. If approved, an Active Session is created.
6. The session eventually expires or is revoked.

warning

Custom permission set requests require two separate approvals before access is granted. If either approver rejects the request, the entire request is rejected.

Access Duration Options

When submitting a request, users can choose from the following access durations:

Duration	Use Case
1 hour	Quick debugging or investigation
2 hours	Short operational task
4 hours	Half-day work session
8 hours	Full work day
12 hours	Extended work session
1 day	Multi-session work across a day
2 days	Short project spanning multiple days
3 days	Medium project work
1 week	Sprint-length access
2 weeks	Extended project work
1 month	Long-running project or on-call rotation

tip

Always request the shortest duration that meets your needs. You can submit a new request if you need additional time. This follows the principle of least privilege.

Next Steps

• Authentication -- How to log in to the JIT Portal
• Request Access -- Submit an access request