Drive Phishing-Resistant MFA Migration & Auth Posture

Outcome

Security teams gain a continuously maintained, account-level view of authentication method strength across every user account in the environment — identifying every account that relies on a weak, phishable, or inadequate authentication method and driving migration to stronger controls before those accounts become breach entry points. Findings are prioritized by account privilege, data access scope, and identity type so remediation effort lands where the risk is highest.

What "weak auth" costs in practice: SMS OTP can be intercepted via SIM-swapping. Push notifications can be approved through MFA fatigue attacks. Passwords alone are compromised in bulk through phishing and credential stuffing. Each of these is a known, documented attack pattern — and each is fully preventable with stronger authentication controls. The question is not whether weak auth is exploitable. It is whether you know which of your accounts still rely on it.

Why this is hard without Oleria

Authentication method strength data is fragmented, inconsistently enforced, and not correlated to the risk level of the accounts it protects. Organizations trying to assess weak auth exposure across their environment face:

· MFA enrollment does not equal strong MFA. An account enrolled in MFA may be using SMS OTP — one of the weakest second factors available, vulnerable to SIM-swapping and real-time phishing relay attacks. IDP dashboards report MFA enrollment as a binary: enrolled or not. They do not surface which enrolled accounts are using methods below an acceptable assurance level, and they do not prioritize remediation by the privilege or sensitivity of the account in question.

· Conditional access policy gaps leave MFA bypassable. Even strong MFA policies have gaps: legacy authentication protocols that bypass MFA challenge, trusted network exemptions that allow passwordless access from certain locations, and application-specific policy carve-outs. These gaps are rarely visible in a single admin console view, and they are not correlated to the specific accounts or applications they affect.

· Local accounts bypass IDP auth enforcement entirely. Accounts that authenticate directly to SaaS applications with local credentials — bypassing IDP SSO — are outside the IDP's authentication policy scope. Whether the IDP enforces phishing-resistant MFA is irrelevant for these accounts. They authenticate with whatever the application natively supports, and they are often invisible to identity governance tools focused on IDP-managed identities.

· The weakest method in the chain sets the security level. A user may authenticate with FIDO2 to their IDP but with SMS OTP to a specific SaaS application that has its own MFA layer. The weakest method used anywhere in the authentication chain is the effective security level of that account. Without a cross-application view, teams see the strongest method in use — not the one that actually determines breach risk.

· No cross-application auth method visibility. Each application surfaces authentication data within its own admin console. There is no native mechanism to produce a unified, prioritized view of auth method strength across every account in every connected application — making it impossible to know the full weak auth exposure at any given moment.

· External and contractor accounts fall outside enforcement scope. Guest and contractor accounts in Entra ID and Okta, and local accounts used by third parties in SaaS applications, are often subject to weaker or no authentication policy enforcement — and are rarely included in method strength assessments.

‍

What Oleria delivers

Oleria Trustfusion ingests authentication method enrollment data from IDPs and SaaS application connectors, classifies each account's effective assurance level, and surfaces weak auth findings prioritized by privilege tier and risk context — continuously, across the full account population.

Authentication method classification per account.

For every account, Oleria classifies the authentication method in use against a configurable assurance tier model. Methods are grouped as phishing-resistant (FIDO2/passkey, hardware security key, certificate-based authentication); standard (authenticator app TOTP, push notification with number matching); and weak (SMS OTP, voice call, email OTP, simple push without number matching). The effective assurance level — the weakest method available for the account, not the strongest — is what is evaluated against policy.

Weak MFA method gap detection

Accounts enrolled in MFA but using methods below the configured minimum assurance level for their privilege tier are surfaced as weak auth findings — distinct from accounts with no MFA at all. An admin account using only SMS OTP has a different remediation action than one with no MFA enrolled. Both are tracked, prioritized, and assigned through Posture Campaigns.

Password-only accounts flagged by privilege and scope.

Accounts that authenticate with password alone — no MFA of any kind — are surfaced and ranked by privilege tier and access scope. A password-only admin account is a critical finding. A password-only standard user in a low-sensitivity application is lower priority. Prioritization reflects the actual blast radius of a successful credential attack.

Conditional access and policy enforcement gap detection.

For Okta and Entra ID environments, Oleria evaluates whether each account is covered by a sign-on or conditional access policy that enforces the required assurance level — including whether legacy authentication protocols are blocked and whether trusted network or location exemptions create MFA bypass paths for specific accounts or applications.

Local account authentication exposure.

Accounts that authenticate directly to SaaS applications outside IDP SSO are identified and their authentication posture evaluated independently. Local accounts with weak or no MFA on privileged roles are critical findings — they are simultaneously outside IDP auth enforcement and using inadequate authentication controls.

External and guest account auth posture.

Contractor and guest accounts — including Entra ID B2B guests and Okta external users — are evaluated for authentication method strength alongside internal accounts. External accounts with privileged access and weak or no MFA are surfaced as high-priority findings, consistent with the broader external identity risk posture in Trustfusion.

Continuous posture monitoring

Authentication method posture is re-evaluated continuously. If a user removes a strong MFA method and falls back to SMS, if a new privileged account is provisioned without meeting the required assurance level, or if a conditional access policy change creates an enforcement gap — a finding is generated within hours, not at the next periodic review.

How it works

Stage 1 — Continuous Ingest of Authentication Method Configurations Across Okta and Entra ID: Oleria connectors pull MFA enrollment records and registered authenticator method types from IDPs — Okta factor enrollment data and Entra ID authentication method registrations — alongside sign-on policy and conditional access rule configurations, and legacy authentication protocol enablement per application. For SaaS applications with their own MFA layers, connector data includes per-account authentication method configuration where available via API. All data is ingested continuously via read-only connections.

Stage 2 — Classifying Verification Assurance Tiers Within the Unified Access Graph Architecture: Authentication method data is normalized to a common assurance tier schema and correlated to each canonical identity in the Access Graph. A single user's authentication posture across their IDP account and their local SaaS accounts is attributed to the same identity record. The effective assurance level — the weakest method available across all authentication pathways for that identity — is calculated and recorded. Privilege tier is applied from the entitlement data already present in the Access Graph.

Stage 3 — Automated Posture Evaluation Against NIST and Corporate Authentication Policies: Each account is evaluated against a configurable minimum assurance level by privilege tier: phishing-resistant MFA required for highly privileged roles; at minimum standard MFA for all accounts with any system access above a defined baseline; no password-only accounts above a defined privilege threshold. Conditional access policy coverage is evaluated separately for Okta and Entra ID environments. Each violation generates a typed posture finding with severity, the specific method gap, and remediation guidance.

Stage 4 — Executing Targeted Posture Campaigns to Force Phishing-Resistant Migration: Findings surface in the Posture Dashboard filterable by auth weakness category (no MFA, weak method, policy gap, local account), privilege tier, identity type, and application. Posture Campaigns assign findings to IT admins or account owners' managers with method upgrade guidance and due dates. When an account's auth method is upgraded or a policy gap is closed, the finding is re-evaluated and resolved. The complete remediation chain — finding opened, owner assigned, action taken, confirmed closed — is retained as timestamped audit evidence

What good looks like

A mature authentication method assurance program produces measurable, continuously validated outcomes across the full account population:

· Phishing-resistant MFA on every highly privileged account. Every account carrying a highly privileged role — Global Admin, Super Admin, production system administrator — authenticates with a phishing-resistant method: FIDO2, hardware security key, or certificate-based authentication. No highly privileged account relies on SMS OTP, push notification alone, or password only. This is a tracked KPI with zero tolerance for open findings.

· No SMS or voice MFA on any privileged account. The use of SMS OTP or voice call as the sole or primary MFA method on any account above the standard user privilege tier is a tracked finding remediated within a defined SLA. The population of privileged accounts relying on weak methods trends to zero over time and is reported to security leadership.

· No password-only accounts with any system access. Every account with access to any corporate system has at minimum standard MFA enrolled and enforced. Password-only accounts are continuously detected, owned, and remediated — not left open because they are not visible.

· Conditional access gaps closed. Legacy authentication protocols are blocked for all accounts above the standard user tier. Conditional access policies are confirmed to cover every privileged account with no trusted-network or application exemptions that create MFA bypass paths.

· New accounts meet assurance requirements before they become operational. Any new account provisioned above the password-only threshold without meeting the required assurance level generates a finding within hours. Accounts are not operational for sensitive workloads until their auth method meets the required level for their privilege tier.

· Compliance evidence produced on demand. The authentication method inventory, current posture state, and remediation history for every account is available from Trustfusion for PCI DSS, NIST SP 800-63B, CISA phishing-resistant MFA requirements, FedRAMP, and SOC 2 auditors — without manual report assembly.

Frequently Asked Questions

How does Oleria define "weak" authentication?

Oleria classifies authentication methods against a configurable assurance tier model aligned with NIST SP 800-63B Authenticator Assurance Levels. Phishing-resistant methods — FIDO2/passkey, hardware security key, PIV/CAC certificate-based authentication — meet the highest assurance level. Standard methods — authenticator app TOTP and number-matching push notification — meet a moderate assurance level. Weak methods — those that are phishable or interceptable — include SMS OTP, voice call OTP, email OTP, and simple push notification without number matching. Password-only accounts (no MFA) are treated as the lowest assurance level. The specific assurance requirement per privilege tier is configurable by the organization.

What is the difference between a "no MFA" finding and a "weak MFA method" finding?

A no-MFA finding means the account has no second factor enrolled — it authenticates with password alone, with no additional verification step. A weak-method finding means the account has MFA enrolled, but the enrolled method is below the minimum assurance level for the account's privilege tier — for example, a privileged admin account enrolled with SMS OTP only. The remediation actions differ: no-MFA accounts need MFA enrollment enforced; weak-method accounts need the enrolled method upgraded. Oleria surfaces both as distinct finding types with separate remediation guidance and SLA targets.

Can Oleria detect when a legacy authentication protocol is enabling MFA bypass for specific accounts?

For Okta and Entra ID environments, Oleria reads conditional access and sign-on policy configurations and evaluates whether legacy authentication protocols — Basic Auth, NTLM, legacy Exchange protocols — are enabled for specific accounts or applications in a way that allows authentication without MFA challenge. Accounts where such a bypass exists are surfaced as conditional access gap findings, distinct from weak-method findings. The finding identifies the specific account, the protocol, and the policy scope where the gap exists.

How does this use case relate to the MFA coverage use case?

The MFA coverage use case answers "does every privileged account have MFA?" — a binary enrolled / not-enrolled question. The weak auth methods use case goes further: "for accounts that have MFA, is the method strong enough for the privilege level of the account?" The two use cases are complementary layers of the same authentication posture program. An account with SMS OTP enrolled passes MFA coverage but fails the weak auth method assessment. Both findings are surfaced in Trustfusion and can be managed together in the same Posture Campaign workflow.

Does Oleria cover authentication method strength for external and contractor accounts?

Yes. Guest and contractor accounts — including Entra ID B2B guests and Okta external users — are evaluated for authentication method strength using the same framework as internal accounts. External accounts with privileged access and weak or no MFA are surfaced as high-priority findings. This is particularly important given that external accounts are among the most frequently exploited initial access vectors and are often provisioned with weaker authentication requirements than internal employees.

How does Oleria handle accounts that use different MFA methods for different applications?

Oleria records authentication method data per account and per application where available, and calculates the effective assurance level as the weakest method in use across any of the account's authentication pathways. A user who authenticates with FIDO2 to their IDP but with SMS OTP to a specific SaaS application that enforces its own MFA layer is evaluated at the SMS OTP assurance level — because that is the weakest link in the chain and the one an attacker would target.

Which compliance frameworks have specific requirements for authentication method strength?

NIST SP 800-63B defines three Authenticator Assurance Levels (AAL1, AAL2, AAL3) with specific method requirements at each level — phishing-resistant authentication is required at AAL3 for high-assurance use cases. PCI DSS v4.0 (Requirements 8.4 and 8.5) requires MFA for all access into the cardholder data environment and specifies that the MFA implementation must resist replay attacks — a standard that SMS OTP does not meet. CISA's Phishing-Resistant MFA guidance specifically identifies SMS and simple push-based MFA as insufficient for high-value targets. FedRAMP and CMMC both require phishing-resistant MFA for privileged access. Trustfusion provides the authentication method inventory and remediation evidence needed to demonstrate compliance with these requirements.

Find every weak authentication method in your environment and replace it before the next incident