কোনো কর্মচারী চলে গেলে কীভাবে WiFi অ্যাক্সেস বাতিল করবেন

Welcome to the Purple Technical Briefing. I'm your host, and today we're tackling one of the most common gaps in enterprise offboarding: what actually happens to WiFi access when an employee leaves? It sounds straightforward. Someone hands in their badge, HR closes their account, and you move on. But if your network still runs on a shared WPA2 password, that person walked out the door still knowing the password. And unless you rotate it for everyone, they can reconnect from the car park. That's the problem we're solving today. We'll cover the three credible models for per-user WiFi revocation, walk through a same-day revocation checklist, and explain exactly what an ISO 27001 or SOC 2 auditor expects to see in your logs. Let's get into it. Section one: why shared passwords are the wrong tool for the job. WPA2-Personal, the standard home-router setup, uses a single pre-shared key. Everyone on the network knows the same password. When one person leaves, that password is still valid on their phone, their laptop, any device they ever connected. The only way to revoke their access is to change the password for the entire network and redistribute it to every remaining user and device. In a hotel with 200 staff, that means updating every point-of-sale terminal, every back-office PC, every manager's phone. In a retail chain with 50 stores, it means a coordinated rollout across every site. The operational cost is high, the disruption is real, and the window between the leaver's last day and the completed rotation is a genuine security gap. PCI DSS, the payment card industry standard, requires you to change shared credentials whenever personnel with knowledge of them leave. So if your tills are on the same network as your staff WiFi, a leaver triggers a compliance obligation, not just a best-practice recommendation. The root cause is simple: a shared password has no identity attached to it. The network cannot distinguish between a current employee and a former one. To fix that, you need per-user credentials. Section two: the three models that actually work. Model one is 802.1X with EAP-TLS certificate-based authentication. This is the gold standard for enterprise WiFi security. In this model, each user or device holds a unique digital certificate issued by your Certificate Authority, or CA. When they connect to the WiFi, the RADIUS server validates that certificate cryptographically. The certificate is tied to an identity, not a password. To revoke access, you revoke the certificate at the CA level. The RADIUS server checks revocation status in real time using OCSP, the Online Certificate Status Protocol. When you mark a certificate as revoked, the next time that device tries to authenticate, the RADIUS server queries the OCSP responder, gets back a revoked response, and sends an Access-Reject to the access point. The device is off the network within seconds of the next authentication attempt. For active sessions, you use RADIUS Change of Authorisation, or CoA, to terminate the existing session immediately. Combined, OCSP and CoA mean you can revoke WiFi access for a leaver in under a minute, with a full audit trail in your RADIUS logs. The challenge with EAP-TLS is the PKI overhead. You need a Certificate Authority, a mechanism to issue certificates to devices, typically via an MDM like Microsoft Intune, and a process to revoke them. For organisations with a mature MDM and identity infrastructure, this is the right answer. For smaller teams or environments with IoT devices that cannot support certificate authentication, you need a different approach. Model two is iPSK, Identity Pre-Shared Key. Cisco calls it iPSK, Ruckus calls it DPSK, Aruba calls it MPSK, but the concept is the same: every user or device gets a unique password, even though they all connect to the same SSID. The RADIUS server maps each unique key to a specific identity and, optionally, to a specific VLAN. When you delete that key from the RADIUS database, the device can no longer authenticate. The blast radius of a leaver is exactly one person. Everyone else's keys remain valid. iPSK is particularly well-suited to environments with mixed device types. IoT devices, point-of-sale terminals, and legacy hardware that cannot support 802.1X certificates can all use iPSK. It is also simpler to operate than a full PKI deployment, making it the right choice for mid-market organisations that need per-user revocation without the infrastructure overhead. The revocation time for iPSK is typically a few minutes, not seconds. The key deletion propagates to the RADIUS server, but active sessions may persist until the device re-authenticates or until you send a CoA packet to force disconnection. Model three is SCIM-driven deprovisioning. SCIM stands for System for Cross-domain Identity Management. It is an open standard, defined in RFC 7643 and RFC 7644, that allows your identity provider to push user lifecycle events to downstream systems in real time. Here is how it works in practice. Your identity provider, whether that is Microsoft Entra ID, Okta, or Google Workspace, is the authoritative source of truth for user accounts. When HR disables a leaver's account in the identity provider, SCIM sends a request to every connected system, including your WiFi management platform. Purple connects to your identity provider via SCIM. The moment you disable a user in Entra ID, Okta, or Google Workspace, Purple receives the SCIM event and revokes their WiFi credentials at the next authentication. The event is logged with a timestamp, the user's identity, and the action taken. That log entry is exactly what an ISO 27001 auditor needs to see. SCIM does not replace 802.1X or iPSK. It sits above them. SCIM handles the identity lifecycle; the authentication protocol handles the network enforcement. The combination of SCIM plus 802.1X gives you automatic, real-time revocation with a full audit trail and zero manual steps. Section three: the same-day revocation checklist. When a leaver's last day arrives, here is the sequence your IT team should follow. Step one: disable the account in your identity provider. This is the trigger for everything else. In Microsoft Entra ID, set the account to disabled. In Okta, deactivate the user. In Google Workspace, suspend the account. Step two: if you are running SCIM, verify the deprovisioning event fired. Check your SCIM logs or your WiFi management platform for the corresponding event. If SCIM is not in place, manually revoke the certificate in your CA or delete the iPSK key from your RADIUS database. Step three: send a RADIUS CoA to terminate any active WiFi session. Most enterprise RADIUS servers, and platforms like Purple, can do this automatically on a deprovisioning event. If you are doing it manually, use your RADIUS server's CoA interface to disconnect the user's device by MAC address or session ID. Step four: confirm no active sessions remain. Check your WiFi controller dashboard. On Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet, you should be able to search by username or device and confirm zero active associations. Step five: archive the audit log entry. Export or flag the RADIUS authentication log, the SCIM event log, and the CoA log for the relevant user and date. Store these in your ITSM or security information and event management platform. ISO 27001 Annex A control A.9.2.6 requires you to remove or adjust access rights of all employees and contractors upon termination. Your log is the evidence. Step six: if you are running WPA2 shared PSK and none of the above applies, rotate the password. Coordinate the rollout across all sites and devices before the leaver's last day if possible, or immediately after. Section four: what the auditor expects. ISO 27001 and SOC 2 both require you to demonstrate that access is removed promptly when employment ends. For WiFi specifically, auditors look for four things. First, a documented offboarding procedure that explicitly includes network access. Second, evidence that the procedure was followed for a sample of leavers, typically ten to twenty-five individuals selected from the past twelve months. Third, a log showing the timestamp of account disable and the timestamp of WiFi access revocation, with the gap between them clearly visible. Fourth, confirmation that no former employee accounts show active WiFi sessions. If you are running WPA2 shared PSK, you cannot produce evidence for items three and four. There is no per-user log. The best you can do is show the password rotation date and argue that it was completed before or on the leaver's last day. Auditors increasingly push back on this. If you are running 802.1X with SCIM, the log is automatic. Purple records every SCIM deprovisioning event with a UTC timestamp, the identity provider source, the user's unique identifier, and the resulting action. That is a clean, auditable record. Section five: implementation pitfalls and how to avoid them. The most common mistake is assuming that disabling an account in the identity provider is sufficient. It is not, unless your WiFi platform is connected to that identity provider via SCIM or a similar real-time integration. Without that connection, the WiFi system has no way of knowing the account was disabled. The second pitfall is certificate caching. Even with OCSP, RADIUS servers cache good responses for a configurable period, typically 15 to 60 minutes. If you revoke a certificate and the RADIUS server has a cached good response, the device may continue to authenticate until the cache expires. Set your OCSP cache TTL to 15 minutes or less for high-security environments. The third pitfall is forgetting active sessions. Revoking credentials prevents new authentications but does not terminate an existing WiFi session. Always send a RADIUS CoA after revoking credentials to disconnect the device immediately. The fourth pitfall is IoT and shared devices. A device registered to a leaver's identity may be a shared workstation or a piece of operational hardware. Before revoking, confirm the device is personal, not shared. If it is shared, re-register it under a service account before revoking the leaver's credentials. Section six: rapid-fire questions. Question: how fast can certificate-based WiFi access be revoked? With OCSP and RADIUS CoA, under 60 seconds from the moment you revoke the certificate at the CA. The OCSP check happens at the next authentication attempt. The CoA terminates the active session immediately. Question: does SCIM work with all WiFi hardware? SCIM operates at the identity management layer, not the hardware layer. Purple is hardware-agnostic and works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. The SCIM integration is with Purple, not with the access points directly. Question: what if we have no MDM and cannot deploy certificates? iPSK is your answer. It gives you per-user revocation without requiring certificate infrastructure. Purple can manage iPSK keys and connect to your identity provider to automate the lifecycle. Summary and next steps. The core message is this: if you cannot revoke WiFi access for one person without affecting everyone else, you have a shared-credential problem. The fix is per-user credentials, either certificates via 802.1X EAP-TLS or unique keys via iPSK, combined with SCIM-driven deprovisioning to automate the revocation the moment HR acts. Purple connects to Microsoft Entra ID, Okta, and Google Workspace via SCIM, runs across 80,000 live venues, and logs every deprovisioning event for audit. If you are preparing for ISO 27001 or SOC 2, or simply want to close the leaver gap before it becomes an incident, that is where to start. For the full technical breakdown of certificate revocation and OCSP, see our guide on OCSP and certificate revocation for WiFi authentication. For the broader joiner-mover-leaver automation picture, see our enterprise WiFi security guide. Thank you for listening to the Purple Technical Briefing.