How should organisations balance privacy and fraud prevention when using device proximity signals?

Why This Matters for Security Teams

Device proximity signals sit in a sensitive middle ground: they can help detect mule activity, shared-device abuse, and impossible travel patterns, but they can also become a covert location trace if the system is designed poorly. The privacy risk is not only what is collected, but how long it persists, who can correlate it, and whether it can be repurposed across customers. Current guidance suggests treating proximity data as fraud telemetry, not as a general-purpose identity attribute, which aligns with the principles in EU General Data Protection Regulation (GDPR).

Security teams often underestimate how quickly a “nearby device” signal can become a durable identifier when it is combined with account metadata, timestamps, and repeat observations. That is why minimisation, retention limits, and per-tenant scoping matter as much as the detection model itself. NHIMG’s Ultimate Guide to Non-Human Identities notes that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage, which is a useful reminder that sensitive telemetry often escapes its intended boundary once it becomes widely accessible.

In practice, many security teams encounter privacy complaints only after proximity telemetry has already been reused for broader analytics or cross-customer investigation.

How It Works in Practice

The safest pattern is to separate fraud detection objectives from raw location detail. Rather than storing exact coordinates or continuous device traces, organisations should use proximity proofs, coarse distance bands, or event-level assertions that confirm two devices were plausibly near each other at a given time. That makes the signal useful for fraud scoring while reducing the chance that the data can be reverse-engineered into a movement history.

Implementation should also scope the signal to a single customer account or tenant, so the same device observation cannot be correlated across unrelated users. This is especially important when the same mobile device, browser profile, or credential set appears in multiple contexts. The control goal is to reduce linkability, not merely hide the raw value. Privacy-by-design practice in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this by pairing security monitoring with data minimisation, retention control, and purpose limitation.

• Use the weakest proximity signal that still supports the fraud use case.
• Store only derived risk indicators when possible, not raw location artifacts.
• Limit access to fraud, abuse, and privacy teams on a need-to-know basis.
• Shorten retention so signals expire after the decision window.
• Prevent reuse of the same signal for marketing, analytics, or unrelated investigations.

For organisations comparing implementation patterns, NHIMG’s IOS app secrets leakage report is a useful reminder that sensitive telemetry becomes risky when it is exposed outside its original trust boundary. These controls tend to break down when proximity signals are exported into shared data lakes because downstream consumers usually lose the context needed to preserve purpose limits.

Common Variations and Edge Cases

Tighter proximity controls often increase fraud-operations overhead, requiring organisations to balance detection quality against privacy risk and review cost. There is no universal standard for this yet, so the right answer depends on the regulatory environment, fraud model, and whether the data is used for authentication, step-up verification, or post-event investigation. For example, stronger protections are usually warranted when the signal could reveal home, workplace, or travel patterns.

In some environments, coarse proximity may be enough for fraud scoring, but in others the signal must be combined with device integrity, session reputation, and behavioural telemetry to avoid false positives. When cross-border processing is involved, privacy review should also consider data residency and lawful basis. The operational question is not whether proximity data is “sensitive” in the abstract, but whether the system can prevent re-identification and secondary use.

That is why current guidance suggests documenting a clear fraud purpose, constraining retention, and evaluating whether the same outcome can be achieved with a less revealing signal. Where the organisation cannot explain why exact location is necessary, it should default to abstraction. In real deployments, the hardest failures appear when well-intended fraud controls are quietly expanded into general location analytics.

Related resources from NHI Mgmt Group

• How do organisations balance fraud prevention and user experience in identity flows?
• How can teams balance privacy expectations with fraud prevention controls?
• How should organisations design KYB onboarding to balance compliance, fraud prevention, and conversion rates?
• How should customer service teams use identity risk signals to balance fast resolution with fraud prevention?