Why do verification phishing attacks create risk even when organisations use phishing-resistant MFA for their main IdP?

Verification phishing creates risk because it targets the account creation or verification step, not the primary SSO login. If a user can be tricked into supplying a code, an attacker can register or validate an account on a different IdP and then use that identity to enter a downstream SaaS app. The result is access that sits outside the protected corporate tenant.

Why Verification Phishing Still Bypasses Strong MFA

Phishing-resistant MFA on the main identity provider protects the primary login flow, but verification phishing targets a different trust boundary: account creation, recovery, or secondary verification. That distinction matters because the attacker does not need to defeat the corporate tenant directly. They only need a user to validate an identity on another IdP, then reuse that verified account to enter a downstream SaaS app that trusts the external identity. The exposure is not hypothetical; it is a common pattern in 52 NHI Breaches Analysis-style incidents where identity trust assumptions break outside the main tenant.

Security teams often over-index on the strength of their corporate MFA and miss the fact that SaaS access can be federated, delegated, or independently verified elsewhere. That creates a gap between the protected login and the actual resource boundary. A user can still be socially engineered into authorising an account that sits beyond corporate conditional access, logging, and revocation controls. This is why phishing-resistant MFA is necessary but not sufficient. In practice, many security teams discover this only after a third-party account has already been used to reach sensitive data, rather than through intentional review of the full identity path.

How Verification Phishing Works Across Identity Boundaries

Verification phishing succeeds by separating the moment of user trust from the moment of resource access. The victim may see a code entry, email verification, or “confirm your account” prompt that appears routine. Once the attacker controls that verification step, they can establish an identity in a different tenant or application namespace and then authenticate into a downstream service that accepts that identity as valid.

Operationally, the risk is highest when the SaaS app trusts external IdPs without strong tenant restrictions, domain controls, or policy checks on account provenance. The user believes they are completing a normal security action, but the real effect is account establishment outside the corporate security boundary.

• Primary IdP MFA still protects only the main login path.
• Account verification can be abused to create a fresh trusted identity elsewhere.
• Downstream SaaS often treats the verified account as legitimate if federation succeeds.
• Revocation is harder when the account was never issued by the corporate tenant.

Security controls should therefore focus on the entire identity lifecycle, not only sign-in. That includes verification-step monitoring, domain allowlisting for federation, stricter tenant binding, and alerting on newly created externally sourced identities. The problem is echoed in the OneLogin API Key Vulnerability discussion, where trust in identity plumbing becomes the real attack surface. These controls tend to break down in environments with many unmanaged SaaS tenants because the verification path is distributed across providers and difficult to centralise.

Where Organisations Need Extra Controls and Where Guidance Is Still Evolving

Tighter identity controls often increase user friction and administrative overhead, requiring organisations to balance reduced takeover risk against operational complexity. That tradeoff is especially sharp when contractors, partners, and shadow SaaS apps need legitimate external access. There is no universal standard for this yet, but current guidance suggests that organisations should treat verification flows as security-sensitive events, not just onboarding chores.

Practical improvements include restricting which IdPs can be accepted, requiring tenant-specific federation rules, and reviewing whether self-service registration should be allowed at all for business applications. Organisations should also correlate verification events with anomaly detection, because a newly verified account can be the first observable step in a broader attack chain. For context on how identity abuse expands beyond traditional login phishing, OWASP NHI Top 10 is useful, as is the external view from MITRE ATT&CK Enterprise Matrix when mapping downstream abuse techniques.

One relevant indicator from 2024 ESG Report: Managing Non-Human Identities is that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which underscores how often identity trust is abused once it extends beyond the core tenant. Verification phishing breaks down most in highly federated SaaS estates where account provenance is weak and security teams lack a single place to enforce tenant-bound trust.

Related resources from NHI Mgmt Group

• Why does MFA remain necessary even when organisations use SSO, passkeys, or other phishing-resistant controls?
• Why do email attacks remain effective even when organisations use MFA?
• Why do organisations need stronger identity verification after phishing-resistant MFA becomes more common?
• Why do container runtime vulnerabilities create risk even when organisations already use Kubernetes isolation and managed cloud services?