How to revoke WiFi access when an employee leaves

Welcome to this technical briefing on revoking WiFi access when an employee leaves. The problem often looks smaller than it is. Someone leaves on Friday. Their manager disables email and takes back a laptop. Yet their cell phone or personal device can still join the Staff WiFi on Monday. In a hotel, that may place a former worker near operational systems. In a retail estate, it may give access to a staff network across many stores. In a stadium or conference center, it may make a busy event day harder to manage. The immediate question is not whether the leaver knows a password. It is whether your WiFi can identify that person as a distinct identity, and deny that identity without disrupting everyone else. A single shared WPA2 passphrase cannot do that. Every person has the same credential. Once that passphrase has been shared with a leaver, the network has no clean way to distinguish that leaver from every authorized employee who also knows it. The practical response is a company-wide passphrase rotation, followed by an update on every approved device. That is operationally expensive, creates support tickets, and often gets delayed. It is not a credible same-day offboarding control for a distributed venue estate. There are three credible patterns. The first is per-person 802.1X with EAP-TLS. The second is iPSK, sometimes called an individual pre-shared key. The third is identity-provider-driven deprovisioning using SCIM. You can combine these patterns. The central design choice is still the same: make the access credential attributable to a person or a managed device, then make removal a controlled, logged event. Let us start with 802.1X and EAP-TLS. IEEE 802.1X is the network access-control framework. It separates the device asking to join, the authenticator on the network edge, and the back-end authentication service. EAP-TLS is an Extensible Authentication Protocol method that uses certificates for mutual authentication and key derivation. In plain English, the device proves possession of a certificate and the network proves its own identity in the same authentication exchange. This model suits managed staff devices and high-assurance networks. The leaver action is not to change a shared password. It is to disable the identity and revoke, deny or otherwise remove the certificate's right to authenticate. Your RADIUS and certificate-validation design must be able to recognize that change when a device authenticates. Do not confuse certificate expiry with certificate revocation. Expiry is scheduled. Revocation is the offboarding action you take before the scheduled end date. The timing matters. Certificate-based WiFi access is checked at authentication. So your practical target is clear: prevent the certificate from succeeding at the next authentication attempt, and test that result. If the employee already has an active session, decide separately whether your policy requires a session disconnect. That is a network-operations choice, not a substitute for revoking the identity. Also account for fast reconnect behavior and cached sessions during your design and test process. A design that looks correct in a lab can create a blind spot if your production authentication path does not validate the change as intended. The operational checklist for EAP-TLS is straightforward. First, confirm the person's identity record and last working time. Second, disable the source identity. Third, revoke or deny the relevant certificate according to your certificate authority and RADIUS process. Fourth, remove or terminate an active session if your policy requires it. Fifth, attempt a fresh connection with the former employee's managed device or a controlled equivalent. Finally, retain the request, the change, the result, the time, and the accountable owner. The second pattern is iPSK. Instead of one passphrase shared by the whole workforce, each person or device has a distinct key on the same Staff WiFi network. That makes removal targeted. Delete the key associated with the leaver, confirm that a new join attempt fails, and leave every other key unchanged. iPSK can work well where you have devices that cannot use certificates, where a managed-device program is still developing, or where you need a practical transition away from one shared passphrase. iPSK is not the same as a generic staff password with a different name. The key must be tied to one identity or device record. Keep an inventory of the key owner, issue date, device or person association, network role, and removal status. Make the key sufficiently distinct that a deletion event can be traced to the leaver. If the same iPSK is reused by a team, contractor group or shift, you have recreated the shared-secret problem in a smaller container. The third pattern is SCIM-driven deprovisioning. SCIM is a standard HTTP-based protocol for provisioning and managing identity data across systems. In a good joiner-mover-leaver process, HR or IT disables the account in your identity provider, the disabled state flows to the WiFi access service, and a later WiFi authentication is denied. Purple ties WiFi access to the identity provider through SCIM. The relevant identity providers are Microsoft Entra ID, Okta and Google Workspace. The operational benefit is not magic. It is a single source of truth: the event that ends employment also starts WiFi removal. Treat SCIM as a control path, not a slogan. You need a unique identifier that maps the identity-provider account to the WiFi access record. You need an agreed disable event. You need to know what error the receiving service produces when a disable request fails. And you need a test identity that proves your monitoring catches that failure. Now move from design to implementation. Start with an access inventory. List each Staff WiFi network, its security mode, the identity source, the RADIUS path if present, the certificate authority if present, the iPSK owner record if present, the session-disconnect capability, and the log destination. Do this by property group, not as one flattened company list. A hotel, a main street store and a stadium can share policy while using different operational teams and hardware. Next, choose the control that removes the most manual work from the offboarding process. For managed corporate devices, use 802.1X with EAP-TLS where your certificate authority, RADIUS design and device management can support it. For mixed estates and devices that cannot use certificates, use iPSK only when each key is uniquely owned and deletable. For an estate already using Microsoft Entra ID, Okta or Google Workspace, use SCIM-driven deprovisioning to make account disablement the trigger for WiFi removal. Purple can connect that identity event to WiFi access status. Do not add a second manual ticket unless it is an exception path. Build a same-day offboarding runbook. HR confirms the end time. The identity owner disables the account. The network owner confirms the relevant certificate, iPSK or WiFi access record is no longer valid. Operations decides whether an active session needs disconnecting. A named tester performs a fresh authentication attempt. The case closes only when the result is recorded. This is deliberately unglamorous. It is also the part an auditor can reconstruct. For ISO 27001 or SOC 2 evidence, retain a small but complete chain: the authorized offboarding request, the identity provider change, the WiFi change, the verification result, the timestamps and the owner of each step. Avoid collecting more personal data than the control needs. Access records can be personal data, so include them in your retention and access-control decisions. If Staff WiFi can impact payment systems, discuss scope and segmentation with the team responsible for PCI DSS rather than treating WiFi revocation as a standalone compliance claim. Watch for four failure modes. First, a shared password is still in use on an overlooked SSID. Second, the WiFi record is matched to a mutable email address instead of a durable identity. Third, a disable event reaches the identity provider but not the WiFi access service. Fourth, you test only the dashboard state and not a real new join attempt. Each failure mode is preventable if you inventory, monitor and test the control. Rapid-fire questions. Can a shared WPA2 password be revoked for one leaver? No. Rotate it for everyone, or replace it with a per-identity control. How fast can EAP-TLS access be revoked? At the next authentication, provided your certificate and RADIUS validation design recognizes the revocation. Does SCIM remove an active session? Not by itself. Treat session control as a separate operational decision. Is iPSK suitable for every device? No. It is a practical identity-bound key model where certificate authentication is not appropriate. The next step is a short design review. Pick one Staff WiFi network. Follow one leaver event from HR notification to denied authentication. Find the manual step. Then remove it. A WiFi credential should leave when the employee does, not at the next password-rotation project.