Just-in-time (JIT) access provides users with the minimum level of access required to a system, only when they need it, and for a limited amount of time. By reducing how long users can reach sensitive applications or data, JIT access makes sure that permissions aren’t left open indefinitely.
If your organization already uses an Identity and Access Management (IAM) or Privileged Access Management (PAM) system, JIT access can be enabled within that system. APIs or integrations allow the IAM system and the resource requiring access to talk to each other.
JIT access isn’t meant to replace individual end-user accounts; it’s a way to avoid unnecessary always-on access (standing access). In a zero trust model, trust is never assumed, and every access request is continuously verified.
JIT access not only verifies each request but also enforces the principle of least privilege (PoLP) by granting temporary, minimal access.
How does JIT access work?
- Zero trust baseline: Employees and contractors start with zero standing privileges to sensitive systems or data.
- Initiating access request: When a user needs to perform a specific task (for example, database maintenance or code deployment), they initiate a JIT request using an identity management system.
- Adding request specifics: The exact system or resource they need access to, the level of access required, the period of time for which access is needed, and the reason for this access request are all included.
- Automatically checking policies: The JIT system checks the incoming request against predefined access control policies, role-based use cases, clearance levels, and any active security alerts or lockdowns.
- Approving the request: Approvals are automatic for routine requests matching predefined policies. Privilege elevations or unusual requests need a designated approver.
- Multi-factor authentication: Upon approval, the user must usually complete a multi-factor authentication (MFA) process to receive the temporary access.
- Revoking access: All granted permissions are automatically revoked when the set time limit expires or if the user logs out. The entire JIT session is logged for compliance and security.
Standing access vs. birthright access
Standing access offers continuous, always-on access without expiration. Birthright access, on the other hand, is automatically granted based on preset rules and adjusted as roles or conditions change within an organization.
Standing access | Birthright access | |
Definition | Continuous, always-on access without time limits | Automatically assigned access based on preset roles or attributes |
Access duration | Permanent, until manually revoked | Dynamic — granted during onboarding and only updated if the role changes |
Risk | Higher risk compared to birthright access | Lower risk of unused access |
Administrative overhead | Lower, because frequent updates aren’t required | Low, because access assignment is automatic |
JIT vs. birthright access
Within IAM, birthright access grants entitlements when specific conditions — such as job title — are met. This access is automatically revoked if those conditions change, during a change in job title or department.
Compared to JIT access, birthright access reduces administrative overhead and makes for a more convenient user experience.
JIT access | Birthright access | |
Access duration | Temporary, only when needed, and revoked automatically after use | Permanent or long-term, based on the user's role or group membership |
Security model | Obeys aero trust and enforces PoLP | Grants broad, standing access; does not toe the line with PoLP |
Privilege management | On demand and based on specific tasks or requests — cinches unnecessary access | Users hold access privileges throughout their tenure — can increase privilege creep |
Approval process | Requires approval for each access request, usually via MFA or other conditional policies | Granted automatically at onboarding without ongoing oversight |
Flexibility | Highly flexible; can be time-based, context-aware, or role-based access control | Less flexible; requires updates if access needs to be changed |
Audit and compliance | Detailed logging and tracking are available for every request | Less granular logging — makes compliance audits more tedious |
Risk exposure | Reduces the attack surface by limiting the duration of access | Prone to risk due to persistent, long-term access that attackers can exploit |
Scalability | Scales efficiently, especially in large, dynamic environments with frequent access changes | Static roles become difficult to manage as the organization grows |
PAM vs. JIT-enabled PAM
Standard PAM solutions extend static control of privileged accounts but leave users with broad, persistent access. This can become a risk over time. JIT-enabled PAM works on demand, granting privileges only when needed.
Standard PAM | JIT-enabled PAM | |
Purpose | Acts as sluice for privileged accounts — admin or root, with full-time, nonrestricted access | For on-demand access to privileged accounts — granting temporary, task-specific access when necessary |
Access granularity | Broad, ongoing access to multiple critical systems inherent to privileged roles | Fine-grained, context-aware access, granting privileges only for specific tasks, at specific times |
User interaction | Users retain high-level access indefinitely. Re-authentication for privileged activities is most often not required. | Users must request access for each task. Access is revoked automatically when the task is completed. |
Incident response | Requires continuous monitoring to detect misuse or abuse; leads to slow incident detection | Allows faster incident detection by limiting access windows and leaving little room for privilege misuse |
Cost and resource management | High costs because privileged sessions need 24/7 monitoring | Lower ongoing costs because JIT access removes the need for full-time access monitoring |
Types of just-in-time access
1. Justification-based access control
Also known as “broker and remove” access, this type of JIT requires users to provide a reason for requesting privileged accounts. Once this request comes through, a designated authority approves or denies access. Broker and remove access is ideal for environments with strict compliance requirements.
2. Ephemeral accounts
These “temporary accounts” or “zero-standing privilege” accounts are activated only when needed. They are then deactivated and deleted after use. Contractors on short-term projects can request ephemeral accounts; no lingering permissions remain.
3. Temporary elevation
Temporary elevation raises privileges on a by-request basis. Privileges are then automatically taken back after the specified period expires. If employees occasionally need admin-level access, this is the type of JIT access to use.
Break-glass access, on the other hand, is emergency or contingency access for authorized individuals. These individuals can bypass regular access controls to resolve emergency cybersecurity incidents.
Benefits of just-in-time access
JIT access enforces PoLP
JIT access implements the principle of least privilege (PoLP), granting users access only when necessary and for the least amount of time. Providing default access as with birthright access undermines PoLP and opens the door to needless security risks.
Access provisioning and deprovisioning is automatic
JIT access automates the entire access lifecycle — from request to revocation. IAM typically integrates with external identity providers (IdPs) via SAML assertions. This allows JIT to provision temporary IAM roles on the go based on real-time user attributes from the IdP.
Here’s an example. When a user attempts to access AWS, they are authenticated by the IdP, sending a SAML assertion with details like identity and group memberships. AWS uses this information to assign the appropriate IAM role. The user is then granted only the permissions needed for that session. This eliminates the need for preconfigured, long-term access.
Simplifies compliance and auditing
With ConductorOne, you get detailed audit trails for all access activities. This helps you meet regulatory standards like SOX, HIPAA, and GDPR. The platform generates extensive reports on who accessed what, when, and why, reducing the time spent on manual access reviews.
Includes flexible access controls
Creating custom roles that match certain job functions or tasks within your organization is easy with ConductorOne. For example, you could design a role that grants temporary access to financial data only for users in the accounting department during audit season.
You can also set up multistep approval workflows for high-risk applications — such as customer databases — requiring approvals from both a manager and the security team before opening up access.
Allows self-service access requests
Self-service JIT access requests can be submitted via the Request access form, Browse access page, Slack, or a command-line interface (CLI). Users can browse a personalized app catalog to request individual permissions or predefined bundles, specifying how long they need access.
ConductorOne’s Browse access page is a personalized app catalog containing all the apps currently assigned to you and available for you to request.
Each request requires a justification, and there is an emergency access option as well. Once submitted, users can track the status of their request, view assigned reviewers, and also receive notifications.
Gives human-in-the-loop approvers more context
ConductorOne’s Access Copilot uses AI to give risk-based recommendations that guide approvers. Along with the JIT access request, approvers can see the user’s past access patterns, behaviors, compliance tags, and more.
All of these features act as stumbling blocks against both internal and external security threats. JIT prevents internal users from having unnecessary long-term access privileges. Detailed audit logs can help identify unusual access patterns — a sign of external threat actors.
How does JIT work together with other security controls?
With cloud security posture management (CSPM)
CSPM tools shepherd cloud configurations and can identify vulnerabilities or misconfigurations. When JIT is in the mix, users only have limited access to sensitive cloud resources.
For example, if an admin needs to configure a cloud server, JIT ensures access is granted for that session alone. Alongside this, CSPM tools verify that the cloud configuration remains airtight after the fact.
With identity governance and administration (IGA)
IGA tracks user identities across their lifecycle — during onboarding, role changes, and offboarding. JIT and IGA together make sure that even if a user has broad role-based privileges, they don’t have constant access to all sensitive systems.
With security information and event management (SIEM)
SIEM systems shadow JIT to spot unusual patterns in access requests. In a way, JIT reduces the overhead on the SIEM system by lowering the number of privileged actions that need to be tracked. If an unauthorized access request is flagged, the SIEM system can automatically trigger alerts or block further access.
Related → What Is Cloud Infrastructure Entitlement Management (CIEM)?
Moving from birthright to JIT access using ConductorOne
What does your current access setup look like? Use ConductorOne’s discovery features to identify all existing birthright access across your organization. Group access types by importance and frequency of use.
Define JIT policies: Create custom JIT access policies for each application, role, or resource. Set time frames for access windows — ranging from a few hours to a few days. Then configure approval processes for different access levels.
Configure the self-service portal: Build a self-service interface to allow users to request JIT access easily. Field user requests through Slack, CLI, and web app.
Create approval workflows: Sensitive resources can have multistep approvals while low-risk access requests only need auto-approval policies. Also enable automatic provisioning and deprovisioning.
How are you set up for emergency access? Set up break-glass procedures in ConductorOne for emergencies that require immediate, limited-time access.
Gradually phase out birthright access: Start with noncritical systems, moving them to JIT access in ConductorOne.
Train users on how to request JIT access using ConductorOne’s interfaces. Also walk approvers through using ConductorOne’s contextual information for decision-making.
FAQs
1. What happens when a user’s task takes longer than the initial access period?
If a user needs more time than what was allocated, they can submit a formal request for a time extension. This request can include the justification for more time, incomplete tasks, and an estimate of the additional time needed.
ConductorOne includes automated workflows to handle similar extension requests before the access period expires.
2. Can JIT access be used to provide remote access?
Yes, JIT access can be used to provide safe remote access to systems and resources. JIT can be combined with a VPN and some form of device authentication so that only approved users receive remote access.
3. How does JIT use APIs to provide real-time access?
Let’s say your developer needs temporary access to a production database for troubleshooting:
- The developer submits a request through your JIT access portal.
- The JIT system calls an API call to your identity provider — like Microsoft Entra ID (previously Azure AD)— to verify the developer’s identity and role.
- If approved, the JIT system makes an API call to the database management system to create a temporary user account with the right privileges.
- The developer then receives any temporary credentials; a password manager may be used here.
- After a set time period, the JIT system automatically makes API calls to revoke the temporary access and delete the account.
- Your SIEM system logs all actions via API calls for auditing.
4. Does JIT always use a centralized vault for password management?
No. While JIT uses a central vault in PAM systems, it can also use token-based (OAuth 2.0), API-based (AWS IAM), or federated identity systems (Microsoft Entra ID).
