How should fraud, IAM, and privacy teams share responsibility for device trust?

How to split responsibility without splitting the control

device trust works best when fraud, IAM, and privacy treat it as one control surface with different decisions attached to it. Fraud should judge whether the signal improves detection and step-up accuracy, IAM should decide how the signal feeds authentication and policy, and privacy should decide whether collection, use, and retention stay proportionate to the purpose.

The practical issue is not who “owns” device trust in the abstract, but which team owns which decision when the trust signal changes a risk decision. If one team optimises only for its own outcome, the model will drift, either becoming too weak to stop abuse or too invasive to justify.

Device trust is strongest when the three teams agree on three things upfront: what the signal is for, what it is not for, and what happens when the signal is missing or ambiguous. That shared definition prevents a fraud feature from quietly becoming a permanent identity attribute or a privacy exception that never expires.

Where each team should draw the line

Fraud owns the performance of the signal in a decisioning context. That includes whether the device signal actually improves fraud score quality, reduces false positives, or helps distinguish ordinary friction from suspicious behaviour. Fraud should also own tuning and monitoring, because a weak or stale device signal can be worse than no signal at all if it drives bad decisions at scale.

IAM owns the integration point where device trust affects access. That means deciding whether the signal influences authentication strength, conditional access, session duration, reauthentication, or challenge policies. Zero Trust Identity Guide is useful here because the access decision must remain policy driven, not whatever the risk engine happens to prefer that week.

Privacy owns necessity and retention. If a device attribute is not needed for the stated purpose, or if it can be retained only for a shorter period, privacy should set the boundary. That is especially important when device trust data becomes persistent profiling data rather than a transient security signal. The EU General Data Protection Regulation (GDPR) is the clearest reference point when device data can identify a person or be linked back to one.

How to govern the shared signal in practice

The cleanest operating model is a joint policy that lists the approved device signals, the permitted uses, the retention period, the escalation path, and the review cadence. That policy should be signed off jointly, because device trust creates a genuine boundary issue: the same attribute can be a fraud feature, an IAM control input, and a privacy-sensitive identifier.

Teams should also define a fallback path for low-confidence or unavailable device trust. If the signal is absent, the system should degrade in a controlled way, usually by relying more heavily on stronger authentication or step-up checks, rather than silently widening access or blocking too aggressively. A stable fallback matters more than pretending the trust score is always available.

For implementation, use the signal as an input to a decision, not as a standalone verdict. That keeps IAM accountable for access, fraud accountable for detection quality, and privacy accountable for data minimisation. When the model starts making decisions that no team can explain or audit, governance has already failed.

Risk and Threat Considerations

Device trust becomes risky when the signal is over-relied on, over-collected, or left unmanaged across teams. The main exposure is policy drift: a signal introduced to reduce fraud can gradually become a broad access shortcut or a long-lived profile that exceeds its original purpose.

Failure mechanism: The device signal is treated as universally authoritative, even though it is only one input into authentication, fraud detection, and privacy decisions. Weak governance then allows stale, excessive, or poorly explained device data to shape access and retention beyond its intended scope.

Impact: That can lead to unjustified access, missed fraud, over-retention of personal data, and inconsistent decisions across channels. It also makes it harder to defend the control during audit, incident review, or privacy assessment.

Practitioner Guidance

What to verify: Confirm that every approved device signal has a named decision owner, a documented purpose, and a deletion or expiry rule. If the answer is “the platform handles it,” the control is already too vague.

Decision rule: If the signal changes access, challenge, or retention decisions, require IAM and privacy sign-off before production use; if it only improves fraud analytics, keep it within the fraud control boundary.

What good looks like: The same device trust signal should produce consistent results across channels, with clear escalation when confidence is low and no hidden expansion of collection over time.

Practitioner takeaway: Shared responsibility only works when the teams share the signal but not the decision authority, each team must own its own control outcome and agree on the boundary conditions that stop the signal from becoming policy by accident.

Related resources from NHI Mgmt Group

• Should IAM and fraud teams share responsibility for session trust controls?
• How should fraud teams and IAM teams share responsibility for step-up decisions?
• How do IAM and NHI teams share responsibility for zero trust governance?
• Should fraud, IAM, and digital product teams share ownership of customer trust controls?