This chapter covers Just-In-Time (JIT) VM Access, a critical security feature in Microsoft Defender for Cloud that reduces exposure to brute-force attacks by locking down inbound traffic to Azure VMs. For the AZ-500 exam, this topic appears in the Identity and Access domain under objective 1.2, typically representing 5-10% of questions. You will need to understand the mechanism, configuration, and integration with Azure Policy and Role-Based Access Control (RBAC). This chapter provides the depth required to answer scenario-based questions and avoid common traps.
Jump to a section
Imagine a secure warehouse that stores sensitive documents. The warehouse has a heavy steel door that is normally locked and can only be opened by a security guard who verifies credentials. However, the guard is not always at the door; instead, the door is controlled by a timer and a request system. Employees who need to enter the warehouse must first submit a request through a secure intercom, stating their name, reason, and expected duration. The guard, who is monitoring the intercom, checks the request against an approved list and, if valid, unlocks the door for a specific period—say, 30 minutes. During that time, the employee can enter and exit freely. Once the timer expires, the door relocks automatically. If the employee needs more time, they must submit another request. This system prevents unauthorized access because the door is only open when explicitly approved, and each access is audited. The guard never unlocks the door for longer than necessary, and the employee cannot open the door without going through the request process. This mirrors JIT VM Access: the VM's RDP/SSH port (the door) is normally closed, and access is granted only after an approved request, for a limited time, with auditing.
What is Just-In-Time (JIT) VM Access?
Just-In-Time (JIT) VM Access is a feature of Microsoft Defender for Cloud that provides on-demand, time-limited access to Azure virtual machines. Its primary purpose is to reduce the attack surface by blocking inbound traffic to management ports (RDP port 3389, SSH port 22) except when explicitly requested and approved. Instead of leaving these ports open continuously — which invites brute-force attacks — JIT opens them only for a specific user, source IP, and duration.
Why JIT Exists
Traditional network security groups (NSGs) or Azure Firewall rules allow you to restrict access to management ports, but often administrators open them broadly (e.g., 0.0.0.0/0) for convenience. This creates a persistent vulnerability. JIT solves this by enforcing a "zero standing access" model: no permanent rules allow RDP/SSH from the internet. Access is granted dynamically based on user requests that are logged and audited.
How JIT Works Internally
JIT operates through a combination of Azure Policy, NSG rules, and Defender for Cloud. Here is the step-by-step mechanism:
Enablement: You enable JIT on a per-VM basis or via Azure Policy across a subscription. When enabled, Defender for Cloud creates deny rules in the VM's associated NSG (or Azure Firewall) to block inbound traffic on RDP (3389) and SSH (22) from all sources, except for the Azure Load Balancer health probe and Azure Bastion (if configured).
Request: An authorized user (with at least Reader role on the VM and a role that allows JIT access, such as Security Admin or Contributor) requests access via the Azure portal, CLI, PowerShell, or API. The request specifies:
- The VM(s) - The port (3389 or 22) - The source IP address (or * for any) - The duration (1-3 hours by default, configurable)
Approval: Defender for Cloud checks the user's RBAC permissions and any conditional access policies. If approved, it temporarily adds an allow rule to the NSG (or Azure Firewall policy) that permits inbound traffic from the specified source IP to the requested port. This rule has a lower priority than the deny rule but is evaluated first because it is more specific (source IP is not *).
Timeout: After the requested duration expires, Defender for Cloud automatically removes the allow rule, restoring the deny state. The user can request an extension if needed.
Audit: All requests and approvals are logged in the Azure Activity Log and can be exported to Azure Monitor or SIEM.
Key Components, Values, Defaults, and Timers
Default ports: RDP (3389) and SSH (22). You can add custom ports (e.g., 5985 for WinRM, 1433 for SQL) when enabling JIT.
Maximum duration: 3 hours per request. You can configure this via policy or in the JIT settings (range: 1-3 hours).
Source IP: Can be a single IP, CIDR range, or '*' (any). For security, specify a specific IP or range.
NSG rule priority: Deny rules have priority 1000 (or higher if you customize), and allow rules are created with priority 100-200 (lower number = higher priority). The allow rule is more specific (source IP = requester's IP) so it overrides the broader deny rule.
Azure Firewall: If the VM is behind Azure Firewall, JIT creates NAT rules instead of NSG rules.
RBAC roles required: To request JIT access, the user needs the 'Reader' role on the VM and a role that includes 'Microsoft.Security/justInTimePolicies/read' and 'Microsoft.Security/justInTimePolicies/initiate/action'. Built-in roles like 'Security Admin' or 'Contributor' include these permissions. To enable JIT, you need 'Security Admin' or 'Owner'.
Configuration and Verification Commands
Enable JIT via PowerShell:
$JitPolicy = (@{
id = "/subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm-name>"
ports = (@{
number = 22
protocol = "tcp"
allowedSourceAddressPrefix = "*"
maxRequestAccessDuration = "PT3H"
})
})
Set-AzJitNetworkAccessPolicy -ResourceGroupName <rg> -Location <location> -Name "default" -VirtualMachine $JitPolicyRequest access via CLI:
az vm jit-access request --resource-group <rg> --name <vm-name> --port 22 --source-ip <your-ip> --duration 1hVerify JIT status via CLI:
az vm jit-access list --resource-group <rg>Check NSG rules:
Get-AzNetworkSecurityGroup -Name <nsg-name> -ResourceGroupName <rg> | Get-AzNetworkSecurityRuleConfig | Where-Object {$_.Name -like "*JIT*"}Interaction with Related Technologies
JIT integrates with: - Azure Policy: You can enforce JIT on all VMs in a subscription using built-in initiative 'Enable JIT network access control on virtual machines'. - Azure Bastion: JIT and Bastion are complementary. Bastion provides secure RDP/SSH via the Azure portal over TLS, while JIT controls NSG-level access. They can be used together: Bastion traffic is allowed by default, but JIT can still protect management ports from direct internet exposure. - Azure Firewall: When VMs are behind Azure Firewall, JIT uses Firewall NAT rules instead of NSG rules. - Log Analytics: JIT logs can be sent to Log Analytics for monitoring and alerting. - Conditional Access: You can require multi-factor authentication (MFA) for JIT requests via Azure AD Conditional Access policies applied to the Azure Management app.
Important Exam Details
JIT is available only with Microsoft Defender for Cloud (requires Azure Defender for Servers plan). Without it, JIT is not available.
JIT does not support VMs with public IPs that are not associated with an NSG. The VM must have an NSG (or be behind Azure Firewall) for JIT to work.
JIT does not work with Azure Virtual Machine Scale Sets (VMSS) directly; you must enable it on each instance.
The maximum request duration is 3 hours, but you can configure it via policy to a lower maximum.
JIT access requests can be approved automatically (default) or require approval from another user (via Privileged Identity Management integration).
Enable JIT on a VM
Navigate to Microsoft Defender for Cloud in the Azure portal, select 'Just-in-time VM access' under 'Cloud Security', and enable JIT on desired VMs. Alternatively, use Azure Policy to enforce JIT across subscriptions. When enabled, Defender for Cloud creates deny rules in the VM's NSG to block RDP/SSH from all sources. These rules have a default priority of 1000 and are named 'JIT-Deny-Rule-<port>'. The VM must have an NSG attached; otherwise, JIT cannot enforce access.
User requests access
An authorized user initiates a JIT request via Azure portal, CLI, PowerShell, or REST API. The request includes: VM name, port (e.g., 22), source IP address (or '*' for any), and duration (1-3 hours). The user must have the 'Reader' role on the VM and permissions to initiate JIT (e.g., 'Security Admin' or 'Contributor'). The request is sent to Defender for Cloud.
Defender for Cloud validates request
Defender for Cloud checks the user's RBAC permissions and any conditional access policies. If the user is authorized, it proceeds to create a temporary allow rule. If the user lacks permissions, the request is denied and logged. The check occurs within seconds.
Temporary allow rule created
Defender for Cloud adds an allow rule to the VM's NSG (or Azure Firewall NAT rule) that permits inbound traffic from the specified source IP to the requested port. The rule is named 'JIT-Allow-Rule-<port>-<timestamp>' with a priority between 100-200, lower than the deny rule's 1000, ensuring it takes effect. The rule is more specific (source IP is the requester's IP) than the deny rule (source IP is '*'), so it overrides the deny.
User connects and timer runs
With the allow rule in place, the user can now connect to the VM via RDP or SSH. The timer starts from the moment the rule is created. The user can disconnect and reconnect within the allowed duration. The timer is not paused; it is a fixed duration from request approval. Once the duration expires, Defender for Cloud automatically removes the allow rule, restoring the deny state. The user cannot extend access without submitting a new request.
Enterprise Scenario 1: Securing Administrative Access for a Global IT Team
A multinational corporation has hundreds of Azure VMs across multiple regions. Their IT administrators need to occasionally RDP into VMs for patching and troubleshooting. Previously, they left RDP open to the internet, leading to constant brute-force attacks. They deployed JIT via Azure Policy, enforcing it on all VMs. Administrators now request access through a custom portal that integrates with Azure AD Conditional Access, requiring MFA. The JIT duration is set to 2 hours by default. This reduced the attack surface dramatically; the NSG deny rules block all inbound RDP except when explicitly requested. Performance is negligible because NSG rules are evaluated at the Azure backbone level. Misconfiguration: if the NSG is detached from the VM, JIT cannot enforce access, leaving the VM exposed. They now use Azure Policy to prevent detachment.
Enterprise Scenario 2: Compliance with PCI DSS
A financial services company must comply with PCI DSS requirement 7.2.1, which mandates least-privilege access. They use JIT to ensure that administrative access to payment processing VMs is time-boxed and audited. They configure JIT with a maximum duration of 1 hour and require approval from a security manager via Privileged Identity Management (PIM). All JIT requests are logged to Azure Monitor and sent to their SIEM for real-time alerting. They also use Azure Firewall for additional network segmentation; JIT creates NAT rules on the firewall. One challenge: if the firewall policy has a rule that denies all traffic by default, the JIT NAT rule must be correctly prioritized. They set the firewall rule priority to 100 for the JIT allow rule, ensuring it overrides the default deny. Without this, access would fail even with a valid JIT request.
Scenario 3: Third-Party Vendor Access
A SaaS company allows third-party vendors to access specific VMs for support. They use JIT to grant time-limited access only from the vendor's public IP. The JIT request is automated via a webhook that triggers a PowerShell script. The vendor's IP changes occasionally, so they use a dynamic DNS name that resolves to the vendor's current IP. The JIT request specifies the resolved IP. This ensures that even if the vendor's IP changes, they can still request access. However, if the DNS resolution is stale, the request may fail. They mitigate by using a short TTL on the DNS record. This scenario demonstrates JIT's flexibility in non-standard environments.
What AZ-500 Tests on JIT VM Access
The AZ-500 exam covers JIT under objective 1.2: 'Configure access management for Azure resources.' Expect 3-5 questions on JIT, often scenario-based. You must know:
Prerequisites: VM must have an NSG, and you need Microsoft Defender for Cloud with Azure Defender for Servers.
Default ports: 3389 and 22; custom ports allowed.
Maximum duration: 3 hours (configurable via policy).
RBAC: To request access, user needs Reader on VM and Microsoft.Security/justInTimePolicies/initiate/action.
Integration with Azure Policy: Built-in initiative 'Enable JIT network access control on virtual machines'.
Auditing: Logged in Activity Log, can be sent to Log Analytics.
Common Wrong Answers and Why Candidates Choose Them
"JIT requires Azure Bastion." Wrong. JIT and Bastion are independent. Bastion provides browser-based RDP/SSH, while JIT controls NSG rules. They can work together but are not dependent.
"JIT works without an NSG." Wrong. JIT creates NSG rules; if no NSG is attached, JIT cannot enforce access. The VM would be directly exposed.
"JIT can grant access for up to 8 hours." Wrong. The maximum is 3 hours. Candidates may confuse this with other Azure timeouts.
"JIT requires Contributor role on the VM." Wrong. Reader is sufficient for requesting access; Contributor or Owner is needed to enable JIT.
Specific Numbers and Terms on the Exam
Default ports: 3389, 22.
Max duration: 3 hours (PT3H in ISO 8601).
NSG rule priority: deny at 1000, allow at 100-200.
RBAC action: Microsoft.Security/justInTimePolicies/initiate/action.
Policy name: 'Enable JIT network access control on virtual machines'.
Edge Cases the Exam Loves
VM without NSG: JIT cannot be enabled. The exam may present a scenario where a VM has no NSG and ask what is needed.
VM behind Azure Firewall: JIT uses Firewall NAT rules. The exam may ask about the difference in rule type.
User requests access but lacks Reader role: The request is denied. The exam may ask why access fails.
JIT and Azure Policy: If policy requires JIT, but a VM is created without an NSG, the policy will be non-compliant. The exam may ask how to resolve.
How to Eliminate Wrong Answers
Understand the mechanism: JIT modifies NSG rules dynamically. If an answer mentions any permanent change or does not involve NSG rules, it is likely wrong. Also, remember that JIT is a Defender for Cloud feature; without the appropriate plan, it is unavailable. Always check for prerequisites in the scenario.
JIT VM Access reduces attack surface by blocking management ports (RDP 3389, SSH 22) until a time-limited request is approved.
JIT requires Microsoft Defender for Cloud with Azure Defender for Servers enabled.
The VM must have an associated NSG or be behind Azure Firewall for JIT to work.
Default maximum request duration is 3 hours; configurable via policy.
To request JIT access, a user needs Reader on the VM and Microsoft.Security/justInTimePolicies/initiate/action permission.
JIT creates temporary NSG allow rules with priority 100-200, overriding permanent deny rules at priority 1000.
JIT can be enforced via Azure Policy using the built-in initiative 'Enable JIT network access control on virtual machines'.
All JIT requests are logged in Azure Activity Log for auditing.
These come up on the exam all the time. Here's how to tell them apart.
Just-In-Time (JIT) VM Access
Controls NSG rules to allow/deny inbound traffic to management ports.
Requires an NSG or Azure Firewall to enforce rules.
Supports any RDP/SSH client (e.g., mstsc, Putty).
Access is time-limited (max 3 hours per request).
Available only with Microsoft Defender for Cloud (Azure Defender for Servers).
Azure Bastion
Provides browser-based RDP/SSH access via the Azure portal over TLS.
Does not require an NSG; uses a dedicated subnet and Bastion host.
No client software needed; works in a web browser.
Access is not time-limited by default; session can be active until user disconnects.
Available with or without Defender for Cloud (standalone service).
Mistake
JIT VM Access works on any Azure VM regardless of network configuration.
Correct
JIT requires the VM to have an associated Network Security Group (NSG) or be behind Azure Firewall. Without an NSG, JIT cannot create allow/deny rules, and the VM remains exposed.
Mistake
JIT can grant permanent access to a VM.
Correct
JIT is designed for temporary, time-bound access. The maximum duration per request is 3 hours, and access is automatically revoked after the time expires. There is no option for permanent access via JIT.
Mistake
JIT replaces the need for Azure Bastion.
Correct
JIT and Azure Bastion serve different purposes. Bastion provides secure RDP/SSH access through the Azure portal without public IPs, while JIT controls NSG-level access. They can be used together for defense in depth.
Mistake
Any user with Reader role on a VM can enable JIT.
Correct
Enabling JIT requires higher privileges: Security Admin or Owner. Reader role only allows requesting access if JIT is already enabled and the user has the initiate action permission.
Mistake
JIT access requests are always automatically approved.
Correct
By default, requests are automatically approved, but you can configure JIT to require approval from another user (e.g., via Privileged Identity Management). The exam may test that approval can be required.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The VM must have a Network Security Group (NSG) attached to its network interface or subnet, and you must have Microsoft Defender for Cloud with the Azure Defender for Servers plan enabled. Additionally, the user enabling JIT needs Security Admin or Owner role. Without these, JIT cannot be configured.
JIT does not natively support VMSS as a resource. You must enable JIT on each individual VM instance within the scale set. Alternatively, you can use Azure Policy to enforce JIT on all VMs, but the scale set itself is not a valid target for JIT configuration.
Each JIT request creates a separate NSG allow rule for the specific source IP and port. Multiple rules can coexist, allowing multiple users to access the VM simultaneously, each with their own duration. When a user's timer expires, only their rule is removed.
No, the maximum duration per request is 3 hours. However, the user can submit a new request after the current one expires. If you need longer access, consider using Azure Bastion or configuring a longer maximum duration via custom policy (but the hard limit is 3 hours).
Yes. When a VM is behind Azure Firewall, JIT creates NAT rules on the firewall instead of NSG rules. The firewall must have the appropriate policy and rules to allow the JIT traffic. The mechanism is similar: a temporary NAT rule is created for the requested port and source IP.
Yes. All JIT access requests and approvals are logged in the Azure Activity Log under the 'Microsoft.Security/justInTimePolicies' category. You can stream these logs to Azure Monitor, Log Analytics, or a SIEM for auditing and alerting.
If the NSG is deleted, the VM loses its network security filtering. JIT will not be able to enforce deny rules, and the VM becomes exposed. Defender for Cloud will show a warning that JIT is not properly configured. You must reattach or recreate an NSG to restore JIT functionality.
You've just covered Just-In-Time (JIT) VM Access — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?