Multi Factor Authentication Stops an Attacker Who Has Your Password

That is real, and it is the cheapest security gain available to any organization.

It is also the most oversold one. MFA protects the accounts you enrolled. It does nothing about the password already sitting in a broker's dataset under your name, and nothing about identities you never registered in the first place.

What the Second Factor Actually Proves

Multi-factor authentication is a login requirement that combines two different kinds of proof, something you know and something you have or are, so a correct password alone is insufficient to complete the sign-in. The concept is narrow by design. It governs authentication events against enrolled accounts.

What it is not: it is not encryption of the credential, not a substitute for a password manager, and not a monitoring service. A second factor changes the math of one login attempt. It says nothing about whether a copy of your password is currently being traded.

The distinction matters because the 2026 threat picture is mostly a credential supply problem. Check Point Research reported a 160% increase in compromised usernames and passwords in 2025 compared with the previous year (per IT Europa). Volume like that is not produced by guessing. It is produced by collection, from infostealer logs, breach dumps, and broker aggregations that persist long after the original incident.

CISA makes the mechanical point cleanly: an account protected only by a password is accessible to anyone who has that password. MFA's job is to break that equivalence, and it does.

Where the second factor sits in a larger defense

Authentication is one layer. Credential discovery, continuous exposure monitoring, and data broker removal are separate layers operating on different data. An executive can have flawless MFA on every corporate account and still have a personal email, an old brokerage login, and a decade of address history indexed on people-search sites. That surface does not authenticate, so no second factor touches it.

What to Look For in an Authentication Stack

Criteria, plus the evidence that tells you whether each one is actually met.

Criterion	What to check
Second-factor type	Is the default an app push, a hardware key, a passkey, or SMS? SMS is the weakest link because it can be intercepted through number porting.
Phishing resistance	Can the factor be relayed by a proxy site in real time? Push notifications and one-time codes can. Hardware-bound credentials cannot.
Enrollment coverage	Which accounts have it, and which were left out because they are personal, legacy, or owned by a subsidiary.
Recovery path	What happens when someone loses their device? A weak recovery flow undoes the factor entirely.
Assurance level	Does the deployment satisfy the standard your regulators or counterparties expect?
Discovery coverage	Who is checking whether your credentials are already circulating, and on what schedule.

The assurance question is not decorative. NIST SP 800-63B says verifiers shall offer at least one phishing-resistant authentication option at AAL2. Phishing-resistant means the credential is bound to the origin, so a cloned login page captures nothing usable. If your stack offers only push and SMS, you have met the login requirement without meeting the resistance requirement.

Compliance adds a second obligation that security teams routinely miss. The same standard requires that an agency consult with its SAOP and analyze whether collecting personal information to issue or maintain authenticators triggers the requirements of the E-Government Act of 2002. Authentication infrastructure handles personal data. That handling has its own review path.

For the executive audience, this is where information warfare programs begin: the identity layer is the first thing probed, and it is the layer most organizations document least.

How the Attack Fails, Step by Step

Understanding the mechanism tells you which configurations hold and which only appear to.

1. The attacker obtains a valid username and password from a breach dump, an infostealer log, or a credential marketplace. At this point the credential is correct and current.
2. They submit both values to the login endpoint. The system accepts the first factor and moves to the second.
3. The system issues a challenge that requires a proof the attacker does not possess: a signature from a hardware-bound key, a biometric confirmation on a registered device, or a code from an app bound to that specific enrollment.
4. Without that proof, the session is never established. The password retains its value as a first factor and loses its value as a key.

This is why the blocking rate is so high on automated attacks. Microsoft's figure holds at 99.9 percent of automated account compromise attempts precisely because automation scales against the login, and the login now requires a human-held device.

Scale deployment shows the same result at the organizational level. Google deployed FIDO security keys to all 85,000 employees in 2017 and subsequently reported zero successful phishing attacks against employee accounts (per Petronella Technology Group). Hardware-bound credentials, not codes, produced a categorical result rather than a percentage one. ^➄

The exception is the real-time relay. An adversary-in-the-middle proxy sits between the victim and the genuine login page, harvests the password and the one-time code as they pass through, and replays both inside the live session. The defense is a credential the proxy cannot use because it never leaves the origin. That is the practical difference between having MFA and having phishing-resistant MFA, and it is the single configuration choice most deployments get wrong.

How to Decide Where MFA Ends and Monitoring Begins

You face a scoping decision, not a security decision. MFA is the right answer for authentication on every account you control. It is the wrong answer for exposure you do not control.

Three signals settle the scope. If your organization's risk register includes named executives, board members, or founders with public profiles, their personal accounts sit inside your enterprise risk whether or not you administer them. If you have completed MFA rollout and still cannot answer which employee credentials appear in circulating breach data, your coverage has a discovery hole. If a security incident in the last year originated outside your systems, MFA would not have stopped it.

Pick the self-managed path when your environment is small, your accounts are all corporate, and you have someone whose actual job is identity and access. That person can run enrollment, audit recovery flows, and handle hardware key logistics. This is a real option and it works.

Pick the engaged path when the exposure extends past the accounts you administer, or when nobody owns credential discovery as a named responsibility. Discovery, continuous monitoring, and suppression of personal records from data brokers are workstreams with their own cadence, and they do not close because your MFA rollout closed. A program built around the wider information warfare picture treats authentication, monitoring, and removal as one surface with three schedules.

The trade-off nobody states plainly: managed monitoring costs more than a hardware key per employee and produces no visible dashboard win. It buys the one thing MFA structurally cannot give you, which is knowledge of a compromise that never touched a login you control.

Where People Go Wrong With MFA

The most common error is treating enrollment as the finish line. Teams roll MFA out across corporate systems, check the box, and never inventory the personal accounts, legacy service logins, and subsidiary identities that sit outside the scope. Credential breaches do not respect that boundary. An old personal address used as a recovery email becomes the weakest account in the chain, and it is the one nobody enrolled.

A close cousin is confusing MFA with phishing resistance. Push notifications and one-time codes satisfy a second-factor requirement and remain relayable in real time. Executives who are individually targeted face relay attacks, not brute force, which means the resistance property is the operative one for this audience. Buying MFA without specifying the factor type solves the problem you do not have.

Recovery flows are where careful deployments quietly fail. A system with hardware keys and a weak account recovery process, one that resets through an email inbox or a support phone call, has relocated the weakest link rather than removed it. Attackers read the same documentation your help desk does.

Enrolling the executive and stopping there is the fourth pattern. The executive's exposure is not only their own login. Family members, executive assistants, and household accounts form the practical perimeter around a public figure, and a compromise anywhere in that ring produces access to schedules, travel, and correspondence.

Mistaking authentication for deletion is the fifth. MFA governs sign-in. It does not remove the address history, phone numbers, and relational records that data brokers sell, and those records are what make the targeting possible in the first place. Suppression and removal are separate work. Treated as a one-time task, they fail; run on a schedule, they hold.

Frequently Asked Questions

Does MFA still work if the attacker already has my password?

Yes, and that is its core function. The login cannot complete without the second proof, so the stolen password becomes a partial credential. The limit is scope: it protects the accounts where you enrolled the factor, and nothing else.

Which second factor should executives actually use?

Hardware-bound credentials, passkeys, or FIDO security keys. Push notifications and SMS codes can be relayed by an adversary-in-the-middle proxy in real time, which is the attack pattern targeted individuals actually face. NIST SP 800-63B requires that verifiers offer at least one phishing-resistant authentication option at AAL2. Ask your provider which factor satisfies that, and require it as the default rather than an option.

What does MFA not protect against?

Accounts you never enrolled, credentials already circulating in breach data or infostealer logs, and the aggregated personal records that data brokers publish about you. Those records do not authenticate to anything, so no second factor governs them. Discovery of exposed credentials and removal of broker listings are separate workstreams with separate schedules, and they persist after your MFA coverage reaches full.

Can I run MFA and broker-removal work at the same time?

You should, because they operate on different data with different cadences. MFA is a configuration change applied once and audited periodically. Credential monitoring runs continuously, since new breach data appears on its own timeline. Removal runs on a repeating schedule, because brokers re-list records after an opt-out. Treating any of the three as finished is how a defense that looked complete develops a gap nobody is watching.

How does an organization know whether its MFA deployment is actually working?

Check three things: which accounts are enrolled and which were excluded, what factor type is set as the default rather than merely available, and how account recovery resets credentials. A deployment with broad enrollment, relayable factors, and a weak recovery flow fails against the attacks that matter.

If your organization needs the discovery and removal side of this handled by a dedicated team, reach us at greyman@a52.io or +15712102227, or write to 1350 Beverly Road, STE 115, PMB 175, McLean, Virginia 22101.

Sources

• ➄ petronellatech.com

  Google deployed FIDO security keys to all 85,000 employees in 2017 and subsequently reported zero successful phishing attacks against employee accounts.

Sources checked on September 29, 2026.