Just-in-time access provisioning: architecture that automates from the help desk

Just-in-time access provisioning grants the minimum permissions an employee needs for a defined window, then revokes them automatically. The best architectures also run automated access management from the help desk: employees request in Slack or Teams, approvers decide in-thread, and JIT provisioning plus deprovisioning execute without IT copying data between consoles. Teams that treat JIT as a portal checkbox often leave standing admin rights in Okta groups or provision quickly but fail access deprovisioning audit when timers expire.

JIT access explained in one workflow

An engineer needs production database read access for eight hours to debug an incident. They request access in Slack. The platform checks eligibility (role, location, employment type), routes approval to their manager and a security group, provisions access, logs justification and timestamps, and removes access when the timer expires. No one files a follow-up ticket to revoke. Standing privileges do not accumulate.

That lifecycle is the reference architecture. Every design choice below either strengthens it or reintroduces standing access through a side door.

Architecture decision 1: IdP layer vs. application layer

JIT can be enforced in two places, and mature programs use both deliberately.

IdP layer (Okta, Microsoft Entra, Google Workspace). Provisioning adds the user to a group or assigns an app role that syncs downstream via SCIM. Revocation removes the group membership. Your IdP remains the source of truth for identity; JIT tooling adds time-bound role assignment on top. Okta JIT provisioning via group membership is the default pattern when SCIM is reliable.

Application layer (direct API to SaaS or internal tools). Some systems do not honor IdP group changes quickly, or permissions live only inside the app (custom roles, project-scoped keys). JIT then calls the application's API to grant and revoke a role directly. This is faster for apps without reliable SCIM but requires per-app workflow maintenance.

Design rule: Default to IdP-mediated JIT for any app with SCIM. Add application-layer workflows only where IdP sync is insufficient. Document which apps use which path so auditors do not assume Okta group removal instantly removes in-app rights everywhere.

Serval does not replace Okta. It sits alongside it: Okta continues to authenticate users and hold baseline entitlements; Serval manages temporary elevated roles, access approval workflow logic, and revocation workflows from help desk intake.

Architecture decision 2: what "time-to-access" actually measures

Procurement decks confuse three different clocks. Separate them in your architecture and your SLAs.

Time-to-first-response: How fast the employee gets a reply in Slack or email. Chatbots optimize this; it says nothing about access granted.

Time-to-approval: How long approvers take. Workflow design (parallel vs. serial approvers, escalation, on-call routing) dominates this number.

Time-to-access: Elapsed time from request submitted to permission active in the target system. This is the metric employees feel and the one Zero Trust programs should publish internally.

High-performing JIT programs compress time-to-access for low-risk roles (auto-approve under four hours, provision in minutes) while keeping multi-step approval for sensitive roles without forcing the same latency on every request. Together AI automates 95% of just-in-time access requests with Serval performing authorization logic for infrastructure access in a transparent, reviewable way. Todd Thiel, Senior Manager of Enterprise Security, noted that building comparable approval and workflow logic historically took months with legacy service desk tools and weeks with standalone JIT products; with Serval, complex guidance and workflows can ship in a day.

Derek Chamorro, Head of Security at Together AI: "We've saved days, not minutes or hours, but days of time of having to wait because Serval does a lot of the automatic provisioning for us."

When benchmarking vendors, ask for median time-to-access on your top five roles, not demo videos of chat responses.

Architecture decision 3: approval speed without approval theater

Least-privilege access fails when approvals are either so heavy that employees escalate outside the system, or so light that they are meaningless. Architecture should tier policies by risk:

Self-approve or auto-approve for read-only or widely granted roles under a duration cap.

Single manager approval for standard software access.

Multi-party approval for production admin, finance systems, or break-glass access.

Business justification capture stored in the audit log, not free-text lost in Slack threads.

Approval speed improvements come from routing logic (notify the right approver in Slack, escalate after N hours) and from eligibility checks before humans see the request. If contractors cannot request production admin, the security team should not spend cycles rejecting them.

Perplexity's security team uses Serval to practice least privilege by helping employees identify minimum access and grant it only for the necessary duration. That only works when policy is encoded in access profiles and policies, not remembered at approval time.

Architecture decision 4: time-bound access and access expiration

Time-bound access is the control that separates JIT from "we made people click a request form but left permissions forever." Architecture requirements:

Maximum duration per role enforced by policy (e.g., eight hours for prod admin, ninety days for contractor repo access).

Extension requests that re-run approval instead of silently extending.

Access expiration enforced automatically: the same integration path that grants must revoke.

Revocation symmetry: if provisioning used an Okta group, revocation removes the group membership. If provisioning used a SaaS API, revocation calls the revoke endpoint.

Break-glass logging: emergency access still gets a shorter timer and heightened logging.

Automatic deprovisioning is not optional. Together AI's case study highlights access removed without relying on a human to remember. Manual revocation tickets recreate the standing-privilege problem JIT was meant to eliminate.

Architecture decision 5: audit trail as structured data, not screenshots

Auditors ask for who had access, why, who approved, when it started, and when it ended. A JIT architecture should emit that tuple on every grant without a separate quarterly project.

Minimum audit fields:

• Requester identity and employment context

• Requested role and target application

• Business justification text

• Approver identities and timestamps

• Provision method (IdP group, API, manual task)

• Start time, scheduled end time, actual revocation time

• Export format your GRC team can ingest (CSV, SIEM, API)

Serval tracks each access request's full conversation, duration, and business justification, with exportable JIT history for access governance and access reviews. That is the difference between JIT as security theater and JIT as compliance infrastructure.

Access reviews should query the same log: which users received JIT access to which applications in the period, not static group membership alone.

Architecture decision 6: Zero Trust, least privilege, and standing privileges

Zero Trust access assumes breach. Standing privileges are the largest blast-radius multiplier: dormant admin groups, unused contractor access, orphaned SaaS roles after role changes.

On-demand provisioning attacks standing privileges by design:

• Least-privilege access: default is no elevated role; elevation is requested, approved, and scoped.

• JIT access: permissions exist only for the window of work.

• Standing privileges elimination: replace "always-on" admin with break-glass and time-bound paths.

JIT does not replace MFA, device trust, or network policies. It governs authorization after authentication. Pair with your IdP's SSO and step-up auth for sensitive roles.

How Serval fits the architecture (without competing with Okta)

Serval operates in the access management category focused on JIT provisioning and deprovisioning from help desk requests. Employees ask in Slack or Teams; the Help Desk Agent guides them to the correct role; the Automation Agent runs deterministic TypeScript workflows for approve, provision, and revoke.

Integrations:

• Identity providers: Okta, Entra, Google. Serval imports users and groups and provisions by group membership where SCIM applies.

• Applications without SCIM: API-based provisioning workflows.

• IGA and PAM: complementary. IGA handles birthright access; Serval handles temporary elevation; PAM may vault credentials after Serval grants a role.

Together AI's 95% figure applies specifically to just-in-time access requests, not all IT tickets. That distinction matters for architecture planning: JIT automation rates should be measured on access volume, separately from help desk password resets and device requests.

See how Serval provisions time-bound access through Okta →

Frequently asked questions

What is just-in-time access provisioning?

Just-in-time access provisioning grants temporary, role-based permissions when an employee needs them and revokes those permissions automatically when a defined time window ends. It replaces standing elevated access with on-demand, approved, logged grants tied to least-privilege policies.

Should JIT run at the IdP or inside each application?

Use the IdP layer (Okta, Entra, Google) as the default for apps with SCIM or group sync. Use application-layer APIs when permissions are not represented in the IdP or revocation must be immediate inside the app. Document both paths in your architecture standard.

How do you measure JIT access success?

Track median time-to-access from request to active permission, percentage of grants with automatic revocation at expiry, percentage of access requests automated end-to-end, and audit export completeness. Together AI automates 95% of JIT access requests on Serval; use your own baseline before and after deployment.

Does JIT access management replace Okta?

No. Okta remains the identity provider and SSO layer. JIT tools like Serval add time-bound role requests, approvals, provisioning orchestration, and revocation on top of existing Okta groups and policies.

What audit evidence do SOC 2 auditors expect for JIT?

Auditors expect logs showing requester, role, justification, approvers, grant time, scheduled expiry, and revocation time. Quarterly access reviews should sample JIT grants, not only static group membership. Exportable history by role or team satisfies most SOC 2 and ISO 27001 evidence requests.

How does JIT relate to privileged access management (PAM)?

PAM secures credentials and sessions for privileged accounts. JIT governs who receives elevated roles and for how long. Many enterprises use Serval to grant a database admin role for eight hours and PAM to vault the credential used during that window.