What Is Multifactor Authentication? MFA Explained

What is multifactor authentication?

Multifactor authentication, or MFA, requires more than one distinct type of proof at sign-in. The types are something you know, something you have, and something you are. Two-factor authentication is MFA using two types. MFA can make a stolen password insufficient, but it does not guarantee account security. Never approve unexpected prompts or disclose authentication or recovery codes to another person.

The Australian Signals Directorate's MFA overview explains that combination of proof types and the extra requirement when one is stolen.

Authentication checks control of authenticators associated with an account, as NIST's digital identity model explains. A username identifies the account; it is not a second authentication factor. Count the kinds of proof, not the screens.

What are the three authentication factor types?

The FTC's account-protection guide describes these categories:

Two knowledge secrets are not two factor types. A password followed by a PIN can be two steps without being MFA. Conversely, a single visible interaction can involve two factors. The screen count cannot settle the classification.

Can one device provide multifactor authentication?

Yes. NIST SP 800-63B distinguishes combining separate single-factor authenticators from using one multi-factor authenticator activated by another factor.

In NIST's framework, biometrics are not authenticators on their own: a physical authenticator supplies possession and the biometric comparison supplies inherence. Where the biometric activates a multi-factor authenticator, that authenticator is the physical component.

Therefore, “uses a fingerprint” does not fully describe a sign-in. Ask what device-held authenticator the fingerprint activates. A hardware key, authenticator application, one-time code or device biometric can have different roles depending on the implementation. Record the actual arrangement rather than copying an “MFA enabled” badge into your notes.

How do codes, prompts and passkeys differ?

These labels describe mechanisms, not interchangeable security guarantees:

The FTC describes the first three mechanisms and the SMS weakness. An app code is not automatically a passkey merely because both appear on a phone.

The FIDO Alliance's passkey explanation describes credentials based on cryptographic key pairs, used from a phone, computer or security key. Passkeys can be device-bound or synced. Their phishing resistance is a property of the authentication design, not of a long code a person types.

For passkey sign-in, the local unlock can use a PIN or biometric. FIDO says biometric information stays on the device rather than being sent to the remote server. That statement describes this passkey process, not every service that accepts uploaded biometric information.

Does passwordless mean there is only one factor?

No. Removing a typed account password does not remove the distinction between controlling an authenticator and activating it.

For a concrete provider example, Microsoft's passkey instructions list a synced credential manager, phone or tablet, physical security key, and local Windows Hello storage as possible saving locations. Availability depends on the account and setup. For work or school, the organization must support passkeys and may restrict the options.

This is why a useful setup record names where a credential was saved. “On my computer” could refer to different storage arrangements; Microsoft distinguishes a synced manager from local Windows Hello storage. Follow the provider's current documentation for your chosen option. This comparison is not a recommendation to change managed-device settings or move workplace credentials into a personal account.

Is number matching phishing-resistant MFA?

Do not equate the two. In its MFA guidance bulletin, CISA recommends phishing-resistant MFA and describes number matching as an interim mitigation for organizations unable to implement it immediately.

Number matching is meant to mitigate MFA fatigue, in which repeated prompts pressure someone into approving an unwanted request. It does not turn any prompt into proof that the person asking you to approve it is legitimate. An unexpected request remains a reason to stop.

Our editorial rule is to never approve an unexpected authentication request, even if someone claiming to be support tells you it is necessary. For managed accounts, report it through your established IT or security channel.

What risks remain after MFA is enabled?

NIST's threat discussion includes disclosed knowledge secrets; lost, stolen or damaged physical authenticators; replicated biometric characteristics or false matches; and deception that causes a person to reveal information or grant access.

MFA changes what proof is needed. It is not a conclusion that every request, device or recovery interaction is trustworthy.

Use an official application or an independently known service address, not an unsolicited sign-in link. The FTC's phishing guidance recommends checking a suspicious message through contact information you already know is real. Do not send passwords, one-time codes or recovery material to another person. Suspected compromise of an organization-managed account goes to the responsible security team.

How should you plan for a lost authenticator?

NIST recognizes saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing. A consumer service may offer only some of these; do not assume that naming an option makes it available on your account.

Review the provider's official recovery process during setup. Store recovery material as it directs, and keep it private. If a device is lost, stolen, damaged or outside your control, follow that official route or contact the responsible organization administrator. Do not use third-party bypass offers.

For example, Google's 2-Step Verification help distinguishes losing a phone, security key or passkey. Its phone-loss options depend on what was already configured, such as a saved backup code, an added security key or a passkey on another device. If sign-in is unavailable, Google directs users to account recovery. Its work/school section also directs users to their administrator.

The practical question is whether the backup remains reachable when the primary device does not. A list of options is not evidence that you personally enrolled them.

What belongs in a useful MFA setup record?

This is an original planning worksheet, not a request to record secrets. Keep it privately and follow workplace policy.

Leave an unconfirmed field marked unconfirmed. Do not put passwords, codes, QR enrollment images or secret keys in this worksheet. A colleague helping review the plan needs to understand the missing step, not receive account access.

Separate three questions: What can I use now? What would still be available if this device were lost? Which official process applies if neither works? Answering the first does not answer the other two. The worksheet is complete only when its claims describe your actual setup, rather than options the provider advertises.

Our DNS guide explains locating a service; what HTTPS means explains connection protection. Neither replaces evaluating an authentication request. The security-hygiene collection keeps those account decisions in their proper context.

Sources

• Australian Signals Directorate: MFA overview
• NIST SP 800-63: Digital identity model
• NIST SP 800-63B: Authentication and authenticator management, including authenticator arrangements, biometrics, recovery and threats; federal assurance requirements are not universal consumer-account rules.
• FTC: Two-factor authentication
• FIDO Alliance: Passkeys
• Microsoft Support: Creating and saving passkeys
• CISA: Phishing-resistant MFA and number-matching guidance
• FTC: Recognizing phishing
• Google Account Help: 2-Step Verification problems