> ## Documentation Index > Fetch the complete documentation index at: https://www.c1.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Use case: Just-in-time (JIT) access > See how C1 provisions access for a set duration instead of indefinitely, for both routine requests and emergencies, and removes it automatically when it's no longer needed — and where to go for setup details. 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](/docs/product/use-cases/self-service-app-directory) and [identity governance](/docs/product/use-cases/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](/docs/baton/intro) 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](/docs/product/how-to/create-requests): the web app, the [C1 app for Slack or Microsoft Teams](/docs/product/how-to/create-requests#request-using-the-c1-app-for-slack), or the command line via [Cone](/docs/product/cli/install) (for people) or [c1i](/docs/product/cli/c1i-agent-skills) (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](/docs/product/admin/policies) 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](/docs/product/admin/emergency) 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](/docs/product/admin/access-requests) — 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](/docs/product/how-to/qs-aws-jit-identity-center) and [Get started with GCP JIT access](/docs/product/how-to/qs-gcp-jit) — and on-call rotations, where access can be tied to who's currently on call; see [Get started with on-call access control](/docs/product/how-to/qs-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](/docs/product/admin/automations-triggers-reference#unused-access), which fires when an account hasn't been used for a duration you set. See the [unused access cleanup example](/docs/product/admin/automation-examples#unused-access-cleanup): warn the user, wait, then revoke if it's still unused. * **The justification no longer applies.** If the access came from [membership automation](/docs/product/admin/dynamic-access-control), 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](/docs/product/use-cases/jml-automation). ## 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](/docs/product/admin/system-log) 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](/docs/product/admin/manage-campaigns#generate-a-campaign-report) covers who had what, for how long, and who approved it. ## Related resources