Castle competitors and alternatives

The alternatives, briefly

Kaidn compared with Castle

Account security for developers: registration abuse, credential stuffing, account takeover and session risk, driven by device and behavioural signals.

Castle and Kaidn get compared because we both sell risk scoring to engineers rather than to a fraud department, and because we both think a score you cannot interrogate is not much use. On the question of who the buyer is, we agree.

We are pointed at different halves of the problem, and the halves are further apart than they look.

Abuse of accounts, abuse by accounts#

Castle's centre of gravity is protecting accounts that already exist and belong to real people. The attacker is an outsider: they have a credential list, or a session token, and the job is to stop them getting in.

Our centre of gravity is accounts that were created by exactly the person using them, for a purpose you did not intend. Nobody is breaking in. The account is doing precisely what an account is supposed to do, forty times, from forty registrations, and converging on one payout destination.

Those need different signals. Account takeover is caught by a change: an unfamiliar device, an impossible location, a login pattern that breaks with history. Farming has no history to break, so it is caught by relationships between accounts instead of anomalies within one.

Where each of us is weaker#

They do not have a cross-operator view, and for takeover it matters much less, because the signal is internal to the account's own past.

We do not do in-session scoring, and we do not ship challenge or step-up flows. We return a verdict and you decide what to do with it. If you want a product that both detects and handles the login interaction, that is genuinely theirs and not ours.

Running both is reasonable#

More teams than you might expect should do this, and it is not a fudge. Login protection and funnel abuse are separate loss centres with separate signals, and buying one product for both usually means one of them is being served badly.

If you have to pick one, the question is where the money actually went last quarter. If it left through compromised accounts, buy theirs. If it left through accounts that were never real in the first place, that is us.

The two shapes, side by side#

Anomaly detection and relational detection read differently in code, which is the clearest way to see why one product rarely covers both.

Takeover is a break with an account's own history, so the question is always "compared to what this account normally does":

// the comparison is INTERNAL: this account's own past
const risky =
  device.id !== account.lastKnownDevice &&
  asn !== account.usualAsn &&
  hoursSince(account.lastLogin) < impossibleTravelThreshold(distanceKm);

Farming has no history to break, because every account is new. The question is "compared to the other accounts", and no amount of per-account state answers it:

const { verdict, reasons, device } = await kaidn.score({
  event: "signup",
  user_id: user.id,
  ip,
  email: user.email,
  device_id: fingerprint,
});

// device_reuse and account_count are statements about OTHER accounts, which is
// information a single account's own record cannot contain.
if (reasons.includes("device_reuse")) {
  log(`${device.account_count} accounts on this device, ${device.account_count_same_network} on this network`);
}

That is the whole argument on this page compressed into two snippets. The first needs the account's past; the second needs everybody else's present.

Running both, concretely#

Two calls on two different events, and no conflict between them:

app.post("/login", async (req, res) => {
  const risk = await castle.risk({ event: "$login", user: req.user, context });
  if (risk.policy.action === "challenge") return challenge(res);
  return res.json(await session(req.user));
});

app.post("/payout", async (req, res) => {
  const { verdict, reason_text } = await kaidn.score({
    event: "cashout",
    user_id: req.user.id,
    ip: req.ip,
    email: req.user.email,
    device_id: req.body.kaidn_device_id,
  });
  if (verdict === "block") return res.status(403).json({ error: reason_text });
  return res.json(await payout(req.user));
});

Where we would send you elsewhere#

If you are already on Auth0 or Stytch, look at what your identity provider includes before buying anything, because a good-enough feature you do not have to integrate often beats a better one you do. And if you are being attacked at a scale where the economics of automation are the problem, Arkose is a different and sometimes better answer than detection.