Guest WiFi content filtering: how to filter every device on every network
Guest WiFi content filtering decides which sites, apps and threats people on your public network can reach. Purple Shield does it at the DNS layer: every lookup is checked against the policy for that network, so harmful categories, phishing and malware domains never resolve, on every device, with nothing installed on any of them.
- Filtering built to the Internet Watch Foundation bar
- No hardware, no agents on devices
- Fails closed, across multiple data centres
Reviewed on 9 October 2026
Shield in numbers
- 241,000threats a week blocked on the guest WiFi at St George's Healthcare NHS Trust
- 10 daysearlier warning of new threats than standard blocklists
- 80,000+venues on the Purple platform Shield runs on, in 90 countries
In short
Key takeaways
- Filter guest WiFi in DNS. You cannot install software on a guest's phone, and a firewall agent never sees it, but every device asks DNS before it connects.
- Give each network its own policy. Guests, staff, paid tiers and children's areas should never share one rule set, and each can change by the hour.
- A filter is only as good as its enforcement. Force devices onto your resolver and block outbound port 53 and 853 to anything else, or hard-coded DNS walks round it.
- Shield filters to the Internet Watch Foundation and Friendly WiFi bar, and runs on the Purple platform behind 80,000+ venues in 90 countries.
- Ad blocking comes with the same layer: up to 44% less data and 62% fewer DNS queries on a filtered network.
- Start with one network. The first is free for 30 days, with no hardware to buy and no firewall change.
What it is
What is guest WiFi content filtering?
It is a policy that decides which sites, apps and threats people on your public or guest network can reach. On guest WiFi it works best at the DNS layer, because that covers every device without software on any of them.
Every guest who joins your WiFi brings a device you do not own and cannot configure. You cannot push an agent to it, you cannot see inside most of its traffic, and you will not meet its owner again. Content filtering is how you still decide what that network is used for.
A content filter does three jobs. It blocks the categories you choose, such as adult content and gambling. It blocks known-bad destinations, such as phishing pages, malware hosts and the servers an infected device calls home to. And it shapes what is left, by enforcing Safe Search, stripping ads and trackers, or limiting heavy streaming at busy times. Purple Shield does all three in one layer, for guest WiFi on any network, with a policy for each SSID, VLAN and venue.
There are three places a filter can sit, and the difference matters more on guest WiFi than anywhere else.
| Placement | What it sees | Covers guest devices | What you install | Main weakness |
|---|---|---|---|---|
| Device agent | Everything the device does | No. Guests will not install it | Software on every device | Protects only devices you manage |
| Firewall with web proxy | URLs, and page content if HTTPS is decrypted | Yes, for traffic through the gateway | A hardware or virtual appliance at every site, plus a certificate on each device to read HTTPS | Cannot read encrypted traffic without a certificate guests will not accept; a box to run at every site |
| DNS filter | Every domain lookup, before any connection starts | Yes, every device on the network | One DNS setting on the network | Sees domains rather than full URLs, so a device that ignores the network's DNS has to be forced back (covered below) |
Why filter
Why does a venue have to filter its guest WiFi?
Because the network is yours. When something harmful is reached on your WiFi, nobody asks the device owner. They ask you, and the question is whether you can prove nothing got through.
Public, guest and student WiFi carries a duty of care. Children use it. Parents use it with children beside them. Staff watch screens in reception, in the lobby and across the restaurant. A single complaint about what was visible on a venue's network lands on the venue, whatever device it was.
There is a security side too. One phone that arrived infected can join your network and start calling home to its command-and-control server, and every other user on that network now shares it with an active threat. Your firewall may never see it, because the guest device is not one it manages. A DNS filter answers that lookup with nothing, so the connection never starts.
Both problems have the same fix: a check on every lookup, on every device, before a connection begins.
- 241,000threats a week blocked on guest WiFiAt St George's Healthcare NHS Trust. Threats means malware, phishing and command-and-control lookups stopped by Shield.
- 10 daysearlier warning of new threats than standard blocklists
- 80,000+venues on the Purple platform, in 90 countries
- 30 daysfree trial on your first network
How it works
How does DNS-based filtering work on guest WiFi?
A device asks DNS where a site lives before it connects. Shield is the resolver for the network, so it returns the real address when the policy allows the domain and your branded block page when it does not. A blocked connection never starts.
- Guest deviceOpens a site or an appThen: 2. Network DHCP
- Network DHCPHands out Shield as the resolverresolver: 3. Shield resolver
- Shield resolverChecks the domain against the policy for this networkallow: 4. Allowedblock: 5. Blocked
- AllowedReal address returned and the page loads
- BlockedBranded block page, or no answer for a threat
- A guest device asks the network for a resolver, the network hands out Shield, and Shield either returns the real address for an allowed domain or shows a branded block page for a blocked one.
The mechanism is plain. When a device joins, DHCP tells it which DNS servers to use (the Domain Name Server option, option 6). If those are Shield's addresses, every name the device looks up, from a web page to an app's background call, goes to Shield first. Shield checks the name against the content categories, allow and block lists and schedule for that network, and against its threat intelligence.
The answer depends on what was found. A blocked content category returns your branded block page, so the person understands why. A command-and-control callback goes unanswered, so the infected device never reaches home. Anything allowed resolves as normal.
| Answer | What the device sees | When to use it |
|---|---|---|
| Address of a block page | A page explaining the site is blocked, in your branding | Content categories, where a person should understand why |
| No such domain (NXDOMAIN) | A browser error, as if the site did not exist | Threat callbacks and malware, where no page is needed |
| Refusal with an Extended DNS Error | An application-level error that can say the lookup was blocked, censored, filtered or prohibited (RFC 8914 codes 15 to 18) | Clients that read the code and can show the reason |
Policy
What should a guest WiFi policy block?
Start with the categories every public network blocks, add threat defence, then set stricter or looser rules per network. Guests, staff, paid tiers and children's areas each carry their own policy, and each can change by time of day.
A policy is a list of decisions per category, plus your own allow and block lists, plus a schedule. The trap is writing one policy for the whole estate. A guest network, a staff network and a children's area have different people on them, so they need different rules, and Shield applies the policy to the network the device is on, not to the device.
| Category | Open guest WiFi | Staff network | Children or student area | Why |
|---|---|---|---|---|
| Adult content | Block | Block | Block | Duty of care on any public network |
| Gambling | Block | Block | Block | Age-restricted content |
| Phishing and malware domains | Block | Block | Block | Known-bad destinations are never worth a connection |
| Command-and-control callbacks | Block | Block | Block | An infected device cannot reach home |
| Proxies, anonymisers and VPN endpoints | Block | Block | Block | Closes the easiest route round the filter |
| Peer-to-peer file sharing | Block | Block | Block | Copyright exposure and bandwidth |
| Streaming video | Limit at peak | Allow | Allow in set hours | Protects shared bandwidth at busy times |
| Ads, trackers and bloatware | Block | Block | Block | Faster pages and less data |
| Social media and games | Allow | Allow | Block in set hours | Matches how the space is used |
Two habits make a policy easy to run. Build the strictest policy for the network with the youngest users first, then copy it down to the others and relax it where the audience allows, rather than copying a loose policy up. And use the schedule: a venue that wants strict rules in the evening and a lighter touch at the weekend sets it once.
- Guest SSIDVisitors and customersThen: 4. Shield
- Staff SSIDEmployeesThen: 4. Shield
- Children's VLANPlay areas and classroomsThen: 4. Shield
- ShieldOne resolver, one policy per networkThen: 5. Family-safe categoriesThen: 6. Threat defence firstThen: 7. Strictest policy
- Family-safe categoriesAds stripped, Safe Search on
- Threat defence firstStaff allow and block lists
- Strictest policyPlus schedules by hour
- Guest, staff and children's networks all send their lookups to Shield, which applies a separate policy to each: family-safe categories for guests, threat defence first for staff and the strictest rules for the children's area.
Standards
What do the Internet Watch Foundation and Friendly WiFi expect?
The Internet Watch Foundation maintains a list of webpages confirmed as child sexual abuse imagery, and filtering providers block them. Friendly WiFi is the scheme that marks public WiFi as filtered to a published standard. Shield's filtering meets both bars.
Two names come up whenever a venue, a council or a brand owner asks whether public WiFi is filtered properly.
The Internet Watch Foundation (IWF) is the UK charity that finds and removes child sexual abuse imagery online. It publishes a URL list of confirmed webpages, which filtering providers use to block access. A filter that does not consume that list is not filtering to the bar the UK sector is measured against.
Friendly WiFi is the scheme for public WiFi that has been filtered to a published standard. A venue that meets it can say so to its guests, which matters in any space where families connect.
Shield's content filtering meets the Friendly WiFi and Internet Watch Foundation standards, on every device and every network the policy covers. Search is handled in the same layer: Google, Bing and YouTube each document a safe-search address that a resolver can answer with in place of the normal one, and Shield enforces Safe Search on all three.
Setup
How do you set up guest WiFi content filtering, step by step?
Point the guest network's DNS at Shield, choose a policy, then force every device to use it. On a controller that is a DHCP change on the guest VLAN. The first network is free for 30 days and needs no new hardware.
Filter your first guest network
List the networks you want filtered
Write down every SSID and VLAN that guests, staff, residents or children can join, and the venue each sits in. Each one gets its own policy, so this list is your policy map.
Check: You can name the people on each network.
Start the free trial and create the network
Create the first network in the Shield dashboard and note the resolver addresses it gives you. Running change control? A Purple engineer plans a pilot on one SSID with your team or your ICT provider.
Check: You have the resolver addresses for the network.
Set Shield as the resolver on the guest network
In the DHCP scope for the guest VLAN, replace the DNS servers with the Shield resolver addresses. On most controllers this is a per-SSID or per-VLAN setting.
# On a laptop joined to the guest SSID nslookup example.com # The Server line should show a Shield resolver addressCheck: A device that joins the guest SSID is handed the Shield addresses as its DNS servers.
Choose a starting policy
Start from a ready-made policy or build your own allow and block lists. Turn on category blocking, threat defence, Safe Search and ad blocking, and add your branded block page.
Force devices to use it
Allow DNS only to Shield on the guest VLAN's egress, and deny it to everywhere else. This stops a hard-coded resolver such as 8.8.8.8, and DNS over TLS or QUIC, from going round the filter.
# Guest VLAN egress rules (vendor-neutral) allow udp/53, tcp/53 to <Shield resolver addresses> deny udp/53, tcp/53 to any deny tcp/853, udp/853 to any # DNS over TLS and DNS over QUICCheck: A lookup sent straight to a public resolver from the guest SSID fails.
Test a blocked and an allowed site
Visit a site in a category you have blocked and confirm your block page appears. Visit an ordinary site and confirm it loads at normal speed.
Check: The block page shows your branding.
Read the reporting
Open the blocked URLs and threat analysis for the network and confirm your test lookups are listed beside the policy that stopped them.
Roll the policy out
Copy the policy to the next SSID or venue, then tighten or relax it per network and per hour. Every device on the network is covered at once.
Guest WiFi filtering launch checklist
0 of 14 done
Bypass
Can guests get round a guest WiFi filter?
Only by stepping outside the network's DNS: a hard-coded resolver, encrypted DNS in the browser, a VPN or a connection to a bare IP address. Each has a known countermeasure, and applying them is what separates a filter that works from one that only looks as if it does.
| Method | What the guest does | What closes it |
|---|---|---|
| Hard-coded DNS | An app or device uses 8.8.8.8 or another public resolver and ignores the one DHCP gave it | Deny outbound port 53 and 853 to anything but Shield on the guest VLAN, as in the setup steps |
| DNS over HTTPS in the browser | The browser sends lookups to a DoH provider over port 443 | Firefox keeps DoH off by default when the network answers NXDOMAIN for its canary domain use-application-dns.net; block the hostnames of public DoH providers with a block list for the rest |
| iCloud Private Relay | An Apple device tunnels its Safari traffic through Apple's relays | Apple documents that returning no answer or NXDOMAIN for mask.icloud.com and mask-h2.icloud.com tells the device the network does not allow Private Relay |
| VPN and proxy apps | A tunnel carries everything, including its own lookups | Block VPN, proxy and anonymiser domains in the filter, by category or with your own block lists, and the common VPN ports at the firewall |
| A bare IP address | An app connects to an address with no lookup at all | DNS never sees it; a firewall rule on known ranges covers it |
Shield answers every DNS lookup on the network it protects, on every device, and there is nothing on the device to switch off. Before you start the trial, a Shield expert shows you how your network handles VPNs and encrypted DNS, so you know where each of these controls sits in your own estate.
Choose
Which guest WiFi filtering setup fits your network?
It depends on who runs the gateway and whether you must stop guests using their own DNS or a VPN. Answer four questions and the tree below lands on a setup.
Pick your setup
Question 1
Do you already run your guest WiFi on Purple Access?
See the whole decision as a list
Do you already run your guest WiFi on Purple Access?
- Yes
Bolt Shield onto Access
- No
Can you change the DNS servers handed out on the guest network?
- Yes
Do you need to stop guests using their own DNS or a VPN?
- Yes, enforce it
Point DHCP at Shield and add the DNS enforcement rules
- Not yet
Point DHCP at Shield and start the trial
- Yes, enforce it
- No, a landlord or provider manages it
Talk it through with a Shield expert
- Yes
By venue
How does guest WiFi filtering differ by venue type?
The categories are the same; the emphasis is not. Hotels weigh guest experience at scale, airports weigh uptime, hospitals weigh threat defence, and anywhere children are present sets the strictest policy.
| Venue | What matters most | Policy emphasis | In production |
|---|---|---|---|
| Hotels | Guest experience across many properties | Family-safe categories, ad blocking for faster pages, a policy per hotel | Whitbread protects its hotel guest WiFi with Shield |
| Airports and transport | Uptime and passenger safety | Fails closed across multiple data centres, so an outage never opens the network | AGS Airports protects passengers at Aberdeen, Glasgow and Southampton |
| Healthcare | Patients and visitors on a large estate | Threat defence first, command-and-control callbacks blocked at the lookup | St George's Healthcare NHS Trust blocks around 241,000 threats a week |
| Restaurants, cafes and retail | Families, short stays, many small sites | Family-safe categories, a branded block page, ad blocking | Shield runs on the Purple platform behind 80,000+ venues |
| Education and student accommodation | Children and young adults on shared networks | The strictest policy per VLAN, schedules by time of day | See school WiFi filtering |
| Offices and public sector | Visitors alongside staff | Separate guest and staff policies on separate SSIDs | Threat defence on the secure network |
Speed and data
Does content filtering slow guest WiFi down?
No. Blocking ads and trackers removes requests before they are made, so a filtered network uses up to 44% less data and makes up to 62% fewer DNS queries. The filter itself adds one answer from a resolver that runs on the Purple platform.
Most security costs you speed. A DNS filter is the exception, because the same layer that blocks threats also drops ads, trackers and bloatware before the device fetches them. Pages have less to load, and the shared connection carries less contention and lower data costs. That matters most on busy or metered backhaul, at a hotel with a few hundred guests online at once or a venue paying for every gigabyte.
The estimate below turns your own numbers into a monthly figure. The saving is the 44% reduction in data used that Purple reports for an ad-blocked network.
Guest WiFi data saving estimate
Result
- Guest data a month
- 105.0 TB
- Data not fetched with ad blocking on
- 46.2 TB a monthAt the 44% data reduction Purple reports
Worked example: At 25 venues, 400 guests a day and 350 MB per guest, guests move about 105.0 TB a month and Shield stops 46.2 TB of it being fetched.
How the numbers are built
- A month is 30 days.
- The 44% is Purple's reported reduction in data used with ads, trackers and bloatware blocked.
- Your own mix of traffic decides where in practice you land, so measure on the free trial.
Cost and start
What does guest WiFi content filtering cost, and how do you start?
Shield starts with a 30-day free trial on one network. After that a Purple expert sends a quote built around your venues and networks. There is no hardware to buy and no firewall change to pay for.
Shield is sold on its own for any WiFi network, and it bolts onto Purple Access on its open, secure and xPSK networks. Either way the quote reflects your venues, your networks and your plan, and there are no published prices because estates differ so much.
The cheapest way to find out what filtering does on your network is to run it. Point one network at Shield, read the blocked URLs and threat analysis for 30 days, and decide on evidence.
Proof
Running on guest WiFi at hotels, airports and hospitals
- 241,000threats a week blocked on the guest WiFi at St George's Healthcare NHS Trust
- 10 daysearlier warning of new threats than standard blocklists
- 80,000+venues on the Purple platform Shield runs on, in 90 countries
- 500 millionlogins a year across the Purple platform
- Whitbread
- AGS Airports
- St George's Healthcare NHS Trust
Compare
How Shield compares
| Compared with | Where Shield wins | What it is built for |
|---|---|---|
| DNSFilter | Built for guest and public WiFi, with ad blocking included, a policy per SSID and VLAN and nothing to install | Pure-play protective DNS for managed and roaming endpoints |
| Cisco Umbrella | Purpose-built for WiFi filtering, live in minutes across a multi-site venue estate | A broad secure-access suite, from DNS security to SWG and ZTNA, for large enterprises on quote-based pricing |
| Legacy filtering appliance | No hardware, no firewall change, and it fails closed across multiple data centres | A box at every site that inspects traffic at the network edge |
Glossary
Key terms
- DNS resolver
- The server a device asks to turn a name such as example.com into an address. On a filtered network the resolver is the filter.
- DHCP DNS option
- The part of DHCP (option 6, Domain Name Server) that tells a joining device which resolvers to use, and the place Shield is set on a network.
- Block page
- The page a person sees when a filter blocks a site. Shield shows your own branded page.
- Category filtering
- Blocking groups of sites, such as adult content or gambling, rather than listing domains one by one.
- Safe Search enforcement
- Forcing search engines to return filtered results. Shield enforces it on Google, Bing and YouTube.
- Command-and-control callback
- The lookup an infected device makes to reach the server that controls it. Blocking it at the lookup cuts the device off.
- IWF URL list
- The Internet Watch Foundation's list of webpages confirmed as child sexual abuse imagery, used by filtering providers to block access.
- Fail closed
- If the filter cannot answer, the network stays protected rather than opening up. Shield fails closed across multiple data centres.
The library
All guides in this pillar
What each group of guides covers in guest WiFi content filtering, so you know where to look.
Venue guest networks
Content filtering for public, hotel, restaurant, cafe and retail WiFi.
Policy and control
Per-network policy, safe search, VPN blocking and acceptable use.
Ads and performance
DNS ad blocking and what it does for speed and bandwidth.
Questions
Questions about guest WiFi content filtering
What is guest WiFi content filtering?
It is a policy that decides which sites, apps and threats people on a guest or public network can reach. Shield applies it at the DNS layer, so every lookup is checked against the network's policy and blocked categories, phishing and malware domains never resolve.
Do I need to install anything on guests' devices?
No. Pointing the network's DNS at Shield covers every device on that WiFi, including iOS, Android and Windows, with nothing installed. There is no appliance to rack and no firewall change.
Does DNS filtering work on HTTPS sites?
Yes. The lookup happens before the encrypted connection starts, so Shield can allow or block the domain whatever protocol follows. It decides on the domain rather than the full page address, which is why category blocking works on HTTPS without decrypting anything.
Can I set different rules for different networks?
Yes. Policy is set per SSID, per VLAN and per venue, and changes by time of day and day of week. Guests, staff, paid tiers and children's areas each carry their own rules.
Is filtering guest WiFi a legal requirement?
Rules differ by country and venue type, so ask your own legal adviser about your obligations. The standard the sector measures against is clear: filtering to the Internet Watch Foundation and Friendly WiFi bar, which Shield meets.
What happens if Shield goes down?
Protection does not lapse. Shield fails closed, so an outage never leaves a network unfiltered, and it runs across multiple data centres, so a fault in one does not take the service down. Shield runs on the Purple platform at a 99.999% uptime SLA.
Will filtering slow my WiFi?
No. Ad and tracker blocking means up to 44% less data and up to 62% fewer DNS queries on a filtered network, so pages have less to load and the shared connection carries less contention.
Can guests get round the filter with a VPN?
Shield answers every DNS lookup on the network, and nothing on the device can switch it off. For VPNs and encrypted DNS, block those domains in the policy and deny outbound DNS to anywhere but Shield. A Shield expert shows you how your network handles each before you trial.
How long does it take to set up?
Live in minutes. The first step is a single DNS setting on the network, then you choose a policy. If your estate runs change control, Purple's engineers plan a pilot on one SSID with your team or your ICT provider.
Does Shield work on WiFi that is not run by Purple?
Yes. Shield is sold on its own for any WiFi network, on any access points, and it bolts onto every Purple Access network. If you can set the resolver for a network, you can filter it.
Keep going
Where to go next
On this site
On other Purple products
The wider picture
Reviewed on 9 October 2026