Device risk decisions should be shared across fraud, IAM, and customer identity teams because the control affects authentication, account security, and transaction authorisation at once. If those teams work separately, the organisation usually creates inconsistent friction and blind spots that attackers can exploit across the customer journey.
Why This Matters for Security Teams
Device risk decisions sit at the intersection of authentication, fraud detection, and downstream authorisation, so ownership cannot be treated as a narrow IAM admin task. A device that looks low risk at login may still be high risk for payment approval, account recovery, or step-up challenges. That is why the control needs shared accountability and common signals, not separate queues with different thresholds.
Current guidance suggests that device risk should be governed as part of a broader identity and trust decision, not as an isolated point-in-time check. The NIST Cybersecurity Framework 2.0 emphasizes coordinated risk management across functions, while NHIMG research shows how weak identity governance and inconsistent access practices create exploitable gaps in the customer journey. The problem is amplified when device intelligence, fraud telemetry, and IAM policy are owned in different systems with no shared decision model. In practice, many security teams encounter this only after attackers have already learned where friction and exception handling diverge.
How It Works in Practice
Operational ownership should be shared, but decision authority must be explicit. Fraud teams usually own behavioural signals, IAM teams own authentication and identity proofing controls, and customer identity teams own the user journey and recovery experience. The practical answer is a joint operating model with a single policy layer that consumes device posture, session risk, user history, and transaction context before deciding whether to allow, challenge, deny, or step up.
That model works best when teams agree on a common risk language and a clear escalation path. For example:
- IAM defines the authentication policy and where device trust affects login, recovery, or token issuance.
- Fraud defines risk thresholds for unusual device behaviour, bot patterns, and impossible travel.
- Customer identity owns the user experience impact, including fallback paths and false-positive handling.
- Security architecture sets logging, review cadence, and policy governance.
NHIMG guidance on Top 10 NHI Issues and the Ultimate Guide to NHIs is useful here because the same governance failure appears in both human and non-human contexts: separate owners create inconsistent controls, which attackers route around. The main implementation mistake is treating device risk as a static rule set instead of a living decision process tied to real-time context, policy review, and incident feedback. These controls tend to break down when legacy IAM, fraud tooling, and customer-facing applications cannot share session telemetry because each system evaluates risk too late to coordinate the outcome.
Common Variations and Edge Cases
Tighter device-risk governance often increases friction and operational overhead, so organisations have to balance stronger trust decisions against customer drop-off and support burden. There is no universal standard for this yet, especially in regulated industries where one team may own authentication policy and another owns transaction risk.
In some environments, fraud owns the final deny decision, while IAM owns only step-up authentication. In others, customer identity owns the experience layer and fraud or security owns the risk engine. The right answer depends on where the decision is enforced and which team can act fastest when a device risk score changes mid-session. Best practice is evolving toward shared policy, shared telemetry, and separate accountability for controls, experience, and investigation. NHIMG’s 2024 Non-Human Identity Security Report highlights the same maturity gap in adjacent identity programmes, where organisations know the control matters but lack consistent ownership and execution. For customer journeys with sensitive actions, teams often need one policy owner and one dispute owner, otherwise exceptions become the attack path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM | Device risk ownership is a governance and risk-management decision. |
| NIST CSF 2.0 | PR.AA | Device risk directly affects how identities are authenticated and trusted. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared ownership prevents inconsistent identity controls and blind spots. |
Assign a cross-functional owner to govern device-risk policy, review outcomes, and reconcile exceptions.
