In the old world, your perimeter was defined by firewalls and LANs. If you were on the corporate network, you were “trusted.” But in Azure, admins and users connect from anywhere — home Wi‑Fi, hotel lobbies, coffee shops. The traditional perimeter doesn’t hold.

Zero Trust in Azure networking means fusing who you are with what you can reach. That’s where Conditional Access (CA), Privileged Identity Management (PIM), and Just‑in‑Time (JIT) VM access come in, reshaping the perimeter around identity itself.

What is Identity‑Driven Network Access?

Microsoft’s Zero Trust mantra: never trust, always verify.

In practice:

• Every network request is tied back to identity (user, service principal, managed identity).
• Access is granted dynamically, based on context → user role, device compliance, location, and risk signals.
• Networking and identity controls are aligned.

Instead of “allow traffic from this subnet range”, you can define:

• Require MFA if sign‑in comes from outside a trusted region.
• Block legacy authentication globally.
• Allow only time‑bound RDP via Bastion after JIT approval.

How Identity Meets Networking in Azure

• Azure Bastion + JIT VM Access

  • Removes the need for open public IPs or permanent RDP/SSH access.
  • Admin session flows through Bastion, authorised by JIT + Conditional Access.
  • Network path only exists while the user is approved.

• Conditional Access Policies (CA)

  • Govern access to the Azure Portal, PowerShell, CLI, and apps.
  • Can require compliant devices, enforced MFA, or block risky sign‑ins entirely.

• Privileged Identity Management (PIM)

  • Admin rights aren’t always‑on. Roles become “eligible,” then explicitly activated when needed, often with approval + MFA.

• Private Endpoints with Identity

  • PaaS workloads (e.g. Azure SQL, Storage) are reachable via Private Endpoint inside segmented VNets.
  • Resource access is granted to AAD identities or Managed Identities, not IP addresses.

Real‑World Impact

Consider a medium‑sized SaaS company:

• Developers occasionally need SSH access to VMs.
• Ops team manages SQL daily but wants no exposure to internet endpoints.
• Security demands no standing admin rights and no exposed RDP.

By combining identity controls + network controls:

• Developers must request JIT VM access, session goes via Bastion, MFA enforced, and access times out automatically.
• Ops team connects only to SQL over Private Endpoint and authenticates with AAD — no public access.
• Security enforces global SARs from Part 2 + Conditional Access, ensuring no open doors even if creds are leaked.

Architecture Overview

Identity acts as the perimeter → access flows only when verified and approved, layered alongside segmentation.

Implementation Examples

Azure Portal Steps

1. Enable JIT VM Access via Microsoft Defender for Servers.

   • Go to Defender for Cloud → Virtual Machines → select your VM → configure JIT.
   • Define allowed ports (22/3389), allowed IPs, and max duration.
   • Access requests then flow through the Azure AD approval process.
   ⚠️

   Warning: JIT VM Access requires an active Defender for Servers plan on your subscription or resource group. Without it, you won’t see JIT in the portal.

2. Configure Conditional Access

   • Create a policy for “Azure Management” → require MFA and compliant device.
   • Block logins from high‑risk sign‑ins.

3. Set up PIM role eligibility

   • Remove permanent Contributor/Owner permissions.
   • Assign roles as “eligible” → require activation with justification and approval.

4. Deploy Bastion in hub VNet

   • Ensure VMs live without public IPs.
   • All management flows tunnel via Bastion + identity policy.

Bicep Example (Functional JIT Policy)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

param vmName string = 'MyVm'

// Existing VM reference
resource vm 'Microsoft.Compute/virtualMachines@2023-09-01' existing = {
  name: vmName
}

// Just-In-Time policy


// Just-In-Time (JIT) network access policy for the VM
resource jitPolicy 'Microsoft.Security/locations/jitNetworkAccessPolicies@2020-01-01' = {
  name: 'JITPolicyLocation/default' // always 'default' for JIT but you have to have a Location pre-defined in Azure
  kind: 'Basic'
  properties: {
    virtualMachines: [
      {
        id: vm.id
        ports: [
          {
            number: 22               // SSH
            protocol: 'TCP'
            maxRequestAccessDuration: 'PT3H'  // ISO 8601 duration, here: 3 hours
            allowedSourceAddressPrefix: '*'   // allow from any IP (tighten this in prod)
          }
          {
            number: 3389            // RDP
            protocol: 'TCP'
            maxRequestAccessDuration: 'PT2H'  // 2 hours
            allowedSourceAddressPrefix: '*'
          }
        ]
      }
    ]
  }
}

Gotchas & Edge Cases

• Licensing dependency: JIT requires Defender for Servers — attempting to deploy without it will fail.
• Watch exclusions: Always maintain at least one break‑glass account exempt from Conditional Access.
• Protocol coverage: Conditional Access works at identity layers, not raw protocol layers. Use CA + Bastion + segmentation together.
• Audit & logs: Track JIT requests, Bastion sessions, and PIM activations for compliance.

Best Practices

• Enforce MFA everywhere, especially admin access.
• Always use JIT + Bastion rather than open NSG rules for RDP/SSH.
• Combine segmentation (Post 1) and AVNM baseline denies (Post 2) with identity enforcement.
• Keep privileged roles “eligible” under PIM, not “always on.”
• Test CA policies carefully to prevent accidental lock‑outs.

Learn More

• Microsoft Zero Trust Identity Guidance
• Conditional Access Overview
• Azure Bastion
• Just-in-Time VM Access
• Privileged Identity Management