MFA
Multi-factor authentication requires two or more proofs of identity, such as a password and a code or device. It makes stolen passwords less useful, but it verifies only the moment of login, not what happens next.
Reading Time:
4 min
Multi-factor authentication (MFA) requires two or more independent proofs of identity before granting access. Instead of a password alone, the person also provides something they have or something they are. A stolen password is then no longer enough on its own.
MFA combines at least two different types. Two passwords are not MFA.
Phishing-resistant methods, such as hardware security keys and passkeys, are the strongest, because they cannot be handed to a fake login page. Authenticator apps are better than text messages. SMS codes and simple push approvals are the easiest to attack.
Service accounts, API keys and automated processes cannot use it. Some protocols, such as classic Kerberos and NTLM inside a Windows domain, do not support it natively. Emergency accounts and older applications are often left out.
It verifies the login, not what follows. An attacker who steals a session token, approves a prompt through fatigue or uses an account that has no MFA gets in, and then acts with the account’s permissions. Nothing in the login shows what happens next.
MFA that is requested depending on risk, using signals such as device, location and behaviour. It is usually delivered through conditional access policies, so that low-risk logins are smooth and risky ones are challenged.
NIS2 lists the use of multi-factor or continuous authentication, where appropriate, among its baseline security measures. DORA expects strong access controls within ICT risk management. MFA is one of the most common ways to meet those expectations.
An attacker who already knows a password triggers prompt after prompt on the victim’s phone, hoping they will approve one to make it stop, or at the wrong moment. Number matching, rate limits and phishing-resistant methods reduce the risk.
A control for push notifications in which the person must type a number shown on the login screen into their app. It prevents approving a prompt by reflex, because the number must match the real login attempt.
Account recovery and factor resets are a frequent target, because an attacker who persuades a help desk to reset MFA bypasses it altogether. Recovery should require strong proof of identity and be monitored like any other privileged action.
Every extra step is friction. Adaptive policies reduce it by asking only when risk is higher, and passkeys and hardware keys are both faster and stronger than codes, which makes adoption easier.
Start with privileged accounts and remote access, prefer phishing-resistant methods, cover every entry point and not only the main login, use number matching to limit push fatigue, protect the recovery process and monitor what happens after the login.
Sharelock monitors identity behaviour after login, down to individual transactions and queries on critical applications, so a session that passed MFA but acts unlike its owner still stands out.
Explore more terms