The mistake is treating an active call as proof of fraud. Many legitimate customers will be on calls while using an app, especially in support or banking flows. A better approach is to use the signal as a prompt for proportionate friction, warning banners, additional verification, or human review when the action itself is sensitive or high value.
Why This Matters for Security Teams
Blocking someone solely because they are on a phone call creates a brittle control that confuses context with risk. A call can be a normal part of a legitimate workflow, especially in banking, customer support, travel, or recovery journeys. The security question is not whether the user is speaking, but whether the action is anomalous, high impact, or inconsistent with the expected session. That distinction matters because overblocking creates abandonment, support load, and user workarounds that weaken security rather than improve it.
Security teams often miss that call-state signals are only one piece of behavioural context. Used well, they can support step-up checks or fraud review. Used badly, they become a false positive engine that punishes legitimate users and still misses coordinated attacks. The right frame is proportionate friction, not automatic denial. This aligns with the broader posture philosophy in the NIST Cybersecurity Framework 2.0, where controls should reduce risk without creating avoidable operational harm.
In practice, many security teams discover the weakness only after a legitimate customer is locked out during a time-sensitive transaction, rather than through intentional fraud testing.
How It Works in Practice
A better implementation treats “on a call” as a soft signal that can influence a risk engine, not a standalone rule. The system should combine it with device trust, geolocation consistency, transaction sensitivity, account age, recent password resets, and prior session behaviour. If the user is on a call and tries to change payout details, reset a factor, or add a new beneficiary, the response may be step-up verification, transaction delay, or queueing for manual review. If the user is simply checking a balance, blocking is usually disproportionate.
Operationally, teams should define what the signal means, where it comes from, and how much weight it carries. Current guidance suggests using call-state data cautiously because it can be noisy, platform-dependent, and easy to misinterpret. It is also important to separate fraud signals from accessibility and customer-service contexts. A user may be on a support call to resolve an account issue, and the very act of blocking them can escalate risk and degrade trust.
- Use the signal as one factor in a risk score, not as a binary gate.
- Escalate only when the requested action is high-value or irreversible.
- Log the reason for friction so analysts can tune false positives.
- Provide a fallback path such as human review or secure callback verification.
For teams formalising detection and response, CISA Secure Our World is a useful reminder that user-facing protection works best when it is understandable and repeatable, not opaque and arbitrary. These controls tend to break down when call-state data is unavailable, spoofed, or delayed by mobile OS restrictions because the signal becomes inconsistent across devices and sessions.
Common Variations and Edge Cases
Tighter call-based friction often increases false positives and support overhead, requiring organisations to balance fraud reduction against customer experience and accessibility. There is no universal standard for weighting call-state data, so best practice is evolving rather than settled. Some environments should be especially cautious: shared devices, assisted digital support, enterprise mobility, and regulated payment flows all create legitimate reasons for users to be on a call while transacting.
One common edge case is recovery. A customer may be speaking with a helpdesk while trying to regain access after a lockout. Another is social engineering defence: an attacker may keep a victim on the line while the victim performs actions in an app. In that case, the call itself is not proof of fraud, but it can raise the urgency of additional verification if the request is sensitive. The practical control objective is to slow down high-risk actions without blocking routine ones.
Teams should also be careful when mapping this to policy. If the only rule is “on call equals deny,” the control becomes easy to bypass with VoIP, second devices, or scripted relays. Better outcomes come from combining behavioural signals, policy thresholds, and analyst review, with clear customer messaging and a tested exception path. For identity and authentication programmes, the most relevant baseline remains whether the action meets an assurance threshold, not whether the microphone is active.
For teams aligning fraud and access decisions with identity assurance, NIST SP 800-63 Digital Identity Guidelines is a stronger anchor than a raw call-state rule.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Context-aware access decisions should use multiple signals, not call state alone. |
| NIST SP 800-63 | IAL/AAL/FAL | Assurance should be based on identity proofing and authenticator strength, not phone status. |
| OWASP Agentic AI Top 10 | Behavioural signals can be misused as brittle policy inputs in automated decisioning. | |
| NIST AI RMF | GOVERN | Risk-based friction needs governance for accountability, tuning, and user impact. |
Design automated decisions to be explainable, reversible, and resistant to noisy signals.
