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 who the buyer is, we agree.

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

Abuse of accounts, abuse by accounts#

Castle protects accounts that already exist and belong to real people. The attacker is an outsider with a stolen password list or a session token, and the job is to keep them out.

We deal with accounts 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, all converging on one payout destination.

Those need different signals:

• Takeover is caught by a change. An unfamiliar device, an impossible location, a login that breaks with everything the account did before.
• Farming has no history to break. Every account is new, so it is caught by relationships between accounts instead of anomalies inside one.

Where each of us is weaker#

They do not have a cross-operator view. For takeover that matters much less, because the signal lives in the account's own past.

We do not score during a session, 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 spots the risky login and handles the interaction, that is genuinely theirs and not ours.

Running both is reasonable#

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

If you have to pick one, ask where the money actually went last quarter. Out through compromised accounts, buy theirs. Out through accounts that were never real, that is us.

The two shapes, side by side#

The clearest way to see why one product rarely covers both is to read them in code.

Takeover is a break with an account's own history, so the comparison is always against 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 what this account shares with all the others, and no amount of per-account state answers that:

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 this whole 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. A good-enough feature you do not have to integrate usually beats a better one you do.

And if you are being attacked at a scale where the economics of automation are the real problem, Arkose is a different and sometimes better answer than detection.