By NHI Mgmt Group Editorial TeamDomain: Governance & RiskSource: AuthsignalPublished August 12, 2025

TL;DR: Traditional MFA that stops at login no longer covers the full customer journey as phishing, session hijacking, contact center fraud, and SMS man-in-the-middle attacks shift risk beyond the front door, according to Authsignal and iProov. The practical lesson is that authentication must become journey-based, risk-aware, and resistant to replay, not just stronger at sign-in.


At a glance

What this is: This is a webinar-based analysis of why login-only MFA is failing against AI-powered fraud and where passkeys and biometrics fit into journey-based authentication.

Why it matters: It matters because IAM, fraud, and customer identity teams must secure recovery, transactions, and contact center flows, not just the initial sign-in moment.

By the numbers:

👉 Read Authsignal's webinar analysis of AI-powered fraud, passkeys, and biometrics


Context

Traditional MFA often treats authentication as a single event at login, but customer identity risk now follows the whole journey. Session hijacking, phishing, contact center fraud, and SMS man-in-the-middle attacks all exploit moments that sit outside the initial gate.

The article’s core point is that authentication has to shift from a point-in-time control to a journey-based control. For IAM teams, that means recovery, device change, high-value transactions, and call-centre verification need their own risk logic and assurance step.

For consumer identity programmes, that is a governance problem as much as a product problem. The weakest assumption is that the first factor at the front door is enough to protect every later interaction.


Key questions

Q: How should security teams design authentication beyond login for customer journeys?

A: They should map every identity-sensitive step after login, then set an assurance level for each one. Recovery, device change, dormant account access, and payment approval often need stronger checks than routine sign-in. If the same factor protects every step, the programme is usually overconfident about its actual fraud coverage.

Q: Why do passkeys reduce phishing risk more effectively than SMS OTPs?

A: Passkeys use cryptographic keys bound to the legitimate domain, so they cannot be reused on a phishing site the way an SMS code can. That removes the attacker’s ability to intercept or replay a shared secret. They are strongest when deployed as the primary login factor, not as a substitute for recovery controls.

Q: What do security teams get wrong about biometric authentication?

A: They often treat biometrics as a stand-alone proof of identity when they work best as part of a broader assurance chain. Biometrics should be anchored to strong onboarding evidence and used for step-up or recovery where identity continuity matters. Used alone, they can create confidence without fixing the fallback process.

Q: Who is accountable when fraud moves outside the login screen?

A: Accountability usually sits with multiple owners at once: IAM for assurance policy, fraud teams for abuse patterns, and product or operations teams for fallback journeys. The practical test is whether any user path allows a weaker channel to override a stronger one. If it does, ownership has not been assigned to the real control point.


Technical breakdown

Why login-only MFA leaves the rest of the journey exposed

Traditional MFA is usually bound to the authentication event that creates a session, not to the subsequent actions that session can perform. That leaves a gap between identity proofing, session establishment, and later business actions such as payment, recovery, or profile change. Attackers target those later stages because they often rely on weaker checks, less visibility, or human-assisted workflows. The control failure is not that MFA is absent, but that its protection boundary is too narrow for modern customer journeys.

Practical implication: extend assurance decisions beyond sign-in to the transactions and recovery paths that actually carry fraud loss.

How passkeys change phishing resistance and domain binding

Passkeys use public-private key cryptography so the private key never leaves the device and the signature is bound to the legitimate domain. That binding matters because phishing sites can imitate look and feel, but they cannot persuade a passkey to authenticate to the wrong origin. Compared with passwords or SMS OTPs, the attacker loses the ability to replay or intercept a reusable secret. Passkeys do not solve every fraud problem, but they materially reduce credential phishing and token theft.

Practical implication: prioritise passkeys where credential replay and phishing drive the majority of account takeover losses.

Why biometrics work best as a recovery and step-up control

Biometrics are strongest when they complement a possession factor rather than stand alone as a screen lock. In this model, biometrics answer continuity of identity during onboarding, recovery, dormant account reactivation, and other high-risk moments where the system needs to re-establish who the user is. The article’s point about binding biometrics to KYC documents is critical because it moves biometrics from convenience to assurance. That makes biometric use a governance issue, not just a user-experience feature.

Practical implication: reserve biometric step-up for high-risk lifecycle events where the identity link must be re-established, not for every routine login.


Threat narrative

Attacker objective: The attacker aims to impersonate the customer across the full journey and complete fraudulent actions without triggering high-assurance checks.

  1. Entry occurs through phishing, session hijacking, SMS interception, or contact center manipulation that avoids the primary login gate.
  2. Escalation follows when the attacker uses weaker post-login workflows such as recovery, device change, or transaction approval to increase assurance bypass.
  3. Impact is account takeover, fraudulent transaction execution, or unauthorized reactivation of dormant accounts.
  • MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
  • Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Journey-based authentication is now the baseline, not an enhancement. Login-only MFA assumes the risky event happens once, at the beginning of the session. That assumption no longer holds when fraud can emerge during recovery, device enrollment, contact center interaction, or transaction approval. IAM programmes that still treat authentication as a single checkpoint are governing the wrong boundary.

Passkeys solve replay risk, but they do not eliminate identity governance failure modes. The value of cryptographic binding is that it removes phishing and domain substitution from the attacker playbook. But if account recovery, dormant reactivation, or call-centre verification still rely on weak fallback checks, the programme simply shifts the weakest link to a different workflow. Practitioners should treat passkeys as a control boundary change, not a complete fraud strategy.

Biometric assurance becomes more defensible when it is anchored to onboarding evidence. The article’s strongest operational idea is not biometrics alone, but biometrics linked to trusted identity proofing and then reused in recovery or step-up flows. That aligns with a broader IAM principle: higher assurance is most reliable when the system can preserve the identity chain from enrolment to later verification. Practitioners should design for continuity, not isolated checks.

High-trust identity is a customer journey design problem disguised as an authentication problem. Fraud teams, IAM architects, and customer identity owners all touch the same control surface, but each often owns only one slice of it. The result is fragmented assurance, inconsistent fallback paths, and a false sense of coverage at login. Practitioners should reframe authentication governance around the complete lifecycle of access, not the first factor alone.

From our research:

  • Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
  • For a broader identity context, see Ultimate Guide to NHIs , Key Challenges and Risks for how over-privilege and visibility gaps persist across identity types.

What this signals

Journey-based assurance is becoming the practical minimum for consumer identity. As AI-assisted fraud lowers the cost of impersonation, teams should expect the strongest control to move from the initial login event to the highest-risk interaction in the journey. That is especially true where account recovery, call-centre handling, and device enrolment still depend on human exceptions rather than policy.

Face-swap, replay, and social engineering attacks now need to be analysed as one control problem. The distinction between authentication and fraud prevention is narrowing because attackers chain them together. Teams that want a defensible programme should align passkeys, biometric step-up, and fallback governance under the same risk model, then measure how often weaker paths are still reachable.

With 44% of developers following secrets best practices according to The State of Secrets in AppSec, the wider lesson is that governance fails when strong controls are undercut by everyday operational exceptions. Identity programmes need the same discipline: the control is only as strong as the weakest recovery path.


For practitioners

  • Map authentication controls across the full customer journey Inventory every place where identity is rechecked, including onboarding, recovery, device change, dormant account reactivation, contact centre flows, and high-value transactions. Assign assurance levels to each step, then remove any fallback path that is weaker than the risk it protects.
  • Deploy passkeys for phishing-resistant primary authentication Use passkeys where the current control objective is to prevent credential phishing, replay, and SMS interception. Keep the deployment tied to the legitimate domain and avoid treating passkeys as a substitute for recovery governance or step-up policy.
  • Bind biometric verification to trusted onboarding evidence Link biometric enrolment to the strongest available identity proofing process, such as document validation and high-assurance onboarding. Reuse that binding for account recovery and high-risk step-up only when the identity continuity is genuinely required.
  • Remove weak fallback paths from recovery and contact centre processes Replace knowledge-based questions, SMS OTP fallback, and manual exception handling with controls that preserve assurance under stress. If a caller or returning user can bypass the strongest factor through a weaker channel, the programme has not reduced fraud risk.

Key takeaways

  • Login-only MFA no longer covers the full fraud surface when attackers move into recovery, support, and transaction workflows.
  • Passkeys materially reduce phishing and replay risk because the credential is cryptographically bound to the legitimate domain.
  • High-assurance biometrics are most effective when tied to trusted onboarding and used selectively for high-risk lifecycle events.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, while PCI DSS v4.0 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63BPasskeys and authenticator assurance map directly to digital authentication guidance.
NIST CSF 2.0PR.AC-1The article is about authentication control design across the customer journey.
NIST Zero Trust (SP 800-207)5.2Journey-based authentication reflects continuous verification and reduced trust in static login.
PCI DSS v4.08.4.2Fraud-resistant authentication is relevant where payment and transaction assurance are in scope.

Use strong MFA and phishing-resistant methods for payment-related identity flows where applicable.


Key terms

  • Journey-based authentication: An authentication model that evaluates trust across the full customer interaction, not only at login. It assigns different assurance levels to onboarding, recovery, support, device changes, and transactions so that security follows risk instead of a single entry point.
  • Passkey: A phishing-resistant authenticator based on public-private key cryptography. The private key stays on the user’s device, while the server verifies a signature that is bound to the legitimate domain, which prevents replay on a fake site and reduces dependence on shared secrets.
  • High-assurance biometrics: Biometric verification used as part of a stronger identity chain, not as a standalone convenience check. In practice, it works best when anchored to trusted onboarding evidence and reserved for recovery or step-up events where identity continuity must be re-established.
  • Fallback path: Any alternate authentication or recovery route used when the primary control cannot be completed. Fallback paths often become the weakest link because attackers target them deliberately, so their assurance level must be governed as carefully as the primary method.

What's in the full article

Authsignal's full article covers the operational detail this post intentionally leaves for the source:

  • Live webinar discussion of how passkeys, biometrics, and adaptive MFA fit together in customer-facing authentication.
  • Practical examples of journey-based design across onboarding, recovery, dormant account reactivation, and contact center verification.
  • Specific fraud scenarios discussed with iProov, including face swap attacks, liveness bypass, and SMS-based interception.
  • Implementation framing for teams moving away from SMS OTPs under emerging regulatory pressure.

👉 The full Authsignal post covers the webinar discussion, implementation examples, and regulatory context for modern authentication.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org