Somewhere in your codebase there's a check that runs when something important is about to happen. Maybe a transaction above a threshold, a withdrawal from an unrecognised device, a request for a feature that's supposed to be gated. The check looks at the user record, reviews account history, confirms verification status, and comes back with... probably fine.

"Probably fine" is carrying a lot of weight.

The question login was built to answer

Login answers one question: does this person have valid credentials for this account?

That's useful. But it's usually not what you actually needed to know.

Most access decisions are really asking something closer to: does this person qualify for what they're about to do? Have they already claimed this reward under a different account? Is there something about this request that doesn't fit real user behaviour?

Those are eligibility questions. Login is an identity question. They overlap but they're not the same — and building your access logic on identity when you need eligibility produces exactly the kind of check that returns "probably fine" when you need a clear yes or no.

What role-based access actually models

RBAC is the standard answer to this gap. Assign roles to users, roles determine permissions, permissions determine access. It works well for internal systems with stable structure and clear organisational lines.

It breaks down when roles are just proxies for facts that could be stated directly.

"Premium subscriber" is a role. "Has an active paid subscription" is a fact. In most systems they're treated as the same thing, but they're not. The role is a label. The fact is a condition that was true at a point in time — and when you need to know if it's still true, you have to check the underlying data the role was supposed to represent.

If you've maintained one of these systems long enough, you know what follows. Roles accumulate. Every edge case gets resolved by adding another one. At some point someone asks "does this role still actually gate anything?" and nobody is sure. The permissions model became hard to audit not because access control is complicated, but because the abstraction didn't match what the system was actually trying to enforce.

The account is a container, not an answer

The usual response to "is this user legitimate?" is to check the account. Email verified. 2FA on. Account six months old. Activity history looks normal.

This establishes that the account has the properties legitimate accounts tend to have. It doesn't establish there's a real human behind it.

For most applications most of the time, that's fine. Fake accounts are cheap to make but usually not worth the effort unless there's something worth gaming. The moment your system has that something — a reward, a financial product, an airdrop, subsidised access — the inference breaks. Those account properties can be manufactured. The account is a container. It holds whatever was put into it. It doesn't say who did the putting.

The eligibility question

The design shift isn't complicated to describe, even if it takes work to implement.

An identity system needs to know who a user is, so it stores and verifies identity data and makes access decisions from it. An eligibility system needs to know if a user qualifies, so it asks a specific yes/no question — is this a unique human, has this person already received this grant, does this account meet the age requirement — and stores the answer, not the evidence.

Less data, simpler logic, and the access check answers the actual question instead of inferring it from whatever signals are available.

Most systems don't work this way for the same reason the data collection problem exists: the infrastructure to ask eligibility questions without holding identity data wasn't practical at the application layer until recently. Most teams inherited a design that made sense when it was built and never had a reason to revisit it.

What "probably fine" is actually saying

When a check returns "the account looks legitimate," it usually means the system can't answer the question it's being asked. It's doing the best it can with what it has.

What it has is an account record, not a claim about the person behind it. That gap is architectural. You can patch around it — better heuristics, tighter rate limiting, more behavioural signals — but the patches don't close the gap. They make it harder to fall into by accident.

Most teams won't rethink the access model until something forces it: a fraud event, a drained reward pool, a compliance question nobody can answer cleanly. The engineers maintaining these systems usually already know where the gap is. The "probably fine" return is a smell they've learned to recognise and route around.

There's a different design. One where the access check answers the actual question — does this person qualify — rather than inferring it. Where the logic stays simple because the abstraction matches what the system is actually trying to do.

Login got authentication right. The question was always the problem.