Evil Twin Wi-Fi on Planes and Hotels: How to Verify the Hotspot

A familiar Wi-Fi name is not proof that the airline, hotel, airport, or conference operates it. An evil twin can use an exact or lookalike network name to attract travelers to the wrong hotspot. The practical defense is to verify the exact SSID and portal process through a separate trusted source, stop on unexpected prompts or certificate warnings, and disconnect instead of investigating the radio yourself.

Protected Management Frames, or PMF, addresses a narrower problem. After PMF is negotiated, it cryptographically protects defined Wi-Fi management traffic, including deauthentication and disassociation frames. It can make selected forged disconnect attempts fail. It does not authenticate the name a person sees, validate a captive portal, prevent a second access point from advertising a plausible name, or stop literal radio-frequency interference.

Direct answer: Verify the official network before joining. On a Delta flight, the official instructions checked August 15, 2026 say to choose DeltaWiFi.com, open deltawifi.com if the portal does not appear, complete the portal, and only then start a VPN. A stronger signal, a word such as fast, or a padlock on a web page is not equivalent evidence.

The Short Version

• Confirm the exact SSID and login process. Use the airline or hotel app, a page saved before travel, printed signage, or staff. CISA specifically recommends confirming both the name and login procedure.
• Do not choose by signal strength or marketing words. A nearby personal hotspot may be stronger and can be named anything.
• Stop on mismatches. Duplicate names, repeated disconnects, a different portal domain, a request for unrelated credentials, or a browser certificate warning are reasons to disconnect.
• Forget the suspect network. Then use cellular service when available or wait for staff to confirm the service. Do not scan, intercept, inject frames, jam, or try to locate the operator.
• Use HTTPS, but understand the limit. Encryption protects traffic to the domain whose certificate was validated. The FTC notes that a scammer can also run an encrypted website.
• Start a VPN after the legitimate captive portal. A tunnel protects traffic after it connects; it does not validate the hotspot or protect a password entered into a fake portal beforehand.
• PMF is useful, not universal. WPA3 requires it, WPA2 deployments may make it optional, and only clients that actually negotiate it receive its protection.

1

SSID shownA human-readable label is advertised. It is easy to copy or imitate and is not a certificate of ownership.

→

2

Portal reachedThe network may redirect a browser. The domain, certificate, and requested data still need scrutiny.

→

3

Secure sessionHTTPS and a VPN can protect defined paths after they are established. Neither identifies the radio.

→

4

Intended serviceThe final domain, app, account, device, and MFA state determine whether protected traffic reaches the right party.

Duplicate or lookalike SSID

Do not choose by strength. Disconnect, forget the network, confirm the exact spelling and login path through staff or an official source, and report the duplicate.

Unexpected portal or certificate warning

Do not bypass the warning, install a certificate, or enter a reusable password. A legitimate captive portal should not require weakening browser trust.

Verified portal, then VPN

Complete only the documented portal process, establish the VPN, and confirm it remains connected. This reduces exposure beyond the tunnel but does not retroactively protect portal entries.

PMF negotiated

Defined management frames gain anti-forgery and replay protection. The network name, captive portal, radio spectrum, upstream service, and destination website remain separate trust layers.

Advanced: PMF policy and session state

Optional mode lets compatible clients negotiate Protected Management Frames (PMF) while other clients may join without it. Required mode refuses clients that cannot negotiate PMF. Check the negotiated state for each associated client instead of assuming the network setting protects every session. Before cryptographic keys exist, initial management traffic does not have PMF's strongest protection. None of these states authenticates the SSID or captive portal.

What The Delta Flight Story Establishes

This article began with Hackaday's August 14 security roundup and the linked 10:06 ThioJoe video. Both examined reports from Delta Flight 591 from Las Vegas to Atlanta after DEF CON 34. Publicly circulated crew communications described a network named Delta WiFi FAST, treated it as a security issue, and used the word "jammed."

Delta's official connection page instead instructs passengers to select DeltaWiFi.com. That makes the reported name a lookalike rather than the documented SSID. TechCrunch's report says passenger Wi-Fi was turned off for roughly 30 minutes and carries Delta's statement that flight safety was not in question, aircraft operating systems were not affected, and Delta was investigating with federal law enforcement and aviation regulators.

Evidence boundary: Those sources support an unauthorized, trusted-looking network name and an airline security response. They do not establish that forged deauthentication frames, RF interference, a credential-harvesting portal, successful credential theft, an arrest, or access to aircraft systems occurred.

Evidence status	What can be said	What cannot be added
Supported in reviewed reporting	A lookalike SSID was reported; crew treated it as a security concern; passenger Wi-Fi was temporarily disabled; Delta said flight safety and aircraft operating systems were unaffected.	The exact hardware, software, operator, motive, or traffic path.
Plausible, not established	A fake hotspot could present a phishing portal. Forged disconnect frames or RF interference could contribute to service loss.	That any of those mechanisms were actually used, or that credentials were collected.
Unsupported in material reviewed	No attributable source reviewed by TechGeeks identified or charged a person or proved an aircraft-system compromise.	Claims that agents met the plane, a named attendee was responsible, or passenger Wi-Fi reached avionics.

What the full video adds

TechGeeks reviewed the full video, its human-authored English captions, metadata, chapters, on-screen references, and source chronology. It traces the public ACARS posts, Delta's official SSID, first-person claims, an early TikTok, and later retellings. Its strongest contribution is not a new technical finding; it is a demonstration of how evidence changed as the story spread.

The video finds support for the rogue-name report and airline response. It does not find reliable proof for the exact attack method, a fake Google login, captured credentials, police boarding, or an arrest. That is why this article does not repeat those details as facts even though several are technically possible and appear in later coverage.

How An Evil Twin Creates Risk

An SSID is the name displayed by a phone or laptop. It helps a person select a network, but the name is not globally registered and does not prove ownership. Two unrelated access points can advertise the same name. An attacker can also choose a small variation that appears newer or more desirable, such as adding Free, Guest, 5G, or Fast.

The risk begins when a person or an auto-join rule selects the wrong network. A rogue hotspot might forward internet traffic, display a convincing captive portal, manipulate name resolution, or provide no useful service at all. The visible SSID alone does not tell an observer which behavior is present. A second SSID is evidence of another broadcast, not proof of phishing or interception.

HTTPS materially changes the passive-snooping risk. When a browser validates the correct certificate for the intended domain, traffic to that site is encrypted. The FTC's current consumer guidance says widespread encryption makes public Wi-Fi usually safe for ordinary web use. The same guidance supplies the critical caveat: a scammer can run an encrypted site, so a padlock only says the connection to that domain is encrypted. It does not say the domain belongs to the airline, hotel, bank, or identity provider the page imitates.

A captive portal is also not network authentication. It is a web workflow that grants access or sells service. A legitimate portal may request an email address, room information, a loyalty login, acceptance of terms, or payment, depending on the operator. Verify that process before travel when possible. Never treat a browser certificate warning, a request to install a root certificate, or an unrelated reusable password as normal portal friction.

Disconnects: Deauthentication, Jamming, Or Failure?

The word "jamming" is often used conversationally for any wireless outage. It has a narrower technical and legal meaning. Keeping the categories separate prevents an alarming symptom from turning into an unsupported attack claim.

Possible cause	What it means	What a traveler may notice	Evidence an operator needs
Forged deauthentication or disassociation	Wi-Fi management messages are impersonated to make an existing session end. PMF is designed to reject protected forgeries after negotiation.	Repeated disconnects or reassociation, which are not unique to this cause.	Authorized radio capture, negotiated PMF state, controller events, client logs, and aligned timestamps.
RF jamming or interference	Radio energy prevents or degrades communication. Intentional jamming is different from protocol-frame forgery.	Broad loss, severe instability, or inability to connect; ordinary interference can look similar.	Spectrum measurements, affected channels and locations, timing, authorized RF analysis, and equipment state.
Congestion or service failure	Capacity, access-point, portal, DHCP, DNS, satellite, air-to-ground, backhaul, maintenance, or coverage problems interrupt service.	Slow pages, portal loops, no address, partial reachability, or disconnects.	AP and controller health, client counts, DHCP/DNS/portal logs, backhaul telemetry, and maintenance records.
Operator shutdown	The venue intentionally disables guest Wi-Fi to contain risk or troubleshoot.	The service disappears or stops for many users.	Incident timeline, change record, staff communication, and restoration tests.

A traveler cannot reliably diagnose those causes from a network list or signal meter. Report the exact SSID, time, location or seat area, what the device displayed, and whether the official network also failed. Leave collection and attribution to the network owner and authorized investigators.

What PMF Actually Protects

PMF is the deployed name for protection standardized around IEEE 802.11w and incorporated into later Wi-Fi specifications. Current Wi-Fi Alliance security material says WPA3 networks require PMF and describes PMF protection for unicast and multicast management action traffic. Current Cisco Catalyst 9800 documentation provides the narrower frame list: deauthentication, disassociation, and defined action frames. Frames outside the protected set do not become protected merely because PMF is enabled.

For an associated client that negotiated PMF, a forged protected deauthentication or disassociation message should fail cryptographic validation. PMF also uses Security Association Query procedures to make selected attempts to tear down an existing association harder to spoof. This is a meaningful resilience control because it addresses a protocol-level path to forced disconnection.

NIST IR 8235 independently documents the same deauthentication-versus-jamming distinction, says PMF is supported in WPA2 and mandatory in WPA3, and notes an important timing boundary: initial management traffic used before cryptographic keys exist is not protected. In other words, PMF gains its strongest relevance inside an established security context. It is not a signature over every network advertisement a traveler sees.

Disabled, optional, and required are different policies

• Disabled: the WLAN does not offer PMF protection.
• Optional or capable: compatible clients can negotiate PMF, but a legacy client may associate without it. The SSID setting does not prove every session is protected.
• Required: clients must negotiate PMF to associate. This gives the clearest policy but can reject old or noncompliant clients.

Operators should verify the negotiated state per client rather than relying only on the WLAN profile. Cisco's current documentation, for example, distinguishes the configured PMF support from a client record showing whether 802.11w was actually negotiated. The exact field names vary by vendor.

Traditional open Wi-Fi and Enhanced Open

A traditional open WLAN has no per-user WPA key exchange, so it does not provide the same keyed PMF context. Wi-Fi Enhanced Open, based on Opportunistic Wireless Encryption, can add unauthenticated per-user data encryption to a public network and can coexist with captive portals. Wi-Fi Alliance lists Enhanced Open and PMF as separate improvements for public Wi-Fi. "Unauthenticated" remains the key word: Enhanced Open can protect the radio link without proving the venue owns the SSID. Travelers still need the identity workflow.

What PMF Does Not Do

• It does not prevent another transmitter from advertising an exact or lookalike SSID.
• It does not make a stronger signal more trustworthy.
• It does not authenticate a captive portal domain or the organization behind a web page.
• It does not stop intentional RF interference, accidental interference, congestion, coverage loss, or failed backhaul.
• It does not protect every management frame, especially initial traffic before keys and protection are established.
• It does not protect a session that did not negotiate PMF on an optional WLAN.
• It does not replace HTTPS, certificate validation, secure DNS where appropriate, MFA, endpoint updates, client isolation, monitoring, or incident response.
• It does not prove or disprove how the Delta Flight 591 incident was performed.

Documented fact: PMF protects a defined set of management exchanges after negotiation. TechGeeks recommendation: require PMF where the tested client population supports it, and pair it with a separate, explicit hotspot-identity process. Lab status: TechGeeks did not transmit deauthentication frames, create an evil twin, jam RF, or test an airline or hotel network for this article.

A Safer Traveler Workflow

Before the trip

• Install operating-system, browser, VPN, and security updates before leaving. Do not make a major update when the only recovery path is an airport connection.
• Turn off automatic joining for open networks. Remove saved airline, hotel, airport, cafe, and conference networks you no longer use.
• Save the airline or hotel connection instructions in the official app or an offline note. A search result reached through the suspect network is not an independent check.
• Use a password manager so a lookalike domain does not receive an expected autofill. Use passkeys or phishing-resistant MFA where available, and carry recovery codes appropriate to your account policy.
• Know which work tasks require your employer's VPN, device management, or approval. A consumer travel workflow does not override company policy.

At the airline, hotel, or venue

1. Confirm the exact network name and procedure. CISA recommends asking appropriate staff before using an airport, airplane, hotel, or cafe hotspot. For a hotel, compare the front-desk answer, room material, and official app. For a flight, use the airline's current instructions.
2. Compare the complete name. Spaces, punctuation, suffixes, and words such as Fast matter. Signal strength does not.
3. Join once and inspect the portal. Confirm the domain and expected request. Do not install unexplained software or trust certificates. Do not bypass a browser warning.
4. Provide the minimum documented information. A portal should not receive a work, bank, email, or identity-provider password merely because it appears after Wi-Fi association.
5. Complete the legitimate portal, then start the VPN. Delta explicitly says passengers must log in or buy a pass before turning on a corporate VPN. Other captive networks often have the same ordering constraint.
6. Confirm the VPN remains connected. Check the client status after roaming, sleep, or service loss. Follow employer policy for kill-switch, DNS, IPv6, and split-tunnel behavior.

For sensitive banking, administrative access, or recovery of a high-value account, cellular service is a useful fallback when it is available and permitted. This is a risk-reduction recommendation, not a claim that HTTPS on public Wi-Fi is universally broken. The FTC's current position is more measured: modern web encryption usually protects the connection, but the user still has to reach the intended site.

When finished

• Disconnect and forget the network if it is temporary. This prevents a future silent join to a similarly named hotspot.
• Restore sharing, discovery, Private Relay, VPN, or other settings only if you changed them and understand the original state.
• Review important account activity if the portal behavior was unusual, even if you stopped before entering a password.
• Record the exact SSID, time, venue, portal domain, and symptoms for the operator. Do not post device identifiers or accuse a nearby passenger or guest.

Failure And Recovery

The real portal will not open

First verify that the connected SSID is exact. Temporarily disconnect the VPN only if that matches the operator's published process and your work policy. Use the operator's documented portal address rather than an arbitrary search result. Delta currently recommends deltawifi.com and, if connection trouble continues, "Forget This Network" and reconnect. If duplicate names or warnings remain, stop and ask staff instead of repeatedly submitting credentials.

You joined the wrong network but entered nothing

Disconnect, forget it, close the portal tab, and move to cellular or a staff-confirmed network. Joining alone does not prove that credentials or content were stolen. Update the operator with the factual details you observed. Watch for unusual prompts or account alerts, but do not invent a breach from the presence of a second SSID.

You entered a password or payment data

1. Move to a trusted connection and updated device.
2. Change the exposed password at the real service. If it was reused, change every account that shared it, beginning with email, password-manager, financial, work, and identity-provider accounts.
3. Revoke active sessions and tokens where the service provides that control. Review MFA methods and recovery details for unauthorized changes.
4. Inspect account activity and payment transactions. Contact the card issuer or service through an official app, statement, saved contact, or manually entered official domain.
5. Report the hotspot to the venue. Report fraud to the relevant provider and authority. Delta's security page says to change a SkyMiles password and contact Delta when account activity changes; the FTC accepts scam reports through ReportFraud.gov.

Do not factory-reset the device as a reflex. A reset can destroy useful logs and recovery state while failing to address an exposed online account. Escalate to an employer or incident-response team immediately if work credentials, client data, privileged access, or a managed device were involved.

Recommendations For Public Wi-Fi Operators

The following are TechGeeks operational recommendations derived from the documented control boundaries. They are not claims that TechGeeks tested a Delta, hotel, airport, or conference deployment.

Control	Recommended action	Verification evidence	Failure or rollback concern
Hotspot identity	Publish one exact SSID and portal domain in official apps, signs, pre-arrival messages, and staff runbooks.	Channel review and staff spot-checks.	Old signs or partner portals contradict the current process.
PMF	Use WPA3 with PMF required where the supported fleet permits; use a measured migration for mixed fleets.	Per-client negotiated PMF state and association results.	Legacy or defective clients cannot associate after required mode is enabled.
Open-network protection	Evaluate Wi-Fi Enhanced Open where platform and client support are adequate; document transition behavior.	Client compatibility, per-user encryption state, and captive-portal completion.	Clients see duplicate profiles, portal loops, or fall back to a traditional open SSID.
Segmentation	Isolate guests from one another and from staff, management, payment, building, safety, and operational systems.	Authorized negative-path tests from representative clients.	A policy change or IPv6 path bypasses intended isolation.
Detection	Alert on unauthorized APs, duplicate or lookalike SSIDs, association churn, abnormal protected and unprotected disconnect events, and infrastructure health.	Test alert delivery and on-call ownership without transmitting harmful traffic.	An alert exists only in a console nobody watches.
Evidence	Time-synchronize AP, controller, DHCP, DNS, portal, authentication, firewall, and upstream logs; define retention and privacy limits.	Cross-system timestamp comparison and retrieval exercise.	A reboot, failover, or storage limit erases the incident window.
Recovery	Preserve evidence, communicate the exact official network, disable guest service when continued use is riskier, and restore from a known-good configuration.	Runbook exercise with a clean client and representative portal flow.	A rushed PMF or portal change creates a second outage and obscures the first cause.

Roll out PMF without hiding compatibility failures

Inventory client classes and authentication modes, test required mode in a representative environment, and define acceptance criteria before broad deployment. Measure association success, roam behavior, portal completion, and the actual per-client PMF state. Keep a time-bounded exception path for known legacy devices rather than leaving the primary network permanently optional without visibility.

The rollback plan should restore the previous WLAN profile from a versioned configuration, identify who can approve the change, and preserve logs from both states. A rollback restores availability; it does not close the security gap. Record which clients forced it and set a replacement or retirement deadline.

Respond to a suspected rogue hotspot

1. Confirm the official infrastructure state and the affected place, time, radios, and client types.
2. Tell users and staff the exact official SSID and portal domain through an independent channel.
3. Preserve controller, AP, authentication, portal, DHCP, DNS, firewall, upstream, and physical-security records before reboots or broad reconfiguration.
4. Disable or restrict guest access when continued operation presents more risk than a temporary outage.
5. Use authorized staff and approved tools for RF location and evidence collection. Minimize payload collection and protect passenger or guest privacy.
6. Restore from a documented known-good state, validate association and portal flows with clean clients, and monitor for recurrence.
7. Route attribution, seizure, and legal process to corporate security, counsel, regulators, and law enforcement as appropriate.

How To Verify The Controls

Traveler verification

• The complete SSID matches an official source that was not obtained solely through the suspect hotspot.
• The portal domain and requested login method match the documented process.
• No certificate warning was bypassed and no root certificate or unknown app was installed.
• The captive portal completed before the VPN started, and the VPN now reports a connected state.
• The network is treated as public, local sharing is limited, and the temporary profile is forgotten after use.

These checks reduce risk; they do not cryptographically prove who owns the access point. A venue could improve that identity problem through managed profiles, Passpoint, WPA3-Enterprise, or other authenticated onboarding, but support and deployment details vary. The reader workflow remains a practical check, not a formal attestation.

Operator verification

• Representative client records show PMF negotiated where policy requires it; the WLAN setting alone is not accepted as proof.
• Legacy-client exceptions are inventoried, monitored, and assigned an expiration or replacement plan.
• Guest-to-guest and guest-to-internal IPv4 and IPv6 tests fail closed.
• Captive-portal domains, certificates, redirects, and recovery paths work on supported operating systems.
• Duplicate-SSID and association-churn alerts reach an accountable responder with useful timestamps and location context.
• Logs remain retrievable after an AP restart, controller failover, or upstream interruption.
• A clean device can connect after known-good restoration, complete the portal, establish a VPN, and retain service through the expected roam path.

Legal, Privacy, And Safety Boundaries

Do not test an airline, hotel, airport, cafe, conference, neighbor, or employer network without explicit written authorization defining scope, time, data handling, and recovery contacts. This article intentionally omits instructions, commands, tools, and hardware for forced disconnection, RF interference, credential capture, or unauthorized monitoring.

The FCC's official jammer advisory says operating a signal jammer in the United States without express authorization is illegal even on private property, and that only authorized federal agencies are eligible to seek permission. A Wi-Fi jammer emits RF energy to prevent communication; that is not the same mechanism as a forged Wi-Fi management frame. Other interference, computer-misuse, privacy, contract, aviation, and testing rules can also apply. Laws vary by jurisdiction, so this is a defensive boundary, not legal advice.

Operators investigating a rogue hotspot should collect only what is necessary, protect account and device identifiers, restrict access to evidence, and define retention. A suspicious hotspot is not permission to capture user passwords or publish passenger identities. A conference attendee, nearby guest, or device owner should not be named from proximity or an unverified social post.

Evidence And Lab Limits

Performed for this article: TechGeeks reviewed the complete 10:06 source video and captions, the Hackaday source review, Delta's official Wi-Fi and account-security pages, current Wi-Fi Alliance security material, NIST IR 8235, current Cisco PMF documentation, CISA and FTC traveler guidance, the FCC jammer advisory, and independent incident reporting. The official connection, PMF, traveler, and legal claims were rechecked on August 15, 2026.

Not performed: TechGeeks did not reproduce an evil twin, send deauthentication or disassociation frames, generate RF interference, inspect an airline or hotel controller, capture traveler traffic, test PMF optional versus required, validate a specific Enhanced Open deployment, or examine Delta's internal evidence. All PMF behavior in this article is documentation-backed, not an original TechGeeks wireless measurement.

What the evidence cannot prove: A lookalike SSID does not prove a phishing portal, a crew message saying "jammed" does not identify an RF or protocol mechanism, a temporary outage does not prove an attack, PMF does not identify a hotspot, HTTPS does not validate a brand, and Delta's statement about this incident does not describe every airline's network architecture.

Publication-Day Rechecks

This is a draft and has not been published to WordPress. Immediately before publication, the editor must repeat these checks and block publication if an outcome is unresolved:

• Reopen Delta's onboard Wi-Fi page and confirm the exact SSID, portal address, forget-network recovery, and connect-before-VPN order.
• Search Delta's News Hub and attributable current reporting for a technical finding, identification, charge, correction, or investigation update. Do not upgrade a rumor.
• Reopen Wi-Fi Alliance, NIST, and current vendor material to confirm WPA3's PMF requirement, the protected frame scope, optional-versus-required behavior, and pre-key limitation.
• Reopen CISA, FTC, and FCC guidance to confirm the traveler and U.S. jammer statements remain current.
• Open every TechGeeks related-reading URL and confirm the title and slug still resolve.
• Validate Gutenberg blocks, the interactive model at desktop and mobile widths, content length, taxonomy, featured-media state, and draft status after any WordPress import.

The Practical Takeaway

The most useful question on travel Wi-Fi is not "Does this network have PMF?" It is "What evidence says this is the venue's network, and which controls protect the session after I join?" The answer needs several layers: an independently verified SSID and portal, correct certificate validation, modern application encryption, a VPN where policy or risk warrants one, secure accounts and endpoints, and operator monitoring.

PMF belongs in that stack because forged management frames are a real protocol problem. Its value is clearest when it is required, actually negotiated, and verified. Its limit is equally clear: it protects selected Wi-Fi management exchanges, not the human meaning of a network name. Verify first, connect deliberately, and report anomalies without turning a defensive response into unauthorized testing.

Related TechGeeks Resources

• The 2026 Travel Router Kit: Safer Hotel Wi-Fi Without Rebuilding Your Network
• 15 Router Security Settings to Audit Before Something Breaks
• Remote Access Without Opening Router Ports
• Network Security Field Notes: Start Here

References

• Delta Air Lines: Onboard Wi-Fi
• Delta Air Lines: Protect Your Data
• Wi-Fi Alliance: Security, WPA3, Enhanced Open, and Protected Management Frames
• NIST IR 8235: Security Guidance for First Responder Mobile and Wearable Devices
• Cisco Catalyst 9800: Protected Management Frames with 802.11w
• CISA: Cybersecurity When Traveling
• FTC: Are Public Wi-Fi Networks Safe?
• FCC: Warning About Cell, GPS, and Wi-Fi Jammers
• Hackaday: This Week in Security, August 14, 2026
• ThioJoe: Idiot Tries to Hack Plane Wi-Fi
• TechCrunch: Delta Investigating a Fake Wi-Fi Network Mid-Flight