Multi-Factor Authentication Basics

The idea in brief

A password is a single piece of evidence. If someone else learns it, through a phishing email, a reused password from another site or a lucky guess, they may be able to sign in as you. Multi-factor authentication, usually shortened to MFA, asks for more than one kind of evidence, so that a stolen password alone is not enough.

This article explains what counts as a factor, why combining them helps, and what to think about when introducing MFA in an organization. It is general information, not security advice. Qualified security professionals should guide decisions about real systems.

What counts as a factor

Authentication factors are traditionally grouped into three categories.

• Knowledge: something you know. Passwords, passphrases and PINs.
• Possession: something you have. A phone that receives a code or approval request, an authenticator app, a hardware security key or a smart card.
• Inherence: something you are. Fingerprints, face recognition and similar characteristics.

The important point is that the factors come from different categories. Asking for two passwords is not multi-factor, because both are things you know and both can be stolen in similar ways. A password plus a code generated on your phone is two factors, because an attacker would need both your knowledge and your device.

Sometimes people count location or time of day as additional signals. Systems may use these to decide whether to ask for extra proof, but they are better seen as context than as factors in the traditional sense.

Why combining factors helps

Different factors fail in different ways. Passwords can be guessed or phished, but not by someone who lacks your phone. Phones can be lost, but a thief would also need your PIN or fingerprint to use them. Layering factors means that one failure does not automatically become a breach.

This is a reduction in risk, not an elimination. MFA does not stop every attack. Some methods can be defeated by tricking users into approving requests they did not start, or by intercepting codes. Because of this, some methods are generally considered stronger than others; hardware keys and app-based approvals are often seen as sturdier than codes sent by text message, though the right choice depends on the situation. A security professional can help weigh the options.

Common methods

• Text message or voice codes. Easy for users and require no extra software, but they depend on the phone network and can be intercepted or redirected in some attack types.
• Authenticator apps. Generate codes or prompt for approval on a phone. They are widely used and avoid dependence on the phone network.
• Hardware security keys. Small devices that the user plugs in or taps. They tend to be resistant to phishing but need to be bought, distributed and replaced when lost.
• Biometrics. Convenient, but a fingerprint cannot be changed if compromised, so they are typically combined with a device rather than used alone.

Where MFA fits in a central setup

MFA works best when applied consistently, which is one reason it is usually discussed with central identity services. If every application runs its own login, each needs its own MFA setup, and gaps appear. With single sign-on, MFA can be applied once at the central login and cover many applications. That is convenient, but it also concentrates trust in one place, so the central service deserves particular attention. MFA is mainly a form of authentication and does not decide what people may do; that belongs to authorization.

Administrator and other privileged accounts are often a first priority, since the consequences of their compromise are larger. Remote access and systems holding sensitive data are other common candidates. Wider requirements may also arise from centralized IT security programs.

Rollout considerations

Introducing MFA is as much a people project as a technical one. Points to think about include:

1. Scope and order. Decide which systems and groups come first. Many organizations start with administrators and remote access, then widen.
2. Method choice. Offer methods that suit the workforce. Not everyone has a company phone, and some roles, such as shop-floor or shared-device work, need alternatives.
3. Enrollment. Registering a second factor is a moment of risk. Verify identity properly before letting someone enroll, otherwise an attacker could register their own device.
4. Recovery. People lose phones. Define a safe recovery process, and treat it carefully, because attackers target help desks. Staff on the support side need clear instructions on verifying callers, which links to good remote IT support practice.
5. Exceptions. Service accounts and old systems may not support MFA. Record the exceptions, assign owners and look for compensating controls.
6. Communication and training. People accept extra steps more readily when they understand the reason. Plan system training approaches and clear messages, and expect questions in the first weeks.
7. Support capacity. Expect more help desk contacts at launch.

Costs and trade-offs

MFA adds a small amount of friction to every sign-in, and poorly planned rollouts can frustrate staff. Frequent prompts may lead to approval fatigue, where people accept requests without thinking. Hardware keys have purchase and logistics costs. A central dependency matters too: if the MFA service or its notification channel is unavailable, people may be locked out, so a fallback plan is needed.

None of this argues against MFA. It does mean that the design, from the choice of methods to the recovery process, should be chosen thoughtfully and revisited as threats and tools change.