How MFA works
MFA combines factors from different categories: something you know (a password or PIN), something you have (a phone, security key, or authenticator app), and something you are (a fingerprint or face). Because the factors are independent, stealing one is not enough; an attacker with your password still cannot approve the push notification on your phone.
Common second factors include time-based one-time passwords (TOTP) from an authenticator app, push approvals, SMS or email codes, and phishing-resistant options such as FIDO2 security keys and passkeys. The identity provider evaluates which factors to demand at each sign-in, often as part of a broader adaptive policy.
Why MFA matters
Passwords alone fail constantly: they are phished, guessed, reused across sites, and leaked in breaches. MFA blocks the vast majority of automated account-takeover attempts because the attacker needs something they physically do not have.
Not all factors are equal, though. SMS codes can be intercepted through SIM swapping, and simple push approvals can fall to prompt-bombing fatigue. Phishing-resistant factors such as passkeys and FIDO2 keys bind the authentication to the legitimate site, so credentials cannot be replayed on a fake login page. Regulators and cyber-insurance providers increasingly treat MFA as a baseline requirement rather than a best practice.
Deploying MFA in practice
Successful MFA programs start with administrators and remote access, then expand to all users. Offering several factor options improves adoption: passkeys or authenticator apps as the default, with push or codes as fallback. Enforcing MFA at the identity provider rather than per application means one policy protects every connected system.
Adaptive step-up keeps friction low by requesting a second factor only when the risk justifies it, for example from a new device or unusual location. Monosign supports TOTP, passkeys and FIDO2, push, SMS, and email factors with risk-based step-up policies enforced across all connected applications.