Two-step sign-in for hotel staff: where it matters first and how to roll it out

Two-step sign-in asks for two different proofs before an account opens: something you know, like a password, and something you have, like a code on your own phone. In a hotel it belongs first on email, OTA (online travel agency) extranets, payment portals and PMS admin accounts, then on the front desk, with named accounts instead of shared ones.

The extranet is still signed in on the back-office PC from the morning shift, the reservations password is on a note under the keyboard, and three people plus one former employee can open the same account. Adding a code to that account changes less than it looks. This article explains what two-step sign-in actually stops, which hotel accounts deserve it first, what to do about the shared desk login, and how to roll it out without stopping check-in. You will finish with an ordered list you can start on this week.

What does two-step sign-in add, and what does it not stop?#

It adds a second, separate proof so that a password alone cannot open the account. It does not stop someone who already has an open session, or a person being walked through the login by a convincing caller.

Define the terms once for staff, in plain words. The password is something you know. The second step is something you have, like a phone or a hardware key, or something you are, like a fingerprint. Two passwords are not two steps, because both are something you know.

The second proof raises the cost of the most common attack on a hotel account: a password reused from a personal account, seen over a shoulder, written on a note, leaked from another service, or remembered by someone who left the job. Each of these gives an attacker one proof. Two-step sign-in means one proof is not enough.

It does not stop everything. A fake page that passes the code along in real time defeats it. An unattended PC that is already signed in bypasses it entirely. A person who approves a prompt they did not start hands over the second factor willingly. And it does nothing about an employee misusing an account they are legitimately entitled to use.

Session hygiene carries the rest of the weight. A short automatic lock on every desk PC, a sign-out at shift change, and a separate operating-system user per person rather than one shared desktop: these close the gaps the second factor leaves open.

Say the honest version to the team: this makes the cheapest attack expensive, it does not make an account safe. And decide in advance what happens after a mistake, or people will hide mistakes. The sequence is simple: report to the manager, change the password, sign out all sessions, and check recent rate changes and cancellations.

Which accounts should get two-step sign-in first?#

Start with the accounts that can move money, change prices or reset everything else: email first, then the extranets and payment portals, then PMS administration and vendor portals, then everyone else.

Email comes first because it is the reset route for every other account. Whoever holds the inbox can reset the extranet password, the channel manager password and often the domain registrar. Protecting the inbox protects the chain.

OTA extranets and the channel manager come second. Rates, availability, cancellations and guest messages sit there, and a takeover is visible to guests within hours through wrong confirmations and odd replies. Payment and banking portals, and the virtual POS back office, move money directly; treat them at the same level as the extranets.

PMS administration and owner accounts can change roles, export guest data and void records, which is more power than any single reservation. Vendor and integrator portals are the forgotten layer: the e-invoice integrator, door lock management, Wi-Fi management and any portal tied to guest identity notifications. Domain, DNS and social accounts are small in number and large in damage; a lost domain is a lost brand.

Only after those come the everyday named accounts for reservations, front desk and housekeeping supervisors. This is where MFA for hotel staff accounts becomes a daily habit rather than an emergency measure, so it comes last, after the high-damage accounts are locked down. If shared passwords are part of the problem, start with the routine described in shared passwords in hotels: a routine for extranets, Wi-Fi and social accounts.

What do you do about the shared login at the front desk?#

A shared login with one phone collapses two-step sign-in into one step for everyone who can reach that phone. The fix is to stop sharing the account, not to add a code to it.

Understand why sharing exists before removing it. Shift handover, one PC at the desk, seasonal staff arriving mid-week, pressure to check a guest in within seconds, and a habit of buying fewer user licences than people: these are real constraints, and a plan that ignores them will be worked around.

Name what sharing costs. There is no record of who voided a charge or changed a rate. There is no way to cut off one person without cutting off the desk. And the second factor ends up on a phone in a drawer, which is a second step in name only.

Three options, strongest first. Option one: a named account per person with role-based permissions, so the desk sees rooms and bills but not rates or reports; the setup questions are covered in PMS user roles and permissions: a setup checklist for hotels. Option two, the compromise: a low-privilege desk account limited to a small set of actions, with the second step bound to the desk device and a written sign-out log at handover. Option three, the weakest: one account per shift, disabled and reissued at handover, which at least leaves a trail of which shift did what.

Never accept a single phone that everyone uses, or a code written next to the screen. If phones are not allowed at the desk, a hardware key kept on the desk keyring with a named sign-out is the honest compromise. Say plainly that it is weaker than a personal device.

Which second factor will staff actually use?#

Choose by what the shift looks like, not by what is strongest on paper. A method that cannot be completed in ten seconds at check-in will be worked around within a week.

A code by text message works on any phone with no app to install, and fails in a basement office with no signal, on a foreign roaming number, or on a shared desk phone. A code generated by an app on the person's own phone works offline and needs a smartphone with charge; setup takes a few minutes per person and should be done with them, not for them. A push approval is the fastest and trains people to tap approve without reading; pair it with number matching so the screen shows a number the person must compare. A hardware key needs no phone at all, which suits housekeeping, kitchen and anyone without a smartphone; it costs money per key, gets lost, and needs a spare kept in the safe. A passkey or device biometrics is strong and quick on a personal device and awkward on a shared desk PC, so reserve it for managers with their own laptop or phone.

Whatever the method: one factor per person, at least one backup method, printed recovery codes in the safe, and a written lost-phone path that staff have walked through once.

How do you roll it out without stopping the desk?#

Roll out by department in order of risk, one shift at a time, with the lost-phone procedure written and tested before the first person is switched on.

Inventory the accounts first and give each one a named owner, a person rather than a department, so there is someone to ask when a prompt appears at an odd hour. Switch on in this order: owner and finance, reservations and revenue, front desk supervisors, the desk itself, outlets, housekeeping. Each step is small enough to reverse in an afternoon.

Do each switch at a shift change with the person present, never at the end of a Saturday night and never in the first week of high season. Test with one volunteer per shift before the whole team, and keep a named helper on each shift for the first week.

Write the lost-phone procedure as steps: who the person calls, how identity is confirmed, who may issue a temporary code, how long it lasts, and where the issue is recorded. Keep one break-glass administrator account with its factor sealed in the safe, log every use, and read the log monthly; an unlogged emergency account becomes the new shared password.

Tell staff what the first week feels like: slower sign-ins, more help requests, and a manager who answers quickly rather than a queue at the desk.

How do you teach it with a phishing scenario?#

Teach one rule that survives a convincing page: a code is only entered on a page you opened yourself, and it is never read aloud to anyone.

For example, a reservations agent receives a message that looks like an extranet notice about a new booking. The link opens a page that looks exactly right, asks for the password, then for the code, and the code is passed along to the attacker while the agent waits. For example, a caller says they are from the software supplier's support team and need the code to fix the rate screen, at the exact moment the agent is checking a guest in. Both are realistic, and neither is stopped by the second factor on its own. The wider pattern is described in fake booking messages and extranet takeovers: protecting the hotel and its guests.

Give staff three rules they can repeat: never read a code aloud, never approve a prompt you did not start, and when in doubt close the page and open the extranet from your own saved bookmark. Teach with the real screens at handover in five minutes, not with a slide deck once a year, and repeat at the start of every season when new staff arrive.

Say what to do after a mistake, in the same lesson: tell the manager immediately, change the password, sign out all sessions, and check recent rate changes and cancellations together. Keep the tone on the process, not the person; a team that expects punishment stops reporting the one event that matters.

Which accounts still have no second step?#

Review quarterly against the staff list and the vendor list, because accounts outlive the people and projects that created them.

Compare the account list with the current payroll and seasonal list, and disable on the last working day rather than at the end of the month. Check contractor, vendor and integration accounts, and any key that lets a system in without a person; that is a separate problem from staff sign-in, covered in who can reach your hotel systems: vendor remote access, integrations and API keys.

Close the accounts created for a finished project: a renovation, a temporary outlet, a short sales push, a consultant who left in spring. Record five things per account: the account name, its owner, the factor type, the backup factor, and the date it was last reviewed.

Walk the recovery path once a year instead of reading it. A manager who has never issued a temporary code will improvise under pressure. Report the review to the owner in one page, with the accounts still open and the date each will close.

What to do next#

Pick two accounts this week, the main inbox and the extranet you sell most rooms through. Name one owner for each, and switch on the second step there before you design a full rollout. The rest then becomes a sequence rather than a project: the second factor protects the login, named accounts protect the record of who did what, and the written fallback protects the shift when a phone is lost.