Security Service Edge: Internet and Private Access

The End of the VPN Era

VPNs were designed for a world where applications lived in the corporate data centre and employees worked from the office. Connect to the VPN, get an IP address on the corporate network, access everything.

This model has fundamental security flaws in a modern environment:

Excessive access. VPN puts the user on the corporate network. They can reach everything — not just the app they need, but every system reachable from that network segment. If an attacker compromises a VPN-connected device, they have the same broad network access.

No identity-aware decisions. Traditional VPN authenticates once at connection time. After that, the network doesn’t care who you are or what device you’re on. There’s no continuous assessment of risk.

Backhauling kills performance. In a VPN model, a remote worker in Singapore accessing Microsoft 365 (in Singapore’s data centre) first sends traffic to the corporate VPN concentrator in New York, then back out to Microsoft 365. The traffic crosses the globe twice for no security benefit.

Scalability and cost. VPN concentrators are physical (or virtual) appliances with finite capacity. The pandemic proved this — organisations couldn’t scale VPN infrastructure fast enough for 100% remote workforces.

Security Service Edge (SSE) replaces this model with cloud-delivered, identity-aware network security.

Microsoft’s SSE Architecture

Microsoft’s SSE implementation has two components:

Microsoft Entra Internet Access

Entra Internet Access is a secure web gateway (SWG) delivered through Microsoft’s global network. It secures traffic from users to the internet and to Microsoft 365 services.

What it does:

• Web content filtering — Block access to malicious, risky, or policy-violating websites by category or specific URLs
• Conditional Access for internet traffic — Apply Conditional Access policies to internet destinations. Example: “Block access to unsanctioned AI services from unmanaged devices”
• Microsoft 365 traffic optimisation — M365 traffic is identified and routed optimally through Microsoft’s network, avoiding backhauling
• Threat protection — Inline inspection blocks known malicious sites and downloads
• Universal tenant restrictions — Prevent data exfiltration by ensuring users can only sign into authorised Microsoft 365 tenants. Even on personal devices, they can’t sign into a personal OneDrive and upload corporate documents
• Source IP restoration — The user’s original IP is preserved for logging and Conditional Access IP-based policies, even though traffic routes through Microsoft’s proxy

Microsoft Entra Private Access

Entra Private Access is a Zero Trust Network Access (ZTNA) service that replaces traditional VPN. It provides per-app access to private applications — whether they’re in your data centre, Azure, AWS, or any other location.

What it does:

• Per-app access — Users access specific applications, not the entire network. An accountant connects to the financial system but can’t reach the engineering servers.
• No inbound connections — The connector (installed in your network) creates outbound connections to Microsoft’s cloud. No inbound firewall ports need to be opened.
• Conditional Access integration — Every access decision considers identity, device health, location, and risk level
• Quick Access and app segments — Define which private IP ranges or FQDNs are accessible, grouped by application
• Protocol support — TCP and UDP, any port. Not limited to web applications like some ZTNA solutions

Global Secure Access Client

Both Entra Internet Access and Private Access use the Global Secure Access client — a lightweight agent installed on user devices (Windows, macOS, iOS, Android) that captures and routes traffic to Microsoft’s SSE infrastructure.

The client:

• Identifies traffic based on configured traffic forwarding profiles (Microsoft 365, Internet, Private Access)
• Routes selected traffic to the nearest Microsoft Point of Presence (PoP)
• Handles authentication transparently using the device’s Entra ID session
• Doesn’t replace the device’s default gateway — only routes traffic that matches configured profiles

Traditional VPN vs Microsoft Entra Private Access

Aspect	Traditional VPN	Microsoft Entra Private Access
Access model	Network-level — full network access once connected	Application-level — per-app access only
Authentication	Once at connection time	Continuous — Conditional Access evaluates every session
Device posture	Rarely checked after initial connection	Continuously assessed — device risk affects access
Network exposure	User is 'on' the corporate network	User accesses specific apps; no network-level presence
Inbound connections	VPN concentrator needs inbound ports open	No inbound connections — connectors make outbound only
Lateral movement risk	High — compromised device can scan the network	Low — user only reaches defined app segments
Traffic routing	All traffic backhauled through VPN concentrator	Only private app traffic routed; internet goes direct
Scalability	Limited by appliance capacity	Cloud-delivered, scales automatically
Zero Trust alignment	Low — implicit trust after connection	High — explicit verification for every app access
User experience	VPN client connects/disconnects; all-or-nothing	Always on; transparent per-app access

Conditional Access Integration: The Game Changer

What makes Microsoft’s SSE architecturally powerful is its deep integration with Conditional Access. This is unique — other SSE vendors have their own policy engines that exist separately from identity.

With Entra SSE, the same Conditional Access policies that control access to Microsoft 365 and SaaS apps now control:

• Internet access — “Block access to generative AI websites from devices with high risk”
• Private application access — “Require compliant device and MFA to access the finance application”
• Microsoft 365 traffic — “Restrict SharePoint access to managed devices when connecting from outside the corporate network”

The signal flow:

User opens browser → Global Secure Access client intercepts traffic
→ Routes to nearest Microsoft PoP → Conditional Access evaluates:
  - Who is this user? (identity)
  - What device? (compliant, risk level)
  - Where are they? (named location, country)
  - What risk? (sign-in risk, user risk)
→ Policy decision: allow, block, or require MFA
→ Traffic forwarded to destination (or blocked)

Every network access decision is identity-aware. This is the convergence of network security and identity security that Zero Trust demands.

Designing an SSE Architecture

Phase 1: Microsoft 365 Traffic (Low Risk, High Value)

Start by routing M365 traffic through Entra Internet Access. This provides:

• Universal tenant restrictions (prevent data exfiltration to personal tenants)
• Conditional Access for M365 traffic based on network signals
• Traffic optimisation (no more backhauling M365 through VPN)

This phase is low risk because M365 traffic was already going to Microsoft — you’re just routing it through a more secure path.

Phase 2: Internet Access (Medium Complexity)

Enable web content filtering and threat protection for internet traffic:

• Block known malicious categories
• Block unsanctioned SaaS applications
• Enable Conditional Access policies for internet destinations
• Configure logging for security monitoring and compliance

Phase 3: Private Access (VPN Replacement)

Migrate users from VPN to Entra Private Access:

• Identify all applications currently accessed via VPN
• Create app segments defining which private IPs/FQDNs each application uses
• Deploy connectors in each network location (data centre, Azure VNet)
• Pilot with a small user group, then expand
• Eventually decommission the VPN

Important architectural note: Phase 3 is a gradual migration, not a cutover. Many organisations run VPN and Private Access in parallel during transition.

🏛️ Scenario: Torres Replaces Government VPN

Commander Torres’ department has 10,000 employees accessing government applications from offices, homes, and field locations. The VPN infrastructure — three VPN concentrators in two data centres — is at capacity. During peak hours, users experience slow connections and dropped sessions.

More concerning to Torres: every VPN user has full network access to the government network. A compromised laptop at an employee’s home has the same network reach as a workstation in the secure office.

“VPN is a liability, not a security control,” Torres tells Colonel Reeves. “We’re giving full network access to prove we can grant specific application access.”

Torres’ SSE migration plan:

Phase 1 (Month 1-2): Microsoft 365. Route all M365 traffic through Entra Internet Access. Implement universal tenant restrictions — government employees can only access the department’s M365 tenant, preventing exfiltration to personal accounts. Immediate win: M365 performance improves because traffic no longer backhauled through VPN.

Phase 2 (Month 2-4): Internet Access. Enable web content filtering aligned with government security policy. Block unauthorised cloud storage (personal Dropbox, Google Drive). Conditional Access: block internet access from non-compliant devices.

Phase 3 (Month 4-8): Private Access pilot. Start with three applications: the HR portal, the document management system, and the field reporting tool. Deploy connectors in both data centres. Pilot with 500 users across offices and field locations. Measure: connection success rate, latency, user satisfaction.

Phase 4 (Month 8-14): Full migration. Expand Private Access to all 35 government applications. Migrate all 10,000 users from VPN to Private Access. Run VPN in parallel for 60 days as fallback.

Phase 5 (Month 14-16): VPN decommission. Turn off VPN. Decommission concentrators. Close inbound firewall ports that VPN required.

“After Phase 5, there are zero inbound connections to our network,” Torres explains to Specialist Diaz. “Every connection is outbound from our connectors to Microsoft’s cloud. There’s no VPN concentrator for an attacker to target, no broad network access for a compromised device. Every user gets access to exactly the applications they need, verified by Conditional Access every single time.”

☁️ Scenario: Rajan Designs SSE for a Remote-First Workforce

Rajan’s client, a software company with 2,000 employees, went fully remote two years ago. They’ve been using a combination of VPN (for internal tools), a third-party SWG proxy (for web filtering), and Defender for Cloud Apps as a CASB. Three separate tools, three separate policy engines, three separate consoles.

“You’re paying for complexity that works against you,” Rajan tells the client CTO. “Different policy engines mean inconsistent enforcement. Your SWG blocks a URL, but your VPN allows the traffic anyway because it doesn’t check the SWG’s block list.”

Rajan designs a consolidated SSE architecture:

Replace VPN: Entra Private Access with Quick Access definitions for each internal application. The development team gets access to the code repositories and CI/CD pipeline. The sales team gets access to CRM and the proposal system. Neither team can access the other’s applications.

Replace SWG proxy: Entra Internet Access with web content filtering. Same policies as the old proxy, but now integrated with Conditional Access. “Block developer forum access from non-compliant devices” — the old proxy couldn’t check device compliance.

Retain Defender for Cloud Apps: For advanced CASB capabilities (session controls, app governance) that SSE doesn’t replace. Defender for Cloud Apps complements SSE by providing app-level controls like “block download of files from SharePoint when on unmanaged device.”

“Three tools down to two, one policy engine instead of three, and every decision is identity-aware,” Rajan summarises for Priya. “The user experience improves because traffic routes optimally instead of backhauling through a proxy. Security improves because every access decision considers who, what device, and what risk.”

Exam Strategy: SSE and Network Access Questions

SSE questions in SC-100 test whether you understand the architectural shift from network-based to identity-based security:

• “Replace VPN” → Entra Private Access. If the question mentions “per-app access” or “Zero Trust network access,” this is definitely the answer.
• “Secure web access” → Entra Internet Access. If the question mentions web filtering or tenant restrictions, this is it.
• “Prevent data exfiltration to personal Microsoft 365 accounts” → Universal tenant restrictions via Entra Internet Access. This is a specific, testable capability.
• “Identity-aware network security” → SSE with Conditional Access integration. The key differentiator of Microsoft’s SSE is Conditional Access integration.
• “No inbound connections to corporate network” → Entra Private Access with connectors. Connectors make outbound connections only — no inbound firewall ports.
• “Performance issues with VPN” → Backhauling is the problem. SSE routes traffic optimally through Microsoft’s global network.
• Don’t confuse SSE with Azure Firewall. Azure Firewall protects Azure VNet traffic. SSE protects user traffic from endpoints to destinations (internet, private apps, M365). They solve different problems and can coexist.
• Defender for Cloud Apps (CASB) complements SSE — it’s not replaced by it. Session controls and app governance remain CASB functions.

Question

What are the two components of Microsoft's SSE, and what does each replace?

Click or press Enter to reveal answer

Answer

1) Entra Internet Access replaces traditional secure web gateways (SWG) and proxies — it filters and secures internet and M365 traffic. 2) Entra Private Access replaces VPN with Zero Trust Network Access (ZTNA) — it provides per-app access to private applications without granting network-level access. Both use the Global Secure Access client and integrate with Conditional Access.

Click to flip back

Question

Why is Conditional Access integration the key architectural differentiator of Microsoft's SSE?

Click or press Enter to reveal answer

Answer

Most SSE vendors have separate policy engines for network and identity decisions. Microsoft's SSE uses the same Conditional Access policies for internet access, private app access, and M365 traffic. This means every network access decision considers identity, device compliance, risk level, and location — without maintaining separate policy sets. One engine, one policy, applied everywhere.

Click to flip back

Question

How does Entra Private Access eliminate the VPN's lateral movement risk?

Click or press Enter to reveal answer

Answer

VPN places users on the corporate network — they can reach any network-accessible system. Entra Private Access grants access to specific applications only (app segments). The user never has network-level presence. If a device is compromised, the attacker can only reach the specific applications that user was authorised for, not the entire network. Additionally, connectors only make outbound connections — no inbound firewall ports are open.

Click to flip back

Question

What is universal tenant restrictions, and why does it matter for data exfiltration prevention?

Click or press Enter to reveal answer

Answer

Universal tenant restrictions (via Entra Internet Access) ensure users can only sign into authorised Microsoft 365 tenants. Without it, an employee could sign into a personal M365 account and upload corporate documents to their personal OneDrive — even from a managed device. Tenant restrictions block authentication to unauthorised tenants at the network level, preventing this exfiltration path. This works even if the user has personal credentials.

Click to flip back

Knowledge Check

A company with 5,000 remote workers currently uses VPN for all internal application access. They experience peak-hour congestion, and a recent incident showed that a compromised remote device was able to scan the entire corporate network through the VPN. The CISO wants to eliminate broad network access while maintaining connectivity to internal applications. What should the security architect recommend?

AA. Upgrade the VPN concentrators to higher-capacity models and implement network segmentation behind the VPNBB. Deploy Microsoft Entra Private Access with per-app segments, Global Secure Access client on endpoints, and Conditional Access policies requiring device compliance for each applicationCC. Deploy Azure Firewall to inspect all VPN traffic and block lateral movementDD. Implement split tunnelling on the VPN to reduce congestion and add NAC to check device compliance at VPN connection time

Check Answer

Knowledge Check

An organisation discovers that employees are uploading sensitive documents to personal OneDrive accounts by signing into their personal Microsoft 365 tenants from corporate-managed devices. Defender for Cloud Apps blocks downloads from unmanaged devices but cannot prevent uploads to personal tenants from managed devices. What additional control should the security architect implement?

AA. Block all access to OneDrive using Azure Firewall FQDN rulesBB. Implement universal tenant restrictions through Microsoft Entra Internet Access to prevent authentication to unauthorised Microsoft 365 tenantsCC. Deploy DLP policies in Microsoft Purview to prevent sensitive document uploadDD. Remove internet access from managed devices and route all traffic through the corporate proxy

Check Answer

🎬 Video coming soon

---

Next up: Infrastructure Security Decisions — synthesis module with realistic architecture decision scenarios combining everything from Domain 3.