LineCast Networks
Back

Two-Factor Codes Are How People Get Locked Out Abroad

LineCast Networks

A printed sheet of backup codes on a hotel bedside table beside a passport and a phone

A printed sheet of backup codes on a hotel bedside table beside a passport and a phone

The American government's digital identity guidelines are a long, unglamorous document aimed, in their own words, at "the authentication of subjects who interact with government information systems over networks". In my experience a great many security teams who work nowhere near a government quietly borrow from them anyway. They set out requirements for passwords, one-time-code apps, hardware security keys, passkeys and biometrics, method by method, clause by clause. Only one method has been put in a category of its own, labelled restricted, and NIST says flatly that at the time of publication there is one occupant: sending a code over the public telephone network. Which is to say, the text message your bank has been sending you for years.

Part of the objection is criminal. The same section tells services to weigh risk indicators such as "device swap, SIM change, number porting, other abnormal behavior" before texting anybody a secret. But part of it is plumbing, and the reason NIST actually gives is coverage rather than crime: "Some subscribers may be unable to use PSTN to deliver out-of-band authentication secrets in areas with limited telephone coverage, particularly without mobile phone service." So any service using phone-network codes has to keep unrestricted alternatives available to everyone, and is told to remind people of the limitation before they bind a phone to an account.

The subscriber NIST has in mind is at home, in a valley, with one bar on a good day. The document does not say the category belongs to them alone, and it does not have to: what defines it is a handset the message cannot reach. A border does the same work as the valley, and rather faster. Getting on a plane is one of the quicker ways to join the category.

What happens to a code at the border

A text sent to your home number has to find your handset, and finding it abroad depends on an arrangement between your operator and a network in the country you are standing in. Inside the European Union what is legislated is the price of that arrangement, not its existence. Under roam like at home, calls, texts and data are billed at domestic rates while you are in another member state, and the rule covers what you receive as well as what you send. The regime also runs in Iceland, Liechtenstein and Norway, plus Moldova and Ukraine.

It stops there. The European Commission's own page notes that since the United Kingdom left the EU the regime does not cover trips there, though a number of operators kept the perk of their own accord, and it tells you to ask your provider what roaming costs outside the covered countries before you travel. That is the shape of the whole problem in miniature: a rule that is true of one country, not quite true of its neighbour, and false a border further on.

None of it is a promise that the message arrives. Price is one thing, delivery another, and in practice the message is rarely what fails. What fails is the arrangement around it. Roaming was switched off to avoid a bill. The travel data plan carries data and not your number. The home SIM is in a drawer at home, or in a phone that was lifted from a café table in a city where you do not speak the language and cannot walk into a shop to replace it. Every one of those is a normal, sensible decision, and each of them severs the one channel your bank insists on using.

One phone scanning a QR code displayed on another phone across a kitchen table

The app that does not need a network

The alternative is a code-generating app, and its virtue abroad is stated plainly in Google's own documentation: "You can still generate codes without an internet connection or mobile service." A time-based code is arithmetic performed on a shared secret and the clock. Nothing arrives from anywhere. A phone in flight mode, in a valley in Georgia, on a train through a tunnel, will produce the same six digits your bank is expecting.

The catch is moving the secrets, and this is the part people leave until the night before. Google Authenticator syncs its codes when you sign in to a Google Account on the new device. Without an account, the transfer is manual: Menu, then Transfer accounts, then Export accounts on the old phone, which produces a QR code that the new phone scans. Note the requirement buried in that: the old phone must be working and in your hand. This is a job for a kitchen table, not an airport gate.

Then there is the detail that catches people who set things up in a hurry. Google warns that "it may take up to 7 days for Google Authenticator to show up as an available option for sign in." Enrol the app on the eve of departure and you can land with a phone that generates perfect codes your account will not yet accept, and a home number that no longer reaches you. Both doors, locked, from opposite sides.

Microsoft's app has its own asymmetry worth knowing before you leave. Its backup restores different things depending on what the account is. Personal accounts that use a rotating one-time code come back with the code intact. Work or school accounts back up the account name only, and you must sign in again to restore them, which is precisely the thing you cannot do when you are locked out.

One more small thing that goes wrong in transit. Google's checklist for a code the service refuses works through the obvious suspects first, the code that expired while you were typing it, the wrong app, the wrong account, and then ends on the clock: check that "the time on your device is synced and correct for your local time zone." Since version 7.0 the app has no time correction of its own and takes the time from the operating system, so a handset with the hour set by hand, which is more common than it should be among people who fiddle with settings before a trip, will drift out of the window and produce codes that are wrong in a way nothing on screen explains.

Print the backup codes, and put them somewhere stupid

Every serious account offers backup codes, and almost nobody carries them. Google issues them in sets of ten. Each one stops working the moment it is used, generating a fresh set silently retires the old set, and the help page suggests printing them and keeping them "somewhere safe, like where you keep your passport or other important documents." People in Google's Advanced Protection Program cannot download them at all.

The advice about the passport is better than it sounds, because the useful property of paper is that it fails independently of everything else. The two common mistakes both violate that. Storing the codes in a password manager whose vault sits behind the account you are trying to reach is a circle, not a backup. Photographing them into the cloud album on the phone is a copy that gets stolen at the same moment as the original.

Paper, folded into the lining of the bag that is not the bag with the phone in it. It looks absurd until the evening it is the only reason you can pay for a room.

A hardware security key on a keyring beside a boarding pass and foreign coins

Apple's particular way of losing you

Apple displays verification codes automatically on trusted devices, which works beautifully at home, where your other devices are, and less well in a hostel where the only Apple hardware you own is the phone you are trying to sign in from.

Two details are worth carrying. First, the sign-in alert can carry a small map showing roughly where the attempt came from, and Apple is candid that the pin is placed using the new device's IP address and "might reflect the network that it's connected to, rather than the exact physical location". If a login you know is yours appears to come from a city two hundred kilometres away, that is usually the hotel's network provider, not an intruder.

Second, the endgame. If you have access to neither a trusted device nor a trusted phone number, you are into account recovery, which Apple says "might take a few days or longer, depending on the specific account information you can provide", adding, with unusual bluntness, that "contacting Apple can't help speed up the process." There is no counter to plead at. The fix is to add a second trusted phone number before you leave, belonging to somebody who will be sitting at home while you are not.

Why the bank suddenly does not trust you

The suspicion you meet abroad is not a glitch. In Europe it is written into law. Payment providers must run transaction monitoring on a set of risk-based factors that opens with "lists of compromised or stolen authentication elements", and a provider that wants to wave a payment through without a challenge has to perform a real-time risk analysis that turns up none of six listed things. Four are the ones you would guess: "abnormal spending or behavioural pattern of the payer", "unusual information about the payer's device/software access", malware anywhere in the authentication session, a known fraud scenario. The other two are this article's whole subject, sitting there in the statute as items (v) and (vi): "abnormal location of the payer" and "high-risk location of the payee".

Read that as a description of yourself on the third day of a trip. New network, new country of origin for the connection, spending in a currency you have never used, possibly a borrowed laptop, certainly a pattern the model has not seen, and now a location that the regulation itself has told the bank to count against you. The friction is the system doing its job on the profile you now present.

The same logic runs through account recovery, which is where the joke turns cruel. Google's guidance for people trying to recover an account tells them to use a device they frequently sign in from, the browser they usually use, and to "be in a location where you usually sign in, like at home or at work." The recovery path is calibrated for the one place you are not.

Work accounts can be blunter still. Microsoft's corporate identity platform lets administrators define named locations by country, resolved either from the IP address using a periodically updated mapping table or from GPS coordinates collected hourly from the authenticator app on the employee's phone. Policies can then simply refuse. Nobody tells you this at the leaving drinks. If your work depends on that account, ask before you fly, and ask specifically about the countries you will be in rather than about travel in general.

What actually makes this survivable

Passkeys are the direction all of this is moving, and the synced sort behaves well on the road. FIDO's own vocabulary splits them in two. A synced passkey is copied through a cloud service to the other devices signed in to the same passkey provider, and that copying is end-to-end encrypted, so one made on a laptop is already waiting on the phone. A device-bound passkey never leaves the thing it was created on, which is an excellent property in an office and a trap on a trip: if yours lives in a work-managed profile on the laptop you left at home, then it too is at home. Find out which kind you have before you lean on it.

A hardware security key is the device-bound version you can carry, and FIDO points at precisely the situation this article describes, where every device holding your synced passkeys is gone and the key is the thing that gets you back in. It does not care whether you can reach any account at all. It fits in a coin pocket.

The test to run before you go is not whether you can log in. Sitting at your own desk, on your own network, with your own phone charged and beside you, everything works. The test is whether you could log in from a bus, on a borrowed handset, with your own phone at the bottom of a canal and your home number ringing in an empty flat. Run that test in your kitchen, three weeks out, while the old phone still turns on and the printer still has ink. It takes an afternoon. The alternative takes a few days or longer, and contacting anybody cannot speed it up.

Sources