What is MFA/2FA and why one password is no longer enough

Hook

MFA/2FA adds another proof during sign-in. The password says “I know a secret”; the second factor adds “I have my trusted device, key, or approved sign-in method.”

One password is no longer enough because it can be stolen, reused, guessed, pulled from a breach, or typed into a phishing page. MFA does not make an account invulnerable, but it raises the cost of attack sharply.

Problem / Context

Many account takeovers do not start with cinematic server hacking. They start with a simpler path: someone reused a password, a password appeared in a breach, a phishing email worked, or an old device kept access longer than it should. If an account is protected only by a password, the attacker needs only one secret.

MFA changes that path. Even when the password is known, sign-in still needs another factor: a code from an authenticator app, a passkey, a security key, approval on a trusted device, or another verification method. This matters most for email, GitHub, cloud consoles, hosting, domains, password managers, CI/CD, and admin accounts.

2FA usually means two factors: a password plus a second proof. MFA is broader: there may be more than two factors, and policy can depend on role, risk, or device type. For beginners, the distinction is less important than the practical rule: important accounts should not depend on a password alone.

Why it matters

Email is often the master key. It resets passwords for hosting, GitHub, banking, social accounts, and many other services. If email has no MFA, the protection around other accounts becomes weaker too.

In software work, the risk is even larger. One GitHub account may reach private code, deploy keys, Actions secrets, package registries, and the production pipeline. One cloud account can create expensive resources, read data, or shut down services. One domain registrar account can redirect a real website to someone else’s infrastructure.

MFA buys time and creates signal. An attacker may know the password but get stuck at the second factor. The user may notice a strange prompt. The team may receive an alert. This is not an absolute guarantee, but it is a strong baseline security layer.

MFA still needs to be configured thoughtfully. If there is only one phone and no recovery codes, losing the phone becomes an operations incident. If everyone shares one admin account, MFA becomes an awkward ritual with weak accountability. If SMS is used where passkeys or security keys are available, the protection is weaker than it could be.

The mental model

Think of sign-in as a door with two different checks. The password is something you know. The second factor is something you have or approve: a phone with a code, a passkey on a device, or a security key in your pocket.

A healthy team setup looks like this:

• every person has an individual account instead of a shared login;
• MFA is required for admin roles;
• critical accounts use a passkey, security key, or authenticator app;
• recovery codes are stored away from the main device;
• automation access uses service accounts, scoped tokens, and rotation;
• the team has a short procedure for lost devices.

The key point: MFA is not only a button called “enable.” It is a small process around sign-in, recovery, and access removal.

How to do it

1. Start with the most important accounts

You do not need to protect everything perfectly on day one. Start with accounts that can recover or compromise other accounts:

• primary email;
• password manager;
• GitHub or another git platform;
• cloud and hosting;
• domain registrar and DNS;
• CI/CD;
• production admin panels.

If time is limited, email and the password manager come first. They are often the root of access.

2. Choose the right method

SMS is better than nothing, but it is the weaker option. Phone numbers can be moved through SIM swap, messages can be delayed, and the phone network was not designed as a security system.

An authenticator app is usually a better starting point: it works without mobile signal, generates one-time codes, and is supported almost everywhere. For critical accounts, a passkey or security key is even better. They resist phishing more effectively because they are tied to the real site, not just to a code a person can type anywhere.

Push approval is convenient, but use it carefully. If a service only asks “approve sign-in” without a number, location, or context, push fatigue becomes a risk. A user may tap yes simply because prompts keep arriving.

3. Store recovery codes

Recovery codes are needed before trouble starts. They should not live only on the phone that acts as the second factor. Reasonable options include:

• a password manager;
• a printed sheet in a safe location;
• encrypted team storage;
• two admins with separate recovery paths.

After enabling MFA, confirm that recovery codes were generated, stored, and assigned clear usage rules. For a team, this belongs in a short runbook.

4. Do not mix human accounts and automation

MFA works well for people. Scripts, CI/CD, and service accounts need a different model: short-lived tokens, narrow scope, secret scanning, rotation, and audit logs.

A bad setup is taking a human admin account, creating a long-lived token, and putting it into a pipeline. A better setup is a separate service account with minimal permissions and a clear owner.

5. Enable team policy

If the service supports organization policy, require MFA for all members or at least everyone with write/admin access. One well-protected account does not help enough if another admin remains password-only.

Also review old users, contractors, and pending invitations. MFA does not help if an organization still has a forgotten user with unnecessary privileges.

6. Test lost-device recovery

The best time to test recovery is while everything is calm. Pick one non-critical account or a test scenario and walk through the path: what happens if a phone is lost, a security key breaks, or a person leaves the team.

The goal is not heavy bureaucracy. The goal is to avoid searching for recovery codes during panic.

Anti-patterns

• enabling MFA only for the “main” admin while other write-access users stay password-only;
• using one shared admin account for the whole team;
• storing recovery codes on the same phone that acts as the second factor;
• treating SMS as sufficient for cloud, domains, or password managers;
• approving push prompts that the user did not start;
• using a human account as a service account in CI/CD;
• having no procedure for lost devices or offboarding;
• never checking whether MFA is actually enforced for the organization.

Conclusion / Action Plan

MFA/2FA is basic access hygiene. It does not replace unique passwords, a password manager, scoped tokens, and sane permissions, but without it important accounts fall too easily after one password leak.

Start with the practical minimum:

1. enable MFA for email and the password manager;
2. protect GitHub, hosting, cloud, DNS, and CI/CD;
3. choose an authenticator app, passkey, or security key over SMS;
4. store recovery codes separately;
5. remove shared admin accounts;
6. review service accounts and tokens;
7. write a short recovery plan.

When the second factor is configured well, the password stops being the only point of failure. This is one of those small daily inconveniences that saves a lot of stress during a real attack.

Official sources:

• https://www.cisa.gov/MFA
• https://pages.nist.gov/800-63-3/sp800-63b.html
• https://developers.google.com/identity/passkeys
• https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa