The problem
Remote access is the front door of the enterprise. Every user who is not sitting in a building enters through it, which makes it simultaneously the most attacked surface you run and the one users tolerate the least friction on. The classic VPN model treats a valid credential as the whole conversation: right password, full tunnel. That model answers one question and skips the two that matter more — is this really the user, and is the machine they are connecting from in any state to be trusted?
The other half of the problem is availability. A front door that goes down during patching, or falls over when a headend fails, teaches the business to route around it. Remote access has to be boring: always up, always answering, and quietly strict about who gets in.
My role
I own the remote-access stack: the global footprint of Cisco ASA and FTD SSL VPN headends, the integrations that authenticate and authorize every session, and the three-node VPN load-balancing cluster that anchors it — a platform I have run for more than three years. The design decisions, the identity integrations, and the proof-of-concept work exploring what replaces the model are mine.
The approach
Every session has to survive two interrogations before it gets a tunnel. The first is about the human: authentication hands off to Azure MFA, so a stolen password on its own buys an attacker nothing. The second is about the machine: authorization belongs to ISE, which runs a posture check against the connecting endpoint before deciding what, if anything, the session is allowed to reach. The headend terminates the tunnel, but it does not get an opinion on trust — identity and device state do.
That split matters architecturally. The same ISE platform that authenticates the wired and wireless enterprise is the authorization brain for VPN, so remote users are subject to the same policy engine as everyone else. Remote access stops being a separate security model and becomes another entry point into the one model.
Availability comes from the cluster. Three load-balanced nodes share the session population, so losing a headend is a capacity event, not an outage, and patching one is routine maintenance instead of a change freeze. Three-plus years of ownership have been the real test: hardware refreshes, software trains, and vulnerability cycles, absorbed without the business noticing.
What shipped
A global SSL VPN service on ASA and FTD headends, fronted by the three-node load-balancing cluster, with Azure MFA on every authentication and ISE posture on every authorization. Two platforms, one policy model, no session admitted on a password alone.
Where it stands
The stack runs, and the interesting work is what comes after it. A proof of concept pairs a Meraki MX at the remote site with 802.1X against ISE for executive remote access — instead of the user dialing into the network with a client, the corporate network extends to where they are, with the same port-level authentication an office would enforce. It is the same conviction the whole platform is built on: the tunnel is just transport. Identity and device state decide everything.