Home / Insights / MFA Without Mobile Phones: Securing Sign-Ins When Staff Can't Use Their Own Device

MFA Without Mobile Phones: Securing Sign-Ins When Staff Can't Use Their Own Device

Multi-factor authentication (MFA) is one of the most effective things any organisation can switch on. The NCSC recommends it for cloud services and email, and it's part of the technical controls in the government-backed Cyber Essentials scheme. The usual way to roll it out is simple: staff install an authenticator app on their phone and approve sign-ins from there.

The trouble is that "just use your phone" doesn't work for everyone. This article looks at why MFA without phones is a real need in many organisations, and the practical options that keep accounts protected when a personal smartphone isn't the answer.

Why phone-based MFA doesn't always fit

In early years and school settings, it's often not appropriate for staff to have their personal phones on them at all. The EYFS statutory framework expects a setting's safeguarding policy to cover the use of mobile phones, cameras and other devices that can take and share images, and many nurseries keep personal phones in lockers during the working day. That's the right call for safeguarding, but it means a staff member at a shared tablet or classroom PC may have no phone to approve a sign-in with.

In business IT the reasons are different but just as common:

• Staff who don't want work apps on a personal phone, and aren't issued a company one.
• Shared or shift-based roles, such as warehouse, production or front-desk staff using a common workstation.
• Areas where phones aren't allowed or don't get a signal.
• People who simply don't own a smartphone.

If the only MFA method on offer is a phone app, these users either end up excluded from the policy, with exceptions that quietly become permanent, or they find workarounds that weaken security. Neither is a good outcome.

Practical options for MFA without phones

Microsoft 365 and Microsoft Entra ID, along with most other major identity platforms, support several sign-in methods that don't depend on a personal phone. The right mix depends on how and where people work.

Hardware security keys (FIDO2)

A small USB or NFC key that the user plugs in or taps, usually combined with a PIN. Security keys are phishing-resistant, because they only respond to the genuine site they were registered with. They suit staff who use different shared devices, as the key travels with the person. The trade-offs are the upfront cost per key and the need for a process for lost or forgotten keys.

Windows Hello for Business

Sign-in on a managed Windows device using a PIN or biometrics tied to that specific device. It works well for people who have their own assigned laptop or desktop. It's less suited to hot-desking or shared machines, because each user has to enrol on each device they use.

Company-issued devices

Where a role genuinely needs mobile access, issuing a managed work phone or tablet removes the personal-device question altogether. It costs more, but it also brings the device under your management, so it can be wiped if lost and recorded properly in your asset register.

Hardware tokens

Some platforms support small key-fob tokens that display a one-time code. They're simple for users and need no phone, but they're not phishing-resistant, so they're best treated as a fallback rather than the first choice.

Temporary Access Pass for onboarding and recovery

Entra ID's Temporary Access Pass is a time-limited code that IT can issue so a user can sign in and register a stronger method, for example on their first day or after losing a security key. It's a useful tool for the help desk, not an everyday sign-in method.

What to avoid

• Blanket MFA exclusions. If a group can't use the default method, give them a different method rather than switching MFA off for them.
• Shared MFA devices. One phone in the office that "everyone uses" to approve sign-ins defeats the point, because the second factor no longer proves who is signing in.
• Relying on text messages where you can avoid it. SMS codes are better than nothing, but they're weaker than app-based or hardware methods and are better kept as a backup.

Building a policy that covers everyone

A sensible approach is to treat MFA as compulsory for every account, and then decide the method by role:

1. List your user groups and how they work: own laptop, shared devices, mobile, on-site only.
2. Choose a default method for each group, favouring phishing-resistant options where you can.
3. Plan for the edge cases: lost keys, new starters, temporary staff and contractors. Fold this into your joiners, movers and leavers process.
4. Use Conditional Access (an Entra ID P1 feature) to require stronger methods for admin accounts and sensitive systems. Smaller organisations without P1 can start with Microsoft's free security defaults, which turn on MFA for everyone.
5. Train people on why, not just how. MFA works alongside, not instead of, phishing awareness.

Takeaway

MFA without phones isn't a compromise; it's often the more secure route. Security keys and device-bound sign-ins are harder to phish than a push notification. The goal is simple: every account protected, with a method that fits the way each person actually works, and no quiet exceptions.

If you'd like help reviewing your sign-in policies or rolling out MFA across a mixed workforce, KPCR's managed IT services and IT consultancy can help. Get in touch for a no-pressure chat.