How JIT Works: The Four-Step Flow

The Mechanics of Ephemeral Access

JIT access is not magic — it is a structured workflow with four distinct phases. Understanding each phase helps you design, debug, and audit the system.

Step 1: Request

The workflow starts with intent. The user signals what they need, why they need it, and for how long — via a CLI tool, a web portal, or a ChatOps integration (Slack/Teams):

"I need write access to the payments-prod database to fix Issue #99. Duration: 1 hour."

The reason and ticket reference are not optional niceties — they are the audit trail. Every access grant is linked to a specific, documented business justification. This transforms access from an invisible background state into a visible, accountable event.

Step 2: Approval (The Gate)

The system evaluates the request against a policy. Policies can be automated, human-driven, or a combination:

• Auto-Approval: "Is this user currently 'On-Call' in PagerDuty for the payments team?" → If yes, auto-approve immediately. This removes friction for legitimate emergencies.
• Peer Review: "This request targets a sensitive production system." → Ping the Security Manager via Slack: "Alice is requesting write access to payments-prod. Approve or Deny?"
• Time-Based Rules: "Requests during business hours for non-critical systems are auto-approved. After-hours requests require a second approver."
• Risk Scoring: Some systems integrate with threat intelligence — if the user's device has a low security posture score, the request is escalated regardless of other factors.

The policy engine is where your organization's security philosophy is encoded. It is the difference between a system that is secure and one that is so locked down it causes engineers to find workarounds.

Step 3: Provisioning (The Grant)

Once approved, the system elevates the user's identity by making real changes to downstream systems. The specific mechanism depends on the infrastructure:

• Cloud IAM: The user is permitted to assume a high-privilege AWS IAM Role via sts:AssumeRole. Their existing identity gains temporary credentials with an expiry baked in.
• Identity Provider: The user is added to the db-admins group in Okta or Azure AD. Downstream systems that trust Okta for authorization immediately see the new group membership.
• Infrastructure Access: A short-lived SSH certificate is issued (via Teleport, Vault, or Boundary). The certificate is cryptographically signed with a 1-hour TTL — after which it is mathematically invalid, regardless of whether the JIT system is running.
• Kubernetes: A RoleBinding is created in the target namespace, granting the user the edit ClusterRole for the duration.

The provisioning step must be atomic and auditable — the system records exactly what was changed, when, and why, before the change takes effect.

Step 4: Expiration (The Revocation)

This is the most critical step, and the one most often underestimated. After the requested duration, the system automatically reverts every change it made:

• The IAM Role assumption permission is removed.
• The user is removed from the db-admins Okta group.
• The SSH certificate expires (no action needed — TTL handles it).
• The Kubernetes RoleBinding is deleted.

The user returns to their baseline "no-access" state without any human intervention. This is what makes ZSP operationally viable — you do not need an admin to manually clean up after every access grant. The system is self-healing by design.

Senior depth: The hardest part of expiration is handling in-flight sessions. If a user has an active database connection when their JIT window expires, does the system terminate the connection immediately (disruptive) or let it drain (a grace period that could be exploited)? Most mature implementations use a short grace period (5 minutes) with a warning notification, followed by hard termination. The policy for this should be explicit and documented.