What Does One Login Actually Cost You?

Ask an engineering team what a login costs and you'll usually get a pause, then a question back: cost in what sense?

That pause is the interesting part. Most teams can tell you their cloud bill, their cost per customer, and their gross margin. Almost none can tell you the marginal cost of authenticating one user one time — despite authentication being one of the highest-volume operations in the entire system and the one most directly coupled to growth.

It's worth working out, because the number reframes several architectural arguments that otherwise get decided on instinct.

Why the number is hard to see

Identity costs are structurally invisible for three reasons.

They're spread across budgets. CPU for password hashing is in your compute bill. Session storage is in your cache bill. Audit is in your logging bill. Token signing might be in a KMS line item. No single dashboard shows "authentication."

They're amortized. You don't pay per login; you pay for provisioned capacity that logins consume. The marginal cost of one more login is genuinely near zero until it isn't — until you cross a threshold and add another node.

And the expensive parts are the ones that don't look expensive. Everyone assumes the database is the cost. It usually isn't.

Building the number

Let's take a concrete scenario and work through the line items: 50 logins per second at peak, roughly 100 million authentications per month. A mid-sized B2B platform.

I'm going to use round order-of-magnitude figures rather than current vendor pricing, because the point is the ratio between line items, and that ratio is stable even as prices move.

CPU: password hashing

This is the big one, and it surprises people.

Argon2id or bcrypt at a sensible work factor costs roughly 100ms of CPU per verification — deliberately, since that's the entire security mechanism. Fifty logins per second is therefore about 5 CPU-seconds of work per wall-clock second: five cores, continuously, doing nothing but hashing.

Add headroom for peaks and you're provisioning perhaps 8–10 cores purely for password verification. At commodity cloud pricing that's a few hundred dollars a month.

Two things follow. First, login capacity planning is CPU capacity planning — this doesn't parallelize away or cache, because caching a password verification would defeat its purpose. Second, this line item goes to zero for passkey authentications, since signature verification is microseconds rather than 100 milliseconds. That's a real and rarely-cited economic argument for passwordless.

Memory: session storage

A session record is small — call it 1–2 KB with claims, device info, and metadata. The number that matters is concurrent sessions, not logins, and that's driven by session lifetime.

100,000 concurrent sessions at 2 KB is 200 MB. Trivial. But session count scales with lifetime, and lifetime decisions are usually made for UX reasons by people not thinking about memory. Extend sessions from 1 hour to 8 hours and you hold roughly eight times as many concurrently. Add mobile clients — which hold long-lived sessions and multiply per user — and this line grows faster than your user count.

Still usually small in absolute terms. Worth knowing because it's the line item most sensitive to a product decision.

Token signing

RSA-2048 signing is on the order of a millisecond of CPU. ECDSA is faster. Either way, at 50/sec this is negligible — unless you're calling a cloud KMS per signature, in which case you've turned a sub-millisecond local operation into a network round trip with per-call pricing.

At 100 million signatures a month, per-call KMS pricing becomes a real line item, and the latency is worse than the cost. This is why teams using KMS-backed signing almost always end up caching a key handle or using envelope signing. It's a decision with a 100× cost difference between two implementations that look equivalent on a whiteboard.

Audit and logging

Here's where it typically dominates, and it's the line item covered in more depth elsewhere in this series.

The short version: if each login generates 15–20 audit events at ~1 KB each, 100 million logins produce something like 1.5–2 TB of event data per month. Storage for that is cheap. Indexing it in a log analytics platform, at typical per-GB ingestion pricing, is frequently the single largest identity-related line item — often several times the compute cost of the hashing that everyone assumes is the expensive part.

The events-per-login ratio is the number with the largest multiplier effect on your identity bill, and almost nobody knows theirs.

Egress

Usually forgotten entirely. If you stream audit events to a customer's SIEM in another cloud, you pay egress on every byte. At terabyte-per-month volumes, egress alone can exceed your entire compute spend for authentication.

The rough shape

Divide by 100 million and the per-login figure lands somewhere in the small fractions of a cent for most deployments. Which sounds like a reason to stop reading — except the fractions aren't what matters.

What the number is actually for

The absolute cost per login is rarely large enough to change behavior. The distribution across line items changes several decisions.

It relocates optimization effort. Teams instinctively optimize the database. The arithmetic says the database is rarely the problem — audit ingestion and CPU are. An afternoon spent auditing your events-per-login ratio usually returns more than a week of query tuning.

It gives passwordless a cost argument. "Passkeys are more secure" is a security argument that competes with other security priorities. "Passkeys eliminate the largest CPU line item in authentication" is a different kind of argument, and it reaches a different audience.

It exposes the audit-retention decision. When someone asks for seven-year retention with full indexing, the honest response is a number. Retention policy is usually set by people who have never seen its cost, because nobody computed it.

It makes the enterprise-customer conversation concrete. Enterprise customers cost more per user than self-service ones — dedicated federation config, SCIM sync, audit export, longer retention, more concurrent sessions per user. Knowing how much more is the difference between pricing tiers based on intuition and pricing them on evidence.

The costs that aren't infrastructure

Worth naming, because they usually exceed the infrastructure line entirely.

Engineering time is the real expense. A team of three maintaining identity infrastructure costs more annually than any plausible cloud bill for authenticating 100 million times a month. Any architecture argument that saves infrastructure dollars while adding operational complexity is probably losing money.

Support cost per authentication failure. If 0.1% of logins produce a support contact, that's 100,000 contacts a month at your fully-loaded cost per ticket. This is almost always larger than the compute cost of the logins themselves, and it's the strongest available argument for spending engineering effort on reliability rather than on efficiency.

Downtime. If authentication is unavailable, your entire product is unavailable. The cost of one hour of downtime typically exceeds a year of the infrastructure savings anyone is proposing.

That ordering — downtime, then support, then engineering time, then infrastructure — is the ranking that should drive decisions. Infrastructure cost is the one everyone can measure and the one that matters least.

How to work out yours

Four numbers, none of which require new tooling:

1. Events per login. Count what you emit for a single authentication. If it's over ten, ask what an investigator would actually want. This is your highest-leverage number.
2. CPU-seconds per authentication. Your hashing work factor tells you this directly. Multiply by peak rate to get provisioned cores.
3. Bytes per login, end to end. Audit events, session record, token size. Multiply by volume and by every place it's replicated — the same event often exists in five systems.
4. Support contacts per thousand logins. Almost certainly larger in dollar terms than anything above it.

Then ask the question the exercise exists to prompt: does the distribution match where we're spending engineering effort?

For most teams it doesn't, and that mismatch — not the total — is the finding worth having.