How Just-in-Time Access Works for SaaS

What is Just-In-Time-Access?

Just-in-time (JIT) access is a security model where each grant of access carries a defined expiration: when the window closes, the access is revoked automatically, and the user requests again only if they actually need it.

This is the response to the standard SaaS access pattern in most companies: grant it once and never revisit the decision. Someone requests Salesforce because they need to look up an account, an admin approves it, and years later that person still has Salesforce whether they're using it or not. The access matrix accumulates layer on layer of grants made for reasons no one on the team remembers. Most of the time, when JIT access expires, people don't need it back.

How does just-in-time access work?

Just-in-time access works by attaching an expiration to every grant: a user names what they need, an approver decides, the access gets provisioned, and when the clock runs out, the access is removed automatically whether anyone is paying attention or not. The request mechanics are familiar; the difference shows up at the end of the lifecycle.

Permanent access depends on a recurring review to catch what should no longer be granted. Quarterly access reviews, manager attestations, the spreadsheet that gets emailed around twice a year, all of these are compensations for the fact that the access does not expire on its own. The reviews catch some things and miss others, and the gap between what someone has and what someone needs widens between cycles.

Time-bound access removes the catch-up. The grant carries its own expiration; when the clock runs out, the access goes away whether anyone is paying attention or not. The reviews still happen, but they confirm a state the system has already enforced rather than discovering one nobody noticed.

Why the SaaS layer is where this matters most

Just-in-time access started in infrastructure. CyberArk, BeyondTrust, and Delinea built it for the credentials that grant access to servers, databases, and network gear, where every session is privileged and every stale credential is an operational risk. Those tools still cover that surface well.

The risk has since migrated. Most of what an attacker actually wants today is in SaaS: customer records in Salesforce, source code in GitHub, financial data in NetSuite, OAuth tokens that grant onward access to dozens of integrated apps. The credentials that protect those assets do not flow through traditional PAM tooling. They live in Okta, in app-level admin consoles, in Slack workflows that someone built two years ago and forgot to document.

The result is that an organization can have rigorous controls for its handful of bastion hosts and almost no controls for the SaaS apps holding its actual sensitive data. Just-in-time access at the SaaS layer is the response to that asymmetry. The category-level term for it, just-in-time privileged access, applies whether the privileged thing is a Linux root shell or a Salesforce admin role; what changes is the tooling and the integration points.

The request and approval flow

A working JIT request has four moving parts: who asked, what they asked for, who approved, and how long it lasts. The interesting one is the approver.

Many requests have a single approver such as the manager, the app owner, or the IT lead. Sensitive grants need more than one. A request for production database access might route to the app owner first for the technical decision and then to the security team for the policy decision. A request for finance system access might add a controller approval if the role can move money. The flow is sequential by nature, and the user experience depends on how it handles approvers who are slow to respond.

The solution is escalation. If an approver does not respond inside a defined window, the request rolls forward to a backup with enough context to decide. Without escalation, the approval flow becomes the new bottleneck and people learn to over-request to compensate, which is the failure mode JIT is supposed to prevent.

What expiry actually does

Auto-revoke is the part of JIT that does the security work. The request flow can be tightened, the approvals can be cleaner, the audit log can be more searchable, but if access is not removed on schedule, the rest is decoration.

Expiry should default to the shortest duration that fits the task, with longer durations available but not assumed. Useful starting points:

• One hour covers a one-off lookup. Most ad-hoc questions need access only for the few minutes it takes to answer them, and the renewal request that follows surfaces a useful prompt about whether the access is still being used.

• A day fits a debugging session. Investigating a specific issue rarely takes longer than a workday, and the next-day re-request prompts a check on whether the work is actually still active.

• A week works for projects with a defined endpoint, like onboarding to a new tool or a sprint of focused analysis. Anything beyond that should require an explicit reason rather than a default.

• A month is the threshold where the grant starts to look permanent in practice. The renewal step at the end of the period is the only real check that it should continue, so the renewal needs to actually require justification.

Indefinite should require explicit justification, not be a default option in the dropdown. The temptation when implementing JIT is to keep indefinite available for "edge cases," and the result is that everything becomes an edge case.

Where JIT is less effective

JIT works well when access can be requested in advance. The 3am production incident is where it stops working: when something is broken right now and the on-call engineer needs production access in the next 30 seconds, an approval flow with a manager-of-record is a liability.

The pragmatic answer is a break-glass path. A separate, heavily audited route grants emergency access immediately and reviews the grant after the fact. Anyone using break-glass should expect a same-day conversation about why. If the conversation never happens, the path becomes the default and JIT is hollowed out from the inside.

The other common failure mode is contractors and short-term vendors. A six-month contract with weekly re-approvals is overhead masquerading as security. JIT for these cases should align expiry with the contract end date in the HRIS rather than fixed intervals; renewal in the HRIS extends the access automatically, and the absence of a renewal revokes it the day the contract ends.

The orchestration layer

JIT requires three layers working together. There is a system of record for identity, usually Okta. There is a place where requests get made and approved, which is Slack for most modern companies and occasionally Teams. And there is the connective tissue that turns an approved request into a SCIM call, a group membership change, or a custom action against an internal API.

The third layer is where most teams fall short. The identity provider is solved. The Slack interface is solved. But the path from "approved request" to "user actually has the access, scoped, time-boxed, and recorded" is often a manual handoff: an admin gets pinged, opens Okta, adds the user to a group, sets a calendar reminder to remove them, and forgets the calendar reminder. The whole point of JIT collapses at that step.

Tools like Lumos and Opal automate the access-granting side. Console sits a level above as the request and approval surface, where users describe what they need in natural language (from Slack, Teams, Google Chat, or wherever they work) and the system routes the request, runs the approval flow, and triggers the actual grant through whatever mechanism is appropriate, whether that is an Okta group, a custom Lambda, or a Lumos or Opal workflow. The Bloomerang IT team handles hundreds of access requests a month with a desktop team of four; the routine ones complete without anyone touching them, which is what makes the model work at scale rather than collapsing into ticket triage by another name.

A working just-in-time access system turns the access matrix from a slow-moving record of what people once needed into a snapshot of what they are working on right now.