PPSK usm kubang kerian: comparing features and deployment models

Welcome to the Purple Technical Briefing. Today we are covering PPSK at USM Kubang Kerian - what it is, how it compares to the alternatives, and what a practical deployment actually looks like on a large health sciences campus. Let us start with context. Universiti Sains Malaysia's Health Campus in Kubang Kerian, Kelantan, is one of the most complex WiFi environments you will encounter in South-East Asia. You have a 747-bed teaching hospital, multiple medical and health sciences schools, student accommodation, research laboratories, and clinical facilities - all on a single campus, all sharing the same physical network infrastructure. The user population spans medical students, clinical staff, administrative teams, visiting researchers, patients, and their families. The device population is even more varied: managed laptops, personal phones, medical equipment, IoT sensors, CCTV systems, and smart building controllers. The question every IT director at a campus like this eventually faces is: how do you give each of those user groups a secure, isolated network experience without deploying a separate SSID for every segment? Because if you do that - if you broadcast eight or ten SSIDs across a campus of this scale - you degrade WiFi performance for everyone. Every SSID consumes airtime for beacon frames. In a dense environment, SSID proliferation is a performance killer. The answer, increasingly, is PPSK. Private Pre-Shared Key. And that is what we are going to unpack today. So what is PPSK, exactly? It is a WiFi authentication model in which each user, each device group, or each department gets its own unique pre-shared key. They all connect to the same SSID - the same network name - but each key maps to a separate VLAN. The access point handles the key-to-VLAN mapping automatically. The terminology varies by vendor, and that causes genuine confusion in the market. HPE Aruba calls it PPSK - Private Pre-Shared Key. Cisco Meraki calls it iPSK - Identity PSK. Juniper Mist uses ePSK. Ruckus calls it DPSK - Dynamic PSK. Extreme Networks, who developed the concept under the Aerohive brand, call it Private PSK. Ubiquiti UniFi simply calls it PPSK. The underlying mechanism is identical: one SSID, multiple unique keys, each key tied to a VLAN or a policy group. Now, let us compare PPSK against the two alternatives you will most commonly be asked about. The first is standard PSK - one shared password for the entire network. This is what most legacy campus deployments still run. It is simple to deploy, but it is a single point of failure. One compromised password means the entire network is exposed. You cannot revoke access for a single user without changing the password for everyone. At a campus with thousands of users, that is simply not manageable. The second alternative is 802.1X Enterprise - the gold standard for corporate device authentication. 802.1X uses a RADIUS server, an identity provider such as Microsoft Entra ID, Okta, or Google Workspace, and a supplicant on every device. That supplicant is the software component that handles the EAP authentication exchange. Every managed laptop has one. Your student's smart fridge does not. Your clinical IoT sensor does not. Your building management controller does not. 802.1X is the right answer for staff networks and managed device fleets. It is the wrong answer for IoT devices, personal devices, and the kind of mixed-use environment you find on a health sciences campus. PPSK sits in the middle. It gives you per-user isolation and VLAN assignment without requiring certificate infrastructure or a supplicant on every device. It works with any WiFi-capable device, including legacy medical equipment that cannot support WPA Enterprise. That is its key advantage in a healthcare and education environment. Let us look at the technical authentication flow. When a device connects to the SSID, it presents its pre-shared key during the WPA2 four-way handshake. The access point - or the cloud controller behind it - looks up that key in the PPSK store, identifies which VLAN it maps to, and tags the device's traffic accordingly from that point forward. The device sees a normal WiFi connection. It has no idea it has been placed in an isolated segment. Its applications work. Its services pair. Everything behaves as expected. In a RADIUS-backed deployment - which is what Purple recommends for any campus above 200 concurrent users - the controller queries an external RADIUS server for each new connection. The RADIUS server returns an Access-Accept response containing both the key validation and the VLAN assignment. This gives you centralised logging, audit trails, and the ability to revoke access instantly by removing the key from the RADIUS store. The device is disconnected at next re-authentication. No manual intervention at the access point level required. Now let us talk about deployment models, because there are three distinct approaches in production today, and the right choice depends on your campus size, your IT resource, and your existing hardware. The first is controller-local PPSK. The unique keys are stored directly on the wireless controller, with no external RADIUS server required. This works for smaller deployments - up to around 200 concurrent users - and it is the simplest to operate. Ubiquiti UniFi supports this natively. The limitation is scalability. Most controllers cap out at a few hundred local PPSK entries, and you lose the centralised lifecycle management that makes PPSK operationally viable at scale. For a campus the size of USM Kubang Kerian, this model is not appropriate. The second model is RADIUS-backed PPSK. The keys are stored in an external RADIUS server, and the controller queries the RADIUS server for every new connection. This scales to thousands of users. Ruckus SmartZone, HPE Aruba ClearPass, and Cisco ISE all support this model. The operational overhead is higher, but the scalability and lifecycle management capabilities are significantly better. This is the right model for a large campus deployment. The third model - and the one Purple recommends for institutions without dedicated RADIUS infrastructure - is cloud RADIUS as a service. The RADIUS infrastructure is hosted and managed externally, and you connect your access points to it via a cloud overlay. Purple's platform sits on top of your existing hardware - whether that is Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet - and provides the orchestration layer for key provisioning, lifecycle management, and user onboarding. The key lifecycle is fully automated. A student enrols, their key is provisioned via the student management system integration. They graduate or withdraw, their key is revoked instantly. No manual intervention, no security gaps. For USM Kubang Kerian specifically, the recommended architecture is a hybrid model: PPSK for students, residents, and IoT devices, with 802.1X for clinical staff and administrative teams using managed devices. Three distinct authentication models, three distinct VLAN segments, one physical infrastructure. Students on VLAN 10 through whatever the cohort size requires. Clinical staff on 802.1X against the university's identity provider. IoT and building management systems on a dedicated IoT VLAN with egress filtering. Guest WiFi in public areas via a captive portal on a separate VLAN. One critical constraint to flag before you specify hardware: Ubiquiti UniFi's PPSK implementation is currently WPA2 only. If you are deploying WiFi 6E access points and want to use the 6 gigahertz band for PPSK clients, you need a platform that supports WPA3-SAE with PPSK - Aruba, Ruckus, and Meraki all support this. The 6 gigahertz band is exclusive to WPA3, so any PPSK deployment on 6 gigahertz requires WPA3-SAE compatibility. Plan for this in your hardware specification before you commit to a vendor. Let me walk through the implementation pitfalls, because these are the failure modes I see repeatedly in production deployments. The first is SSID proliferation. Every SSID you broadcast consumes airtime for beacon frames. In a dense campus environment, if you are broadcasting six or eight SSIDs per access point, you are degrading performance for everyone. Keep it to a maximum of four SSIDs per radio. Use PPSK to serve multiple user segments from a single SSID rather than creating a separate SSID per department or per floor. The second pitfall is insufficient trunk port configuration. You design a clean VLAN scheme, you deploy the access points, and then traffic silently drops because someone forgot to permit the relevant VLANs on a trunk link between the distribution switch and the access layer. Validate every trunk port during commissioning. Document it. Test it with a device on each VLAN before users go live. The third pitfall is MAC address randomisation. Since iOS 14, Android 10, and Windows 11, devices use randomised MAC addresses by default for privacy reasons. If your RADIUS server is doing a MAC lookup and the device presents a randomised address, the lookup fails and the device cannot connect. The solution is to configure your SSID to request that clients use their permanent hardware MAC address, or to implement a pre-registration workflow where users register their device before connecting. Purple's platform handles this automatically as part of the user onboarding flow. The fourth pitfall is key distribution. Generating keys is straightforward. Getting them to users in a way that is secure and operationally manageable is harder. A QR code in the welcome pack works well for move-in day. A self-service portal where users can retrieve their key and add new devices is better for ongoing operations. Build the key distribution workflow before you deploy, not after. Now let us look at two real-world scenarios that are directly relevant to a campus like USM Kubang Kerian. Scenario one: a 400-bed purpose-built student accommodation block. The challenge is annual cohort turnover. Every academic year, hundreds of students move out and hundreds of new students move in, often within the same week. With a shared PSK model, that means a building-wide password rotation affecting every returning resident. With PPSK, it means revoking the outgoing cohort's keys and provisioning new ones for the incoming cohort - all automated via the student management system integration. One operator using this model reported a 70% reduction in WiFi-related support tickets in the first term, primarily because the device pairing issues that had plagued the previous shared PSK deployment were completely eliminated. Scenario two: a clinical research facility with mixed device types. The challenge here is supporting both managed clinical workstations on 802.1X and legacy medical equipment that cannot support WPA Enterprise. The hybrid model - 802.1X for managed devices, PPSK for legacy and IoT equipment - solves this without requiring separate physical infrastructure. Clinical workstations authenticate via EAP-TLS against the university's identity provider. Legacy equipment gets a dedicated PPSK key mapped to a restricted VLAN with egress filtering to the clinical systems it needs to reach, and nothing else. The security posture is maintained. The operational complexity is manageable. Let me give you three practical rules of thumb before we move to the rapid-fire questions. Rule one: if your campus or building has more than 200 concurrent users, use RADIUS-backed PPSK, not controller-local PPSK. The scalability ceiling of controller-local PPSK will cause you problems within 12 months of go-live. Rule two: plan for MAC address randomisation from day one. Build a pre-registration workflow into your user onboarding process. Do not assume devices will present their permanent MAC address by default. They will not. Rule three: automate the key lifecycle. The operational value of PPSK over a shared PSK is entirely dependent on keys being provisioned and revoked automatically. Manual key management at scale is not viable. Integrate with your student management system or HR system from the outset. Right. Rapid-fire questions. These are the ones that come up most often. Does PPSK work with WPA3? Yes, on most enterprise platforms. WPA3-SAE provides stronger protection against offline dictionary attacks compared to WPA2-PSK, so deploying PPSK on WPA3 where your client devices support it is the right approach. The exception is Ubiquiti UniFi, which is currently WPA2 only for PPSK. How many PPSK keys can a single SSID support? With an external RADIUS server, the practical limit is your RADIUS database capacity. Cisco Meraki supports up to 5,000 iPSK entries per network. Purple's cloud RADIUS service scales to tens of thousands of concurrent keys. Is PPSK a replacement for 802.1X? No. For fully managed corporate device fleets where individual accountability and certificate-based authentication matter, 802.1X is still the right answer. PPSK is the right answer for IoT devices, personal devices, and mixed-use environments where 802.1X is impractical. Can I integrate PPSK with my student management system? Yes, through the vendor's API. Aruba Central, Meraki, Ruckus, and Mist all expose REST APIs for PPSK key management. Purple's platform provides pre-built integrations that automate provisioning and revocation based on enrolment status. To summarise. PPSK is the right authentication model for a complex, mixed-use campus like USM Kubang Kerian. It gives you per-user isolation and VLAN assignment without requiring certificate infrastructure on every device. The hybrid model - PPSK for students and IoT, 802.1X for staff - is the architecture that delivers both security and operational simplicity at scale. Automate the key lifecycle from day one. Plan for MAC randomisation. Keep your SSID count below four per radio. And if you are deploying at scale, use a cloud RADIUS service rather than managing the infrastructure yourself. That is the Purple Technical Briefing on PPSK for USM Kubang Kerian. If you want to go deeper on any of these topics, the full written guide is available at purple.ai. Thanks for listening.