Build or buy device identification? An honest guide for engineering teams.

Build device identification yourself if your need is narrow and you have engineers to maintain it; buy it if you need reliable recognition across browsers and mobile apps, server-side decisions and a team that is not on call for the arms race. Most teams underestimate the second half of that sentence, so this guide is deliberately specific about it.

It is written for engineering teams weighing build vs buy for device fingerprinting and fraud signals. We sell one of the options, so we have tried to say plainly when the other one is the right answer.

#What does it take to build device identification?

A first version is a weekend project. A system you can trust with decisions is a product with several workstreams, each of which keeps going after launch.

• Collection that works across browsers, operating system releases and device types, inside a time budget short enough not to slow a signup.
• An identifier issued and remembered on your server, and a way to recognise a returning device whose attributes have drifted since its last visit, without merging two different devices.
• Storage and lookup that stay fast at your traffic, with scoping so identifiers never leak across customers or environments.
• Detection of automation, virtual machines, modified browsers and, in apps, emulators, rooted devices and tampering.
• Network intelligence for VPNs, proxies and Tor, which depends on data that has to be sourced, licensed and kept fresh.
• A scoring model you can explain, with weights, thresholds and an audit trail for every decision.
• SDKs for every platform you ship, server SDKs, webhooks, an events API and a console for your fraud team.

#What keeps costing after launch?

The maintenance, because the ground moves under you. Browsers change what they expose, and privacy features that randomise what a browser reports reduce recognition overnight. New operating system versions change what apps may read. Attackers adapt to whatever you catch, and each fix must be tuned so real customers are not caught with them.

That is why detections that live on the server matter. When rules run there, an improvement reaches every integration at once. On mobile, where an app update can take months to reach every phone, it is the difference between a fix this week and a fix next year. Building that split yourself is possible, but it is a design decision you must make early.

#What is the privacy burden of building it?

It is yours alone: consent, notices, retention, erasure and app store declarations all become your engineering and legal work. Collecting device data on a phone means a privacy manifest for iOS, store privacy answers for Android, a consent flow that collects nothing until it is granted, and a way to delete stored identity on request.

Fingerly’s SDKs come with these pieces: consent defaults to pending and collects nothing until granted, the iOS framework ships its privacy manifest, there is a call to delete the stored identity, and the SDKs never show a permission prompt. That removes work, but not responsibility. You still write your own privacy notice, and nothing here is legal advice.

#Why is mobile attestation the hardest part to build?

Because an app on the attacker’s phone can lie about everything except what the device’s security hardware proves. Doing that properly means issuing single-use challenges, verifying attestation chains on your server for each platform, handling the states in between (proven, not proven, failed), and deciding what an unproven device means for each action.

Fingerly verifies hardware-backed attestation on Android and App Attest on iOS on the server, records one state per event, and can optionally refuse reports that do not prove themselves. Even then, attestation raises the cost of forging a report; it does not make forgery impossible. Whoever builds this, own that limit in your policy.

#What does buying give you, and what does it not?

Buying gives you a working system on day one and someone else carrying the maintenance. With Fingerly that is one identify call from web, iOS and Android SDKs (with React Native, Flutter and Lynx bridges), server SDKs for Node.js, Python, Go, Java, .NET, PHP, Ruby and Rust, a visitor ID, signals, an explainable suspect score with weights you set, webhooks and a console.

• It does not know your accounts. You store the visitor ID beside each account and order, and your own database holds the counters.
• It does not decide for you. The API returns a score, a level and the triggers, and never blocks a request; your server decides.
• It is not perfect. When too little is reported to identify anyone, the response says so instead of guessing.
• The visitor ID is issued by Fingerly, so leaving means starting recognition from zero. Events are readable for 30 days, so keep your own copy of what you need.

#When is building the right call?

Building is fine when your need is narrow, your volume or constraints are unusual, and you can staff it. Be honest about whether those apply.

• You only need a one-per-device rule on a single logged-in web property, and first-party data such as account history and payment signals already catches most of your abuse.
• A hard requirement keeps all processing in-house, and you accept the ownership that implies.
• Your volume is high enough that a per-request price, however low, dominates your costs, and you have a team to carry the system.
• You already have fraud and mobile security engineers whose job is exactly this.

A middle path often works best: buy identification and signals, and build the policy. The rules that decide what your business does with a signal are specific to you and worth owning.

#How do you test before you commit?

• Pick one flow, such as signup or login, and integrate with a development key. Development and staging requests are free.
• Use the $1 signup credit, about 400 identifications, to try the check on real production traffic.
• Run in observe mode: log the decision the policy would have made next to what happened, and review the disagreements.
• Cost it honestly. Pricing is per identification, from $0.0025, so 100,000 identifications in a month is $250 at the first band, with lower graduated bands as volume grows. Requests that cannot be identified are free.
• Store the visitor ID in your own records from the first day, whatever you decide.