Who should own account takeover detection when phone signals are involved?

Why This Matters for Security Teams

Phone-based signals sit at the intersection of account recovery, step-up authentication, and fraud response, so ownership cannot be treated as a narrow IAM ticket. A number tied to a SIM swap, port-out event, or recycled handset can invalidate trust in the same moment it is still needed for login and recovery. That is why shared ownership between IAM and fraud operations is the practical model, even though current guidance suggests many organisations still route these signals through separate queues. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows how identity compromise becomes materially worse when visibility and response are fragmented.

Security teams also need to recognise that phone signals are not strong proof of identity by themselves. They are risk indicators that should influence authentication policy, recovery friction, and fraud review together, not sequentially. The NIST framing in NIST SP 800-53 Rev 5 Security and Privacy Controls supports coordinated control ownership, because detection is only useful if it can trigger action fast enough to stop takeover. In practice, many teams discover this ownership gap only after a recovery abuse case has already been approved by one workflow and blocked by another.

How It Works in Practice

The most effective operating model is a shared decision path with clear handoffs. IAM typically owns the authentication policy, trust scoring, and recovery restrictions, while fraud operations owns anomaly review, telecom risk signals, and downstream loss monitoring. Both teams should consume the same event stream and the same case record so that a phone-number change, SIM swap indicator, or device reassignment is evaluated once, then acted on consistently. The goal is not to split accountability, but to prevent contradictory decisions.

A practical workflow usually includes:

• Phone signal ingestion from telco, device intelligence, or account telemetry.
• Immediate risk scoring against account age, recovery history, and recent auth behaviour.
• Policy action such as delayed recovery, step-up verification, or temporary hold.
• Fraud case creation when the signal suggests coordinated abuse or monetisation risk.
• Post-event feedback into IAM rules and fraud models so thresholds improve over time.

This structure aligns with the NIST Cybersecurity Framework 2.0 idea of coordinated governance and outcome-driven risk response, and it becomes stronger when organisations tie the workflow to broader identity lifecycle controls. NHI Management Group’s NHI Lifecycle Management Guide is useful here because the same operational weakness appears when identities, recovery factors, and secrets are not managed as a lifecycle rather than a one-time setup. Phone signals should therefore be treated as mutable trust inputs, not permanent proof.

Teams also need predefined escalation thresholds so a suspicious phone event cannot sit in a queue while a user continues to retry access. These controls tend to break down when recovery, support, and fraud are run in separate platforms because each system sees only part of the trust decision.

Common Variations and Edge Cases

Tighter phone-based controls often increase support friction, requiring organisations to balance takeover prevention against customer recovery speed. That tradeoff matters most in high-volume consumer environments, where legitimate number changes are common and false positives can create real abandonment risk. Best practice is evolving, but there is no universal standard for when a number change alone should block recovery versus trigger step-up review.

One edge case is enterprise support for employees who travel, change carriers, or use shared service numbers. Another is lifecycle risk from recycled numbers, where a “valid” phone signal may belong to a different person entirely. In those cases, the control should shift from “who owns the number” to “how much trust should this signal carry right now.” This is especially important when the number is just one factor among device posture, passkeys, email recovery, and recent session telemetry.

Organisations that process high-value transactions should also avoid assigning phone risk solely to fraud if the decision changes authentication permissions. A number used in login recovery affects access assurance, not just loss prevention. That is why the most resilient model is a joint operating procedure with one triage queue, one escalation policy, and shared metrics for both takeover prevention and recovery abuse. Where support teams are empowered to override risk scores without fraud review, the model tends to fail quickly and quietly.

Related resources from NHI Mgmt Group

• Why do phone-number based login methods create account takeover risk?
• Why do passkeys reduce account takeover risk more effectively than OTP?
• Who is accountable when recycled numbers lead to account takeover?
• How should organisations handle recycled phone numbers in account recovery flows?