Stop the takeover, not the owner.

Score every login and payout against the device history behind it: eleven months of clean use, hardware first seen this minute, or a reset four minutes ago.

Talk to an expertSee how it works
Weighted reasons behind every verdictStuffing caught at the deviceFriction only where it is earned
Owneru_4821ALLOWnowent_9a71c204known laptop, 11 monthsPorto, PT

Known laptop, eleven months of clean history, MFA passed an hour ago.

8/100Risk, takeover engine
Weighted reasons
Known device−30
Recent MFA success−18
New country+20
Devices on account, 28d
2
Accounts on device, 24h
1
Owner in, no friction earned
Try another action

The same engine, four verdicts.

Already in production

Publishing platforms, fintech and national charities across Europe already run TrustSig on their forms.

PublitPrint-on-demand and digital book distribution for publishers.Publishing · SwedenLEI SystemOfficial Legal Entity Identifier registration agent.Fintech · EstoniaDisability Sport WalesNational charity for inclusive and disability sport.Charity · Wales
And many more across Europe
Case studyHow LEI System eliminated API abuse & form spamRead the case studyAPI abuse, eliminatedZero false positivesLive in five minutes
01The engine

Scored against the account's own history

TrustSig Pro scores a login against what that account normally does, the hardware it has used before and the networks it usually arrives from.

01Device historyHardware first seen this minute, or eleven months of clean sessions. It is the strongest input in the score, and stolen credentials cannot supply it.
02Reset sequencesA password reset or contact change, followed by a new device and then a payout, scores higher than any of those steps alone.
03Cross-account fan-outOne device, IP or subnet touching many accounts in patterns no person produces. Per-minute rate limits miss the slow version.
04DormancyAn account that has been quiet for months waking up on unfamiliar hardware is worth a question, not a block on its own.
05Automation evidenceWebDriver, CDP, headless gaps, synthetic input timing and pointer humanizers, weighed with the rest rather than in a separate silo.
06Trust dampenersKnown hardware, a recent MFA success and a long clean record carry negative weight, so the genuine owner sails through the same check.
02Wiring

One call where you already decide

No redirect, no hosted page, no client rewrite. Send the login as an event with the token your page already collected, and send the failed attempts too.

login.tsthe decision
const e = await pro.submitEvent({  kind: "login",  user_id: user.id,  request_id: v.request_id,  context: {                      // request binding    ip: req.ip,    user_agent: req.headers["user-agent"],  },});
if (e.decision === "BLOCK") return deny();if (e.decision === "REVIEW") return requireMfa();
failed-login.tspre-auth
// A failed login carries an address the visitor merely typed.// Report it anyway: stuffing is invisible otherwise.await pro.submitEvent({  kind: "login",  user_id: typedEmail,  traits: { email: typedEmail },  identity_confidence: "claimed",});
Claimed identityA typed address is scored and counts toward velocity, but never binds a device to that account or sours its reputation.
Request bindingSend the IP, user agent and TLS your own server saw and TrustSig Pro compares them against what the edge recorded when the token was minted. Mismatches act under your policy.
RevisionsBehavioural evidence lands in the seconds after page load, so verifying at the moment you decide can return a stricter answer than the one issued earlier.
03The response

Friction scaled to the evidence

A binary gate turns every ambiguous login into either a fraud loss or a support ticket. TrustSig Pro returns the verdict with its reasons, and your stack decides what happens next.

01AllowClean evidence against a known account. The session opens and nobody sees a thing.
02ReviewGenuinely unsure. Ask for MFA, a magic link or a manual check instead of turning away a customer with a new laptop.
03BlockHard evidence at the moment of the action, like one host working through 214 accounts in nine minutes.
04Report backSend the MFA success as an event and the account's next login is scored knowing it went well.

Score your own logins before you enforce anything.

Talk to an expert
04 Questions

Account takeover, answered

You post the login as an event with your user_id and a device join. The takeover engine weighs it against that account's own history: known versus first-seen device, a new country, credential-stuffing fan-out, reset-then-new-device sequences and dormant reactivation. The response carries the decision, a risk score and every reason with its signed weight.

Reason weights are signed, so trust pulls the score down: a known device, a recent MFA success, a long clean history. On hardware the account has used before, the same login comes back as an allow or a step-up.

Step up: MFA, a magic link, or a manual queue. TrustSig Pro returns the verdict and the reasons, and your stack applies the friction. Report the MFA success back as an event and the next login is scored knowing it.

Yes, and you should: credential stuffing is invisible otherwise. Send those with identity_confidence: 'claimed' and they are scored and counted toward device and IP velocity. They never bind the device to the named account, so nobody can poison an account by typing its address into your login form.

No. One server-side call at the moment you decide, with the token your page already collected. No redirect, no hosted page, no client rewrite.

05More of the platform

Ask the same platform a different question

Every page below runs on the same telemetry, the same device identity and the same detection catalog.

01Spoofed devices & ban evasionA new fingerprint is not a new device.Anti-detect browsers02Multi-account & alt detectionName the account it is an alt of.Linked accounts03Scams & social engineeringCatch the session the real owner did not start.Coached approvals04Signup & trial-abuse protectionMatch a new signup back to the machine behind it.Serial signups05Account sharing detectionSee which seats are carrying five people.Shared seats06Bots, scrapers & AI agentsSort the crawler from the scraper from the human.Automation evidence07Privacy & data architectureNo cookies. Not one.Cookie-free
06Get started

Put your login flow through it

Tell us what your takeover pattern looks like and what it costs you. We will reply by email to set up access for your team.

  • EU-hosted and GDPR-native
  • Cookie-free device identity
  • Training mode before anything enforces