Sanjay Seth

Zero-Trust Across a 15-Building Campus — FortiGate, FortiAuthenticator and FortiAP in Production

Where the campus started

The institution was a sprawling education campus — fifteen buildings, several thousand users, and a network that had grown the way campuses do: one urgent requirement at a time, for fifteen years. When they called me in, the architecture was an artefact of its history. Flat VLANs stretched across buildings because it had once been convenient. Remote access ran on VPN concentrators that everyone shared and nobody loved. Device identity did not exist — if a thing could plug in or join the Wi-Fi and knew the right password, it was on the network, with reach into far more than its role required.

The triggers for change will sound familiar. An internal audit had flagged lateral-movement risk. Personal devices had outnumbered managed ones years ago without anyone formally deciding that was acceptable. And a minor incident — a compromised staff account used to probe internal systems — had shown how little stood between one stolen password and the whole campus. The leadership’s question was not “what product do we buy?” It was “how do we fix this without stopping the teaching?” That is the right question, and this is how we answered it.

Zero-trust campus deployment with FortiGate, FortiAuthenticator and FortiAP — case study by Sanjay Seth

The design

Identity-driven segmentation

The core decision: stop trusting network location, start trusting verified identity. We rebuilt the segmentation model around who and what is connecting, not which port or SSID they arrive on. FortiAuthenticator became the identity backbone — tying users and devices to directory groups, handling certificate issuance for managed devices, and enforcing multi-factor authentication where it mattered. FortiGate firewalls, placed at the campus core and at building aggregation points, turned those identities into policy: staff, students, faculty research systems, IoT and building-management devices, guests — each with explicit, least-privilege reach. A student device and a finance server now live in different worlds, even when they share a switch.

Posture checks before access

Identity alone is not enough; a valid user on a compromised laptop is still a problem. Managed devices receive certificates and agent-based posture checks — patch level, endpoint protection running, disk encryption — and the result feeds directly into the firewall policy. A device that fails posture does not get blocked into oblivion; it lands in a remediation segment with access to the patching servers and nothing else. That detail matters on a campus: you cannot hold a lecturer’s morning class hostage to a Windows update, but you also cannot let an unpatched machine wander the network. The quarantine-with-a-ladder approach kept both the security team and the timetable intact.

VPN-less ZTNA for remote access

The old VPN gave every connected user a network-layer presence on campus — far more trust than a remote user needs. We replaced it with zero-trust network access through the FortiGate fabric: users authenticate, their device posture is verified, and they are brokered to the specific applications their role permits — the ERP, the library systems, the admin portals — without ever being “on the network” in the old sense. Per-application access, continuously verified, no broad tunnel. The day we retired the shared VPN concentrator was the day the attack surface visibly shrank.

Secure wireless on FortiAP

Wireless was where flatness hurt most. We rebuilt it on FortiAPs managed from the same FortiGate fabric, with separate SSIDs mapped to identity and device class: certificate-authenticated access for managed staff devices, credentials plus MFA for students on the user network, a tightly firewalled IoT SSID for everything from projectors to access-control panels, and a guest network with internet-only reach. Because the APs report into the same policy engine as the wired core, a user walking from a desk port to a corridor AP keeps the same identity and the same restrictions. One policy, everywhere — that consistency is half of what “zero trust” means in practice.

For the theory behind these patterns, I have written up the broader approach in my zero-trust architecture design and implementation guide, and in my notes on working as a zero-trust consultant in India.

The rollout: building by building

We deliberately refused the big-bang cutover. The programme ran in waves: the administrative block first — small, controlled, full of sympathetic users — then academic buildings one or two at a time, timed around the academic calendar, with exam periods and admissions season treated as sacred. Every wave followed the same loop: baseline the building’s traffic for a fortnight, deploy segmentation in monitor mode, tune policy against what the logs said was real, then enforce. Every step was reversible. Until the final enforcement in each building, the old path still existed, and twice we used it — rolled a building back overnight, fixed what we had got wrong, and re-enforced a week later.

Not one class was disrupted across the whole programme. I say that not as a boast but as a design requirement: on a campus, availability of the timetable is a security-adjacent metric, because the fastest way to kill a security programme is to make it the reason a lecture hall sat empty.

What broke, and what it taught

Three things broke, and each made the design better. First, discovery underestimated the IoT estate. The traffic baselines revealed devices nobody owned on paper — lab instruments, a generation of CCTV DVRs, building controllers that had not been patched since installation and never would be. They could not take agents or certificates, so they got their own micro-segments with tightly brokered access. Segmentation contains the risk; it does not cure it, and the register of what lives in those segments is now a maintained document, not a surprise.

Second, early posture policies were too strict for reality. A patch threshold set with a server-room mindset would have quarantined a meaningful share of student-facing machines on day one. We recalibrated to risk-tiered posture: strict for devices touching sensitive systems, pragmatic for general access, with a visible remediation path. Zero trust that users route around is worse than no zero trust.

Third, the identity data was messier than the network data. Directory groups had not been cleaned in years; departed staff still had accounts. None of the firewall work could fix that, so the programme absorbed a full identity-hygiene pass — MFA enrolment, account lifecycle, group restructuring. It was the least glamorous work in the project and, I would argue, the most valuable.

The outcome

All fifteen buildings now run segmented, identity-driven access under central policy. The VPN concentrators are gone; remote access is per-application ZTNA. Wireless and wired enforce the same rules. Posture failure routes to remediation, not to the dean’s inbox. And when a staff account was phished the following semester — these things still happen — the attacker’s access was confined to what that one identity could legitimately reach, which was very little, and the anomaly was visible. Containment worked as designed. That is the outcome that matters: not that nothing ever happens, but that what happens stays small.

Advice for your own campus or multi-building estate

Talk to me about your campus

If you are running a campus or a multi-building enterprise on flat VLANs and shared VPNs, the path out is proven and it does not require stopping the day job. Book a working session and we will map where your estate stands. Based in Delhi, working with enterprises across India.