Device continuity before login
Many important visits happen before a user signs in or creates an account. There is no trusted account relationship at that point. Device continuity supplies earlier context: whether the current device has appeared before, how often it has appeared, and whether recent activity has changed in a meaningful way.
Continuity starts with the first visit
Browser Verifier returns an Imprint after a completed submission. When the customer backend queries Report API v1, a Lite Report includes device.id, device.seen_before, and device.access_count.
seen_beforeis true only when a visit exists before the current visit.access_countincludes the current visit.- Several Imprints can belong to one Device ID. An Imprint identifies one completed Report, while a Device ID represents a recognized device inside the customer’s authorized scope.
These fields provide continuity context before login, account creation, password recovery, invitation redemption, or a trial request.
Pro adds time and recent activity
A Pro Report includes first_seen_at and previous_seen_at. The first visit has a null value for previous_seen_at. Pro can also return event counts, distinct IP counts, and distinct country counts across 5-minute, 1-hour, and 24-hour windows.
The History Endpoint gives Pro and Enterprise customers a time-range view of visits. It supports investigation of access rhythm and change over time while keeping the full history on the server side.
How network changes fit the context
A device may move among home, mobile, corporate, and travel networks. A network change does not automatically erase device history or create a high-risk conclusion.
The Report places the current network state beside the device, browser, operating system, and continuity history for the same visit. Pro can add IP consistency, proxy risk, provider, connection type, ASN, and available location results.
Continuity is risk context
seen_before: true means EchoScan found an earlier device visit inside the customer’s authorized scope. It cannot prove the same real-world person or establish that the visit is trustworthy. Shared devices, browser-profile changes, remote access, and device transfers all affect interpretation.
seen_before: false does not make a visit dangerous. A new user, new device, operating-system reinstall, or meaningful environment change can create a first record.
Use continuity with risk.status, Pro risk reasons, account state, visit purpose, and the customer’s verification results.
Uses before account identity is available
Before account creation, a customer can use device history when reviewing whether the same device has claimed a free entitlement several times. Before login, continuity and network change can help decide whether to add verification. Before a high-value action, recent activity can join the customer’s transaction-risk policy.
Medium risk is a good candidate for added verification, rate limits, or manual review. Immediate denial based on one repeated device can harm people who share devices or return legitimately.
Continue to the Report and History documentation for public fields and query details.
Continuity questions
Does clearing cookies always erase device continuity?
No single storage event guarantees either outcome. EchoScan continuity is based on server-side device context derived from the current visit and prior observations, while browser changes can reduce confidence or lead to a new device record.
Is device history still useful after a network change?
It can remain useful because network data is one part of the context. A network change can be normal, so the current environment, continuity, activity, and your business data should be evaluated together.
Does a previously seen device prove it is the same person?
No. Device continuity describes a recognized device context inside the customer's access boundary. Shared devices, profile changes, remote access, and other real-world conditions prevent it from proving a person's identity.