Cruise ship cybersecurity in 2026: guest app logins and pentests

TL;DR
Cruise ship cybersecurity in 2026 has a blind spot at the first screen every guest sees: the app login. Class rules for new ships fence guest systems off as an untrusted network, so each guest account stays the cruise line's problem.
- IACS UR E26 Rev.1 applies to passenger ships contracted from July 1, 2024, and reaches guest networks only where they touch ship operational systems.
- Everyone in a cabin sails on one booking number, and Celebrity Cruises uses a 7-digit one. Treat it as an identifier, never as proof.
- Store reset tokens the way you store passwords, and never treat a name and birth date as a login factor.
- PCI DSS v4.0.1 asks for penetration tests at least every 12 months and after significant change.
- Mercury Development's onboard spa software for OneSpaWorld has run on over 160 ships since 2018.
Cruise ship cybersecurity stops short of the guest app
CLIA counted 37.3 million ocean-going cruise passengers in 2025. Each sails on a booking, and the guest app is the front door to it.
Pen Test Partners' guide to testing a ship centers on IT, OT, segmentation and the Windows domain, and names corporate systems compromise the most significant risk. BIMCO's policy position says regulation should not cover business resilience, because commercial security is each company's own job.
A guest account is commercial security. Nobody outside your company checks whether the person in the next bed can sign in as you.
IACS E26 covers new ships, not guest accounts
IACS withdrew the first versions of UR E26 and E27 before their planned start on January 1, 2024, and applies the revised texts to ships contracted for construction on or after July 1, 2024. Passenger ships on international voyages are in scope.
Section 1.3.2 of E26 Rev.1 targets operational technology such as propulsion, steering, power and fire detection. Passenger servicing systems and passenger-facing networks appear only as examples of systems with an IP interface to it. Everything outside scope counts as an untrusted network and has to be physically segmented from the ship's security zones.
So class tests the fence: multi-factor authentication for remote access from untrusted networks, lockout after failed attempts, firewall rules and denial-of-service tests, demonstrated at commissioning. Who can open a guest's onboard account is not on that list.
How we put this guide together
We read the three pages that answer this search: the Pen Test Partners guide, BIMCO's position and the ABS regulatory news page on the two rules. None covers guest apps or account recovery, none has an FAQ, and the ABS page still shows the January 1, 2024 date IACS withdrew.
In October 2026 we checked every rule cited here against its primary text. Cruise patterns come from Mercury's delivery records, without client names. Mercury Development builds this kind of software, so read this as an interested view.
Who tests what at a glance
| Rule | Covers | What gets tested | How often | Guest login in scope |
|---|---|---|---|---|
| IACS UR E26 Rev.1 | Ships contracted from July 1, 2024 | Zones, firewalls, remote access, DoS | Commissioning, special survey | Only its interface to ship systems |
| PCI DSS v4.0.1, 11.4 | Cardholder data environment | Internal, external and segmentation tests | Every 12 months and after significant change | Yes, if the app handles card data |
| US Coast Guard cyber rule | US-flagged vessels, MTSA facilities | Penetration test | At plan renewal; plans due July 16, 2027 | Only if it sits in the plan |
| Your own threat model | Sign-in, recovery, sessions | Account takeover | Each release that changes identity | Yes |
A shared booking number is not a password
Cruise bookings are made per cabin. Disney Cruise Line's help center gives each booked stateroom its own reservation number, so everyone in it sails on one number. Celebrity Cruises' account FAQ lets a guest add a booking with a 7-digit reservation number or a stateroom number.
Both are identifiers. A 7-digit number has at most 10 million values, small enough to walk with a script if lookups are not throttled. A sign-in built on booking number plus last name plus date of birth asks for facts the person in the next bed already knows, and so does any travel agent. NIST SP 800-63B-4 lists the authenticators it accepts, and booking facts are not among them. For checking who someone is, SP 800-63A-4 is blunter: knowledge-based verification shall not be used.
At sea the stakes rise: after online check-in, a guest app can hold travel documents, an onboard spending card and spa or dining bookings.
Build it this way instead:
- Use the booking number to find the reservation, then confirm the person with an authenticator bound to their own account, such as a password, a passkey or a one-time code. Under SP 800-63B-4 an out-of-band code has at least 6 digits, works once and must be used within 10 minutes; SMS is a restricted option, and email does not count as an out-of-band authenticator.
- Give each guest an account and share plans by invitation, not by a number everyone knows.
- Throttle reservation lookups and return the same message whether a booking exists or not, as OWASP asks for reset requests.
Treat reset tokens like passwords
A reset token is a password with an expiry date. Keep it in plain text, in the database or a log, and anyone who reads that table can finish a reset for any account with one open.
The OWASP Forgot Password Cheat Sheet sets the rules: a cryptographically secure random generator, enough length to resist brute force, one user per token, invalidation after use and storage the way passwords are stored. NIST SP 800-63B-4 caps codes and links sent for account recovery at 10 minutes by text message and 24 hours by email, and wants saved recovery codes stored hashed.
Three details catch teams out:
- Build the reset link from a configured domain, never from the request's Host header.
- Serve the reset page with Referrer-Policy set to no-referrer, so the token does not travel to other sites.
- After a reset, end existing sessions and invalidate other open reset links.
Then the cruise problem: a guest on ship Wi-Fi without an internet plan may not open the reset email at all. Recover on board through guest services and a document check, not security questions, which OWASP rules out as the sole reset mechanism.
Sessions that survive the gangway
A ship adds a second failure mode. On our cruise programs, a login token issued ashore has stopped working once the guest joins the ship network, and sign-in through Google needs outside internet the guest may not have.
Skip the long-lived token that works everywhere. Issue a ship-side session after a verified sign-in, keep access tokens short and bind refresh to the device. E26 Rev.1 points to E27 capabilities for systems facing untrusted networks, and session integrity and invalidation of session IDs are on that list.
Revocation has to cross the link too. If a guest resets a password ashore while the ship is out of contact, the ship still trusts the old session, so queue revocations like booking data and apply them on reconnect. Cap the exposure meanwhile: SP 800-63B-4 asks every session for a definite overall timeout, so keep ship-side sessions short and ask for a fresh sign-in before onboard charges or document views while revocation data is stale.
Pentesting ship systems: what class checks and what it skips
A typical ship engagement at Pen Test Partners covers onboard systems, IT and OT segmentation, the core network and satellite equipment, Wi-Fi, the Windows domain and proportionate OT checks. Good coverage of a conventional cargo vessel takes 5 days, complex vessels 8 or more.
That work checks guest Wi-Fi from the network side: segmentation and passwords. Neither that list nor the class tests include whether a booking number signs into somebody else's account. That is an application test against your guest API, and it needs no ship.
The US Coast Guard's 2025 rule adds a third clock for US-flagged vessels and MTSA facilities: a penetration test when the Cybersecurity Plan is renewed. Per its fact sheet, first plans are due July 16, 2027.
Scope a guest app pentest before you book ship time
Run the application test ashore, against a copy of the ship stack with no internet route, and save ship days for what only a ship can show. Put these in the statement of work:
- Both API surfaces: the shore API and the ship API.
- Cabin-mate takeover with a known booking number, name and date of birth.
- Lookup enumeration and rate limits.
- Reset flow: token reuse, expiry, Host header handling, referrer leaks, sessions left alive after a reset.
- Shore-to-ship token replay, both ways.
- Payments: if the app handles card data, PCI DSS v4.0.1 expects tests at least every 12 months and after significant change, plus a retest after fixes.
Test what guests reach: on our cruise programs, APIs have worked in production and failed in QA.
What our cruise programs show
OneSpaWorld describes itself as an operator of health and wellness centers onboard cruise ships. Mercury's spa platform for it has run since 2018 on over 160 ships of multiple cruise lines on onboard servers with no external internet connection. Its E-Forms platform collects pre-treatment surveys with signatures on 1,000+ devices for over 3,000 staff members, syncing in near real time over low or sporadic bandwidth with RabbitMQ. That is data a cabin-mate should never read, held on a ship server that enforces access without help from shore.
For cruise line clients Mercury cannot name under NDA, we build React Native passenger apps with pre-cruise readiness and the boarding pass. The identity patterns in this guide come from that work, including guests who cannot tell free ship Wi-Fi from a paid plan.
Own the identity layer
Class looks at the fence, PCI DSS at card data, the Coast Guard at US-flagged ships and port facilities. Nobody owns the question guests care about: can someone else get into my account?
So change the vendor interview. Ask: "My partner and I share one booking number. Show me why she cannot sign in as me, what your reset table stores and what happens to my session on board when I reset my password ashore." A team that has built this names the code channel, the hash and the revocation queue.
Mercury's About page states that the customer owns the code and all underlying IP, the identity service included.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The sign-in, recovery and session designs behind this article come from the cruise app architecture work in the front-end practice he leads.
Guest login built on a booking number? Get it reviewed before the pentest
Tell us how your guests sign in, recover a password and stay signed in between shore and ship. We will map where a cabin-mate or a leaked reset link gets in and draft the pentest scope.