Signals of risk: device, network, behavior (privacy-aware)

Static authentication treats every request the same: the password and the one-time code are checked, and the session is granted. Risk-based authentication adds a question in between — how unusual is this request for this account? — and uses the answer to decide whether the normal factors are enough. Done well, it lets the common case stay fast while the unusual case pays for extra assurance. Done badly, it becomes a pile of opaque scores, a privacy liability and a source of lockouts nobody can explain.

This series follows Tidewater Mutual, a fictional credit union with a mobile app and a web banking portal. Its identity engineer, Marisol Ekwueme, has been asked to stop treating a balance check and a new payee the same way. Her first task is an inventory: which signals does Tidewater already receive, which are worth keeping, and which should never be stored at all?

Three families of signal

Risk signals fall into three families. Device signals describe the thing making the request: a previously enrolled device key, an app installation identifier, a platform attestation result, a browser cookie that survived from a previous login. Network signals describe where the request came from: the IP address and its autonomous system, whether that system is a hosting provider, a coarse geolocation, and whether the address recently produced failures for other accounts. Behaviour signals describe what the session is doing: time of day relative to the account’s history, the sequence of pages, how fast forms are filled, whether the action is one the account has performed before.

The families differ in how hard they are to fake. A device-bound key stored in secure hardware is the strongest: an attacker cannot copy it, only steal the device. A long-lived cookie is weaker because malware and session theft can lift it. Network signals are cheap to manipulate — residential proxies rent IP addresses in any city — but they are still useful in the negative: a request from a hosting provider to a retail banking login is unusual for real members. Behaviour signals are the noisiest and the most privacy-sensitive, and they should carry the least weight on their own.

Facts, not raw data

Marisol’s key design choice is that policy consumes facts, not raw signals. Instead of passing an IP address to the decision engine, the edge service resolves it into a handful of booleans and categories: network.hosting = true, network.country_changed = false, network.recent_failures = high. Instead of passing a browser fingerprint, the device service answers device.known = true and device.first_seen_days = 212. The decision engine, its logs and its analysts see only these conclusions.

This shrinks the privacy footprint dramatically. Raw IP addresses and fingerprints are personal data in most jurisdictions; storing them for every login creates a retention problem and a breach liability. Facts can be computed at the edge with short-lived raw data and then discarded. It also makes decisions explainable: a reason log that says step_up: device.unknown + action.new_payee can be read by a support agent, while a score of 0.73 cannot.

// Edge: raw signal in, named facts out. Raw IP is not persisted.
type Facts = {
  device: { known: boolean; firstSeenDays: number | null; attested: boolean };
  network: { hosting: boolean; countryChanged: boolean; recentFailures: "none" | "some" | "high" };
  behaviour: { actionSeenBefore: boolean; hourUnusual: boolean };
};

Every signal decays

Signals lose meaning over time. A device first seen two years ago and last seen yesterday is strong; one last seen eighteen months ago may have been sold, wiped or lent to a teenager. Tidewater stores, per enrolled device, only a key identifier, a first-seen date and a last-seen date, and treats a device unseen for more than 180 days as unknown again. Behaviour baselines are recomputed over a rolling window rather than accumulated forever. Network reputation is cached for hours, not months.

Decay is also a privacy property. Data minimisation regulations ask that you keep personal data no longer than necessary; a signal that is ignored after 180 days has no reason to be retained after 180 days. Writing the decay period next to each signal in the inventory makes the retention schedule fall out of the design rather than being bolted on by a compliance review.

Weighing the families

The table suggests the weighting. Device facts that rely on non-exportable keys should dominate. Network facts are best used to raise suspicion, not to grant trust: a hosting ASN is a reason to step up, but a residential ASN is not a reason to relax. Behaviour facts break ties and, crucially, describe the action — a first-ever new payee is risky regardless of where the request came from.

Notice what is absent: demographic data, contact lists, location history, the content of messages. None of these improve the owner-versus-attacker question enough to justify collecting them, and all of them create harm if leaked. Marisol’s inventory explicitly lists them under “do not collect” so that a future feature request has to argue against a written decision.

Signals are evidence, not verdicts

Finally, no single fact should deny access on its own unless it is overwhelming — a device key known to be revoked, for example. Members travel, change phones, use VPNs for legitimate reasons and log in at 3am when a baby will not sleep. The output of a signal layer is evidence that informs a proportionate response. The next chapter turns that evidence, combined with the sensitivity of the action, into an actual policy.