Crossing a million users feels like a milestone. Internally, it usually feels like a Tuesday when three things break at once, and nobody can agree on which one caused the others.
The interesting part is not that scale creates new problems. It is that scale quietly invalidates assumptions your team made years earlier, back when those assumptions were completely reasonable and probably correct.
Here are the ones that tend to go first, and what to do about each before they become someone’s incident report.
Assumption One: Your Login Page Is a Feature
At ten thousand users, authentication is a screen. At a million, it is infrastructure with a dedicated adversary attached to it.
The shift is not gradual, which is what makes it easy to miss. Once you are large enough to be worth attacking, your login endpoint becomes a standing target for automated credential testing, and the volume involved is genuinely difficult to imagine from a smaller vantage point.
Verizon’s Data Breach Investigations Report found that stolen credentials were involved in 88% of attacks against basic web applications, and that credential stuffing accounted for a median 19% of all authentication attempts observed at single sign-on providers.
Read that second number again. At scale, roughly one in five login attempts is not a customer. That ratio has enormous implications for your rate limiting, your monitoring, your alerting thresholds and your on-call rotation.
This category of failure is well documented. OWASP lists identification and authentication failures among its top ten application security risks, covering credential stuffing exposure, weak password permission, session handling weaknesses and ineffective MFA.
The practical takeaway is simple. Auth stops being a thing you ship and becomes a thing you operate.
Assumption Two: Building It Yourself Was the Right Call
This one is uncomfortable, because the original decision was usually correct.
Early on, rolling your own authentication is fast, cheap, and fully under your control. There is no vendor, no per-user pricing, and no integration work. For a small product, that is often the sensible path.
What changes at a million users is the maintenance surface. You now need session management that survives regional outages, breached-password screening, MFA that does not destroy conversion, social login across a dozen providers, SSO for enterprise buyers, audit logs your compliance team can actually use, and account recovery flows that do not become your primary support cost.
That is not a feature anymore. It is a product, and it is not the product you set out to build.
This is where an open source CIAM approach becomes worth serious evaluation, because it addresses the two objections teams usually raise at once. Ory’s identity infrastructure is built around customer identity and access management as dedicated infrastructure rather than as a bolted-on module, with an open source foundation that answers the lock-in concern that makes engineering leaders hesitate about proprietary identity vendors.
The argument for open source here is not ideological. It is that identity is the one system you genuinely cannot migrate away from casually. Every user account, every session, every permission lives inside it. Choosing a component you can inspect, self-host and exit is risk management rather than preference.
Assumption Three: Your Password Policy Is Settled
Most teams set password rules once, during the first month, and never revisit them.
Those rules are probably now working against you. Guidance has shifted substantially, and the old orthodoxy of forced rotation and character complexity is no longer recommended practice.
NIST’s Digital Identity Guidelines moved toward favoring length over composition rules, discouraging arbitrary periodic password changes, and screening new passwords against lists of known-compromised credentials.
That last point is the high-leverage one at scale. Checking a password against a breach corpus at the moment it is set closes the credential stuffing pipeline at its source, because a password that already appears in a public dump is not going to survive contact with a million-user attack surface.
If your registration flow still demands a special character and forces a reset every ninety days, you are imposing friction on a million people while making them measurably less safe.
Assumption Four: Support Costs Scale With Users
They do not scale linearly, and this catches finance teams off guard more than engineering ones.
Password reset volume in particular tends to grow faster than headcount, because it is a function of both user count and login frequency. Add a mobile app, or a workflow that pulls users back in weekly rather than monthly, and reset tickets rise even if your user count stays flat.
This is the quiet financial argument for modernizing authentication. Every account recovery ticket has a real cost in support time, and at seven figures of users, small percentage changes translate into meaningful budget. A one percent reduction in reset rate is a rounding error at ten thousand users and a headcount decision at a million.
Passwordless approaches are the current direction of travel here. The FIDO Alliance’s work on passkeys replaces shared secrets with cryptographic key pairs bound to a device, which removes both the reset burden and the credential stuffing exposure at once, since there is no reusable password to steal in the first place.
You do not have to go passwordless immediately, and most teams should not attempt it as a big-bang migration. But if your roadmap for the next two years does not mention it at all, that is worth a conversation with your platform team.
What Actually Breaks First
If you are approaching this threshold, here is a rough order of operations based on what tends to fail earliest in practice.
Rate limiting goes first. Defaults tuned for a small user base become either useless against real attack volume or actively hostile to legitimate customers, and teams often discover which one only when a support queue fills up.
Session management goes second, usually when you add a second region and discover your sessions were quietly single-region all along. This one is particularly awkward because it tends to surface during an expansion launch rather than during a quiet week.
Account recovery goes third, and it goes loudly, because it fails in front of customers who are already frustrated and already trying to get back into something they paid for.
Compliance arrives last but with the least warning, typically in the form of an enterprise prospect sending a security questionnaire that assumes capabilities you have not built. That is a revenue problem wearing a security costume, and it is usually the moment identity gets budget.
Also Read
The Reframe Worth Making Early
The most useful shift is to stop treating identity as a feature you completed and start treating it as a system you run.
Features get built once and maintained occasionally. Systems get monitored, budgeted, staffed and reviewed. Identity belongs firmly in the second category well before you reach a million users, and the teams that make that transition early spend considerably less time firefighting it later.
The million-user mark does not cause these problems. It simply removes your ability to keep ignoring them.
Which makes the period just before you get there the best possible time to act.
