Skip to main content
Standing access — a grant with no end date — is risk that just accumulates: nobody notices it, nobody revokes it, and it’s still there long after the reason for it is gone — exactly the kind of stale entitlement an attacker or an auditor finds first. Just-in-time (JIT) access is the alternative: request it, get it for exactly as long as the work needs, and have it removed automatically. This page pulls together the JIT mechanics already used throughout the self-service and identity governance use cases into one place, plus the emergency-access path those don’t cover.
This page assumes you’ve already added and configured connectors for the systems you want to grant time-bound access to.

Request access where work happens

JIT requests go through the same channels as any other access request: the web app, the C1 app for Slack or Microsoft Teams, or the command line via Cone (for people) or c1i (for agents and coding assistants). A requester picks the resource and, where a duration option is offered, how long they need it.

Apply policy before approval

Every request runs through an approval policy that can route on identity, role, resource, and duration before granting anything — auto-approve for routine, low-risk, short-duration requests, or route to a reviewer for anything longer or more sensitive. For a genuine incident, emergency access is a distinct, expedited path: admins enable specific entitlements for it and assign a separate emergency access policy, so a break-glass request doesn’t wait behind the standard review queue.

Set the scope and expiration

Time limits are set on the entitlement or access profile itself via Max request duration — once it’s on, a grant made against it can’t outlive that window, and C1 sends the requester reminders as it approaches expiry (at 30, 14, 3, and 1 days out, and 1 hour, depending on the grant’s length) so they can request an extension if the work is still ongoing. This same mechanism covers routine time-bound access, cloud infrastructure access — see Get started with AWS JIT access and Get started with GCP JIT access — and on-call rotations, where access can be tied to who’s currently on call; see Get started with on-call access control.

Remove access automatically

What “automatic” means depends on why the access is ending:
  • The clock runs out. This is fully automatic once Max request duration is set — no automation to build, C1 revokes the grant when the window closes.
  • It stops being used. This isn’t automatic by default — build it with the Unused Access trigger, which fires when an account hasn’t been used for a duration you set. See the unused access cleanup example: warn the user, wait, then revoke if it’s still unused.
  • The justification no longer applies. If the access came from membership automation, a role or department change that makes someone stop matching a profile’s condition triggers unenrollment and, depending on how the profile is configured, revocation — covered in depth in the JML automation use case.

Audit evidence

Every request, approval, grant, and revocation is recorded on its task’s audit log, and the underlying events are available as system logs in OCSF format for export to a SIEM. If JIT access is scoped by an access review campaign instead of an individual request, the campaign’s own report covers who had what, for how long, and who approved it.

Access requests

Enable emergency access

Get started with AWS JIT access

Get started with GCP JIT access

Get started with on-call access control

Automation examples

Self-service use case

JML automation use case