Who should own passwordless risk across IAM, fraud, and support?

Ownership should be shared, but accountability should sit with identity governance because the risk spans authentication, device lifecycle, and recovery. Fraud teams may detect abuse and support teams may execute recovery, yet IAM must define the assurance standard and the controls for reissue and exception handling.

Why This Matters for Security Teams

Passwordless authentication does not remove identity risk. It shifts the risk surface into enrollment, device trust, recovery, fraud detection, and help desk workflows, where ownership often becomes unclear. When accountability is split informally across IAM, fraud, and support, gaps appear in exception handling and reissue approvals. NHI Management Group’s Top 10 NHI Issues shows how quickly identity controls drift when operational ownership is not explicit.

The security issue is not whether passwordless is stronger than passwords. It usually is. The issue is whether the organisation has a single team that can define assurance standards, approve recovery paths, and test whether fraud signals actually feed back into access policy. That aligns with the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects clear ownership for identity assurance, access enforcement, and incident response.

In practice, many security teams discover the ownership gap only after a support-led recovery path has been abused or a fraud alert failed to trigger an identity control review, rather than through intentional governance design.

How It Works in Practice

The cleanest operating model is shared execution with single-point accountability. IAM should own the policy, assurance standard, and control design for passwordless access. Fraud should own abuse detection, anomaly scoring, and escalation triggers. Support should own the approved recovery workflow, but only within guardrails defined by IAM. This avoids the common failure mode where support can reissue access based on convenience, while fraud sees the abuse too late to stop it.

Practically, that means defining who approves device binding, who can reset a factor, what evidence is required for re-enrollment, and which events force step-up checks or temporary lockout. The same logic appears in broader identity governance guidance from NIST Cybersecurity Framework 2.0, where governance and protective controls must be measurable, owned, and continuously reviewed.

For teams mapping this to NHI and credential lifecycle patterns, NHIMG’s research on Ultimate Guide to NHIs and The 2024 Non-Human Identity Security Report is a useful reminder that identity assurance breaks down when secrets, recovery, and access exceptions are managed as separate problems rather than one lifecycle. The report notes that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, which is a strong indicator that process ownership is still immature.

• IAM defines the policy: assurance level, recovery rules, and exception thresholds.
• Fraud monitors signals: impossible travel, device change, social engineering patterns, and account takeover indicators.
• Support executes only approved recovery steps with strong verification and logging.
• Security governance reviews exceptions, failed recoveries, and recurring abuse patterns.

These controls tend to break down in high-volume support centres with inconsistent verification scripts and in environments where product teams can bypass central identity policy for speed.

Common Variations and Edge Cases

Tighter recovery controls often increase support friction, requiring organisations to balance user experience against account takeover risk. That tradeoff is especially visible in customer-facing environments, where recovery speed affects retention and fraud pressure affects loss rates.

There is no universal standard for exactly where fraud ends and IAM begins, but current guidance suggests IAM should own the policy framework while fraud supplies risk signals that can suspend, challenge, or elevate recovery. In highly regulated sectors, support may be prohibited from performing any recovery action without a second-verification path. In smaller organisations, one team may operate all three functions, but the separation of duties still needs to exist in process, even if it does not exist in headcount.

NHIMG’s 2024 ESG Report: Managing Non-Human Identities reinforces the practical lesson that identity compromise rarely stays isolated. Once recovery is weak, attackers often chain it into broader access abuse, so ownership must include detection, reissue, and post-incident review, not just login policy.

For teams building mature programs, the right question is not which department “owns” passwordless in a political sense. It is which team can enforce the assurance standard end to end, with fraud and support acting as controlled partners rather than informal exception makers.

Related resources from NHI Mgmt Group

• Who should own risk-scoring decisions across fraud and compliance teams?
• Who should own document fraud controls across IAM and fraud teams?
• Who should own bot abuse response across fraud and IAM teams?
• Who should own passwordless authentication across IAM, IGA, and PAM teams?