How Purple handles contractor and time-limited staff WiFi access

When a hotel guest complains the WiFi is slow, or a venue IT manager can't figure out why the network feels sluggish despite a decent internet package, the culprit usually isn't the hardware. It's the hidden data load eating into available bandwidth before anyone's actually used it: ads, auto-playing video, and background tracking scripts running on every connected device. Ad-related traffic can make up to 38% of a network's total load. That's more than a third of your customer's internet capacity consumed before a guest has loaded a single page. Purple Shield just added three new features that fix this at the DNS level, and they're included free in every Shield licence. What's new in Shield Ad Blocking Stops advertisements before they ever reach the device. You can set this to Moderate (allows ads from trusted platforms like Google) or Strict (blocks all ads on webpages). Because the block happens at DNS level, there's no browser extension, no app to install, and no per-device setup. It works across every connected device on the network, automatically. Tracker Blocking Cuts off the background scripts that track user behaviour across the internet. Moderate mode blocks trackers except those from trusted domains. Strict mode blocks everything. Either way, your customers reclaim the bandwidth those scripts were consuming, and their guests' browsing activity stays private. Enforced SafeSearch Forces major search engines into their strictest safety settings automatically. For any search engine that doesn't support SafeSearch, Shield blocks access to it entirely. This is a one-toggle guarantee of a family-friendly network, with no per-device configuration needed. All three features are independent. Customers can turn on ad blocking without SafeSearch, or tracker blocking without ad blocking. Any combination works. The numbers worth sharing These are the stats that tend to land well in conversations with prospects: Up to 40% reduction in total downloaded data : blocking heavy ad payloads and tracking scripts before they hit the device means the network is doing significantly less work Pages load up to 3.5x faster : removing the 120+ DNS queries typical of an ad-heavy page pushes load times well under the 3-second mark where over half of users abandon a site 44% lower device power consumption : stripping out background scripts reduces CPU load and preserves guest and staff battery life Zero device setup : point the DNS, share the IP, and Shield is live in under 10 minutes Which customers you should be talking to first Hospitality is the obvious starting point. Hotel and venue IT managers are constantly being told the WiFi is slow, but don't have the budget for new hardware or a bigger ISP contract. This is a software fix that instantly reclaims capacity. Retail and shopping centres have a different use case worth calling out. Shield's content filtering lets retailers block competitor sites on their in-store Guest WiFi, so customers browsing on their phones can't pull up a rival's product page or price comparison site mid-purchase. Combined with the performance benefits, it gives retail IT teams a stronger reason to act: faster WiFi and more control over what the network is used for, all configured at network level with no per-device setup. Bars, restaurants, and leisure venues are worth the conversation too. Guests pulling up menus, booking apps, or just browsing while they wait are going to notice if pages take too long to load. Pages loading up to 3.5x faster is a tangible improvement to the time people spend in a venue, and it costs nothing extra for customers already on Shield. High-density venues like airports, transport hubs, and stadiums feel the bandwidth problem most acutely. A 40% reduction in data load has a real impact when hundreds of devices are connected at once. How to position this in conversations The clearest frame is: this is a free upgrade to a product your customers already have. If they're on Shield, turning this on costs them nothing and takes minutes. For those who aren't yet on Shield, it's worth asking whether their current content filtering solution is actually doing everything they think it is. Does it improve network performance, or does it just block content? Is it speeding up page load times, reclaiming wasted bandwidth, and protecting guest privacy, or is it only handling the basics? Most filtering solutions stop at blocking. Shield goes further. The best way to open the conversation is usually with the bandwidth stat: up to 38% of a customer's network capacity is being consumed by ads and trackers right now. That's typically enough to get the question: "So what do I do about it?" The answer is Shield.

A shared WiFi password isn't really a password. Once it's written on a chalkboard, it's effectively public. Former staff have it. Anyone who's ever visited has it. And once someone's on that network, they can see everything else on it...

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.

Every organisation has a version of this story. An employee leaves on a Friday afternoon. Someone remembers to disable their email account. Nobody remembers to remove their WiFi access. On Monday, the former employee can still connect to the corporate network from the car park. That's not a hypothetical. It's a gap that exists in most businesses using shared WiFi passwords or manually managed credentials. And it's the exact problem that Purple Staff WiFi's auto-revocation feature closes. When you're talking to IT managers, HR directors, or operations leads at enterprise or multi-site businesses, this is the feature that turns interest into a signed deal. The problem with manual offboarding Traditional WiFi setups have a structural weakness: access is tied to a password, not a person. When someone leaves, you either change the password for everyone (disruptive) or hope someone remembers to remove that individual's credentials from wherever they're stored (risky). In practice, manual processes fail. IT teams are busy. HR sends a leaver notification. It lands in a queue. The network access stays live for days, sometimes weeks. For a business with 50 staff, that's manageable, if uncomfortable. For a business with 500 staff across 20 sites, it's a genuine security and compliance exposure. Auditors, insurers, and increasingly regulators want to see documented evidence that access controls are enforced at the point of departure. "We update it manually" doesn't hold up. How auto-revocation works in Purple Staff WiFi Purple Staff WiFi connects directly to your client's identity provider (IdP), such as Microsoft Entra ID, Google Workspace, or Okta, through SCIM integration. Staff authenticate using their existing SSO credentials, and the system provisions a unique, device-specific certificate rather than a shared password. The process for a leaver works like this: 1) HR or IT disables the employee in the IdP (the same step they'd already take for email and other systems). 2) Purple's SCIM integration picks up the change automatically. 3) That employee's WiFi certificate is revoked instantly, across every site. 4) Their device can no longer connect. No manual step required. There's no separate WiFi offboarding task. No checklist item that gets missed at 5pm on a Friday. The network access lifecycle follows the identity lifecycle. Why this resonates with IT teams IT managers aren't primarily worried about disgruntled ex-employees sitting in the car park. They're worried about audit findings, cyber insurance questionnaires, and the sheer time their team spends managing WiFi access manually. Zero manual steps required For multi-site businesses, the benefit compounds. An IT team managing 20 locations doesn't have 20 separate WiFi admin tasks when someone leaves. They have one IdP action, and the rest happens automatically. Auto-revocation also supports zero-trust network principles, which is a real requirement for businesses pursuing ISO 27001, Cyber Essentials Plus, or similar frameworks. Network access tied to verified identity, with automatic removal on departure, is exactly what those frameworks ask for. Why this resonates with HR teams HR teams care about this for a different reason: risk at the point of departure. Terminations, especially involuntary ones, carry legal and reputational risk. HR wants a clean, documented process where access to company systems ends at the point of departure, not days later. WiFi has historically been left out of that process because it felt like an IT problem. Purple Staff WiFi brings WiFi access into the same lifecycle management as email, applications, and building access. When a leaver is processed in the IdP, everything moves together. For HR, that's a compliance story. For businesses that have experienced data incidents or are under regulatory scrutiny, it's a non-negotiable. How to lead with this feature in sales conversations Don't open with the feature. Open with the gap. Ask your prospect: "When someone leaves your business today, what's the process for removing their WiFi access?" Most will either describe a manual step that's easy to miss, or pause and admit they're not entirely sure. That's your opening. The feature sells itself once the gap is visible. Your job is to make the gap visible. The broader context: identity-based access isn't new, but WiFi has been left behind Most enterprise businesses already manage application and email access through their IdP. The concept isn't foreign. What's been missing is the same rigour applied to network access. Purple Staff WiFi fills that gap without requiring new hardware. It works with any network infrastructure that supports RADIUS authentication, including Cisco, Aruba, Ruckus, and Ubiquiti. That's an important point for IT teams who've just refreshed their hardware and aren't looking to replace it. The solution layers onto what's already there. The access control, the certificate provisioning, and the auto-revocation all sit above the hardware layer. The short version Auto-revocation closes a security gap that most businesses know exists but haven't prioritised. It does it automatically, at scale, without adding to IT workloads. And it integrates into the identity management workflow your clients are already running. When you're talking to enterprise or multi-site clients, this is the feature that moves conversations from "interesting" to "when can we start". Lead with the gap. Demonstrate the automation. Show how it fits into what they're already doing. The rest follows.

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?