---
title: "Building resilient authentication: device recognition beyond passwords — TraceTail"
description: "Use a visitor ID to tell known devices from new ones at sign-in, add friction only when the risk is real, and know where the signal stops."
url: https://tracetail.io/blog/resilient-authentication
updated: 2026-10-04
---

# Building resilient authentication: device recognition beyond passwords

Use a visitor ID to tell known devices from new ones at sign-in, add friction only when the risk is real, and know where the signal stops.

_TraceTail Team · published December 20, 2024 · updated October 4, 2026 · 3 min read_

Passwords are the weak point of most sign-in systems: people reuse them, attackers collect them from breaches, and once one leaks, it works for anyone. Multi-factor authentication fixes much of this, but adds friction to every sign-in.

Device recognition helps you spend that friction only where it's needed. A sign-in with the right password from the browser this account always uses is a different risk from the same password on a browser it has never used.

## Recognizing the device at sign-in

Identify the browser on your sign-in page and send the visitor ID with the credentials:

```javascript
import { TraceTail } from '@tracetail/js';

const tracetail = new TraceTail({ apiKey: 'YOUR_API_KEY', endpoint: 'https://tracetail.io/api' });
const { visitorId } = await tracetail.generateFingerprint();

// Send the visitor ID with the sign-in request.
await fetch('/api/login', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ email, password, visitorId }),
});
```

On the server, check the credentials first, then the device:

```javascript
async function signIn({ email, password, visitorId }) {
  const user = await verifyCredentials(email, password);
  if (!user) return { error: 'invalid_credentials' };

  const knownDevice = await db.userDevices.findOne({ userId: user.id, visitorId });
  if (knownDevice) {
    await db.userDevices.update(knownDevice.id, { lastSeenAt: new Date() });
    return { ok: true };
  }

  // A browser this account hasn't used: ask for a second factor first.
  return { ok: true, requireSecondFactor: true, reason: 'new_device' };
}
```

## Risk-based decisions

Not every sign-in needs the same scrutiny:

- **Known device, familiar network, usual hours**: let them in.
- **Known device, new network**: they may be traveling; allow it and note it.
- **New device, familiar network**: possibly a new laptop; ask for a second factor once, then remember the device.
- **New device, new network, odd hours, recent failed attempts**: ask for a second factor and tell the account owner by email.

```javascript
function signInRequirements({ knownDevice, knownNetwork, unusualHour, recentFailures }) {
  let score = 0;
  if (!knownDevice) score += 40;
  if (!knownNetwork) score += 20;
  if (unusualHour) score += 15;
  if (recentFailures > 0) score += 25;

  if (score < 20) return { secondFactor: false };
  if (score < 60) return { secondFactor: true };
  return { secondFactor: true, notifyOwner: true };
}
```

## Check again at sensitive moments

A session can be hijacked after sign-in. Rather than polling, identify the device again when it matters, for example before a password change, a payout or new payment details, and compare it with the device that signed in:

```javascript
const { visitorId } = await tracetail.generateFingerprint({ refresh: true });
```

A mismatch is a reason to ask for the password or a second factor again.

## Where the signal stops

- **It's evidence, not proof.** The visitor ID is computed in the visitor's browser and sent by your own page, so treat it as a strong signal rather than proof: an attacker who controls their browser can send any ID they like, including one they learned from a victim. Use it to decide when to ask for a second factor, never as the only factor.
- **Devices change.** The visitor ID uses the browser family, not its version, so routine browser updates don't change it. A new GPU driver or a major operating system update can, though. Treat that like a new device: verify once, then remember it.
- **People share devices.** Two family members on one laptop share a visitor ID; your account logic, not the device check, keeps them apart.

## What users see

For most sign-ins on recognized devices, nothing changes: a password, a passkey or single sign-on, and they're in. Only when something is unusual do they see an extra step, and you can tell them why: "We don't recognize this device. Enter the code we sent you."

That's better security without extra work on routine sign-ins.

## Getting started

Add the SDK to your sign-in page, pass the visitor ID to your backend, and build the rules above on your side. The free allowance of 1,000 requests a month is enough to try it end to end. [Read the docs](https://tracetail.io/docs).

Tags: Authentication, Account takeover, Device trust