Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.


When a work MFA code does not arrive abroad, first identify whether you are waiting for an SMS, phone call, push approval, or time-based code. Preserve the exact prompt, make only the checks allowed for that method, choose an already registered backup if available, and contact your employer through a verified route before repeated requests create a lockout.
Key Takeaways:
- SMS, voice calls, push notifications, and offline authenticator codes fail for different reasons.
- Record the account, application, time, method, error, device, carrier, and last successful sign-in before retrying.
- Use only a backup authentication method that was already approved and registered for the work account.
- Never share a code, approve an unexpected prompt, disable MFA, or let an unsolicited caller re-register your account.
- After recovery, test a second factor that does not depend on the same phone, SIM, bag, or network.
This is an incident-recovery checklist. The travel 2FA preparation guide explains how to remove single points of failure before departure, while the international travel planning guide covers the wider trip.
Read the prompt carefully. An SMS verification code abroad travels through mobile networks, while a voice call needs reachable voice service. A push notification normally needs data connectivity and a correctly registered app. A time-based one-time password, often called TOTP or OATH, is generated on the device and can work without mobile signal, but it depends on the correct account seed and reasonably accurate device time.
Do not describe every failure as “the code did not arrive.” A six-digit code already visible in an authenticator but rejected by the sign-in page is a validation or time problem, not delivery. A push that never appears differs from a push that appears for the wrong account. A text received after it expired differs from a text that never reached the handset.
Write down the work account, application or resource, displayed authentication method, local time and time zone, device, phone number suffix if shown, carrier, current network, error text, and request or correlation ID. Record the last time this exact method worked and what changed: country, SIM, roaming plan, phone, app installation, device time, password, or company enrollment. These identifiers help administrators locate the related sign-in event.[2]
If you see a prompt you did not initiate, deny it and report it. Do not approve it merely to test whether push notifications work. An unexpected prompt can be an attack against an already known password rather than a delivery fault.
For SMS or voice, confirm that the expected SIM or eSIM is active, roaming is enabled where your plan requires it, the device has service, and calls or messages are not being routed to a different device. Check whether the carrier supports inbound roaming in the destination. Do not expose the full number, account PIN, or a received code to hotel staff or a stranger offering help.
Microsoft warns that SMS delivery is not guaranteed because the destination country or region, carrier, and signal strength can affect it. It recommends using another configured method when delivery remains unreliable.[1] A normal personal text does not prove that an enterprise sender or voice route can reach you, but it is useful evidence for separating a general service outage from one sender path.
For push, confirm that the phone has a working data path, the authenticator is allowed to use data, notifications are enabled, and the correct work account is still present. Open the authenticator directly rather than trusting a notification banner. Do not remove and re-add the account unless the employer directs a controlled re-registration.
For an offline authenticator code, set date, time, and time zone to automatic if company guidance permits, then wait for a new code interval and enter the code once. A code changing on screen proves generation, not that the server still has the same registration. If the account label is ambiguous or the phone was restored from backup, stop and ask IT to verify the factor.
Check the sign-in page for a documented “try another way” or equivalent option before requesting more messages. If company or provider guidance defines a retry limit, follow that limit. Microsoft currently suggests up to five phone or text attempts within five minutes for its service, then escalation; that is a Microsoft-specific support limit, not a universal rule for every employer.[1]
After each permitted attempt, note the local time, method selected, whether the request was accepted, when any code arrived, and the exact rejection. Do not create a rapid loop across browser tabs, applications, and devices. Multiple live codes can arrive out of order, and repeated failures can trigger account or risk controls.
Use the newest code only for the sign-in you initiated on the trusted page. Never send it to a support agent, read it over an incoming call, or enter it into a form reached from an unsolicited message. A service desk can verify your identity through its process without asking you to transfer an active MFA secret.
If one approved network comparison is allowed, switch between trusted mobile data and a trusted private or employer-approved network, then repeat once. Do not install a certificate for a captive portal, use a public computer, or conceal your location to change the policy result. Stop when the evidence shows the factor or policy needs administrator action.
Choose only a method already listed by the official sign-in flow or confirmed by IT. It may be a second authenticator, hardware security key, managed backup device, protected recovery code, or a provider-specific temporary access method. The available choices depend on the tenant and organization; a method used for a personal account is not automatically valid for work.
Keep backup factors independent. A spare code stored only in the locked phone, a security key in the same missing bag, and a second SIM tied to the same suspended account do not provide real resilience. The phone-number continuity guide covers keeping a number reachable, and the lost SIM/eSIM guide applies if the factor itself is missing.
Do not ask a coworker to forward a code or approve your prompt. Do not register a personal phone, email, or authenticator against policy simply because it is nearby. If an approved backup works, record which method restored access and still report the original failure if it could recur.
A VPN cannot deliver an employer's MFA message, validate a one-time code, register a factor, unlock an identity, or override organizational policy. Changing the apparent network location is not a legitimate recovery method.
Use a known service-desk URL, managed support application, published phone number, or manager escalation route. Provide the account identifier in the approved format, destination country, local time zone, application, authentication method, phone-number suffix if permitted, device asset ID, exact error, request or correlation ID, attempts made, and whether another approved factor still works.
State important changes: a new SIM, disabled roaming, replacement phone, authenticator restore, lost device, password reset, time correction, or unexpected prompt. Tell support whether SMS and calls fail generally or only for this sender, and whether push or TOTP behaves differently. That detail is more useful than repeating “MFA is broken.”
Verify any return contact. If someone calls after your ticket, confirm the ticket number through the official system before following instructions. Never reveal a password, active OTP, recovery code, QR enrollment secret, or security-key PIN. Do not accept remote control on an unmanaged device unless the organization's documented process explicitly provides it.
The authorized team may verify registration, reset an MFA method, issue a controlled temporary access credential, or require stronger identity proof. Follow the stated expiry and scope. A temporary method should not silently become the permanent weak factor.
After IT acts, start from a trusted device and the official sign-in page. Test the restored factor once, confirm the intended application opens, and check that no unknown method or device appears in your security information. Ask the service desk to confirm whether sessions, risk state, or Conditional Access blocks need separate remediation.
Replace any temporary factor through the employer's approved enrollment process. Register an independent backup if policy permits, store recovery material separately, and test it without signing out of the only working session. Remove an obsolete phone or number only after the replacement is verified and the organization confirms the safe order.
Document the cause as precisely as the evidence allows: carrier delivery, roaming configuration, notification path, incorrect time, stale registration, device loss, provider incident, or tenant policy. If the cause remains unknown, say so. A successful retry does not prove why the earlier request failed.
Before future travel, check support hours, destination coverage, the exact factors accepted by critical applications, and how to recover without the primary phone. The useful outcome is not merely receiving one code; it is a recovery path that still works when one device, number, or network fails.
Different senders and providers can use different routing, filtering, and regional support. A personal message proves only that some SMS service works. Give the carrier and employer the sender-specific timing rather than assuming the phone is fully reachable.
A time-based code can usually be generated offline, while a push notification normally needs data. The offline code still depends on correct time and a valid registration with the work account.
No. Follow the provider's bounded retry guidance, record each attempt, and escalate. Old and new codes may arrive out of order, and excessive attempts can trigger controls.
No. That would defeat individual authentication and may violate policy. Use the organization's recovery and identity-verification process.
No. Disabling protection turns a delivery problem into a security exposure. Ask IT for an approved alternate or temporary recovery method.
Confirm which number and device are registered, whether the old number remains reachable, and whether another factor exists. Do not remove the old factor until an authorized replacement is tested.
It cannot repair SMS routing, restore a factor registration, or override employer policy. A network change may affect push connectivity, but use only an approved path and do not disguise location.
Disclaimer: This article is for general informational purposes only and does not constitute legal, technical, or other professional advice. We make no guarantees regarding the accuracy, completeness, or timeliness of the content.
Sources checked 12 September 2026.
Related Articles:
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.