This chapter covers Just-In-Time (JIT) VM Access, a critical Microsoft Defender for Cloud feature that reduces exposure to brute-force attacks by locking down inbound traffic to VMs until explicitly requested. For the SC-200 exam, JIT appears in Domain 3 (Cloud Security), Objective 3.1 (Configure cloud security posture management). Approximately 5-10% of exam questions touch JIT, often in scenario-based items where you must decide whether JIT, NSGs, or Azure Firewall is appropriate. Mastering JIT's mechanism, configuration, and integration with Defender for Cloud is essential for the exam and real-world cloud security operations.
Jump to a section
Just-In-Time VM Access is like an exclusive nightclub that uses a bouncer with a dynamic guest list. Normally, the club has a VIP entrance that is always locked; no one can get in at any time. When a approved guest wants to enter, they first request access through a dedicated app. The bouncer checks their identity against a pre-approved list, then unlocks the door for a specific, short time window—say 30 minutes. During that window, the guest can enter. Once the time expires, the door locks automatically. The bouncer also logs every entry attempt, including who requested access, when, and for how long. If someone tries to enter without an active request, the bouncer denies them. Importantly, the bouncer never leaves the door unlocked; it only opens for the exact duration needed. This prevents any unwanted party crashers from slipping in during off-hours. In the cloud, JIT VM Access works similarly: the Network Security Group (NSG) rules are like the locked door. When a user requests access, Azure creates a temporary NSG rule that allows traffic from the user's IP to the VM on a specific port (e.g., RDP port 3389) for a set duration. After the time expires, Azure automatically removes the rule, restoring the locked state. The bouncer (Azure) also logs all requests and actions in Azure Activity Log.
What is Just-In-Time VM Access and Why Does It Exist?
Just-In-Time (JIT) VM Access is a feature of Microsoft Defender for Cloud that provides time-bound, approved access to Azure Virtual Machines. Its primary purpose is to reduce the attack surface by eliminating always-open management ports (RDP port 3389, SSH port 22). Instead, these ports are locked by default via Network Security Group (NSG) rules. When an authorized user needs access, they request it through Defender for Cloud, which temporarily creates a rule allowing traffic from their source IP to the VM on the specified port for a configurable duration. After the duration expires, the rule is automatically removed, restoring the locked state.
Why does this matter? Brute-force attacks on management ports are among the most common cloud security threats. By keeping these ports closed except when actively used, JIT drastically reduces the window of opportunity for attackers. The feature is part of the Microsoft cloud security posture management (CSPM) capabilities in Defender for Cloud.
How JIT Works Internally – Step Through the Mechanism
JIT operates through a combination of Azure Resource Manager (ARM), NSGs, and Defender for Cloud. Here is the detailed flow:
VM Onboarding: When you enable JIT on a VM, Defender for Cloud identifies the VM's existing NSG rules for RDP/SSH and removes any rules that allow unrestricted inbound access (e.g., Source: Any, Port: 3389). It then creates a default deny rule for those ports. The VM becomes unreachable on those ports from the internet.
User Request: A user (with appropriate RBAC permissions, e.g., Security Reader or Security Admin) requests access via the Azure portal, Azure CLI, PowerShell, or REST API. The request includes:
- VM ID - Source IP (or range) - Port(s) to open - Requested duration (up to a maximum allowed by policy)
Policy Check: Defender for Cloud checks the request against JIT policies defined for that VM or subscription. Policies can enforce:
- Allowed source IP ranges (e.g., only corporate VPN CIDR) - Maximum request duration (e.g., 3 hours) - Allowed ports (e.g., only 3389, not 22) - Approval workflow (if enabled, requires a second approver)
NSG Rule Creation: If the request is approved, Defender for Cloud uses ARM to add a new NSG rule to the VM's NSG. The rule has:
- Priority: higher than the default deny (e.g., 100) - Source: the user's IP address (or provided range) - Destination: the VM's private IP or subnet - Destination Port: the requested port - Protocol: TCP - Action: Allow - Expiration: set via a custom tag or time-based logic (the rule is not deleted by a timer; instead, Defender for Cloud monitors the request and removes the rule after the duration).
Access Granted: The user can now connect to the VM on the allowed port from their IP. The rule is visible in the NSG but is marked with a description like "JIT Rule for user@domain.com until 2025-01-01T12:00:00Z".
Automatic Cleanup: After the duration expires, Defender for Cloud deletes the temporary NSG rule. If the user closes the session early, they can manually revoke access via the portal or CLI, which triggers immediate rule removal.
Auditing: All requests and actions are logged in Azure Activity Log and Defender for Cloud alerts. You can also export logs to Log Analytics for advanced queries.
Key Components, Values, Defaults, and Timers
Default Ports: RDP (3389) and SSH (22). You can configure additional ports.
Default Maximum Request Duration: 3 hours. This is configurable at the VM or subscription level via policy.
Default Deny Rule: JIT creates a deny rule with priority 1000 (or lower if existing rules conflict) for the protected ports. The temporary allow rule has a higher priority (e.g., 100) to override the deny.
Source IP: The user's public IP as seen by Azure. You can override with a custom IP range.
Approval Workflow: Optional. When enabled, requests require approval from a designated approver (Azure AD user or group) before the rule is created.
RBAC Permissions: To request access, a user needs at least Security Reader role on the VM or subscription. To configure JIT, they need Security Admin or Contributor.
Supported VMs: VMs with a public IP and an NSG attached to the VM NIC or subnet. VMs behind Azure Firewall or third-party firewalls are not supported.
Limitations: JIT does not work with VMs using Azure Bastion (which already provides JIT-like access) or VMs with no public IP.
Configuration and Verification Commands
Enable JIT via Azure CLI:
az vm jit enable \
--resource-group MyResourceGroup \
--vm MyVM \
--ports 3389 22Request access via Azure CLI:
az vm jit request \
--resource-group MyResourceGroup \
--vm MyVM \
--ports 3389 \
--duration 60Verify active requests:
az vm jit list --resource-group MyResourceGroupRevoke access:
az vm jit revoke \
--resource-group MyResourceGroup \
--vm MyVMView logs:
az monitor activity-log list --query "[?resourceId=='/subscriptions/.../MyVM']"How JIT Interacts with Related Technologies
Network Security Groups (NSGs): JIT directly modifies NSG rules. It does not work with Application Security Groups (ASGs) for source restriction—it only uses IP addresses.
Azure Firewall: JIT does not create rules in Azure Firewall. For VMs behind Azure Firewall, you must use Azure Firewall's own JIT-like feature or manually manage rules.
Azure Bastion: Bastion provides secure RDP/SSH access without public IPs. JIT is redundant if Bastion is used. The exam may test scenarios where both are available; choose Bastion for fully private access and JIT for existing VMs with public IPs.
Microsoft Defender for Cloud: JIT is a Defender for Cloud feature, available in the Defender for Servers plan (P2 tier). Without the plan, you can still use JIT but with limited functionality (e.g., no approval workflow).
Azure Policy: You can enforce JIT deployment via Azure Policy (built-in policy: "Management ports should be closed on virtual machines").
Onboard VM to JIT
Enable JIT on a VM from Defender for Cloud. This removes existing allow rules for management ports and creates a default deny rule. The VM becomes inaccessible on those ports from any source. The onboarding process identifies the VM's current NSG rules and replaces them. You can onboard via portal, CLI, or REST API. The default deny rule has priority 1000. If the VM has existing rules with higher priority (lower number) that allow management ports, JIT will not override them; you must manually remove those rules.
User Requests Access
An authorized user initiates a request via the portal, CLI, or API. They specify the VM, port, source IP (defaults to their public IP), and duration. The request is sent to Defender for Cloud. The user must have Security Reader or equivalent role. The request includes a timestamp and is logged in Activity Log. The maximum duration is enforced by policy (default 3 hours).
Policy Evaluation and Approval
Defender for Cloud checks the request against JIT policies. If approval workflow is enabled, the request enters a pending state until an approver (with Security Admin role) approves or denies it. If no workflow, the request is auto-approved. Policies can restrict source IPs, ports, and duration. If the request violates policy (e.g., source IP not allowed), it is denied immediately. The evaluation happens in seconds.
Temporary NSG Rule Creation
Upon approval, Defender for Cloud creates a new NSG rule via ARM. The rule has a high priority (e.g., 100) to override the default deny. Source is the user's IP, destination is the VM's private IP or subnet, destination port is the requested port, protocol TCP, action Allow. The rule is tagged with expiration metadata. The rule appears in the NSG within a few seconds. The user can now connect.
User Connects to VM
The user initiates RDP or SSH from their IP to the VM's public IP on the allowed port. Because the temporary rule allows traffic from that IP, the connection succeeds. The user performs their administrative tasks. The connection is not monitored by JIT itself; it is a standard RDP/SSH session. The user can close the session at any time.
Automatic Rule Removal
After the requested duration expires, Defender for Cloud deletes the temporary NSG rule. The default deny rule takes effect again, blocking all traffic on that port. The user can also manually revoke access, which immediately removes the rule. The deletion is logged in Activity Log. If the user's session is still active, it will be terminated when the rule is removed (the connection will drop).
Scenario 1: Enterprise IT Administration
A large enterprise manages hundreds of Windows VMs in Azure for application development. Previously, all VMs had RDP open to the internet with complex NSG rules that were often misconfigured. After a brute-force attack compromised one VM, the security team deployed JIT. They configured a subscription-level JIT policy allowing RDP only from the corporate VPN CIDR (10.0.0.0/8) with a maximum duration of 2 hours. All developers were granted Security Reader role. When a developer needs to RDP, they request access via the Azure portal, which auto-approves. The temporary rule allows their specific IP (which is within the VPN range). After 2 hours, the rule is removed. This reduced the attack surface by 99% and eliminated persistent open ports. The team also enabled logging to a Log Analytics workspace for auditing. A common issue was that developers would leave their sessions open beyond the duration, causing unexpected disconnections. The team mitigated this by training developers to revoke access manually after use.
Scenario 2: Compliance-Driven Financial Services
A financial institution must comply with PCI DSS, which requires strict access controls to management interfaces. They use JIT with approval workflow. When a system administrator needs SSH access to a Linux VM, they submit a request through the portal. The request is routed to a team lead (Security Admin) who reviews and approves. The approval is logged for compliance evidence. The policy enforces a maximum duration of 1 hour and only allows SSH port 22. The institution also uses Azure Policy to audit VMs without JIT enabled. They discovered that some VMs had JIT disabled because their NSGs were attached to subnets rather than NICs, and JIT could not modify subnet-level rules. They resolved this by attaching dedicated NIC-level NSGs to critical VMs. Performance was not an issue; the overhead of rule creation is minimal.
Scenario 3: MSP Managing Multiple Tenants
A managed service provider (MSP) uses Azure Lighthouse to manage VMs across multiple customer tenants. They deploy JIT across all tenants to provide secure access to their engineers. Each tenant has its own JIT policy. The MSP uses Azure CLI scripts to request access programmatically. A common misconfiguration was that engineers would request access from their home IPs, which were not in the allowed range, causing denial. The solution was to enforce that all engineers connect through a central VPN, ensuring their source IP is within the corporate range. Another issue: when a VM has no public IP, JIT is not applicable, so the MSP uses Azure Bastion instead. The MSP also learned that JIT does not work with Azure Firewall, so for VMs behind Firewall, they use Firewall's DNAT rules with a custom JIT-like process.
The SC-200 exam tests JIT VM Access primarily in scenario-based questions where you must identify the correct security control. Key objective codes: Domain 3 (Cloud Security), Objective 3.1 (Configure cloud security posture management). The exam expects you to understand when to use JIT versus other controls like NSGs, Azure Bastion, or Azure Firewall.
Common Wrong Answers and Why Candidates Choose Them
Azure Bastion as a replacement for JIT: Candidates often think Bastion eliminates the need for JIT. However, Bastion provides secure access without public IPs, while JIT works with VMs that already have public IPs. The exam may present a VM with a public IP already exposed; Bastion would require removing the public IP, which might not be feasible. JIT is the correct answer when the VM must retain a public IP.
NSG rules alone: Some candidates think manually managing NSG rules is sufficient. But JIT automates the temporary rule creation and removal, reducing human error and ensuring ports are not left open. The exam will test that JIT is a managed solution with auditing and policy enforcement.
Azure Firewall's JIT feature: Azure Firewall has a similar feature called "Just-In-Time Access" for VMs behind the firewall. But if the VM has a direct public IP and NSG, JIT in Defender for Cloud is the correct answer. The exam may describe a VM with an NSG; Azure Firewall is irrelevant.
Disabling the VM when not in use: Some candidates think turning off the VM is equivalent. But JIT allows access on demand without downtime.
Specific Numbers and Terms That Appear on the Exam
Default maximum duration: 3 hours (configurable)
Default ports: 3389 (RDP) and 22 (SSH)
Required RBAC: Security Reader to request access, Security Admin to configure
JIT is part of Microsoft Defender for Cloud, Defender for Servers Plan 2
The feature modifies NSG rules, not Azure Firewall rules
Approval workflow is optional and requires a separate approver role
Edge Cases and Exceptions
JIT does not work with VMs that have no NSG attached (you must attach one)
JIT does not work with VMs using Azure Firewall as the only network boundary
JIT cannot be used with VMs that have no public IP (use Bastion)
If a VM has multiple NICs, JIT only affects the NSG of the primary NIC
JIT policies can be defined at subscription, resource group, or VM level
How to Eliminate Wrong Answers
If the scenario mentions a VM with a public IP and the goal is to reduce exposure of management ports, JIT is the likely answer.
If the scenario mentions a VM without a public IP, eliminate JIT and consider Bastion.
If the scenario mentions Azure Firewall, consider Azure Firewall's JIT or DNAT rules.
If the scenario mentions compliance requirements for approval and auditing, JIT with approval workflow is correct.
JIT VM Access reduces attack surface by keeping management ports closed until explicitly requested.
Default maximum request duration is 3 hours, configurable via policy.
JIT works by creating temporary NSG allow rules that override a default deny rule.
Requires Defender for Cloud (Defender for Servers Plan 2) for full functionality like approval workflow.
Users need Security Reader role to request access; Security Admin to configure.
JIT does not work with VMs without public IPs or VMs behind Azure Firewall (use Bastion or Firewall JIT).
All JIT requests and actions are logged in Azure Activity Log for auditing.
JIT policies can restrict source IPs, ports, and duration; approval workflow is optional.
JIT is not a replacement for Azure Bastion; they serve different scenarios (public vs private IPs).
Exam tip: If a VM has a public IP and you need to secure RDP/SSH, choose JIT over Bastion.
These come up on the exam all the time. Here's how to tell them apart.
JIT VM Access
Works with VMs that have public IPs
Modifies NSG rules to allow temporary access
Requires Defender for Cloud (P2 plan for full features)
Supports custom ports and durations
Provides auditing via Activity Log
Azure Bastion
Works with VMs without public IPs (private VMs)
Provides secure RDP/SSH through a Bastion host in the VNet
Requires Azure Bastion service (separate cost)
Supports only RDP and SSH (no custom ports)
Provides session recording and monitoring
JIT VM Access
Automatically creates and removes rules
Enforces policy (source IP, duration, ports)
Provides centralized management in Defender for Cloud
Audits all requests and actions automatically
Reduces human error from leaving ports open
Manual NSG Rules
Rules are static and must be manually updated
No built-in policy enforcement
Managed per NSG, not centralized
Auditing requires separate configuration (e.g., NSG flow logs)
High risk of misconfiguration or forgotten rules
Mistake
JIT VM Access requires the VM to be in a VNet with Azure Firewall.
Correct
JIT works with NSGs, not Azure Firewall. It can be used on any VM with a public IP and an NSG attached, regardless of Azure Firewall presence.
Mistake
JIT permanently opens a port for the user until they manually close it.
Correct
JIT creates a temporary rule with a configurable expiration (default max 3 hours). After the duration, the rule is automatically deleted. The user can also revoke early.
Mistake
Any user can request JIT access to any VM without permissions.
Correct
Users need the Security Reader role (or equivalent) on the VM or subscription to request access. Without it, the request is denied.
Mistake
JIT works with VMs that have no public IP address.
Correct
JIT requires the VM to have a public IP because it creates NSG rules for inbound traffic from the internet. For VMs without public IPs, use Azure Bastion.
Mistake
JIT automatically approves all requests without any policy enforcement.
Correct
Policies can restrict source IPs, ports, and duration. If a request does not meet policy, it is denied. Approval workflow can also require a second approver.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can enable JIT from Microsoft Defender for Cloud. In the portal, go to Defender for Cloud > Workload protections > Just-in-time VM access. Select the VM and click 'Enable JIT'. Alternatively, use Azure CLI: `az vm jit enable --resource-group MyRG --vm MyVM --ports 3389 22`. The VM must have a public IP and an NSG attached. JIT will remove existing allow rules for those ports and create a default deny rule.
You need the Security Reader role (or equivalent) on the VM or subscription. The Security Reader role allows you to view security configurations and request access. To configure JIT policies, you need Security Admin or Contributor role. The exact RBAC action is 'Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action'.
No. JIT requires the VM to have a public IP because it creates NSG rules for inbound traffic from the internet. For VMs without public IPs, use Azure Bastion to provide secure RDP/SSH access without exposing a public endpoint.
No. JIT only modifies NSG rules. If a VM is behind Azure Firewall, you must use Azure Firewall's own JIT feature or manually manage DNAT rules. Defender for Cloud's JIT does not integrate with Firewall.
The default maximum duration is 3 hours. You can configure a shorter duration in the JIT policy. The user specifies the duration in their request, up to the policy maximum. After the time expires, the temporary NSG rule is automatically deleted.
Yes, if you enable the approval workflow in the JIT policy. When a user requests access, the request enters a pending state. An approver (with Security Admin role) can approve or deny it via the Defender for Cloud portal. Without approval workflow, requests are auto-approved if they meet policy.
All JIT requests, approvals, rule creations, and deletions are logged in Azure Activity Log under the category 'Administrative'. You can also send these logs to Log Analytics for advanced querying and alerting. Defender for Cloud also generates security alerts for suspicious JIT activity.
You've just covered Just-In-Time VM Access — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?