Is That Wi-Fi Login Page Real? Check Before You Type a Password

You join the venue's Wi-Fi, a page opens, and it asks you to sign in with an email address or a company account. The network name matches what the front desk told you, and the logo looks right. Neither of those is evidence, because both are copyable in an afternoon. Confirm the sign-in method through a source that is not the page in front of you before you type anything.

Start with the instructions, not the page

That is the whole method: verify through an independent channel, then decide. Everything below is what to compare and what to refuse.

It sounds slow, and it takes about two minutes once you have done it twice.

Read the domain, not the design

Ask the venue how its guest access works, or read the card, receipt or confirmation email that came with the booking. Compare the sign-in domain and the requested information against those instructions. Venues do use outside portal services, so an unfamiliar domain needs verification rather than an automatic assumption in either direction. A domain that matches the instructions is not proof of safety, but a mismatch is a reason to stop.

Look at the address bar rather than the page layout. A padlock only says the connection to that host is encrypted; it says nothing about whether the host is the one the venue intended.

An HTTPS warning is a stop sign, not a thing to click through.

Read what the page is asking for

A Wi-Fi access page has a narrow job: accept a room number, a voucher code, an email address or a terms checkbox. It has no reason to ask for your VPN private key, your work password, your recovery codes or a payment card for a free network. Those belong to different services, and a page that requests them has told you what it is. Treat the request itself as the strongest signal you will get.

Refuse to install a trust certificate or a helper application because the page says access requires it. Legitimate managed requirements come through your organization, not through a captive portal prompt.

If the page demands either one, disconnect and use another network.

Auto-join decides which network you are on

A saved network name can join automatically, which means the device may be on a network you did not deliberately choose at that moment. Check the platform's auto-join settings and forget networks you no longer need. That single habit removes the most common way a lookalike network gets a device onto it without a decision. It also makes the SSID you are on a deliberate choice rather than a background event.

Two networks with the same name can exist in the same place, and the device picks one without asking. Your memory of which one you joined is not a reliable record.

Verify the network you are actually associated with, not the one you meant to join.

The VPN does not cover this step

A VPN needs the access path before it can connect, so the captive portal happens before the tunnel exists. That ordering means the portal cannot be made trustworthy by the VPN, and the VPN cannot retroactively protect credentials you already gave to a false page. Connect the tunnel after the portal is verified and the network is trusted enough to use. Treat the two steps as separate decisions with separate evidence.

If the page is verified and the tunnel still fails, that is a network problem and it belongs to a different checklist.

If you already typed a work password into a page you now doubt, change it from a known-good connection and tell your administrator what happened. Speed matters more than certainty here.

The captive portal architecture described in RFC 8952 is worth reading once, because it explains why the portal sits outside any tunnel you might build later. That knowledge turns a suspicious page into a decision instead of a guess.