Tie office access to identity, not to the switch port
Segmentation, admission and service authorization are different jobs. Three conditions decide whether identity-driven access beats per-port VLANs.
Two designs are on the table. One keeps employees in role-based VLANs and edits switch ports when people move. The other authenticates the session and lets policy decide what it may reach. The choice is not about modernity; it is about whether three conditions hold in your building. If any of them fails, the port-based design is not stupid, it is the one you can actually operate.
The three conditions are enforceability, identity quality and failure behaviour.
Condition 1: can the access devices enforce a returned policy
802.1X is a relationship between a supplicant on the endpoint, an authenticator in the switch or access point, and an authentication server reached over RADIUS. The server can return a VLAN or another policy result, and RFC 3580 describes that signalling. The switch still has to implement the result you are relying on.
Ask for a capability, not for a protocol: dynamic VLAN assignment, downloadable ACLs, or a redirect to a registration portal.
Condition 2: is the identity source authoritative and quick to change
Group membership in the directory helps only if it is the field the business already edits when a role changes. If role assignment lives in a spreadsheet copied into groups monthly, identity-driven access simply automates a stale input. Check the latency as well, because a joiner who cannot work for a day is a worse outcome than a manual port change. Device authentication, user authentication and both together are separate choices, and printers need an explicit model rather than an unexplained bypass.
Write the mapping down: which group grants which policy, and who may change it.
Condition 3: decide the failure behaviour before the pilot
Every deployment has an unauthenticated state and a server-unavailable state, and the policy for both is a security decision. A silent fallback into a trusted segment defeats the design; a hard failure blocks work during an outage. The usual middle ground is a restricted segment with internet-only access and a clear route to the help desk. Test the fallback on the real switch or wireless platform, because vendor defaults differ.
If nobody can describe the fallback in one sentence, the design is not finished.
Where the VPN fits
A VPN authenticates access across an untrusted path, and requiring it on the office LAN too can be a deliberate trust decision. It does not remove the need for group mapping or for the file server own authorization. It also adds gateway capacity, client software and session management to the operational load.
A VPN bought to avoid editing VLANs has solved the wrong problem and added two new ones.
The table, and the one thing to keep
| Condition | Holds? | Design |
|---|---|---|
| Devices enforce returned policy | Yes | 802.1X with dynamic policy, stable segments |
| Devices cannot enforce it | No | Keep segments, add an application gateway |
| Identity source lags role changes | No | Fix provisioning before admission |
| No acceptable unauthenticated state | No | Restricted segment with a portal |
| Departures must lose access quickly | Yes | Dynamic disconnect plus credential revocation |
Keep segments for servers, guests, devices and operational technology. Those boundaries are about traffic rather than job titles, and they survive any reorganisation. Put the employee entitlements in identity policy, where a role change is one edit, and use the supported disconnect mechanism when removal has to be prompt.
The test of the design is a desk move: it should move a person and their equipment, not rebuild their permissions around a different jack.