How can security and fraud teams balance extra checks for unrecognized devices with a smooth experience for trusted customers?

Teams should apply stronger controls when device confidence is low and reduce friction when the device history supports a returning user. That usually means adaptive step-up verification, targeted MFA, and tighter review for suspicious sessions, while trusted devices move through a lighter path. The key is to make risk-based decisions that protect revenue without punishing normal customers.

How risk-based device checks should work in practice

The real design choice is not whether to check devices, but how to make the check proportional to confidence. A trusted device history can lower friction because it gives the team more signal about the session, while an unfamiliar or high-risk device should trigger stronger review before access is granted or a transaction is allowed to proceed.

That balance works best when device trust is treated as one input in a broader decision, not as a binary allow or deny rule. Device reputation, session behavior, account age, location shifts, and transaction value all help determine whether a customer stays on a smooth path or gets stepped up for additional verification.

For teams building or tuning that policy, the useful question is whether the control catches meaningful risk without forcing stable customers through the same challenge flow every time. A well-calibrated policy uses lightweight checks for expected returning behavior and reserves extra friction for sessions that are new, inconsistent, or high impact.

Where extra friction is justified, and where it becomes a problem

Extra checks are most defensible when the device is unrecognized, the session is unusual, or the action being attempted carries higher fraud or account-takeover exposure. In those cases, step-up verification is not just a security control, it is part of the trust decision that protects the customer, the institution, and the transaction itself.

Friction becomes a problem when every exception path is treated the same. If low-risk returning customers are forced through repeated challenges, teams often see avoidable drop-off, more abandonment at login or checkout, and more support burden. The aim is to concentrate scrutiny where the expected loss or compromise probability is actually higher.

One practical signal is whether the step-up path changes only for the risky slice of traffic. If trusted customers routinely see MFA or manual review with no clear increase in fraud prevention, the policy is too blunt. If suspicious sessions pass through with little resistance, the policy is too permissive.

Risk and Threat Considerations

Unrecognized devices are attractive to fraud actors because they often coincide with account takeover attempts, session theft, or scripted abuse. The main risk is false trust, where a customer appears normal enough to bypass checks even though the session is new, anomalous, or already compromised.

Failure mechanism: The control fails when device confidence is based on weak or easily reset signals, or when step-up rules are too loose to distinguish a legitimate returning user from a stolen session or a fraudster replaying access from a fresh device.

Impact: That weakness can lead to unauthorized access, fraudulent transactions, account takeover, and unnecessary friction for legitimate users if the policy overcorrects and treats normal customer behavior as suspicious.

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, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Device trust and step-up checks are access decisions tied to authentication confidence.
Recommendation — Use PR.AA to gate high-risk sessions with stronger authentication and tighter access decisions.
CIS Controls v8	6 — Access Control Management	Balanced device checks depend on least-privilege access and controlled authentication paths.
Recommendation — Apply Control 6 to restrict sensitive actions until risk-based device checks pass.
OWASP Agentic AI Top 10	A1 — Prompt Injection	Selected only for the broader pattern of untrusted inputs driving unsafe authorization decisions in digital workflows.
Recommendation — Treat untrusted context as a trigger for step-up when it can alter a protected decision.
NIST SP 800-63	IAL — Identity Assurance Level	Risk-based step-up depends on assurance strength appropriate to the requested action.
Recommendation — Set assurance requirements to match the sensitivity of the session or transaction.

Practitioner Guidance

What to prioritise: Tie the device decision to the action being attempted. A login from an unknown device may deserve one level of scrutiny, while a payment change, payout request, or credential reset should face a stricter threshold because the downside is higher.

What to verify: Confirm that trusted-device logic is durable and reviewable, not just convenient. Teams should be able to explain why a device was considered trusted, what signal caused step-up, and when that trust expires or is revoked.

Common mistake: Treating device recognition as a substitute for fraud detection. A known device can still be compromised, so the policy should reduce friction only when the broader session evidence supports it, not because a single signal says “familiar.”

Practitioner takeaway: The best balance comes from making device trust conditional, time-bound, and context-aware, so security teams can raise friction only when it materially improves protection.