Security Service Edge: Internet and Private Access
Design Security Service Edge architecture using Microsoft Entra Internet Access and Private Access to replace VPNs with identity-aware, cloud-delivered network security.
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
| 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.
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?
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?
Next up: Infrastructure Security Decisions — synthesis module with realistic architecture decision scenarios combining everything from Domain 3.