Multi-Factor Authentication (MFA) requires two or more verification factors before granting access, instead of relying on a password alone. The factors fall into three categories:
- Something you know: password, PIN, or security question — the easiest factor to compromise via phishing or social engineering.
- Something you have: a smartphone, hardware token, or access card — can’t be stolen remotely the way a password can.
- Something you are: biometrics — fingerprint, facial recognition, retina scan, voice. Unique per person, hard to forge.
Combining factors means a stolen password alone doesn’t get an attacker in.
In this post: Why it matters · What MFA doesn’t stop anymore · When would you actually use this? · Best practices · References
Why it matters
- Neutralizes stolen credentials: even a successful phishing attack only gets an attacker the password — they still need the second factor.
- Required by name in several regulations: HIPAA mandates it for healthcare data access, PCI-DSS requires it for payment processors, GDPR encourages it for personal data with real fines for non-compliance.
- Necessary for remote/cloud access: once employees connect from arbitrary networks and devices, location and device trust stop being reliable signals on their own.
What MFA doesn’t stop anymore
Worth being honest about, since “we have MFA” gets treated as a solved problem more often than it should. Two attack patterns specifically target MFA itself, not the password behind it:
- MFA fatigue / push bombing: an attacker with a stolen password floods the victim with push approval requests until one gets approved out of frustration or habit — no technical bypass, just exploiting the prompt itself. This is what enabled real breaches at Uber and Cisco.
- Adversary-in-the-middle (AiTM) phishing: a proxy phishing kit sits between the victim and the real login page, relaying the legitimate MFA challenge through in real time and capturing the resulting session token once the user completes it. The user never notices anything’s wrong — they logged into what looked like the real thing and MFA succeeded normally. This category has grown sharply enough that several commercial phishing kits now build it in by default.
Neither of these defeats “have a second factor” as a concept — they defeat push-notification and one-time-code MFA specifically, by attacking the human approval step or the session token instead of the credential. Phishing-resistant MFA — FIDO2 security keys, Windows Hello, or passkeys built on the WebAuthn standard — closes both gaps, because the authentication is cryptographically bound to the actual domain being logged into. A proxy site can relay a push notification; it can’t fake the cryptographic handshake a hardware key performs against the real site’s certificate. If your MFA rollout is still push-notification-only, that’s the realistic next step, not a “nice to have.”
Even a successful phishing attack only gets an attacker the password — they still need the second factor.
When would you actually use this?
- You’re securing customer-facing logins (online banking, healthcare portals) where fraud liability actually falls on you if credentials get reused from a breach elsewhere.
- You’re rolling out remote access and can’t rely on “they’re on the corporate network” as a trust signal anymore.
- An auditor is asking specifically whether MFA is enforced for a regulated data category — HIPAA/PCI-DSS/GDPR all name it directly, so “we have strong passwords” won’t satisfy the finding.
- You’re on Microsoft 365/Entra ID specifically and need the actual implementation steps — see Multi-Factor Authentication (MFA) Options for Microsoft for the PowerShell and licensing side of this.
Best practices
- Start with privileged accounts — admins and anyone with access to critical systems, before a full rollout.
- Use adaptive authentication where possible — only prompt for the extra factor in risky scenarios (unknown location/device), not every single login.
- Avoid SMS as the only second factor — it’s vulnerable to SIM swapping. TOTP apps or biometrics are stronger.
- Review policies periodically, not just at initial rollout — session timeouts and re-authentication requirements should get revisited as threats evolve.
References
Hope that clears things up. Feel free to drop a comment if you need more detail.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning