Just-in-time (JIT) access in Azure means nobody holds permanent power to reach a server or change a resource. They ask for it, get it for a short window, and lose it automatically. Azure does this in two separate places: Microsoft Defender for Cloud closes the management ports on virtual machines and opens them briefly on request, and Microsoft Entra Privileged Identity Management (PIM) makes admin roles something a person activates instead of something they own. Most small and midsize teams need both, and they are easy to confuse.
This guide explains what each one does, what it requires in licensing and permissions, where it quietly fails, and how to decide where to start.
TL;DR
- Two features, two jobs. Defender for Cloud JIT controls network access to VM management ports. Entra PIM controls who can hold privileged roles and for how long.
- JIT for VMs needs Defender for Servers Plan 2. By default it opens a port for a maximum of 3 hours, then revokes access.
- JIT is a compensating control. For new builds, Microsoft's guidance is to prefer Azure Bastion, which removes the public IP from the VM.
- Check the limits before you promise coverage. Name-length limits, firewall type and per-identity permissions all trip people up.
- Start with roles. Moving admin accounts to eligible-only roles is usually the cheapest, fastest risk reduction.
Table of Contents
- What "just in time" actually removes
- The two kinds of Azure JIT
- JIT VM access in Defender for Cloud
- Entra PIM: JIT for roles and groups
- Bastion first, JIT second
- Which one should you do first?
- Our perspective
- Where we can help
- FAQ
- Sources
What "just in time" actually removes
The idea behind JIT is to replace standing privilege with zero standing privilege. A permanent admin role, or an RDP port open to the internet around the clock, is a permanent target. If one credential leaks, the attacker inherits everything that credential could ever do.
Microsoft's cloud security benchmark makes the same case: just-in-time privileged access prevents persistent administrative permissions that enable unauthorized access after a credential is compromised. JIT turns access from a static condition into a request that is logged, time-limited and, where you want it, approved.
For a company with a handful of admins and a few dozen servers, this is not a theoretical benefit. Small teams tend to have the broadest standing access, because the same two people do everything and nobody wants to be locked out at 2 a.m.
The two kinds of Azure JIT
| Defender for Cloud JIT VM access | Entra PIM | |
|---|---|---|
| Protects | Management ports on VMs | Roles and group membership |
| Mechanism | Temporary allow rules in NSGs or Azure Firewall | Eligible assignments activated on demand |
| Typical window | 3 hours by default, configurable | Commonly 1 to 8 hours |
| Licensing | Defender for Servers Plan 2 | Entra ID P2 or Entra ID Governance |
| Best for | Legacy VMs that still have public IPs | Every privileged admin account |
People searching for JIT usually mean one of these, and the documentation for each lives in a different part of the portal. Decide which problem you have before you start clicking.
JIT VM access in Defender for Cloud
How it works
JIT VM access is part of Defender for Servers Plan 2. According to Microsoft's overview of just-in-time VM access, it protects RDP (3389), SSH (22) and WinRM (5985 and 5986) by keeping those ports closed. When someone requests access and the request is approved, Defender for Cloud writes a temporary allow rule into the Network Security Group or Azure Firewall. When the window ends, the rule is removed and the deny-all state returns.
The default maximum request window is 3 hours, and you can change it per port. A request also names a source: a specific IP address or range. That detail matters, because it is the first thing to lock down.
Permissions: who can configure and who can request
JIT is governed by Azure RBAC, and the split is deliberate. Per Microsoft's guidance on enabling JIT access:
- Configuring or editing a policy needs
Microsoft.Security/locations/jitNetworkAccessPolicies/writeandMicrosoft.Compute/virtualMachines/write. - Requesting access needs
Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action, plus read access to the VM and the related network resources.
Microsoft also provides a Set-JitLeastPrivilegedRole script that helps you assign only those minimal permissions instead of handing out Contributor. Use it. A common pattern is to let the whole IT group request access but allow only one or two people to edit policies.
Pitfalls that cost people an afternoon
The 56-character limit. The JIT policy name combined with the VM name is capped at 56 characters, according to the enablement documentation. If your naming convention is verbose, for example one that encodes region, environment, application and tier, policy creation can fail with unhelpful errors. Check a sample name before you roll out a convention.
Azure Firewall Policy is not supported. JIT does not support VMs protected by Azure Firewall managed through Azure Firewall Policy, only classic Azure Firewall rules. Many modern hub-and-spoke designs use Firewall Policy, which means the most important workloads may be the ones JIT cannot cover. Find this out in design, not during an audit.
Automation is tied to the caller. JIT access is granted to the identity that makes the request. A Microsoft Q&A answer confirms that you cannot request JIT access on behalf of everyone using one shared service account. If a pipeline or runbook needs to open a port, give that service principal its own explicit, documented permissions.
Open source ranges defeat the point. If users can request access from "Any" as the source, the control looks present but protects little. Tighten the allowed source ranges in the policy and enforce it with Azure Policy where you can. Test the enforcement, since reports from admins show that policy-based blocks on the "Any" source do not always behave as expected.
Entra PIM: JIT for roles and groups
For most organizations the larger risk is not an open port. It is a Global Administrator or Subscription Owner account that is always on. PIM fixes that.
In PIM, a person is assigned a role as eligible rather than active. When they need it, they activate it. Microsoft's documentation on assigning eligibility in PIM for groups describes this for group membership and ownership, and the same model covers Azure resource roles. Activation commonly requires MFA and a business justification, and can require approval from a designated approver. Typical activation windows run from 1 to 8 hours.
Licensing is the practical gate. PIM for groups needs Microsoft Entra ID P2 or Microsoft Entra ID Governance, per the same page. Confirm what your tenant holds, then review Microsoft's Entra licensing overview before you plan a rollout. We are deliberately not quoting per-user prices here, since they change and depend on your agreement.
PIM sits on top of strong sign-in. If MFA is not yet universal in your Microsoft 365 tenant, fix that first, since an activation step that asks for MFA is only as strong as your enrollment. A plain walkthrough of starting MFA with Security Defaults is a reasonable place to begin, and it also touches on activating eligible Azure roles for a limited time with MFA, justification and approval.
A sensible PIM starting configuration
- Inventory standing admins. List everyone holding Global Administrator, Owner, User Access Administrator and Contributor at subscription scope.
- Keep two break-glass accounts. Exclude them from the activation flow, protect them separately and alert on any use. Locking yourself out of your own tenant is the failure mode to design against.
- Convert the rest to eligible. Start with the highest-impact roles.
- Set activation windows by role. A few hours is plenty for most tasks. Require a justification for all of them and approval only for the few that can change identity or billing.
- Review monthly at first. Remove eligibility that nobody has used.
Bastion first, JIT second
JIT VM access is useful, but it is not the first answer for new work. Microsoft's design guide on developer and admin access to Azure VMs describes Azure Bastion as providing browser-based SSH and RDP through the Azure portal with no public IP required on the VM. If the VM has no public IP, there is no internet-facing management port to close in the first place.
So the order of preference for a new deployment is:
- No public IPs on VMs, with Bastion for admin access.
- PIM for the people who can reach Bastion and change the environment.
- JIT VM access for older machines that must keep a public address or cannot move yet.
That last category is where many small businesses live: a line-of-business application on a VM built years ago by a vendor, still reachable by RDP from the internet. JIT is a good, fast mitigation there, as long as you treat it as a bridge and not a destination.
Which one should you do first?
| Your situation | Start with |
|---|---|
| Admins hold permanent Owner or Global Admin | PIM, with eligible assignments |
| Legacy VMs with RDP or SSH open to the internet | JIT VM access now, plan to remove public IPs |
| New workloads being built | Bastion, private networking, PIM |
| Hub-and-spoke design using Firewall Policy | Bastion and PIM, since JIT will not cover it |
| No Plan 2 or P2 licensing yet | Cost the licenses against the exposure before deciding |
If the license cost is the blocker, weigh it against what you protect. A handful of internet-facing servers holding customer data is a stronger case than an isolated test machine.
Our perspective
We see the same pattern in small and midsize environments: the cloud was set up quickly by someone capable, access was granted generously to keep work moving, and nobody went back. The goal is not a perfect zero-trust diagram. It is removing the most dangerous standing access without making daily work miserable.
Our approach is to start with an inventory and a plain-language, prioritized plan the client owns. For JIT, that usually means three things. Fix admin roles first, because it is a configuration change, not a project. Map which VMs actually need a public address and which can move behind Bastion. Then use JIT only where the architecture requires it, with narrow source ranges and a documented owner.
We also push back on treating JIT as set and forget. Policies drift, VMs get renamed or rebuilt, and firewall designs change. A quarterly check that requests are being used, windows are short and exceptions are expired is worth more than a clever initial setup. Where an approval step is added, it has to be staffed. An approval nobody answers just trains people to ask for permanent access again.
— jaras
Where we can help
If you want a second set of eyes on how your Azure environment grants access today, our Cloud & Training work covers cloud architecture and cost optimization, and our security assessment and hardening work covers privileged access. Engagements start with a free technology assessment that ends in a prioritized plan in plain language, which you own whether or not we deliver it. If you have no in-house technology leader to own decisions like these, our fractional CTO engagements cover that gap.
FAQ
Does Azure JIT access cost extra?
JIT VM access is part of Microsoft Defender for Servers Plan 2, so it is billed through that plan, per Microsoft's documentation. PIM generally requires Entra ID P2 or Entra ID Governance licensing. Check current prices on Microsoft's pricing pages and with your reseller, as they vary by agreement.
How long does JIT access last?
For VM access, the default maximum is 3 hours, and administrators can change it. PIM role activations commonly run 1 to 8 hours, depending on how each role is configured. In both cases, access ends automatically when the window closes.
Can I use JIT access with Azure Bastion?
They solve overlapping problems, so you rarely need both on the same VM. Bastion removes the need for a public IP, which is the stronger design. JIT is better treated as a compensating control for machines that still need public exposure.
Why can't I enable JIT on one of my VMs?
The usual causes are a policy and VM name combination over 56 characters, a missing permission on the VM or network resources, or a firewall managed through Azure Firewall Policy, which JIT does not support. Check those three before opening a support case.
Sources
- Understand just-in-time VM access, Microsoft Learn
- Enable just-in-time access, Microsoft Learn
- Enable just-in-time access (policy name limit), Microsoft Learn
- Request JIT with a service account, Microsoft Q&A
- Assign eligibility for a group in PIM, Microsoft Learn
- Microsoft Entra licensing, Microsoft Learn
- Developer and admin access to Azure VMs, Microsoft Learn
- Microsoft cloud security benchmark v2, Privileged Access