Just-in-Time Access Explained
Just-in-time (JIT) access, also called just-in-time privileged access management (JIT PAM), refers to the granting of privileged access or permissions only for the finite moments it is needed. Access terminates, or is revoked, after a set duration of time has expired, or certain conditions are met. A just-in-time access model entails eliminating always-on, persistent privileged access, referred to as "standing privileges".
Most organizations understand that providing just enough access (JEA), and in the right context for the right user, is essential for implementing the principle of least privilege. However, “true least privilege” entails implementing both models (JEA + JIT) together. Combining the just enough and just-in-time approaches is also essential for enabling zero trust.
While enterprises largely grasp how implementing just enough access massively reduces the attack surface, many overlook how enforcing a just-in-time permissions model dramatically condenses threat windows. By combining these two models, organizations vastly minimize the potential footholds for attackers and the paths to privilege that could enable them to advance and escalate an attack.
The problem we see many enterprises struggling with is that they have:
1. (Too) many accounts with unnecessary privileges, permissions, and entitlements – These can easily number in the tens of thousands across Active Directory, Entra ID, Okta, PingOne, AWS, Windows, macOS, Linux, etc. Plus, the myriad SaaS applications that contribute to this permissions sprawl, such as Microsoft 365, Google Cloud, Google Workspace, Workday, Marketo, and Tableau, to name a few.
2. A standing access status quo – There is no just-in-time provisioning—accounts either have privilege(s) and it is always active, or they lack the privilege(s). Today, standing access is most prevalent in the cloud, where permissions and entitlements proliferate, often with little oversight or realization by IT/security that they exist.
3. Privilege blindness – Enterprises are seeing an alarmingly incomplete picture of the identities and accounts with elevated access, or potential for that access. Modern, cloud, and hybrid environments typically have high levels of privilege or permissions nested beneath many layers (i.e. AD access groups, etc.). IT/security may think they have a complete or near-complete view, but when they engage with us and we examine their environment, they are usually shocked to realize they only had fractional visibility, and the residual risk surface is substantive.
4. Lack of context around privileged risk – They are unable to quantify the impact of a privileged account compromise. They can’t visualize the potential blast radius and the privilege pathways that could then be leveraged for lateral movement.
These challenges can seem impossible to effectively solve, and may be further justification for cyber insurance. But these are all challenges BeyondTrust was built to solve, and are part of our core mission to solve for our customers.
In the rest of this blog, my hope is that you will be able to clearly take away:
- Why organizations need a least privilege approach that blends JIT and JEA
- Examples quantifying how much JEA and JIT access models can reduce cyber risk and improve your security posture
- Practical use cases for implementing just-in-time access across cloud, hybrid, and on-premises environments
- How BeyondTrust helps organizations cohesively implement just enough access, just-in-time.
Just-Enough-Access vs Just-in-Time Access
Least privilege management, as traditionally practiced, entails restricting privileges/privileged access for users, processes, applications, and systems to just enough access—and nothing more—to perform a legitimate activity. Multiple technologies and strategies can implement this—from firewalling to systems hardening—but privileged access management (PAM) arguably remains the most significant and effective of these, especially at an identity level.
A just enough access approach advanced by PAM is immensely effective at reducing the threat surface. As we’ve reported in our annual Microsoft Vulnerabilities Report, historically, 75% of Microsoft critical vulnerabilities could have been mitigated by completely removing admin rights from users. That’s just a small glimpse into the awesome risk-reduction power of enforcing just-enough access—the way least privilege is typically conceived of and practiced.
Yet, the abuse and/or misuse of privileges plays a role in almost every cybersecurity breach incident today. Partly, this is because many organizations have still not even implemented the basics of least privilege (i.e. just-enough access) across the moving target that is their evolving IT environment. However, it’s also because most organizations have not matured their least privilege controls to include the just-in-time access model. This model requires higher levels of automation and orchestration.
Despite enforcing just-enough access, the remaining problem and residual privilege risk is that privileged accounts are still:
- always enabled
- always have their entitlements, permissions, and privileges
- can always perform privileged tasks on an asset, or use their cloud permissions to access sensitive resources (i.e. customer data).
It’s important to note that this risk goes beyond traditional privileged accounts (root, Admin, etc.) to encompass any account that may have elevated access. With today’s cloud permissions model, the fact that most users have access to multiple—even dozens—of SaaS apps means the line between privileged and unprivileged is much more blurred than in the past.
Standing privileges present a massive risk surface as it means the privileged access, rights, and permissions are always in a privilege-active mode and ready to be exercised—for legitimate activities as well as for illicit ones. This always-on model equates to a vast over-provisioning of privileges, presenting cyber threat actors with a wide window of opportunity in which to act.
And when you factor in that the unneeded, and often unseen, cloud permissions sprawled across an organization can easily number in the tens of thousands, the magnitude of this largely unmanaged risk becomes evident.
Consider some findings from Microsoft and IBM.
Microsoft’s 2023 State of Cloud Permissions Risks report found:
- Over 40,000 permissions across key cloud infrastructure platforms that can be granted to identities, of which over 50% are high-risk.
- 50% of cloud identities are Super Admins, which are users or workloads with access to all permissions and resources.
- 60% of cloud identities were found to be inactive (dormant) and haven’t used any of their permissions granted in the last 90 days.
The 2022 IBM Security X-Force Cloud Threat Landscape Report found:
- In 99% of pentesting cases conducted by IBM’s X-Force Red, the pentesters were able to compromise client cloud environments through excess privileges or provisions.
To quickly summarize, there is an immense number of privileges and permissions across organizations that creates a huge theoretical risk. And evidence continues to show that the risk for many organizations does not remain theoretical—at some point, it results in an actual security incident or breach.
The Benefits of Just-in-Time Access
Implementing JIT PAM can ensure identities and accounts only have the appropriate privileges when necessary, and for the least time needed. This process can be entirely automated so that it is invisible to the end user.
Just-in-time access sharply limits the duration an account possesses elevated privileges, access rights, and permissions, drastically reducing the window of vulnerability during which time a threat actor can exploit account privileges. The account is inactive until needed, which means the paths to privilege also do not exist until needed.
Consider a typical always-on privileged account that may be “privilege-active” 168 hours (7 days X 24 hours) a week. By shifting to a just-in-time privileged access management approach, you could reduce that privilege-active state from 168 hours down to several hours, or even just minutes, if the account(s) rarely needs to be used.
Below is a representation of an always-on account versus JIT-enabled accounts.
Multiplying this effect across your enterprise will have a highly consequential impact on risk reduction.
Core benefits of enabling just-in-time access include:
- Reduced cyber risk - Privileged threat windows and attack surfaces may be minimized more than 90%. This equates to lower risk and impact of cyberthreats, such as ransomware, malware, insider threats, and more.
- Regulatory compliance - Least privilege and limited standing privileged access are key parts of numerous regulatory and compliance frameworks. In addition, just in time permissions and access minimizes the number of privileged sessions, making it easier to audit privileged activity.
- Cyber Insurance qualification - Enforcement of least privilege is a foundational security control required by most cyber insurers to qualify for coverage and get the best rates. Cyber insurers appreciate controls such as JIT access that can curb cyber threats and lower risk.
- Reduced workload - JIT access automation removes manual processes and much of the decision-making burden from IT. For instance, dynamically determining and provisioning amongst the tens of thousands of cloud permissions is manually infeasible. JIT access also gives the right users what they need, when the need it, without hassle.
How JIT PAM Works
In a just-in-time access model, the necessary privileges or cloud permissions are auto-provisioned based on an approved task or mission, and subsequently revoked once the task is complete, or the window or context for authorized access has expired.
When a privilege or permission is requested, it must meet the required contextual parameters before being checked out—the privilege is never owned by the account. Context is determined by policy and by intelligence feeds. For instance, context includes source IP address, geolocation, group membership, host operating system, applications installed or operating in memory, documented vulnerabilities and other risks, etc. Based on any logical combination of these traits, JIT account access can be granted or revoked to satisfy business requirements and mitigate risk.
In traditional JIT PAM deployments, access is typically enabled within a single domain only. For example, JIT access may be enabled for an admin to perform work within AD. In this JIT privileged access model, a user might trigger multiple sequential or concurrent JIT requests to achieve an objective that spanned a diverse DevOps environment.
However, the emergence of permissions bundling capabilities can now enable JIT access that crosses multiple domains via one seamless workstream. The assignment of permissions bundles to users improves efficiency and also simplifies auditing.
A just-in-time access workflow may look like this:
- A trigger initiates the privilege or permissions request. This can happen completely invisible to the end user, or can occur via a streamlined self-service process in which the user chooses what they need access to and requests it via email, Jira, Slack, a ticketing system, etc.
- The method of just-in-time access elevation is invoked based on technology, platform, and technical requirements.
- Access is monitored.
- Good behavior is audited, reported, and documented.
- Bad behavior initiates a workflow for investigation.
- Elevated access is revoked.
Here’s a representation of how a just-in-time cloud permissions workflow may work via a self-service request:
There are multiple methods for enabling JIT access, each with its own set of use cases. Here’s an overview of some methods:
1. JIT Privileges - The account has individual privileges, permissions, or entitlements added to perform a mission. The rights are revoked once the mission is complete, and should include certification that no other privileges were inappropriately altered.
2. JIT Account Creation and Deletion - The creation and deletion of an appropriate privileged account to meet objectives. The account should have traits to link it back to the requesting identity or service performing the operation for logging and forensics.
3. JIT Group Membership - The automatic addition and removal of an account into a privileged administrative group for the duration of the mission. The account should only be added to an elevated group when the appropriate criteria are met. Group membership is revoked upon mission completion.
4. JIT-Disabled Admin Accounts - Disabled administrator accounts are present in a system with all the permissions, privileges, and entitlements to perform a function. They are enabled to perform a specific mission and subsequently disabled once operational criteria have been satisfied. This concept is no different than having always-on administrative accounts, with the exception that native enablement functionality is leveraged to control JIT access.
5. JIT Impersonation - The account is linked to a preexisting admin account(s). When a specific application or task is performed, the function is elevated using the admin credentials. This is commonly done using automation or scripting with Windows “RunAs” or *Nix SuDo. Typically, the end user is unaware of the impersonation account for this type of operation, and the process may overlap with always-on privileged account delegation.
6. JIT Tokenization - The application or resource has its privileged token modified before injection into the operating system kernel. This form of least privilege may be used on endpoints to elevate the privileges and priority of an application without elevating privileges for the end user.
Use Case Examples for Just-In-Time Privileged Access
Some common initial use cases for adopting a just-in-time access model in an enterprise include:
- Privileged remote access: The remote user (employee, vendor, etc.) is provisioned access to the appropriate privileged commands and functions for the finite moments needed.
- DevOps environment access: Access is limited to specific functions to control the scope of their potential actions on the system and prevent any perceived violation of separation of duties requirements. This can involve spontaneous generation of secrets or SSH keys to enable ephemeral access.
- Break glass / emergency response: In an emergency or unexpected failure scenario, a JIT model can enable instant access to key resources so a team can quickly troubleshoot and rectify the issue.
- Temporary Projects: JIT access can be used to provide temporary access (for developers, marketing, HR, and other roles) to cloud resources during short-term projects or collaborations.
Recent advances in JIT cloud permissions mean that, in addition to improving security, implementing ephemeral access across a broad swathe of the workforce is now practical at scale.
Implementing True Least Privilege with BeyondTrust
Earlier, I mentioned four key challenges BeyondTrust was built to solve. The just-in-time access approach outlined above covers the first two:
1. (Too) many accounts with unnecessary privileges, permissions, and entitlements
2. A standing access status quo
We can effectively implement a JIT access model across your organization to address both of these security risk areas—without disrupting your business. BeyondTrust enforces least privilege by removing admin rights and other unnecessary privileges and entitlements, and by enforcing modern just-in-time access models for PAM and cloud permissions management.
We also address #3 and #4 via the BeyondTrust Privileged Identity Security platform, powered by our Identity Security Insights solution:
3. Privilege blindness
4. Lack of context around privileged risk
Identity Security Insights illuminates privileged pathways and identity vulnerabilities (lack of MFA, vulnerability to pass-the-hash and kerberoasting attacks, etc.), and uses AI-based capabilities to pinpoint attacks that other tools miss—across the entire identity fabric.
We believe it’s essential to address all four of these areas in a cohesive way. After all, you need visibility into all privileged identities, permissions, and potential paths to privilege, and you need to put risk in context, to effectively implement JIT PAM and achieve true least privilege.
While zero standing privileges (ZSP), meaning elimination of all standing (always on) privileges, is the aspirational end-state of a JIT access implementation, this is probably not achievable. For instance, machine accounts used for automation, such as service accounts and functional accounts, may need always-on privileges to ensure seamless orchestration. With that said, it’s especially critical that these accounts are onboarded and managed. BeyondTrust can also ensure these types of automation accounts are all known, onboarded, and managed from a secrets management and least privilege perspective.
If you’d like to discuss how BeyondTrust can help your organization implement true least privilege seamlessly across cloud and on-premises environments, and give you a force multiplier for risk reduction, contact us today.
Learn More About How to Achieve Just-in-Time Access & Least Privilege
Reduce Risk Through a Just-in-Time Approach to PAM (Gartner® analyst research)
Zero Standing Privileges Explained (Glossary)
Buyer’s Guide for Complete Privileged Access Management (Guide)
Sam Elliott, SVP, Products
Sam Elliott is the Senior Vice President of Products at BeyondTrust, where he oversees the company’s solution portfolio. Leading with an identity security first approach, he drives product innovation and integration strategies across the broader security ecosystem. A technology veteran of over 18 years, Elliott’s focus is in privileged access management, remote access security, and SaaS strategies. He has helped build successful, cloud-first, startups and held product leadership roles across core technology industries, including Cyber Security, IT Asset Management, and IT Service Management. Elliott earned his Bachelor of Science from Florida State University.