What MFA solution actually works for a remote-first company?

After conducting a multi-year integration project for a client migrating from a legacy on-premise identity provider to a cloud-native, remote-first model, I've concluded that the most critical failure point isn't the core authentication, but the Multi-Factor Authentication (MFA) user experience. A poorly chosen MFA solution can cripple productivity and lead to widespread shadow IT as users seek workarounds.

For a remote-first company, the ideal MFA solution must satisfy several architectural non-negotiables:
* **Protocol Agnosticism:** It must support SAML, OIDC, and direct RADIUS for legacy VPNs without forcing different user experiences per application.
* **Resilience in Low-Connectivity Scenarios:** Users may be on subpar home networks or traveling. Solutions requiring constant push notification approval fail here.
* **Phishing Resistance:** SMS and one-time codes via email are trivial to intercept and should be considered deprecated from a security standpoint.
* **Administrative Cohesion:** The solution must be manageable entirely within the Entra ID admin ecosystem. Introducing a separate, disjoint admin console for MFA is a recipe for inconsistency and overhead.

In our implementation, we architected a tiered approach using Microsoft Entra ID's native capabilities, which proved successful:

```json
// Example Conditional Access policy configuration (conceptual)
{
"displayName": "Require Phish-Resistant MFA for Critical Apps",
"state": "enabled",
"conditions": {
"applications": {
"includeApplications": ["app-guid-for-crm", "app-guid-for-erp"]
},
"users": {
"includeUsers": ["All"]
},
"locations": {
"includeLocations": ["Any"]
}
},
"grantControls": {
"operator": "AND",
"controls": [
{
"control": "requireAuthenticationContext",
"value": "c1"
},
{
"control": "requirePhishingResistantAuthenticator"
}
]
}
}
```

The practical rollout involved:
1. **Primary Method: FIDO2 Security Keys (YubiKey, Windows Hello for Business).** This satisfies the phishing-resistant requirement for administrative and high-impact users. It works offline once registered.
2. **Fallback Method: Microsoft Authenticator App (Number Matching).** For the general user base, the authenticator app with number matching (not just tap-to-approve) significantly reduces MFA fatigue and accidental approvals. It requires less hardware logistics than keys.
3. **Contingency Method: Temporary Access Pass.** Generated by the help desk within the Entra admin portal, this provides a time-bound, high-privilege code for break-glass scenarios or when a user's primary method is lost.

The key was leveraging **Conditional Access** to apply these methods contextually, not universally. For example, accessing the development VPN from a new country might require the FIDO2 key, while checking email from a registered home laptop might only trigger the authenticator app once every 30 days. The data consistency across these states—ensuring a user's authentication strength is recognized by all integrated SaaS applications (CRM, ERP, IPAAS platforms)—is paramount.

My question to the community is this: in a heterogeneous environment where you must also integrate legacy systems (e.g., on-prem file servers via Azure AD App Proxy) and third-party SaaS that may not support the latest authentication context, how have you structured your CA policies to enforce strong MFA without creating user-hostile workflows? I am particularly interested in real-world data sync issues, such as MFA claims not properly propagating to downstream systems via SCIM or custom SAML claims.

-- Ivan