Azure Bastion and just-in-time VM access both reduce the risk created by administrative ports, but they solve that problem in different ways. Bastion gives administrators a managed path to reach virtual machines over private IP addresses without putting a public IP on the VM. Just-in-time access, provided through Microsoft Defender for Cloud, keeps management ports closed and opens them temporarily for approved access requests. One changes the connection architecture; the other changes when inbound rules are allowed.
The distinction matters in real Azure design because “secure RDP and SSH” is not one technical requirement. Some teams want to eliminate public VM exposure entirely. Others have legacy workflows in which VMs still have reachable addresses but management ports should not remain open. Some environments need browser-based access, some need native clients, and some need session recording or private-only administration. This topic therefore connects directly to AZ-104, AZ-700, cloud security and the wider Microsoft Azure infrastructure certification path.
Bastion removes the need for a public IP on the target VM
Azure Bastion is a managed service deployed for administrative connectivity. With a standard dedicated Bastion deployment, the service sits in a dedicated AzureBastionSubnet and makes the final RDP or SSH connection to the target VM over its private IP address. Administrators can connect through the Azure portal, and higher SKUs add native-client and other connection options.
The key architectural benefit is that the target VM does not need its own public IP. That removes one of the most common ways management services become directly exposed to the internet. Network security groups can keep RDP and SSH closed to internet sources because administrators reach the machine through the Bastion path instead.
Bastion should therefore be considered when the design objective is to eliminate direct public management access. It is especially useful in hub-and-spoke networks where a centralized administrative service can reach workloads over peering, subject to SKU and network design. Premium capabilities extend the model further with private-only deployment and session recording for higher-security environments.
Bastion is not a full user VPN. It is designed for administrative connectivity to machines. If engineers need broad network access to databases, private web applications and many non-VM resources, a VPN or another private-access model may be more appropriate. Choosing Bastion just because “it is secure” can create a poor operational fit if the actual requirement is general network connectivity.
JIT keeps management ports closed until access is requested
Just-in-time VM access is a Microsoft Defender for Cloud control designed to reduce the time that sensitive management ports are reachable. Instead of leaving SSH, RDP or another configured port open all day, Defender for Cloud maintains deny behavior and creates a temporary allow path after an authorized user requests access.
The request can specify the port, source IP address or range and the allowed time window. When the window expires, the temporary allowance is removed and the protective state returns. This is valuable for VMs that still use a network path in which inbound management ports could otherwise remain exposed.
JIT works through network controls such as NSGs and supported Azure Firewall configurations. It does not create a separate managed connection service in the way Bastion does. The administrator still connects to the VM using the normal management protocol after the access request has opened the path.
This difference is important for security analysis. JIT reduces exposure time, but it does not automatically remove the target VM’s public IP. Bastion removes the requirement for a public target address in the first place. If the goal is “no internet-facing VM management interface,” Bastion is usually the cleaner architectural answer.
The two controls are not mutually exclusive
Teams sometimes treat Bastion and JIT as competing products that require one universal winner. In reality, they can exist in the same organization for different workloads. A modern production landing zone might standardize on Bastion for private administrative access, while a legacy subscription uses JIT to reduce risk until public management endpoints are removed.
The right comparison starts with the threat model. If the concern is internet scanning against open RDP and SSH, both controls can reduce risk, but Bastion can eliminate the target’s public exposure. If the concern is limiting when a known administrative path can be used, JIT introduces explicit time-bounded access. If the concern is auditing interactive sessions, higher Bastion SKUs may provide capabilities that JIT does not.
Neither control replaces identity security. A user who can reach a VM still needs appropriate Azure permissions to initiate the connection and appropriate operating-system credentials or rights on the machine. Network reachability, Azure authorization and guest operating-system authorization are separate layers.
That layering is consistent with role-based access control: granting a person the ability to view or connect through Azure should not automatically make them an administrator inside every target VM.
Use Bastion when private management is the design goal
Bastion is the stronger fit when an organization wants private-IP management without deploying a public IP on each target machine. It is also useful when administrators need a managed browser-based connection from the Azure portal rather than a traditional jump server that the organization must patch and operate.
Standard and Premium tiers add operational features beyond the basic portal experience. Native-client connectivity can preserve familiar SSH or RDP tooling. IP-based connections and peering support broaden which machines can be reached. Premium private-only deployment can remove the public IP from the Bastion resource itself, which is relevant to tightly controlled environments.
Those features come with cost and architecture decisions. Dedicated Bastion tiers require the appropriate subnet design and consume managed service capacity. A small development environment may not need the same tier as a production administrative hub. Design the service around concurrent users, connectivity methods, security requirements and network topology rather than choosing a tier by name.
Use JIT when temporary port opening matches the operating model
JIT makes sense when the machine is still reached through a conventional inbound path but management ports should remain closed until someone actually needs them. It can reduce the attack window for systems that cannot yet be redesigned around private access.
The access policy should be stricter than the default if the environment requires it. Restrict allowed source addresses, use the shortest practical time window and protect only the necessary ports. A policy that allows “any source” for long windows weakens the purpose of the feature.
JIT also depends on Microsoft Defender for Servers Plan 2. That licensing and operational dependency should be part of the architecture decision. The control is valuable when Defender for Cloud is already part of the security model, but it should not be introduced without considering who will operate requests, how access is logged and what happens when network rules are managed by other automation.
There are also technical compatibility considerations. JIT interacts with NSGs and supported firewall configurations; teams using centralized Azure Firewall policies need to verify current support rather than assuming every firewall-management model works the same way.
Do not use either service as a substitute for endpoint hardening
Reducing exposure to RDP and SSH is only one part of virtual-machine security. An attacker who compromises credentials, exploits an application port or gains access through another path can still attack the VM. Patch management, endpoint protection, least privilege, disk encryption, logging and segmentation remain necessary.
The broader cybersecurity architecture lesson is that administrative access is a chain of controls. Network reachability determines whether a connection can arrive. Azure RBAC determines who can use cloud control-plane features. Guest operating-system permissions determine what the user can do inside the machine. Defender and monitoring services help detect suspicious behavior after access occurs.
A strong design also avoids shared administrator credentials. Use identity-based access where supported, enforce MFA and privileged workflows, and ensure that emergency access is distinct from routine administration. Bastion or JIT can make a poor identity model slightly less exposed, but they cannot make it safe.
Decision framework
- Choose Bastion when target VMs should not need public IP addresses for RDP or SSH.
- Choose Bastion when portal-based or managed native-client administrative access is desirable.
- Choose Premium Bastion when private-only deployment or session recording is part of the security requirement.
- Choose JIT when VMs still use inbound management ports but those ports should open only for authorized, time-bounded requests.
- Use both patterns across an estate when different subscriptions are at different stages of modernization.
- Use neither as a full VPN replacement when administrators need general private network access to many resource types.
The most important question is not “Which service is more secure?” Security depends on the architecture. Bastion is usually stronger when the goal is to remove direct public management exposure. JIT is strong when the existing access path must remain but should be available only on demand. Understanding that difference produces a cleaner design than treating both features as interchangeable ways to open RDP.
Migration from public management to private administration
Many Azure estates do not start with a clean Bastion design. They begin with public IP addresses, NSG rules restricted to office ranges and perhaps JIT layered on later. A practical modernization path is to reduce exposure in stages rather than wait for a perfect network redesign.
First inventory which VMs still have public management endpoints and who actually uses them. Enable JIT where those ports must remain reachable during the transition, tighten source ranges and remove permanently open rules. Then deploy Bastion in the network topology that will serve the surviving administrative use cases. Test browser and native-client workflows, confirm DNS and peering behavior, and migrate operator runbooks before removing public IPs.
Finally, treat the removal of public management addresses as a configuration standard. New production VMs should not quietly recreate the old pattern. Azure Policy, landing-zone templates and code review can help keep the environment on the private-access model once the migration is complete. This staged approach makes JIT a useful risk-reduction control without confusing it with the end-state architecture.