Phishing-resistant MFA, federated identity, single sign-on, cloud access security, and complete authentication logging — applied to every user across your distributed environment. From onboarding to offboarding, no gaps in between.
Most firms believe they are protected because they "have MFA." But MFA is not a single technology — it is a spectrum, and most of what firms deploy today is vulnerable to the exact attacks regulators are warning about. The difference between standard MFA and phishing-resistant MFA is the difference between a lock that can be picked and one that cannot.
Standard MFA — the kind most firms use — sends a push notification to the user's phone. The user taps "Approve" and they're in. The problem is that attackers exploit this exact behavior. In an MFA fatigue attack (also called MFA bombing), an attacker who already has the user's stolen credentials floods them with repeated push notifications — at 2 AM, during meetings, over and over. The user, exhausted and just wanting it to stop, taps "Approve" on a request they didn't initiate. The attacker is in.
This is not theoretical. MFA fatigue attacks were behind breaches at Uber, Cisco, Okta, and other major organizations. The Uber breach in September 2022 happened exactly this way — a Lapsus$ attacker bombarded an employee with push notifications until they approved one.
Standard push-notification MFA lets a user approve an authentication request they did not initiate. The user does not need to see the attacker's screen, verify any context, or take any deliberate action beyond tapping a button. One tap of "Approve" — whether intentional or out of fatigue — grants full access.
CISA — the Cybersecurity and Infrastructure Security Agency — does not consider push notifications, SMS codes, or standard one-time passwords to be phishing-resistant. In its Zero Trust guidance (OMB M-22-09), CISA mandates phishing-resistant authentication and identifies FIDO2/WebAuthn as the standard that meets this requirement. The reason is straightforward: phishing-resistant MFA requires a cryptographic handshake between the user's device and the specific service being accessed. It cannot be intercepted by a proxy, it cannot be socially engineered through notification fatigue, and it cannot be replayed by an attacker who captures a code.
Instead of a simple push notification that can be approved without thought, phishing-resistant MFA requires the user to take a deliberate, verifiable action. For example: the user sees a number on their login screen and must type that exact number into their authenticator app — not just tap "Approve." After that, biometric re-authentication (fingerprint or face) confirms it is actually the person holding the phone. This is number matching plus biometric verification.
The user cannot accidentally approve a request they did not initiate, because they would need to see the number on the attacker's screen — which they cannot. It takes two more seconds than tapping a button. It stops the entire category of fatigue attacks.
"Enabling MFA is not the same as enforcing phishing-resistant MFA. One gives you a checkbox. The other gives you actual protection. CISA does not consider push notifications, SMS, or standard OTP codes to be phishing-resistant — and neither should your firm."
Most firms use Microsoft Authenticator to protect Microsoft 365. On the surface, this makes sense — it's included, it's convenient, it integrates natively. But from a security architecture perspective, it creates a dangerous concentration of risk. If Microsoft's authentication infrastructure is compromised, the tool you depend on to verify identity is compromised at the same time.
Token theft accounted for 31% of Microsoft 365 breaches in 2025, making it the single largest attack vector against M365 — surpassing even traditional credential theft. In an Adversary-in-the-Middle (AiTM) attack, the attacker sets up a phishing page that acts as a real-time proxy between the user and Microsoft's actual login page. The user enters their credentials and completes MFA normally — through Microsoft Authenticator — and the login succeeds. But the attacker, sitting between the two, captures the session token that Microsoft issues after authentication. With that token, the attacker accesses the user's Outlook, OneDrive, Teams, and SharePoint — without ever triggering another MFA prompt.
In December 2024, Oasis Security disclosed "AuthQuake" — a critical vulnerability in Microsoft's MFA implementation that allowed attackers to brute-force MFA codes with unlimited attempts, no rate limiting, and no user notification. An attacker could bypass MFA in under 70 minutes with a greater than 50% success rate. The vulnerability affected every Microsoft account protected by authenticator-app-based MFA — Outlook, OneDrive, Teams, Azure Cloud. Microsoft had more than 400 million paid Office 365 seats exposed before the fix was deployed. The attack required no user interaction. The user never knew it was happening.
FCI does not use Microsoft Authenticator. Instead, FCI deploys a separate, independent authentication provider — outside the Microsoft ecosystem entirely. The principle is straightforward: do not put all your eggs in the same basket. If Microsoft's identity infrastructure is the target — and it demonstrably is — then the tool that verifies identity should not also be a Microsoft product. By separating the authenticator from the system it protects, FCI ensures that a compromise of one does not automatically compromise the other.
The credentials, the MFA verification, the session tokens, and the authentication logs all flow through Microsoft's infrastructure. When attackers target Microsoft — through AiTM phishing, OAuth device code abuse, or token theft — they are attacking the same ecosystem that is supposed to be verifying the user's identity. A breach of one layer exposes every layer.
FCI uses an authentication provider that operates outside the Microsoft ecosystem. The MFA challenge is issued by a different provider, verified by a different provider, and logged by a different provider. Even if an attacker compromises Microsoft's token infrastructure, the authenticator's security boundary is untouched. The entity verifying security should never be the same entity being verified.
"Microsoft is the most targeted identity platform in the world. Using Microsoft Authenticator to protect Microsoft 365 means the lock and the key are both made by the company under attack. FCI separates them — by design, not by accident."
Financial services firms operate in an environment where every user is both a productivity asset and an attack surface. Regulators require that firms control who has access, verify that users are who they claim to be, and log every authentication event. Most firms believe they have this covered because they turned on MFA. The reality is different. MFA is often risk-based rather than enforced, federation and single sign-on are confused or misconfigured, and authentication logs are incomplete — or simply not captured at all.
The result is an identity layer that looks secure on paper but fails under scrutiny. When an examiner asks for proof of who logged into what system, when, and from where — or when a breach investigation needs to trace lateral movement — the gaps become visible.
Most firms enable MFA but configure it as risk-based — meaning Microsoft decides when to challenge the user based on its own risk assessment. If the login looks "normal" to Microsoft, MFA is skipped. The firm believes every login is verified. It isn't. And there's no log showing when MFA was bypassed because the system decided it wasn't needed.
These are three different technologies that serve three different purposes. Federation syncs usernames between systems. Single sign-on eliminates repeated authentication. MFA verifies the person. Most firms — and even many IT providers — conflate them. The result is misconfigured identity infrastructure where gaps exist that no one recognizes because the terminology itself is misunderstood.
Microsoft's native authentication logs capture basic events but miss critical context. Risk level, device location, authentication method, login source country — this information exists but is not captured by default. Without extended logging, a firm cannot answer the questions regulators and forensic investigators will ask.
Users are added when they join. But who tracks inactive accounts? Who detects anomalous behavior? Who ensures that when someone leaves, every access point is actually closed — not just the obvious ones? Most firms have no systematic process for user lifecycle management. Orphaned accounts accumulate, and each one is a door that should have been locked.
The Question Every Firm Should Ask
Can you prove — for every user, every login, every application — who accessed it, when, how they were authenticated, and whether the access was appropriate?
FCI does not rely on Microsoft's default authentication behavior or trust that MFA is "probably" being enforced. FCI builds a complete authentication ecosystem — federation, single sign-on, CASB, and advanced MFA working together — so that every access decision is verified, logged, and provable. Every capability below is enforced through templates and automation, not configured once and assumed to be working.
Traditional Mobile Device Management has significant problems in a BYOD environment. Users report battery drain, restricted functionality, and a surveillance-like experience on their personal device. MDM platforms are costly to license and complex to administer. For most financial services field offices, the tradeoff isn't worth it.
Every managed service provider can turn on MFA. The difference between FCI and everyone else is not the tools — it is mastery of the authentication ecosystem, automation that replaces manual identity management, consistency across every user and every access point, and persistent proof that every login is verified and logged.
"FCI does not trust that Microsoft's risk-based decisions are protecting the firm. Every login is verified. Every authentication event is logged with full context. The firm can prove who accessed what, when, and how — not because someone checked a box, but because the controls enforce it automatically."
A verified identity is not just a login event. It is the access decision that determines whether a user reaches the endpoint, the network, the data, and the cloud applications. Every domain protects every other domain — and user security is the gatekeeper that makes the rest enforceable.
Regulators, home offices, and cyber insurance carriers all ask the same question: can you prove who has access and how they were authenticated? FCI produces continuous evidence as a byproduct of how it operates. There is no scramble before an exam. The proof already exists.
What Your Examiner Will See
Exactly who has access, how every login was verified, which authentication method was used, and whether the controls are enforced continuously — not just on the day you knew they were coming.