Auto-revocation: The WiFi feature that closes the deal

Education is one of the strongest verticals for Purple Staff WiFi. Schools and universities carry a specific set of network problems that generic enterprise WiFi solutions don't solve well: a rotating cast of staff, students, contractors, and personal devices, all sitting on the same network with wildly different access needs. This guide walks through why that creates opportunity for partners, and how Purple addresses each pain point directly. Why Education Is Different Most IT managers at schools and universities will tell you the same things. Their networks were built for a simpler time. Shared passwords get passed around. Ex-employees still have access weeks after they leave. The IT team spends a disproportionate amount of time dealing with WiFi tickets that have nothing to do with actual infrastructure problems. But the real issue is structural. Education environments typically run three or four distinct user groups on the same physical network: permanent teaching staff, support staff, short-term contractors or supply teachers, and students. Each group has different access requirements, different devices, and different risk profiles. Most traditional WiFi setups treat them the same. That mismatch is where Purple Staff WiFi fits. The 4 problems worth talking about with education prospects 1) BYOD chaos Staff bring their own laptops, tablets, and phones. IT has no control over what lands on the network, and shared WPA2 passwords mean the credentials are effectively public within weeks of being issued. Purple replaces the shared password with a certificate-based WiFi pass that's tied to the individual. Each staff member authenticates through their existing Microsoft Entra ID, Google Workspace, or Okta login and gets a credential that's specific to their device. It can't be forwarded in a WhatsApp group or written on a sticky note in the staffroom. Once the certificate is provisioned, the device connects automatically across the whole campus without any repeated logins. That covers the roaming problem too, which matters on large sites like universities where a lecturer might move between buildings multiple times in a day. 2) Contractor and temporary staff access Supply teachers, visiting lecturers, construction crews, cleaning contractors. Education sites run on a steady flow of people who need temporary network access, then shouldn't have it anymore. This is where most IT teams lose time. Someone leaves, a ticket gets raised, someone forgets to revoke the credential. The window between departure and access removal is a real security gap. Purple handles this through SCIM integration with the identity provider. When a staff member or contractor is disabled in the IdP, their network access is revoked at the same time. There's no separate step, no ticket queue, no manual process. Access ends when the person does. For contractors who don't have a school-issued identity, Purple's iPSK (Unique Identity Pre-Shared Keys) option gives them a credential that's specific to them without needing the full app setup. It's still individual and auditable, unlike a shared guest password. 3) Compliance Pressure Schools and universities sit under GDPR and, in many cases, sector-specific safeguarding requirements around student data. Network access logs matter. Knowing who was on the network, when, and from which device is part of demonstrating compliance. With a shared password setup, none of that is possible. You know a device was connected, not who was using it. Purple ties access to a verified identity from the start. That means IT can run a report showing that a specific staff member's device was on the network at a specific time. For safeguarding audits or data breach investigations, that's the difference between having an answer and not having one. 4) IT capacity Most school IT teams are small. Universities are bigger, but still stretched. WiFi support tickets are a time drain, and most of them stem from the same root causes: someone can't connect, a device switched and the credential doesn't work, someone changed their password. Purple's onboarding flow is self-service. Staff download the app, authenticate with their SSO credentials, and get connected. No helpdesk involvement required in the typical case.  Organisations using Purple report up to an 80% reduction in WiFi-related IT support requests. For a school IT team of two or three people, that's a meaningful shift in how they spend their days. What's already built In (no custom work required) Part of the pitch for education partners is that Purple doesn't require institutions to rip out their existing infrastructure. It works with any network hardware that supports RADIUS authentication: Cisco, Aruba, Ruckus, Ubiquiti, and others. That removes the "but we just invested in our access points" objection. The features most relevant to education come standard: SSO integration with Microsoft Entra ID, Google Workspace, and Okta. Most schools and all universities already use one of these. Automated SCIM provisioning and deprovisioning. Access aligns with the IdP automatically. Cross-platform device support. Windows, macOS, Linux, iOS, Android. Also headless devices like printers and lab equipment via iPSK. Analytics and occupancy data. Dashboards showing attendance patterns and space usage. Some organisations have cut estate costs by up to 35% using this data to consolidate underused facilities. Staff communication tools. Role-based or location-based messages and surveys pushed through the WiFi connection. Useful for shift updates, policy reminders, or staff surveys without needing a separate app. How to position this with education IT and finance teams IT teams respond to the security and workload arguments. Lead with the shared password risk, the offboarding gap, and the support ticket reduction. Those are problems they already know they have. Finance and operations teams care about compliance exposure and estate costs. The GDPR and safeguarding angle lands well when framed around audit readiness: can you prove who was on your network and when? The occupancy analytics case is worth raising with universities specifically, where underused buildings are a real cost. Procurement teams in education often push back on vendor lock-in. The vendor-agnostic infrastructure point addresses this. Purple sits on top of whatever hardware the institution already has. There's no forced migration. The honest sales cycle Education procurement moves slowly. Budget decisions often align with the academic year, and IT projects compete with everything else on the capital expenditure list. But the pain is consistent and well understood by anyone who's worked in school or university IT. The strongest conversations start with a specific problem, not a product overview. Ask about their current offboarding process. Ask how they handle contractor WiFi access. Ask when they last audited who had network credentials. Those questions surface the gaps, and Purple's features map directly onto the answers. For partners, education is a vertical worth building a pipeline in. The problems are structural, not seasonal. And institutions that solve them tend to stay solved: Purple's automated lifecycle management means the IT team doesn't have to keep revisiting the same issues every term.

When a contractor walks onto your site on day one, they need network access. When their contract ends six weeks later, that access needs to go away. Simple in theory. In practice, most businesses handle this badly. A shared password gets handed over on a sticky note. The contractor leaves. The password doesn't change. Six months later, someone wonders why an unknown device is still showing up on the network. Purple's Staff WiFi solves this without extra admin work. Here's how. The problem with temporary access today Most Guest WiFi setups weren't designed for time-limited staff. You're choosing between two bad options: 1) Put them on the regular staff network, where you have to manually remove them when they leave. That depends on someone remembering to do it. 2) Put them on the Guest WiFi alongside actual visitors, where they share bandwidth, get no role-based access, and you lose any visibility into who's who. Neither option works well for contractors, seasonal workers, or event crew who need more than guest-level access but shouldn't have permanent credentials. How Purple handles it differently Purple ties network access to identity, not passwords. When a contractor is added to your identity provider (Microsoft Entra ID, Google Workspace, or Okta), Purple picks that up through a SCIM integration and provisions them a certificate-based WiFi pass. They authenticate once through the Purple app and connect without typing a password. That WiFi pass is personal and unshareable. It works on their device and only their device. It follows them across your entire site without re-authentication, which matters on large estates or multi-building campuses. The automatic offboarding part This is where it actually gets useful for contractors. When a contractor's end date arrives and they're disabled in your identity provider, the SCIM integration catches that change immediately. Their access is revoked. No IT ticket required. No one has to remember. Time-limited credentials without extra setup Some contractors don't have a company device and won't be added to your identity provider at all. Purple handles this with Unique Identity Pre-Shared Keys (iPSK). These are individual credentials issued per device, not shared passwords. The difference between an iPSK and a regular shared password: if one iPSK gets compromised, you revoke that one credential. The rest of the network is unaffected. With a shared password, everyone's affected the moment it leaks. What you actually see on your end Purple gives you dashboards that show who's on the network, when they connected, and from where. For IT teams managing contractors across a large site, that's the audit trail you need. You can see that a specific contractor connected on Tuesday at 9am and disconnected at 5pm, rather than just seeing an anonymous device. That visibility also feeds into space utilisation. If you can see that a contractor team only uses two out of five rooms in a building, that's data you can act on. Works with whatever hardware you already have Purple doesn't require you to replace your existing network infrastructure. It uses RADIUS authentication, which is supported by Cisco, Aruba, Ruckus, Ubiquiti, and most enterprise-grade access points. You're not locked into a specific hardware vendor. The short version Contractor arrives, gets added to your identity provider, gets a personal WiFi pass through the Purple app. Contractor leaves, gets disabled in your identity provider, loses access automatically. No manual steps. No tickets. No lingering credentials.  For businesses that rotate temporary staff regularly, that's a meaningful reduction in security risk and admin overhead.

The IT manager across the table from you isn't trying to be difficult. They're cautious — and for good reason. They've sat through vendor pitches that promised transformation and delivered headaches. They manage networks that keep the business running, and they're not about to let a slick sales deck convince them to risk that. So when you walk in talking about passwordless WiFi and identity-based networks, this guide gives you the conversation structure and the responses to handle it. Understand what you're actually selling Before you address a single objection, get clear on what Purple actually is — because "passwordless WiFi" undersells it. Purple staff WiFi Purple’s staff WiFi is a cloud-native authentication platform that connects an organisation's existing identity systems (Microsoft Entra ID, Google Workspace, Okta, or any SAML/OIDC provider) directly to their WiFi network. When someone joins the company, they get WiFi access automatically. When they leave, it's revoked instantly. No shared passwords. No captive portals. No manual intervention. No on-premise RADIUS servers to buy, host, or maintain. The core pitch to your IT manager contact is simple: they've probably already invested heavily in identity management. Purple makes their WiFi work the way the rest of their security stack already does. The objection playbook "We already have a system that works." What they mean: Change is risky, and I don't see enough pain to justify the disruption. What to say: Ask them to define "works." Does it mean staff share a WiFi password that's been the same for three years? Does it mean guests sit through a captive portal that 40% abandon before connecting? Does it mean when someone leaves the company, IT manually revokes their access — if they remember? None of that "works" from a security or efficiency standpoint. It's just familiar. The point isn't to embarrass them. It's to surface pain they've normalised. Shared passwords with no visibility into who's actually on the network is a genuine security gap. Manual offboarding is a compliance risk. Captive portals are friction that costs venues real engagement. "802.1X is too complex to deploy at scale." What they mean: I've tried certificate-based authentication before and it was a nightmare. What to say: They're right that traditional 802.1X deployments are painful — certificate management, PKI infrastructure, device enrolment. Purple removes that entirely. The Purple app handles credential provisioning on the user's device. Staff authenticate once via their familiar SSO login and Purple takes care of everything else. No certificate infrastructure. No manual device configuration. "We don't want to replace our existing infrastructure." What they mean: We've spent real money on Cisco/Aruba/Ruckus kit and I'm not ripping it out. What to say: They don't have to. Purple is vendor-agnostic and works with any 802.1X-compatible access point. Cisco Meraki, Aruba, Ruckus, Juniper Mist, UniFi — Purple sits on top of what they already have. This isn't a forklift upgrade. It's an authentication layer that makes their existing infrastructure significantly more intelligent. "How do we know who's on the network at any given moment?" What they mean: I need visibility and control, not just authentication. What to say: Because every connection is tied to a verified identity, the network becomes a source of real intelligence. IT can see who is connected, from which device, at which location, and when — in real time. When someone leaves the organisation and their account is deprovisioned in the identity provider, their WiFi access is revoked automatically via SCIM sync. No manual steps. No lag. For compliance teams, this means complete access logs tied to verified identities, not just IP addresses. The conversation structure that works Start with their problem, not your product. Ask how they currently handle WiFi access for new starters. Ask what happens to someone's network access on their last day. Ask how they manage guest WiFi. Let the gaps surface naturally. Validate before you pivot. When they describe their current setup, acknowledge it genuinely. "That's a common approach — a lot of IT teams we work with were doing the same thing." This lowers defensiveness before you introduce an alternative. Position Purple as additive, not disruptive. It works with their existing directory, their existing access points, and their existing SSO. The ask is not to change their infrastructure. The ask is to make it smarter. Bring in the three use cases as appropriate. Staff WiFi (passwordless zero-trust with automatic provisioning), Guest WiFi (Passpoint-based, no captive portal), and Multi-Tenant (private micro-segments for residents with iPSK). Different IT managers will feel the pain in different places — follow their concern. The IT manager who pushes back hardest is often the one who, once convinced, becomes the most vocal internal champion. Earn their trust with specifics, not superlatives, and the close usually follows.

Zero trust is a framework that more and more organisations are committing to as a strategic security direction, but its application to WiFi is often an afterthought. Understanding how identity-based networking maps to zero trust principles gives you a stronger footing in security-led conversations and helps you meet buyers where they already are. The core idea Zero trust is built on a straightforward premise: access to any resource should never be assumed based on network location alone. Instead, every connection request is evaluated against verified identity, device context, and policy — continuously, not just at the point of entry. For WiFi, this raises a direct question that's worth putting to prospective customers: does your wireless network actually know who's on it? If the answer involves a shared password, or a captive portal that collects an email address and waves users through, the answer is effectively no, and that's a meaningful gap in any zero trust posture. Where legacy WiFi authentication falls short Zero trust requires three things that traditional WiFi authentication struggles to deliver: 1) Verified identity at the point of connection. Shared passwords don't identify individuals. When multiple people use the same network key, the network sees a set of anonymous, indistinguishable connections. There's no audit trail, no visibility, and no way to apply policy at the user level. 2) Context-aware, least-privilege access. A visitor connecting at a reception area shouldn't have the same level of access as a full-time member of staff at their regular desk. Zero trust demands that access rights reflect who someone is and where they are — dynamically and automatically, not as a manual configuration exercise. 3) Immediate revocation when circumstances change. If a user account is suspended or a contractor's engagement ends, their network access should end at the same moment — not when someone gets around to updating a spreadsheet. Delayed revocation is one of the most common and easily overlooked gaps in real-world security posture. How Identity-Based WiFi maps to Zero Trust The shift from password-based WiFi to an identity-first approach is, in practical terms, the application of zero trust to the wireless layer. Here's how the principles translate: Continuous verification becomes per-user, per-session authentication. Each connection is tied to a live identity verified against your customer's directory. When that identity changes (a role change, a suspension, a departure) network access updates automatically, with no manual step required. Least-privilege access becomes network segmentation driven by identity. Employees, contractors, and guests can each receive different levels of access, governed by the same policies that apply elsewhere in the organisation. That consistency is what zero trust actually looks like in practice. Assumed breach, minimised impact becomes meaningful isolation between user groups. When each person's access is scoped to what they actually need, the potential blast radius of any single compromised credential is contained by design. The questions worth raising In conversations with prospective customers, it's often more effective to surface the gap than to lead with a solution. A few questions that tend to prompt useful reflection: "If a contractor's access needed to be revoked today, how long would that take — and is there any manual step involved?" Most organisations have at least one. "Your team has invested in directory management and single sign-on. Is your WiFi authentication connected to any of that infrastructure?" The identity stack often exists in one place; WiFi lives somewhere else entirely. "Can you tell me, right now, exactly who is connected to your guest network?" With a shared password and no identity layer, this is genuinely unanswerable. "What actually happens to someone's network access when their account is suspended in your directory?" The gap between "it gets revoked automatically" and "someone needs to action that" is exactly where zero trust WiFi adds value. Beyond security: The operational case Positioning zero trust WiFi purely as a security measure undersells it. When every connection carries a verified identity, the network generates a level of intelligence it simply didn't before. Occupancy patterns become reliable and attributable. Device usage becomes visible and auditable. IT teams can demonstrate compliance with complete access logs tied to real identities rather than anonymous sessions. And the elimination of manual provisioning and revocation processes reduces overhead in ways that resonate with operations leads as much as security teams. That breadth matters when positioning the conversation. Zero trust WiFi isn't a discussion that belongs only in the security team's meeting room. 

Walk into almost any organisation and the WiFi setup tells the same story: a password on a sticky note, a portal nobody finishes, and an IT team fielding the same access requests they were fielding five years ago. The sector changes — corporate office, student accommodation, hotel, hospital — but the underlying problems don't. That consistency is exactly why Purple's solutions translate so cleanly across verticals, and why the partner conversation tends to follow a similar shape regardless of who you're selling into. There are three problems that come up again and again. Understanding them, and being able to articulate them in client terms, is the foundation of a good conversation when it comes to Purple's identity-based networks. Problem 1: Shared passwords Shared credentials are the path of least resistance, and most organisations have been following that path for years. The password goes on the onboarding sheet, the welcome card at reception, the sign behind the café counter. It gets shared freely by design, and then further than intended because there's no mechanism to prevent it. The consequences vary by sector but the root cause is consistent. A corporate IT team has no real visibility into who's on their network — only what devices have connected. A student accommodation provider can't stop former residents passing credentials to friends who moved out months ago. A hospitality group can't prevent guests extending their WiFi access well beyond checkout. In every case, shared passwords mean anonymous connections, and anonymous connections mean no control over who's actually on the network or what they're doing there. The Purple solution to shared passwords Purple replaces shared passwords with identity-bound credentials. Staff are provisioned through their organisation's directory. Guests and residents receive unique credentials generated at the point of authentication. There's nothing to share because the credential only works for the person it was issued to. Purple also offers private micro-segments for students, hotel guests, and residents. Identity PSK gives each person their own network space where their devices can discover each other—AirPlay, Chromecast, smart speakers—while remaining completely isolated from neighbours. Problem 2: Leavers staying connected When a password is shared across the whole organisation, removing one person's access means disrupting everyone else's. When access is managed manually, it depends on someone doing the right thing at the right time — and that doesn't always happen. The implications play out differently depending on the context. For a corporate client, a former employee retaining network access after leaving is a security exposure that most IT policies explicitly prohibit, but few have a clean technical answer to. For a university, thousands of student accounts cycling in and out each academic year creates a deprovisioning workload that manual processes can't reliably handle. For a hotel or serviced apartment operator, guests who remain connected after checkout represent both a revenue and a network integrity issue. The Purple solution to leavers staying connected Because Purple ties access to a verified identity rather than a shared secret, deprovisioning happens automatically. For staff environments, it syncs with the identity provider — remove someone from the directory and their network access is gone. For guest and residential deployments, access is scoped to the duration of the stay from the outset. No manual process, no risk of it being overlooked, no collateral disruption to anyone else. Problem 3: A poor user experience The captive portal is the most familiar symptom of a network that doesn't know who its users are. Every sector has its version: the business traveller trying to get online in a hotel room at 11pm, hunting for a confirmation email with their access code. The conference delegate clicking through a terms page on a phone screen. Completion rates on captive portals are low, which means businesses often aren't capturing the visitor data the portal was supposed to collect. The security benefit is minimal. And the friction, however familiar, still generates complaints and support overhead. The Purple solution to a poor user experience Purple removes the friction. Guests and residents authenticate without portals or forms — the process runs in the background using Passpoint and OpenRoaming, standards already built into the devices your clients' users are carrying. It connects the way a mobile network does: without asking anything of the person using it. Enterprise security without the complexity To summarise, Purple's identity-based network platform addresses three distinct scenarios, each with its own requirements but sharing a common foundation: 1) Staff WiFi: Passwordless zero-trust access for employees, with automatic provisioning and revocation tied to your directory. 2) Guest WiFi: Frictionless visitor access that eliminates captive portals while maintaining security and compliance. 3) Multi-Tenant: Private network experiences for residents in student accommodation, hotels, and multi-dwelling units. One identity. Three use cases. Enterprise security without the complexity.

What Is Identity-Based Networking? Traditional network security focuses on the network itself: firewalls, VLANs, access points. This made sense when networks had clear boundaries and users sat at fixed desks. Today, the perimeter has dissolved. Users move between locations, devices multiply, and the workforce extends beyond employees to contractors, visitors, and residents. The network boundary is no longer a useful security concept. Identity-based networking inverts the model. Instead of asking "is this device on the right network?", we ask "who is this person and what should they be able to access?". Your existing identity provider becomes the source of truth. Your directory becomes the network policy engine. Purple is the cloud-native platform that makes this possible across three use cases: Staff WiFi for passwordless employee access, Guest WiFi to eliminate captive portals, and Multi-Tenant for private network experiences in student accommodation, hotels, and residential properties. Full technical detail on each is covered in the dedicated IBN articles. Talking to Clients The technology is straightforward once clients understand the problem it's solving. The key is to lead with their frustration, not with the product. Most people haven't articulated their WiFi pain — they've just accepted it. A good opening question does the work of surfacing it. Once they've described the problem, your job is to connect it to a concrete outcome: faster provisioning, instant revocation, no more portals, devices that just work. Clients don't need to understand RADIUS or 802.1X to see the value — they need to picture what life looks like when the problem is gone. Staff WiFi The people you're talking to here are usually an IT Manager or Head of IT. Their pain tends to sit in one of three places: 1) The overhead of manually provisioning and deprovisioning access 2) The risk of shared passwords that never quite get changed 3) Acompliance requirement that's forcing the issue. A good opening question is: "When someone leaves your organisation, how long before their WiFi access is revoked?" Most can't give a clean answer — and the uncertainty alone signals the problem. A follow-up that lands well is: "Is there a WiFi password written on a whiteboard anywhere in your office right now?" It usually gets a laugh, and immediately makes the shared-credential problem feel real. From there, the key things to communicate are: every employee gets their own unique credentials rather than a shared password; provisioning and deprovisioning happen automatically in sync with their directory; and the network maintains a full audit trail of who connected, when, and from where. If they're already using Entra ID, Okta, or Google Workspace, that's worth calling out directly — Purple connects natively to all of them, so the identity foundation is already there. Guest WiFi Here you're often talking to IT alongside someone from marketing, operations, or the business side — because the captive portal problem is both a technical and an experience issue. The question that opens this conversation well is: "What percentage of your guests do you think actually complete your current WiFi sign-in process?" Most overestimate. Guests often get frustrated by captive portals, and give up connecting to the WiFi altogether. The outcome to paint for them is straightforward: guests connect automatically and securely, with no form, no redirect, and no friction — but the client still gets compliant consent records and access logs. It's worth being direct that killing the captive portal doesn't mean losing the data it was supposed to capture; it means capturing it properly. For guests who are new to Purple-enabled venues, onboarding is handled through the Purple app. For repeat visitors anywhere in the Purple network, connection is completely seamless. Multi-Tenant Your contact here is usually a Property Manager, Head of Residence, or Operations lead. The trigger for this conversation is almost always the same: residents complaining they can't connect smart TVs, games consoles, or AirPlay — or IT fielding support calls about device pairing. Ask: "Do your residents ever raise issues about connecting their smart devices to the network?" It's rarely a no. The follow-up is: "And how do you handle it when a resident shares their password, or when someone leaves and the credentials need changing?" That surfaces both the experience problem and the operational one. What to communicate: each resident gets their own private network segment on the shared infrastructure, so their devices can discover each other just like on a home network, but they're completely invisible to their neighbours. When a resident leaves, their access is revoked automatically. No shared passwords, no support calls about device pairing, no manual credential management. The "private home network on shared infrastructure" framing tends to click immediately with property and ops people — it describes exactly what they want without requiring any technical context. Moving the conversation forward The goal of the first meeting isn't to close — it's to identify which use case resonates most and earn a follow-up with the right people in the room. If they're nodding at the provisioning problem, suggest a call with their IT lead. If the portal abandonment number landed, propose including whoever owns the guest experience. If it's a multi-tenant property, a short pilot on one building or floor is usually an easy yes. The strongest readiness signal across all three use cases is that they already use an identity provider. If they do, the hard work is already done on their side — and that's worth saying out loud. 

The problems with traditional WiFi For staff The most common setup you'll encounter is a shared pre-shared key, or PSK. There's one WiFi password, everyone knows it, and the network works. It's simple, easy to set up, and your customers have probably been using the same approach for years without an obvious incident. The trouble is that "no obvious incident" isn't the same as "no incident." With a shared password, every single person on the network is indistinguishable from every other. There's no way to know which device belongs to whom, no way to see what any individual user is doing, and no audit trail if something goes wrong. If a device is compromised, there's no way to isolate it without disrupting everyone. If an employee leaves, the only way to remove their access is to change the password for the entire organisation — every printer, every phone, every laptop in the building, updated manually. This isn't a theoretical risk. It's the operational reality of most small and medium businesses, and it's why a single disgruntled ex-employee or a lost laptop can expose an entire network. For guests Captive portals — the login pages we commonly see in hotels, cafes, and offices — solve one narrow problem: they create a record of who accessed the network at a given time. On the surface, that feels like security. In practice, it falls well short. Once a user is past the login page, their traffic is typically uncontrolled and often unencrypted. The portal itself can become a security liability — users conditioned to enter credentials on any page that looks like a login screen are easy phishing targets. And the experience is poor. Guests fill in forms, confirm email addresses, agree to terms and conditions, and still find themselves kicked off the network an hour later and forced to do it all again. Every reconnection is friction. Every friction point is a reflection on the organisation providing it. For organisations that need to demonstrate controlled access to auditors or regulators, a captive portal log is also a thin evidential basis. It records that someone with a particular email address clicked through a portal. It says nothing meaningful about what happened on the network after that. For residents in multi-tenant environments The problems compound in multi-tenant environments — hotels, student accommodation, co-working spaces, and residential buildings. Here, the shared infrastructure model doesn't just fail on security grounds; it fails on the most basic expectation of the people using it. When everyone in a building shares the same network, devices can see each other. A student in one flat can potentially see the devices of the student next door. A hotel guest's laptop sits on the same logical network as every other guest. This isn't an abstract threat — it's a routine consequence of shared WiFi architecture, and it's the reason residents and guests frequently report feeling that the provided network isn't trustworthy enough for personal use. The workaround most providers reach for is client isolation, which prevents devices from communicating with each other entirely. That solves the privacy problem, but creates a new one: it also prevents the resident's own devices from talking to each other. Their phone can't cast to their TV. Their laptop can't connect to their printer. The smart home devices they've brought with them stop working as intended. The network feels broken, because for their purposes, it is. The solution: Identity-based networking IBN changes the fundamental model. Instead of one password that everyone shares, every user and every device gets its own unique credential tied to a verified identity. The network knows who is connected at all times and can apply the right policies automatically — without making users do anything complicated. For staff For staff networks, IBN means provisioning and revocation are tied directly to your client's identity directory — whether that's Microsoft Azure AD, Google Workspace, Okta, or another provider. When someone joins the organisation, their network access is created automatically. When they leave, it's revoked instantly, affecting only them, with no disruption to anyone else and no manual intervention required. The day-to-day experience for staff also improves. With certificate-based IBN, devices authenticate automatically in the background after initial setup. There's no password to remember, no login page to navigate, and no re-authentication interrupting a working day. Staff simply connect — and the organisation has a complete, per-identity audit trail showing who accessed the network, from which device, and when. For guests For guest networks, IBN makes the captive portal unnecessary. Rather than asking visitors to fill in a form and click through a login page, guests with a compatible device connect automatically and securely the moment they're in range of an enabled network. Authentication happens in the background, using credentials provisioned through the Purple app. The guest doesn't notice it happening, because there's nothing for them to do. For residents in multi-tenant environments For multi-tenant environments, IBN solves both the privacy problem and the device compatibility problem at the same time — something traditional approaches cannot do simultaneously.  Each resident or guest is provisioned with their own identity-bound credentials, and the network uses those credentials to place their devices into a private micro-segment. Within that segment, their devices can discover and communicate with each other freely — a phone connects to a TV, a laptop connects to a printer, smart home devices work as the manufacturer intended. Outside of that segment, they're completely isolated from every other person on the same physical infrastructure. The student next door is invisible. The guest in the adjacent hotel room is on an entirely separate logical network. This is the experience residents and guests expect, and until now it has been genuinely difficult to deliver at scale without significant infrastructure complexity. IBN makes it a standard outcome rather than an engineering challenge, and it does so without requiring residents to do anything different from what they'd do on their network at home. What this means for your conversations The qualifying questions are straightforward. Does your customer have staff whose access isn't tied to their identity? Do they provide WiFi to guests who have to navigate a portal to connect? Do they operate any kind of multi-tenant environment where residents share infrastructure? If the answer to any of these is yes, they have a problem that a shared password or a captive portal is not equipped to solve. The customers who push back most often do so because they've never had a visible incident. The response to that isn't to frighten them. It's to ask them, honestly: with a shared password and no identity on your network, how would you know if you had?

"It works, doesn't it?" That's the response most IT managers give when someone raises the subject of WiFi authentication. And they're right, technically. The network is up. People can connect. Nobody's filed a ticket today. But "it works" and "it's not costing us anything" are different statements. The costs of traditional WiFi setups are real, they're just spread across departments, buried in IT logs, and occasionally showing up in audit findings that get quietly remediated and forgotten. This post is for partners who need to make the business case for change. Not a technical argument. A financial one. The cost centres nobody tracks 1) IT time: The hours nobody counts Password resets and access management for WiFi rarely appear as a line item anywhere. They're absorbed into general IT support, which makes them invisible on a spreadsheet but very real in practice. Here's what that looks like in a typical mid-sized organisation: A staff member leaves. Someone in IT needs to remember to remove their WiFi access, find the right system to do it in, and confirm it's done. If they're using a shared PSK, the only way to revoke access is to change the password for everyone, which means notifying the whole organisation, updating every device that doesn't auto-reconnect, and fielding the support tickets that follow. Do this four or five times a year and you're looking at a meaningful chunk of IT capacity spent on a problem that shouldn't exist. Guest WiFi compounds this. Captive portals require maintenance. Browser compatibility breaks. iOS updates interfere with redirect logic. Someone has to fix it, and that someone is usually already stretched thin. 2) Security incidents: The cost of not knowing who's on your network This one is harder to quantify until something goes wrong, which is exactly the problem. When a shared password is the only thing standing between your client's network and an ex-employee, a disgruntled contractor, or anyone they ever gave the password to, the exposure is open-ended. The organisation doesn't know who has it. They don't know who's used it since the last rotation. They can't answer either question in an incident investigation. 3) Customer experience: The cost that shows up in reviews A captive portal adds friction at the moment a guest is trying to settle in, get to work, or enjoy a service. They open their browser, get redirected, type in an email address, agree to terms they don't read, hit submit, and sometimes it works. Sometimes they get an error. Sometimes the redirect doesn't fire on their device and they give up. The data on this is clearer than most people realise. Searches for "free WiFi" and "WiFi near me" have increased by 60% over the past year. And 80% of people say they'll choose where to visit, eat, or stay based on WiFi quality. WiFi isn't a nice-to-have. It's a factor in the decision to walk through the door. Removing that friction has measurable upside too. When Purple replaced the mandatory data capture form with a post-connection prompt, "would you like to share your details for offers and rewards?" the amount of data guests voluntarily shared went up by over 20%. Less friction, more engagement. The compulsory form was actually counterproductive.  What does fixing it actually cost? This is where the conversation usually stalls. The business case for change only works if the cost of change is lower than the cost of staying put. Identity-based networking via Purple doesn't require replacing hardware. It works with whatever 802.1X-compatible access points your client already has, Cisco Meraki, Aruba, Ruckus, Juniper Mist, UniFi. The infrastructure investment is in the authentication layer, not the physical network. Implementation is measured in weeks, not months. Because Purple is cloud-native with no on-premise RADIUS servers to deploy, the heavy lifting is integration with the client's existing identity provider (Microsoft Entra, Okta, Google Workspace etc.) which is well-documented and typically completed in a single project sprint. Ongoing cost is lower than the status quo for most organisations once you account for the IT time recovered from manual credential management, the support tickets that stop arriving, and the compliance overhead that gets automated rather than manually assembled each audit cycle. How to frame this for a client Don't lead with the technology. Lead with the problem they already recognise. Ask how they currently handle WiFi access when a staff member leaves. Ask when they last rotated their wireless password and what that process involved. Ask whether they could produce a list of every device that connected to their network in the last 90 days and who owned each one. Most IT managers will pause at that last question. That pause is the conversation. From there, the case builds itself. The hours are already being spent. The risk is already present. The compliance gap is already there. The question isn't whether to change, it's how much longer the current setup is worth defending. The bottom line Good enough WiFi has a price. It's just not on any invoice. The IT hours are in the support logs. The security exposure is in the access policy, or the absence of one. The compliance risk is sitting in the next audit. The customer experience cost is already showing up in satisfaction scores. The case for identity-based networking isn't that it's newer or more technically sophisticated. It's that the alternative is costing your clients money they haven't calculated yet. Want the numbers for your next client proposal? Purple's team can help you build a custom business case based on your client's size, sector, and current setup. Talk to the team today!

WiFi authentication is broken. Employees share passwords on Post-it notes. Guests abandon a captive portal before entering their email. IT teams spend hours manually revoking access for leavers. This experience has barely evolved in twenty years. The cost of this broken system is significant. When everyone shares the same password, there’s no visibility into who is actually on the network, creating major security blind spots. Every forgotten password is a support ticket, and every captive portal is a barrier for users. If a person's WiFi access is not revoked immediately and automatically when they leave, it creates a security problem. There’s a better way. The solution is a shift to identity-centric networks. Traditional security focuses on the network itself: firewalls and VLANs. This made sense when networks had clear boundaries. Today, that perimeter has dissolved. Users move between locations and devices multiply. The network boundary is no longer a useful security concept. This guide breaks down what identity-based networks actually are, why they represent a genuine step-change from traditional WiFi, and how you can introduce the concept in client conversations without drowning anyone in jargon. The problem with the way WiFi has always worked To understand the benefits of identity-based networks, you first need to understand why the existing model is broken, because it has been, for a long time, and most organisations have simply learned to live with it. Traditional WiFi authentication comes in two main flavours. The first is the shared password — a WPA2-PSK key that everyone in the building uses, often written on a whiteboard or pinned to a noticeboard. The second is the captive portal — the frustrating splash page that guests often abandon. Both approaches were designed for a simpler time: smaller offices, fewer devices, lower stakes. But in 2026, they create serious problems. The shared password problem When everyone uses the same WiFi password, you lose visibility over who is actually on your network. You can see devices, but not identities. This creates several compounding issues: Leavers stay connected. When an employee leaves, their device doesn't. Unless someone manually changes the password (which disrupts everyone still using it) former staff, contractors, and disgruntled ex-employees retain access indefinitely. Passwords spread uncontrollably. Slack messages, sticky notes, text messages to the cleaner…WiFi passwords find their way to people who were never meant to have them. And once a password is out, you can't put it back. You can't see what's happening. There's no audit trail. No way to know who connected at 11pm on a Tuesday, or whether that device belongs to a trusted employee or someone sitting in the car park. Role-based access is impossible. Senior leadership, temporary contractors, delivery drivers, and full-time staff all share the same password and the same network access. There's no way to differentiate. The captive portal problem Guest WiFi portals are designed to feel like a security measure, but they fail on almost every dimension: They're frustrating. Most people have experienced the friction: the page that doesn't load, the agreement button that won't work, the re-authentication every time you return. It's the exact opposite of a good customer experience. The data they collect is low quality. "WiFi4cookies@gmail.com" is not a lead. When people enter an email purely to get online, accuracy goes out the window. Marketing teams end up with bloated, unreliable contact lists. They're not actually secure. Captive portals typically run on open networks, which means data is transmitted unencrypted from the moment a user connects, before they even see the login page. That's a meaningful liability. The 3 products Purple delivers on IBN Purple's identity-based network platform covers three distinct use cases, each addressing a different kind of WiFi environment. As a partner, understanding the distinctions is essential so you can sell the right product into the right situation, and so you can identify opportunities to bundle all three. 1) Staff WiFi: Passwordless Zero Trust Purple's Staff WiFi product is built for organisations where employees need secure, seamless access across one or many locations. Staff authenticate once via their corporate IdP (Entra ID, Google Workspace, or Okta), and their device connects automatically from then on at every office, every branch, every coworking space running Purple. The killer feature is automatic revocation: when an employee leaves and their account is deactivated in the directory, their WiFi access disappears at the same moment. No IT ticket. No password reset. No window of vulnerability. 2) Multi-Tenant WiFi: The at-home experience In environments where multiple residents or guests share the same building (student accommodation, hotels, build-to-rent properties, care homes) traditional WiFi creates a dilemma: shared passwords mean everyone can see each other's devices, but managing individual access is operationally nightmarish. Purple's Multi-Tenant WiFi solves this with Private Area Networks (PANs): each resident or guest gets their own isolated network bubble that contains all of their personal devices. A student can connect their laptop, phone, gaming console, and smart speaker, and they all sit inside a single private space, invisible to their neighbours. Simple iPSK handles legacy devices that don't support browser-based authentication. 3) Guest WiFi: Frictionless, secure, data-rich Purple's Guest WiFi replaces the captive portal with the Purple app: guests authenticate once with their email, get an encrypted connection from their very first packet, and reconnect automatically every time they visit. For the business, this means real marketing data from genuinely opted-in contacts, powerful footfall analytics, CRM integration, and a guest experience that actually reflects well on the brand. For IT, it means ISO-certified compliance and no open networks. Why this matters right now Firstly, hybrid work has made the old model untenable. When staff are moving between offices, client sites, and co-working spaces daily, the idea that a single shared password provides any meaningful security has become impossible to defend. Identity-based access is the only approach that scales with how people actually work now. Data protection regulation has raised the stakes for guest WiFi. GDPR and its equivalents require that personal data is collected lawfully, minimally, and with meaningful consent. Captive portal email captures were always borderline, and as regulators become more sophisticated, the risk of continuing with them is growing. And for clients who run multi-site operations, the analytics case for IBN is increasingly hard to ignore. Knowing who is on your network (not just that someone is) opens up a range of insights that shared-password WiFi simply cannot deliver. How to introduce IBN in a client conversation The most common mistake partners make when introducing Purple is leading with the technology. "We use WPA2-Enterprise via a cloud-native RADIUS alternative" is accurate, but it's not a conversation opener. The better approach is to start with the problem your client already knows they have, and work towards IBN as the natural solution. Here are three opening questions that tend to unlock the right conversation: For IT-led conversations: "When someone leaves the company, how quickly does their WiFi access get turned off?" "If I asked you right now who is connected to your staff network, could you tell me?" "How do you handle WiFi access for contractors or temporary staff?" For business-led conversations: "Are you capturing useful data from your guest WiFi, or just email addresses people never check?" "Has your cyber insurer asked you about network access controls recently?" "How much time does your IT team spend on WiFi support calls or password resets?" Once the problem is on the table, the IBN explanation almost writes itself. "What if your network already knew who each person was, so they never needed a password — and access stopped the moment they left the business?" That's a concept most decision-makers grasp within 30 seconds, and it naturally opens the door to a deeper conversation about Purple. How about booking a demo so you can see the benefits for yourself?