MFA (Multi-Factor Authentication)

Multi-Factor Authentication (MFA) requires a user to present two or more independent pieces of evidence before being granted access to an account or system. These factors fall into distinct categories: something you know (a password or PIN), something you have (a phone, hardware security key, or authenticator app), and something you are (a fingerprint, face, or other biometric). Because an attacker must compromise factors from separate categories, MFA makes a stolen or guessed password far less useful on its own.

Why it matters

Passwords are the weakest link in most authentication systems. They get reused across services, phished, and dumped in breaches. MFA breaks the chain: even if a credential leaks, the attacker still lacks the second factor. This is the single most effective defence against credential-based attacks like phishing, credential stuffing, and password reuse, and it is why frameworks such as PCI DSS, SOC 2, and most cyber-insurance policies now treat MFA on administrative and remote access as a baseline requirement rather than a nice-to-have.

How it works

After the first factor (usually a password) succeeds, the service challenges for a second factor. Common methods, from weakest to strongest:

• SMS / email one-time codes — better than nothing, but vulnerable to SIM-swapping and interception.
• TOTP authenticator apps (e.g. Google Authenticator, Authy) — generate time-based 6-digit codes offline; resistant to interception but still phishable.
• Push notifications — approve a prompt on a trusted device; convenient but susceptible to "MFA fatigue" prompt-bombing.
• FIDO2 / WebAuthn hardware keys and passkeys — cryptographically bound to the site's origin, making them phishing-resistant. This is the gold standard for high-value accounts.

A concrete example

An employee's password is captured by a phishing page and sold on. The attacker tries to log into the company's admin console. With MFA enabled, the login stalls at a hardware-key challenge the attacker cannot satisfy, and the failed attempt surfaces in the audit log. Without MFA, that same stolen password is an open door — and admin access is exactly what turns a minor leak into a full account or infrastructure takeover.

How it relates to your external attack surface

MFA is an authentication control, so a scanner cannot read it directly. What FortWatch surfaces instead is the exposed surface where MFA should be protecting access: login portals, admin panels, VPN gateways, RDP/SSH endpoints, and management interfaces reachable from the internet. Any such service exposed on a public port is a place where weak or missing MFA becomes exploitable, so FortWatch flags it for review — see port monitoring. Equally important, MFA does nothing for assets that bypass login entirely: an unauthenticated database, a public cloud bucket, or a leaked .env file hands over data with no credential prompt at all.

Where it fits in remediation

Treat MFA as a foundational mitigation, not a finished one. Enforce it everywhere — prioritising admin, remote-access, and identity-provider accounts — prefer phishing-resistant FIDO2/passkeys, and remember it complements rather than replaces reducing what is exposed in the first place. For deciding what to fix first across a noisy surface, see how to prioritize vulnerabilities.