Multi-Factor Authentication: More Than One Kind of Evidence

A password is one secret that can be guessed, reused, phished, logged, or stolen from another service.

Multi-factor authentication, or MFA, requires an attacker to obtain a different kind of evidence as well.

MFA combines factors from separate categories, such as something you know, possess, or are.

Two passwords are two steps, but still one factor category. Independence is what creates the extra protection.

A concrete example: a stolen password

An attacker obtains an employee's password from a phishing page.

At the real company login, the password is correct. The service also requires a registered hardware security key.

The attacker does not possess the key, so the password alone is insufficient.

MFA reduces the impact of password compromise. It does not make the account invulnerable to stolen sessions, malicious recovery, or an employee approving a fraudulent prompt.

Factor categories

Common categories are:

• Knowledge: Something known, such as a password or PIN
• Possession: Something held, such as a phone, authenticator app, smart card, or security key
• Inherence: A biometric characteristic, such as a fingerprint or face

Context may add signals such as device health or location, but these are not always treated as independent authentication factors.

A password plus a security question remains knowledge plus knowledge. If both can be learned from the same data breach or social profile, they provide weak independence.

SMS codes

SMS MFA sends a one-time code to a registered phone number.

It is better than password-only authentication in many situations, but can be attacked through:

• SIM swapping
• Mobile-account takeover
• Message interception
• Phishing
• Phone-number recycling
• Weak account recovery

SMS remains useful when stronger options are unavailable and accessibility or device constraints matter.

Treat it as one layer with known limitations, not as proof of high-assurance identity.

Authenticator-app codes

An authenticator app can generate time-based one-time passwords, commonly six digits that change every 30 seconds.

During enrollment, the service and app share a secret. Both independently calculate the current code.

Advantages:

• No mobile signal required
• Not dependent on the phone number
• Broad support

Limitations:

• A phishing site can request and immediately relay the code.
• Device loss requires backup or re-enrollment.
• The shared enrollment secret must be protected.

The code is short-lived, but still usable by an attacker in real time.

Push approval

A login sends a notification to a registered app. The user approves or denies it.

Simple approve buttons can create MFA fatigue: an attacker repeatedly attempts login until the user accepts a prompt to stop the interruptions.

Safer push designs display:

• The requesting service
• Approximate location
• Device details
• A number that must match the login screen

Users should deny unexpected prompts and report them. Organizations should rate-limit prompts and investigate repeated failures.

Security keys and WebAuthn

A hardware security key uses public-key cryptography and binds authentication to the legitimate website.

The service stores a public key. The device keeps the private key. A fake domain cannot request a valid proof for the real domain.

This provides strong phishing resistance.

Platform authenticators built into phones and computers can use the same standards, often unlocked with a PIN or biometric.

Security keys need:

• Backup or alternate keys
• Secure enrollment
• Revocation after loss
• Compatibility planning

They are particularly valuable for administrators and high-risk users.

Biometrics unlock a local secret

A fingerprint or face scan often does not travel to every website.

Instead, the device uses the biometric to unlock a cryptographic credential stored locally.

This distinction matters:

• The site receives proof from the credential.
• The device handles biometric matching.
• The biometric cannot be changed like a password if its representation leaks.

Biometrics are convenient but imperfect. Systems need secure fallback for injuries, sensor failure, device loss, and accessibility.

Enrollment is a high-risk moment

When adding a new factor, the system should confirm that the legitimate account holder requested it.

An attacker who has stolen a session may try to register their own phone or key.

Safer enrollment can require:

• Recent password entry
• Existing-factor confirmation
• Reauthentication
• Notification through another channel
• Delay for high-value accounts
• Administrator review

Removing a factor deserves similar protection and notification.

Recovery can bypass MFA

Recovery methods may include:

• Backup codes
• A second registered key
• A trusted recovery contact
• Verified organizational support
• A recovery key

If support removes MFA after answering easily researched questions, the recovery process becomes the weakest factor.

Backup codes are possession secrets. Store them securely and mark each as used after redemption.

Recovery should be usable during genuine loss without becoming an easy social-engineering route.

Step-up authentication

Not every action needs the same assurance.

A service may allow normal browsing with an established session but require a fresh strong factor before:

• Changing payment details
• Exporting personal data
• Viewing recovery codes
• Adding administrators
• Disabling security controls

This is step-up authentication.

It limits the power of an old or partially compromised session while avoiding constant interruption for low-risk actions.

MFA does not replace secure sessions

After MFA succeeds, the application usually issues a session cookie or token.

An attacker who steals that session may bypass the login factors.

Protect sessions with:

• HTTPS
• Secure cookie settings
• Shorter lifetime for high-risk access
• Rotation
• Device and anomaly checks
• Revocation controls
• Protection against script injection

MFA protects authentication. The resulting session remains a valuable credential.

Choosing an MFA method

In general:

• Security keys and passkeys provide strong phishing resistance.
• Authenticator-app codes avoid phone-number attacks but can be phished.
• Push can be convenient when designed against fatigue and relay attacks.
• SMS improves password-only accounts but has more weaknesses.

The best available method is one users can enroll, use, recover, and support reliably.

Organizations may offer several methods while requiring stronger factors for privileged roles.

Rolling out MFA responsibly

A rollout should include:

• Clear enrollment flow
• Accessible alternatives
• Tested recovery
• Multiple-factor registration
• Support training
• Monitoring of failures and bypasses
• Strong protection for factor changes

Measure whether people are actually protected, not merely whether the MFA setting is marked enabled.

Exemptions should be rare, documented, reviewed, and supported by compensating controls.

Knowledge check

1. Why are two passwords not true multi-factor authentication?
2. What attack can intercept an authenticator code in real time?
3. Why are WebAuthn security keys phishing resistant?
4. How can MFA fatigue lead to compromise?
5. Why must account recovery receive protection comparable to MFA?

The one idea to remember

MFA limits password theft by requiring an independent kind of evidence. Phishing-resistant factors, secure enrollment, protected sessions, and strong recovery determine how much protection it truly provides.