Two-Factor Authentication: Definition and How It Works

Two-factor authentication, usually shortened to 2FA, requires two different forms of evidence before opening an account. A password is no longer enough: the login must also be confirmed with a device, a temporary code, a security key, or a biometric check.

This second step limits the damage caused by a stolen password. It does not make an account invulnerable, and the method matters. An SMS code, a code from an authenticator app, and a security key do not resist the same attacks.

Why add a second authentication factor?

A password can be reused across websites, exposed in a breach, entered into a fake login page, or guessed when it is weak. In each case, someone who knows the password can ordinarily impersonate its owner.

Two-factor authentication adds an independent requirement. Knowing the password is not enough: the person must also control a registered phone, generate a valid code, or present a physical key. This is particularly useful against credential stuffing, where attackers try email-and-password pairs leaked by other services.

The word independent matters. Asking for two things that a person knows does not create two factors. A password followed by a security question is still two memorised secrets and therefore two proofs of the same kind.

What are the authentication factors?

Common methods fall into three groups.

Something you know includes a password, PIN, or passphrase. It can be copied, disclosed, or captured as it is entered.

Something you have includes a phone, smart card, authenticator app, or security key. The login depends on an object or on a credential held by that object.

Something you are includes a fingerprint, face, or another biometric. On a modern device, biometrics commonly unlock a cryptographic key locally rather than sending a fingerprint to the remote service.

True 2FA combines two groups, such as a password you know and a security key you possess. The MDN definition of multi-factor authentication uses this distinction between different kinds of evidence.

What happens during a 2FA login?

A typical login has two visible screens, but its security does not come from the number of screens.

1. You enter your username and password.
2. The service verifies that first factor.
3. It requests a second factor registered to the account.
4. You approve the request from an enrolled device or provide a code.
5. The service creates a session and may remember the device for a limited time.

That final step explains why 2FA may not appear on every login. A service can request it on a new device, after a defined period, or before a sensitive action. Not seeing a prompt for several days does not necessarily mean that 2FA has been disabled.

SMS, authenticator app, prompt, or key?

All of these can be a second factor, but they provide different protection.

Codes delivered by SMS

The service creates a one-time code and sends it to the registered number. This is easy to understand and requires no dedicated application.

It also depends on the mobile carrier and continued control of the number. SIM swapping, interception, or weak account-recovery procedures can redirect the messages. A fake login page can also ask for the code and relay it immediately to the real service.

Codes from an authenticator app

Google Authenticator, Microsoft Authenticator, and similar apps can generate a TOTP code, usually six digits valid for thirty seconds. The service and app hold the same secret and calculate the same result from the current time. No message is sent, and the app works offline.

This removes the dependency on a phone network, but the code can still be read and phished. Security also depends on protecting the secret: a copy of the setup QR code can generate every future code.

The mechanism is covered in detail in our complete guide to TOTP.

Approval prompts

The phone receives a request that the user accepts or rejects. This is faster than copying a code, but repeated prompts may eventually make someone approve by mistake. A sound implementation shows useful context, asks the user to match a number displayed during login, and limits repeated requests.

Security keys and passkeys

A FIDO2 security key or passkey uses public-key cryptography. The service stores a public key while the private key remains on the device. The proof is bound to the genuine domain, making it substantially more resistant to fake login pages than a code that a person can copy.

When a service supports them, these methods are generally the strongest choice for administrators and other sensitive accounts.

2FA, MFA, and two-step verification

These terms are related but are not perfect synonyms.

2FA combines exactly two factors of different types. MFA, or multi-factor authentication, combines at least two and may require three or more. Microsoft’s overview of multi-factor authentication therefore describes 2FA as a subset of MFA.

Two-step verification primarily describes a process with two stages. The stages may belong to the same category and would not then constitute two factors in the strict sense. Consumer interfaces nevertheless often use the phrase to mean 2FA.

The useful question is not what a setting is called but which independent forms of evidence it actually verifies.

What 2FA does not stop

Two-factor authentication substantially reduces the risk from an isolated password theft. It does not repair every other security weakness.

• A fake site can relay a password and TOTP code in real time.
• Malware can steal an already authenticated session.
• Weak account recovery can bypass the second factor.
• A copied TOTP secret produces the same codes on another device.
• A person who is already authorised can misuse that access.

Teams still need to protect devices, investigate unexpected prompts, store recovery codes away from the account they recover, and review active sessions. 2FA complements named user accounts and roles; it does not justify sharing one login when a service supports one account per person.

How should you choose a 2FA method?

Start with the most phishing-resistant method the service offers.

1. Prefer a passkey or security key for critical accounts.
2. Otherwise, use an authenticator app instead of SMS.
3. Keep SMS when it is the only choice, because it is still better than a password alone.
4. Generate recovery codes and store them outside the protected account.
5. Enrol two administrative recovery methods when possible, then test them.

For an account used by several people, first check whether the service offers members, roles, or delegated access. Those controls are almost always better than a shared account.

How should a team manage 2FA for a shared account?

Some services still provide only one login even though a team needs access. The wrong response is to send the TOTP setup QR code to everyone: every copy is permanent, invisible, and impossible to revoke individually.

A healthier arrangement keeps the secret in one system and gives authorised people access to current codes. Rights are assigned per person and account, every code view is recorded, and one colleague can be removed without enrolling everyone else again.

The practical options are compared in the best ways to manage 2FA for shared accounts. For the direct workflow, read how to share 2FA codes with a team securely.

The rule to remember

Enable two-factor authentication whenever an important account offers it, then choose the method according to the risk. SMS improves on a password alone, TOTP removes the mobile-network dependency, and a FIDO2 key or passkey provides stronger phishing resistance.

In a team, do not confuse sharing access with multiplying copies of a second factor. Access should be attributable and revocable. Copying the credential creates a security debt that the service itself cannot even measure.