Notifications
Clear all
Topic starter
12/06/2026 10:24 pm
TL;DR: Device fingerprinting, VPN detection, and related device intelligence can improve fraud prevention and reduce false positives, according to Fingerprint’s July 2025 posts, but they do not replace a full trust model for anonymous or returning users. For identity teams, the real issue is how to govern risk signals without treating them as proof of identity.
NHIMG editorial — based on content published by Fingerprint: how to detect a VPN to prevent fraud in 2026 and related device fingerprinting articles
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams use device fingerprinting without over-trusting it?
A: Use device fingerprinting as one signal in a broader risk model.
Q: Why do VPN detection signals matter in fraud prevention?
A: VPN signals matter because they often indicate that a user is hiding network origin or attempting to blend into a different location profile.
Q: What do security teams get wrong about device intelligence?
A: The common mistake is assuming that a stable device or familiar fingerprint means the session is trustworthy.
Practitioner guidance
- Define device signals as risk inputs Document that fingerprint, VPN, and browser-consistency checks may influence step-up, throttling, or review, but do not by themselves authorise access or prove identity.
- Separate fraud triggers from IAM assurance Create explicit policy boundaries so that account protection teams can act on suspicious device patterns without turning those patterns into account trust decisions.
- Use step-up for high-risk actions Require stronger verification when device intelligence suggests concealment, mismatch, or repetition and the user is attempting login, checkout, payout, or account recovery.
What's in the full article
Fingerprint's full article covers the operational detail this post intentionally leaves for the source:
- Practical examples of database validation, timezone checks, OS mismatch detection, and other fingerprinting signals used in fraud workflows
- Detailed guidance on how VPN detection fits into fraud prevention decisions without creating excessive false positives
- Specific uses of device intelligence in account protection and user recognition flows that implementation teams can adapt
- The article's own examples of how to identify suspicious sessions while maintaining usability for legitimate users
👉 Read Fingerprint's guidance on device fingerprinting and VPN detection for fraud prevention →
Device fingerprinting and VPN detection: what IAM teams miss?
Explore further
13/06/2026 1:08 am
Device fingerprinting creates a stronger signal, not a stronger identity. That distinction is central to governance. Fingerprint-style controls help teams recognise patterns, but they do not change the fact that the subject may still be anonymous, shared, automated, or compromised. The practitioner implication is to stop treating device intelligence as an identity control and govern it as a probability input.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most programmes still operate with incomplete identity inventory and weak assurance signals.
A question worth separating out:
Q: Who should own decisions when device signals and identity controls conflict?
A: Ownership should sit with the team that governs the action, not the signal source alone. IAM should own identity assurance decisions, fraud teams should own abuse detection logic, and product teams should align policy on step-up and denial paths. That keeps device intelligence informative without letting it become an ungoverned policy engine.
👉 Read our full editorial: Device fingerprinting for fraud prevention is not a full trust model
