Captive portal security is the part of hotel WiFi that guests see first and hotels understand least. The captive portal is the branded splash page that appears when a phone or laptop joins your guest network, asks for a room number or an email address, and then lets the device onto the internet. It looks like a formality. To an attacker it is the single most valuable page in the building, because whoever controls that page controls the first thing every guest device trusts.
This guide explains, in plain terms, how attackers hijack guest WiFi through the portal, why UK hotels are exposed, and the controls that actually close the gap.
We wrote it as a companion to our wider hotel WiFi security guidance and our breakdown of the CaptiveCrunch hotel WiFi campaign. Where those pieces cover the estate and one specific attack, this one stays on the portal itself: the mechanics of a hijack, the standards that govern it, and a 90-day plan a UK property can actually follow. The house term throughout is deliberate — good cybersecurity here is not a firewall bolt-on, it is captive portal security designed in from the first access point.
Table of contents
- What Captive Portal Security Really Means for a Hotel
- Why the Captive Portal Is the Weakest Link in Guest WiFi
- How Attackers Hijack Guest WiFi Through the Captive Portal
- Evil Twin Attacks: Cloning the Captive Portal Login Page
- Rogue Gateways and DNS Hijacking: Attacking Captive Portal Security From Inside
- The Connectivity Check: How a Captive Portal Redirect Is Weaponised
- What CaptiveCrunch Taught UK Hotels About Captive Portal Security
- The Standards Behind Modern Captive Portal Security: RFC 8908 and RFC 8910
- WPA3 Enhanced Open: Encrypting Guest WiFi Without a Password
- Passpoint and Hotspot 2.0: Captive Portal Security Without a Portal
- Captive Portal Gateway Hardening: The Controls That Matter
- Detecting a Hijacked Captive Portal Before Your Guests Do
- What the UK Numbers Say About Guest WiFi and Captive Portal Security
- A Captive Portal Security Cost Model for a UK Hotel
- Captive Portal Vendor Management: Questions to Ask Your WiFi Supplier
- Incident Response When the Captive Portal Is the Breach
- A 90-Day Captive Portal Security Roadmap for UK Hotels
- Captive Portal Security: Frequently Asked Questions
- References
What Captive Portal Security Really Means for a Hotel
Captive portal security is the set of controls that keep a guest’s first interaction with your network honest. When a device joins an open WiFi network, the operating system runs a connectivity check, notices it cannot reach the internet, and opens the captive portal so the user can accept terms or sign in. That flow depends on three things a guest never inspects: the network they joined is the real one, the page they see is served by the hotel, and the gateway that relayed it has not been tampered with. Break any one of those and the guest is exposed while believing they are safe.
The reason captive portal security matters more in hospitality than almost anywhere else is scale and trust. A hotel invites hundreds of unmanaged devices onto its network every night, most belonging to people who are tired, in a hurry, and conditioned to click “Connect to WiFi” without a second thought. Business travellers among them will sign into email, VPNs and cloud apps over that same connection. The portal is where all of that trust is granted, so it is where a competent attacker aims first.
The portal is a trust anchor, not a login form
It helps to stop thinking of the portal as a login form and start thinking of it as a trust anchor. Everything downstream — DNS resolution, the redirect to the sign-in page, the certificate a browser does or does not warn about — hangs off the assumption that the captive portal in front of the guest is legitimate. Captive portal security is really the discipline of making that assumption safe to hold.
Where the portal sits in the hotel network
Physically, the portal is enforced by a gateway appliance or wireless controller that sits between the guest SSID and the internet. That same box usually runs DHCP and acts as the DNS resolver for every guest device. Consolidating those roles is convenient and cheap, and it is exactly why a single compromised gateway is so dangerous — it lets an intruder rewrite name resolution for the whole guest population at once. Sound captive portal security starts by treating that gateway as a high-value asset, not plumbing.
Why the Captive Portal Is the Weakest Link in Guest WiFi
Most hotel guest networks are open networks. There is no WiFi password, because asking every guest to type a WPA2 passphrase printed on a card is a support nightmare. Convenience wins, and the network is left unencrypted at the radio layer. That single design choice is the root of the captive portal security problem: on an open network, the traffic between a guest device and the access point is sent in the clear, and the portal is the only gate in front of it.
An open network with a captive portal gives guests the feeling of a controlled, private connection while delivering almost none of the protections a password-based network would. Anyone within radio range can watch association traffic, and an attacker with the right hardware can impersonate the network entirely. The portal does nothing to stop that, because the portal is an application-layer page sitting on top of an unencrypted link. Captive portal security cannot be bolted on after the fact when the layer beneath it is wide open.
Open networks broadcast an invitation
The comparison table below shows why the default hotel setup is the weakest of the common options. Each row is a real WiFi mode a hotel can deploy; the captive portal security column is the honest assessment of how much the portal actually protects the guest.
| WiFi mode | Radio encryption | Evil twin resistance | Captive portal security posture |
|---|---|---|---|
| Open + captive portal (typical hotel) | None | Very low | Portal is the only gate; trivially cloned |
| WPA2-Personal (shared password) | Yes, shared key | Low | Key is public, so impersonation still works |
| WPA3 Enhanced Open (OWE) | Yes, per-device | Medium | Traffic encrypted; portal still needs hardening |
| Passpoint / Hotspot 2.0 | Yes, WPA3-Enterprise | High | No portal to attack; device authenticates the network |
The convenience trap
Hotels chose open portals for a rational reason, and that rationality is the trap. Every layer of friction added to guest WiFi generates front-desk calls, poor reviews and lost loyalty. So the portal is kept frictionless, the network is kept open, and captive portal security is quietly deprioritised until an incident forces the conversation. The goal of this guide is to make that conversation happen before the incident, not after.
How Attackers Hijack Guest WiFi Through the Captive Portal
There is no single “captive portal hack”. There is a family of techniques that all end the same way — the guest interacts with something the attacker controls while believing it belongs to the hotel. Understanding the chain is the foundation of captive portal security, because each link is a place to intervene. The table below sets out the four dominant approaches and where each one breaks down under proper controls.
| Attack | What the attacker controls | What the guest sees | Control that stops it |
|---|---|---|---|
| Evil twin AP | A fake access point with the hotel’s SSID | A cloned portal login page | WPA3, 802.1X, WIPS rogue-AP detection |
| Rogue gateway / DNS hijack | The real gateway appliance | A genuine SSID, poisoned name resolution | Gateway hardening, credential hygiene, patching |
| Portal redirect abuse | The connectivity-check response | A fake update or sign-in prompt | Signed portals, RFC 8908 API, user training |
| Credential phishing on the portal | The form fields on the page | A request for email or M365 login | Never collect reusable credentials at the portal |
The common thread: the guest cannot tell
Every one of these techniques works because a captive portal, by design, appears without the user asking for it and before any secure session is established. The guest did not type a URL, did not check a certificate, and often cannot check one because the portal is served over an intercepted connection. Captive portal security has to compensate for the fact that the human on the other end has no reliable way to verify what they are looking at. That is the design constraint every control in this guide is built around.
Attacks scale with device count
A second thread is scale. An attacker does not target one guest; they target the network and harvest whoever connects. A property that puts hundreds of sessions through the portal each night is offering hundreds of chances per night. This is why captive portal security is a volume problem as much as a technical one, and why the numbers later in this guide matter as much as the mechanics.
Evil Twin Attacks: Cloning the Captive Portal Login Page
The evil twin is the classic hotel WiFi attack and the one most guests have unknowingly been near. MITRE ATT&CK catalogues it as technique T1557.004, created in September 2024 and updated in April 2025, sitting under the Credential Access and Collection tactics. The description is blunt: adversaries “deploy fraudulent Wi-Fi access points mimicking legitimate networks to trick users into connecting”, then steal credentials and manipulate traffic. Captive portal security has to assume this technique is always available to an attacker, because the hardware to run it costs less than a night in the hotel.
The mechanics are simple. An attacker brings a portable access point — a WiFi Pineapple is the tool named in ATT&CK’s own procedure examples — and broadcasts the same SSID your guests expect, such as “Hotel-Guest”. Devices that have connected before, or that are simply looking for open WiFi, associate with whichever signal is strongest. Deauthentication frames can be used to knock guests off the real access point so they reconnect to the fake one.
Once associated, the guest is shown a cloned captive portal that looks exactly like the hotel’s, and whatever they type is captured. From the guest’s side, nothing looks wrong, which is precisely the failure captive portal security exists to prevent.
A real conviction, not a hypothetical
This is not theoretical. In November 2025 an Australian court sentenced a 44-year-old Western Australian man to seven years and four months in prison, with a five-year non-parole period, after he pleaded guilty to 15 charges relating to evil twin attacks. Investigators found he used a WiFi Pineapple to detect the probe requests devices broadcast, then “instantly created a matching network with the same name, tricking a device that it is a trusted network”. He ran the fake pages at Perth, Melbourne and Adelaide airports and on domestic flights, harvesting email and social-media logins and thousands of private images.
Airports and planes are not hotels, but the technique is identical, and it is the clearest public illustration of why captive portal security cannot rely on guests spotting a fake.
Why the same-named network wins
The uncomfortable truth is that an evil twin does not need to be clever, only closer. WiFi clients favour the access point with the strongest signal for a given SSID, so an attacker in the lobby with a better antenna beats the hotel’s ceiling-mounted AP two floors up. This is the single hardest problem in captive portal security on an open network, and it is why the durable fixes — encryption at the radio layer and letting the device authenticate the network rather than the other way round — matter far more than anything done on the portal page itself.
Rogue Gateways and DNS Hijacking: Attacking Captive Portal Security From Inside
The evil twin attacks the airwaves. The more damaging attack goes after the gateway. Every guest device is handed a DNS resolver by DHCP, and on most hotel networks that resolver is the captive portal gateway itself. If an attacker takes over that appliance, they do not need a fake access point at all — they own name resolution for every device on the genuine network, with the real SSID and no radio-layer clue that anything is wrong. This is the failure mode that keeps captive portal security experts awake, because the guest experience is flawless right up to the moment credentials are stolen.
Gateways get taken over the boring way. Internet-facing management interfaces — SSH, SNMP, or a web admin console — protected by weak, default or reused credentials are the usual entry point. There is not always a glamorous exploit; often it is simply an admin password that was never changed. Once inside, the attacker points DNS records for common login domains at their own server, and the poisoned portal or fake sign-in page is served over the hotel’s own infrastructure. Captive portal security that stops at the login page and ignores the gateway is guarding the door while leaving the wall open.
When the vulnerability is in the box itself
Sometimes the gateway is the vulnerability. In May 2026, Palo Alto Networks disclosed CVE-2026-0300, a critical buffer overflow in the User-ID Authentication Portal — the captive portal service — of PAN-OS, carrying a CVSS v4.0 score of 9.3. It let an unauthenticated attacker run code as root on affected PA-Series and VM-Series firewalls by sending crafted packets, with exploitation observed before the patch. The affected branches spanned PAN-OS 10.2, 11.1, 11.2 and 12.1.
A captive portal service reachable from an untrusted network is a captive portal security exposure by definition; when it also carries a 9.3 flaw, it is an open door. Patch cadence on the gateway is not optional.
DNS is the pivot point
The reason DNS hijacking is so effective is that it is invisible to the layers guests and even IT staff usually watch. The certificate on a fake sign-in page can be made valid for the attacker’s own lookalike domain, so the browser shows a padlock. The SSID is real. The signal strength is normal. Only the name resolution has been quietly rewritten. Captive portal security therefore has to include DNS integrity monitoring and a hard separation between the gateway’s management plane and the guest data plane — subjects we cover in our hotel network design guide.
The Connectivity Check: How a Captive Portal Redirect Is Weaponised
To understand redirect abuse you have to understand how a device decides a portal exists at all. When a phone or laptop joins WiFi, it quietly fetches a known URL and checks the answer. On Windows, the Network Connectivity Status Indicator (NCSI) requests http://www.msftconnecttest.com/connecttest.txt and expects the exact text “Microsoft Connect Test”, and resolves dns.msftncsi.com expecting the address 131.107.255.255. Apple and Android devices do the equivalent.
If the response is anything other than expected, the OS concludes it is behind a captive portal and pops the portal window. This mechanism is the hinge of captive portal security, because it is the moment a browser is opened automatically, before the user has chosen to go anywhere.
An attacker who controls the gateway or the DNS resolver controls that connectivity-check response. Instead of returning the real answer, they return a redirect to a page of their choosing. Because the operating system opened the window itself, the guest reads it as the hotel’s official portal. That is how the “please install this update to continue” and “sign in with your Microsoft 365 account to get online” lures are delivered — not through a link the guest clicked, but through the automated check every device makes. Captive portal security has to treat the connectivity-check path as an attack surface, not a background nicety.
The three payloads a hijacked portal delivers
Once the redirect fires, the guest typically meets one of three things: a fake sign-in page that harvests credentials directly; a “device code” prompt that tricks the guest into authorising the attacker’s session on a genuine provider page; or a fake browser or driver update that installs malware. The device-code variant is especially nasty for captive portal security because the guest completes multi-factor authentication willingly on a real Microsoft page — there is no lookalike domain and no certificate warning. We break the full chain down in our CaptiveCrunch analysis.
Why “just install the update” is the deadliest prompt
Of the three, the fake update is the one that turns a WiFi nuisance into a full compromise. A guest who types a password has lost a password; a guest who runs an “update” has lost the device. Strong captive portal security includes a simple, repeated message to guests and staff alike: a WiFi network never needs you to install software or run a script to get online. If a portal asks, it is not the hotel’s.
What CaptiveCrunch Taught UK Hotels About Captive Portal Security
The abstract risk became concrete in the summer of 2026. Microsoft published research on 31 July 2026 into a campaign it named CaptiveCrunch, attributing it to the actor it tracks as Storm-2945 and assessing it as a sub-cluster of Midnight Blizzard, the group Western governments link to Russia’s SVR. ReliaQuest had disclosed the same activity on 23 July 2026. Attackers compromised captive portal gateways at hotels and redirected guests to credential-harvesting and malware pages. For UK captive portal security, the campaign was a wake-up call: the targets were the exact appliances British hotels run.
The detail that makes CaptiveCrunch relevant beyond the specific victims is Microsoft’s observation of “commonalities in equipment and management systems” across affected sites. In other words, the weakness was often in the shared captive portal platform, not in one hotel’s mistake. A UK property running the same vendor gateway as a compromised US or Indian hotel inherits the same captive portal security exposure whether or not it has done anything wrong. That is the argument for treating gateway patching and vendor scrutiny as core controls rather than afterthoughts.
The lesson: your supplier’s security is your security
CaptiveCrunch reframed captive portal security as a supply-chain question. Most hotels do not build their guest WiFi; they buy a managed platform and a gateway appliance from a vendor. If that vendor ships weak default credentials, exposes management interfaces, or is slow to patch, every hotel on the platform is exposed simultaneously. The vendor-management section later in this guide turns that lesson into concrete questions you can put to a supplier.
The Standards Behind Modern Captive Portal Security: RFC 8908 and RFC 8910
For years the captive portal worked by hijacking connections — the network deliberately intercepted a device’s traffic to force the portal open. That “attack-shaped” behaviour is exactly what makes portals easy to abuse, because a device cannot tell a hostile interception from a friendly one. Two IETF standards, both published in September 2020, were written to replace interception with something a device can verify, and they are the backbone of modern captive portal security.
RFC 8910 defines a way for the network to tell a device it is behind a portal, cleanly, using a DHCP or Router Advertisement option that carries a URI. It uses DHCPv4 option 114, DHCPv6 option 103 and IPv6 Router Advertisement option type 37, and it replaced the earlier RFC 7710.
RFC 8908 defines the Captive Portal API the device then queries at that URI, returning a small JSON document with the media type application/captive+json. The required field is a boolean, captive, that says whether the device is still restricted; optional fields include user-portal-url, venue-info-url, seconds-remaining and bytes-remaining. Together they let a device discover and satisfy a portal without any traffic interception at all — the structural foundation of trustworthy captive portal security.
The standards are honest about their own limits
Crucially, the RFC authors did not pretend the standards solve everything. RFC 8910 states plainly that “an attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of the attacker’s choosing”, because DHCP and Router Advertisements have no built-in authentication. What the standards buy is visibility: because the portal URI is explicit rather than hidden, a client can “render the page in a sandboxed environment” and label it untrusted.
RFC 8908 mandates HTTPS for the API and warns that a portal hostname may use “confusable characters” to mislead a user. Good captive portal security uses these standards as intended — as a way to make the portal inspectable — while keeping the radio-layer and gateway controls that the RFCs explicitly say they do not provide.
The RFC key reference for portal builders
| Standard | Purpose | Key detail |
|---|---|---|
| RFC 8910 | Tell the device a portal exists | DHCPv4 opt 114, DHCPv6 opt 103, RA opt 37 |
| RFC 8908 | Let the device query portal state | JSON captive flag, media type application/captive+json |
| RFC 8110 | Encrypt open networks (OWE) | Per-device keys, basis of WPA3 Enhanced Open |
WPA3 Enhanced Open: Encrypting Guest WiFi Without a Password
The most important upgrade a hotel can make to captive portal security is to stop running the guest network truly open. WPA3 Enhanced Open, built on Opportunistic Wireless Encryption (OWE, defined in RFC 8110), gives every device its own encryption keys negotiated with a Diffie-Hellman exchange during association — with no password for the guest to type. The guest experience is identical to an open network; the difference is that the traffic between device and access point is now encrypted, and passive eavesdropping stops working. For captive portal security, this is the difference between a link anyone can read and one they cannot.
Enhanced Open does not solve everything, and honest captive portal security says so. Because there is no authentication of the network — only encryption of the traffic — a determined evil twin can still stand up an OWE network with the same name. What Enhanced Open removes is the trivial, passive interception that makes open networks so cheap to attack, and it raises the effort required for an active attack. Combined with Protected Management Frames, which WPA3 makes mandatory, it also makes the deauthentication trick behind many evil twin attacks far harder to pull off.
Why PMF matters for the evil twin
Protected Management Frames deserve their own mention in any captive portal security review. The classic evil twin relies on deauthentication frames to force guests off the real access point. PMF protects those management frames from forgery, so an attacker can no longer trivially kick a device onto the fake network. WPA3 requires PMF, and it is mandatory on the 6 GHz band, which is one more reason to move guest WiFi onto modern hardware rather than keeping a decade-old open SSID running.
Passpoint and Hotspot 2.0: Captive Portal Security Without a Portal
The strongest move in captive portal security is to remove the portal. Passpoint, the Wi-Fi Alliance certification also known as Hotspot 2.0 and built on IEEE 802.11u, lets a device discover, authenticate to and join a network automatically using stored credentials or a certificate — with WPA2 or WPA3-Enterprise encryption and 802.1X authentication behind a RADIUS server. There is no splash page, no room-number-and-surname form, and critically, the device authenticates the network rather than the network merely presenting a page to the device. An attacker cannot clone a portal that does not exist.
For a hotel, Passpoint changes the captive portal security equation from “how do we protect the login page” to “there is no login page to protect”. A returning guest’s device recognises the network and connects silently and securely; a business traveller gets enterprise-grade encryption without lifting a finger. The trade-off is cost and complexity: Passpoint needs a RADIUS back end and provisioning, which is why it remains more common in large chains than independent properties. But as the R3 revision (which addresses WPA3) matures, it is the clearest long-term answer to guest WiFi hijacking, and worth planning for even if it is not this year’s budget.
A staged path most hotels can afford
Few independent hotels will jump straight to Passpoint, and captive portal security does not require it overnight. A realistic ladder is: move the open SSID to WPA3 Enhanced Open this year; harden and monitor the gateway in parallel; and put Passpoint on the roadmap for the next wireless refresh. Each rung reduces the attack surface, and none of them depends on guests changing their behaviour — which is the only kind of control that reliably works at hospitality scale.
Captive Portal Gateway Hardening: The Controls That Matter
Because so many captive portal attacks route through the gateway, hardening that appliance is the highest-leverage work in captive portal security. The controls are not exotic; they are the same discipline any internet-facing device needs, applied to a box that too often ships as an appliance and is then forgotten. The list below is ordered by impact.
- Take management interfaces off the internet. SSH, SNMP and the web admin console should never be reachable from the public internet, and ideally not from the guest VLAN either. This single change closes the most common gateway-takeover path.
- Kill default and reused credentials. Every appliance gets a unique, strong admin password stored in a vault, with multi-factor authentication on the console wherever the vendor supports it. Reused credentials are how CaptiveCrunch-style intrusions begin.
- Patch the gateway on a schedule. CVE-2026-0300 showed a 9.3-severity flaw in a captive portal service exploited before many organisations patched. Treat gateway firmware with the same urgency as a public web server.
- Separate the management plane from the guest data plane. The network that administers the gateway must not be the network guests sit on. This is core network design, and it limits what a compromised guest device can reach.
- Lock down and monitor DNS. The gateway resolver should be constrained to known-good upstreams, and changes to DNS configuration should raise an alert. DNS integrity is the heart of captive portal security once an attacker is inside.
Hardening is continuous, not a project
The mistake hotels make is treating gateway hardening as a one-off installation task. Captive portal security degrades the moment a firmware update is skipped or a temporary admin account is left enabled after a maintenance visit. The controls above only work if they are enforced continuously, which is why ongoing managed IT services and monitoring matter more than the initial build.
Detecting a Hijacked Captive Portal Before Your Guests Do
Prevention will never be perfect, so captive portal security also depends on detection — noticing a hijack before a guest reports fraud. The good news is that most portal attacks leave signals a well-run network can see. The table below lists the practical ones and what each indicates.
| Signal | Likely meaning | Where to watch |
|---|---|---|
| A second AP broadcasting your SSID | Evil twin nearby | WIPS / rogue-AP scan |
| Unexpected DNS config changes | Gateway compromise | Gateway change logs |
| A burst of deauthentication frames | Clients being pushed to a fake AP | Wireless controller |
| Guest reports of “update” prompts | Portal redirect abuse | Front-desk / support tickets |
| Admin logins from new locations | Credential theft on the gateway | Gateway auth logs |
Rogue-AP scanning is a compliance duty too
Detecting evil twins is not just good captive portal security; for any hotel taking card payments it is a compliance requirement. PCI DSS v4.0.1 requirement 11.2.1 obliges an entity to detect and identify both authorised and unauthorised wireless access points at least once every three months — even where wireless is not used in the cardholder data environment, because a rogue AP can be attached so easily. A continuous wireless intrusion prevention system does that automatically and forms the backbone of portal-hijack detection. Our hotel PCI DSS guide covers the wider obligation.
The human sensor
The cheapest detector in captive portal security is a trained front-desk team. Guests who mention a strange WiFi login, a demand to install software, or a page that “didn’t look right” are giving you early warning of a live attack. A one-line note in the incident log, escalated to IT, turns anecdote into signal. Staff who know that a portal never asks you to install anything will flag the exact behaviour an attacker depends on going unreported.
What the UK Numbers Say About Guest WiFi and Captive Portal Security
Captive portal security is easy to defer because the risk feels abstract until it lands. The national data argues against complacency. The UK government’s Cyber Security Breaches Survey 2025/2026, run by DSIT across 2,112 businesses, found that 43% of UK businesses reported a cyber breach or attack in the previous 12 months — roughly 612,000 organisations. Phishing was the dominant vector, experienced by 38% of businesses and present in around 85% of the incidents that occurred. A hijacked captive portal is, at its core, a phishing delivery mechanism with a captive audience, which puts hospitality squarely in the path of the most common attack UK businesses face.
Hotels are attractive because they aggregate exactly the victims phishing campaigns want: mobile, distracted business travellers signing into corporate accounts on an untrusted network. Every one of those sign-ins is a captive portal security event. The phishing that a corporate firewall would filter on the office network arrives unfiltered through the hotel portal, and the traveller’s guard is down because they are “just getting online”. The numbers below turn that exposure into something a general manager can size.
Guest WiFi is corporate WiFi’s blind spot
The strategic point for hotels is that they now sit in other companies’ attack surface. When a guest’s Microsoft 365 credentials are phished through your captive portal, the victim organisation may never learn where it happened — but your property was the venue. Captive portal security is therefore partly a duty of care to guests who are trusting your network with their working life, and increasingly a reputational risk if your brand becomes associated with a hijacking campaign.
A Captive Portal Security Cost Model for a UK Hotel
Abstract risk does not move budgets; numbers do. The worked example below uses a mid-sized UK property and only arithmetic stated here, so you can re-run it with your own figures. It sizes the exposure first, then the cost of closing it, so captive portal security can be argued as a business case rather than a fear.
Take a 200-room hotel at 82% occupancy. That is 164 occupied rooms a night (200 × 0.82 = 164). At an average of 2.3 connected devices per occupied room, that is 377 guest devices (164 × 2.3 = 377.2, rounded to 377). Add roughly 40 public-area devices in the lobby, bar and meeting rooms and the property pushes about 417 captive portal sessions a night.
Over a 30-day month that is 12,510 sessions through the portal. If just one session in 25 belongs to a corporate traveller signing into email or a cloud app, that is 500 credential opportunities every month (12,510 ÷ 25 = 500.4) presented to whoever controls the portal.
Sizing the fix against the exposure
Against 500 exposed corporate sign-ins a month, the cost of captive portal security is modest. The illustrative build below prices the controls this guide recommends for the same 200-room property. The figures are planning estimates to frame the decision, not a quote.
| Control | Indicative cost | Captive portal security benefit |
|---|---|---|
| WPA3 Enhanced Open on existing APs | £0–£1,500 (firmware/config) | Encrypts guest traffic, blocks passive sniffing |
| Gateway hardening + patch policy | £1,200–£3,000 setup | Closes the top gateway-takeover paths |
| WIPS rogue-AP monitoring | £1,800–£4,000/year | Detects evil twins, meets PCI 11.2.1 |
| Managed monitoring + DNS alerting | £3,600–£7,200/year | Catches hijacks before guests do |
| Passpoint (next refresh) | Capital project | Removes the portal attack surface entirely |
Even at the top of those ranges, a full year of layered captive portal security costs a fraction of the fallout from a single publicised guest-WiFi breach — and far less than the goodwill lost when a business guest traces a compromised account back to a stay at your property.
Captive Portal Vendor Management: Questions to Ask Your WiFi Supplier
Because most hotels buy rather than build guest WiFi, captive portal security is largely decided by the supplier. The CaptiveCrunch campaign’s lesson — that shared platforms create shared exposure — makes vendor scrutiny a control in its own right. The questions below are the ones that separate a serious provider from a box-shifter, and they belong in every WiFi vendor management review.
- How is the gateway’s management interface protected, and is it ever reachable from the internet? The answer should be “never”, with MFA on admin access.
- What is your patch SLA for critical gateway vulnerabilities? After CVE-2026-0300, “we patch within X days of a critical CVE” is a fair question to demand a number for.
- Do you support WPA3 Enhanced Open, and can you enable it on our estate? A vendor that cannot encrypt an open network is behind the curve on captive portal security.
- Is the portal served over HTTPS with a certificate we control? A portal on plain HTTP is indefensible in 2026.
- How would we know if our gateway were compromised? If the vendor has no monitoring or alerting story, you are buying a blind spot.
- Do you provide RFC 8908 API support and rogue-AP detection? These are the modern building blocks of trustworthy captive portal security.
Put the answers in the contract
Verbal reassurance is not captive portal security. The commitments that matter — patch timelines, management-interface isolation, breach notification, encryption standards — belong in the contract and the SLA, so there is a remedy when they slip. A vendor unwilling to commit in writing to a patch window for a critical gateway CVE is telling you how the next incident will go.
Incident Response When the Captive Portal Is the Breach
If the portal is hijacked, captive portal security becomes an incident-response problem, and hotels handle these badly when they have not rehearsed. The instinct is to keep guest WiFi running because switching it off generates complaints; the correct move is usually the opposite. A guest network actively harvesting credentials is doing more reputational damage every hour it stays up than an outage would. A rehearsed incident response plan makes that call in minutes, not meetings.
The first hour matters most. Isolate or disable the affected SSID and gateway, capture logs before they roll over, and switch guests to a known-good fallback if one exists. Preserve the gateway’s configuration and DNS records as evidence — they show what the attacker changed. Then work outward: confirm whether the management interface was reached, rotate every gateway credential, and check whether the same platform is used elsewhere on the estate. Captive portal security in an incident is about containing the blast radius quickly and honestly, not protecting the WiFi’s uptime figures.
Tell guests, and tell them straight
The hardest part of captive portal security during an incident is communication. If guests may have entered credentials on a hijacked portal, they need to know so they can change passwords and watch their accounts. Silence protects the brand for a day and destroys it for a year if the breach surfaces later. A short, factual notice — what happened, what to do, who to contact — is both the ethical response and, under UK data-protection duties, frequently the legally required one.
A 90-Day Captive Portal Security Roadmap for UK Hotels
Captive portal security improves fastest when it is sequenced rather than attempted all at once. The plan below turns this guide into three phases a property can execute in a quarter, each ending in a measurably safer guest network.
Days 1–30 — see and stop the bleeding. Inventory every access point and gateway. Change all default and reused admin credentials, and confirm no management interface is reachable from the internet. Enable WPA3 Enhanced Open where the hardware supports it. Brief the front desk that a portal never asks a guest to install software. These moves cost little and remove the easiest captive portal security wins for an attacker.
Days 31–60 — harden and watch. Put the gateway on a patch schedule with a named owner. Stand up rogue-AP monitoring to satisfy PCI DSS 11.2.1 and detect evil twins. Add DNS-change alerting on the gateway. Separate the management plane from the guest VLAN. Review the WiFi vendor against the questions above and get patch and notification commitments into the contract. This phase is where captive portal security moves from reactive to monitored.
Days 61–90 — prove and plan. Run a tabletop incident-response exercise for a hijacked portal, so the “switch it off” decision is made before it is needed. Consider a penetration test that specifically targets the guest network and portal. Put Passpoint on the roadmap for the next wireless refresh. Fold captive portal security into your ongoing IT governance so it is reviewed, not forgotten. By day 90 the property has closed the common attacks, can see the rest, and has a plan to remove the portal attack surface for good.
Captive Portal Security: Frequently Asked Questions
Is a captive portal itself a security risk?
The portal is not inherently dangerous, but the open network it usually sits on is, and the portal is the thing an attacker impersonates. Captive portal security is about protecting the network beneath the page and making the page verifiable, not about removing the portal — though Passpoint, which removes it entirely, is the strongest option where it is affordable.
Can a guest tell if a hotel captive portal is fake?
Usually not, and that is the core problem. The portal opens automatically, before any secure session, so the guest cannot check a certificate or a URL they trust. This is why captive portal security cannot depend on guest vigilance and must be built into the network — the one reliable rule to teach guests is that a portal never needs you to install software.
Does WPA3 stop captive portal attacks?
WPA3 Enhanced Open encrypts guest traffic and its mandatory Protected Management Frames blunt the deauthentication trick behind evil twins, so it materially improves captive portal security. It does not authenticate the network, so a determined evil twin is still possible — which is why gateway hardening and, ultimately, Passpoint matter alongside it.
What is the single most important captive portal security control?
Hardening the gateway. Most damaging portal attacks route through a compromised gateway appliance, so taking its management interface off the internet, killing default credentials and patching it promptly closes more risk than any change to the portal page itself.
How does captive portal security relate to PCI DSS?
Any hotel taking card payments must detect authorised and unauthorised wireless access points at least quarterly under PCI DSS v4.0.1 requirement 11.2.1. Rogue-AP detection is both a captive portal security control and a compliance obligation, which is why continuous wireless monitoring is worth the spend.
References
RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements
RFC 8110: Opportunistic Wireless Encryption
MITRE ATT&CK T1557.004: Evil Twin
Australian Federal Police: WA man jailed over evil twin WiFi attacks
Palo Alto Networks Security Advisory: CVE-2026-0300
Unit 42: PAN-OS Captive Portal Zero-Day Exploitation
Microsoft: Network Connectivity Status Indicator overview
DSIT: Cyber Security Breaches Survey 2025/2026
Wi-Fi Alliance: Passpoint (Hotspot 2.0)
