Home-built login costs your engineering team a recurring number of hours every quarter, and you can calculate it yourself: add up the hours spent on security updates, sales requests, support tickets and incidents, then multiply by the loaded cost of the engineers who did the work. We cannot give you a trustworthy industry average, because the figure depends heavily on how many enterprise customers you have and how old your login code is. What we can give you is a worksheet, which is below, so the number you bring to your next planning meeting comes from your own tracker and payroll data.
This post is written for CTOs and founders of B2B SaaS companies with roughly 15 to 150 people, where login was built in-house or is only lightly managed. The cost of building authentication is usually discussed as a one-time project, but the part that grows is the maintenance, so that is where the worksheet focuses.
Why does login work not end at launch?
Login work continues after launch because the standards it must meet, the libraries it depends on and the customers who use it all keep changing. Your first version probably took a few weeks, but nobody scheduled the dependency upgrades, the new customer requests or the late-night lockout someone had to fix. The cost of that ongoing work is what this post measures.
Two public documents show why the target keeps moving. The NIST Digital Identity Guidelines, SP 800-63B, define authenticator requirements, and the fourth revision, published in 2025, replaced Revision 3 from 2017, so anyone who maps their login to NIST should review their controls against it. The OWASP Application Security Verification Standard (ASVS) lists individual checks for authentication and session management, and version 5.0, released in May 2025, restructured those chapters, which means a security-minded customer can ask you to meet a newer edition than the one you built against.
Dependencies add a second source of work. The OWASP Top 10 has listed outdated dependencies as a risk category since 2013, and the 2025 edition widened it into Software Supply Chain Failures. Your login path usually pulls in a password hashing library, a token library, an email provider SDK and a web framework. Each of those publishes fixes on its own schedule, and somebody on your team has to read them.
What recurring work does in-house login create?
In-house login usually creates four kinds of recurring work, and each one maps to a line on the worksheet. Looking at them separately matters because they reach different people: security updates land on your senior engineers, sales requests land on whoever knows the code, support tickets land on your support team and then escalate to engineering, and incidents land on whoever is on call.
Security updates and dependency upgrades
This category covers reading advisories, upgrading libraries, re-testing the login flow and shipping the change. A framework major version upgrade often touches session handling, so it deserves a line of its own. If you also review password storage and rate limiting against the OWASP Authentication Cheat Sheet once or twice a year, count those hours here too.
Sales requests for SSO, MFA and audit evidence
Enterprise buyers regularly ask for single sign-on (SSO, where their employees sign in through their own company identity system), multi-factor authentication (MFA, a second proof of identity beyond a password) and logs showing who signed in. Each request is usually a mini-project: a deal depends on it, so an engineer is pulled off the roadmap to build or configure it. Our post on what to check when you compare building and buying identity covers the technical side of those requests in more detail, and our post on how long it takes to become enterprise-ready on login covers the timeline.
Questionnaires matter here too. A single security questionnaire can take an engineer several hours to answer accurately, and if you handle a few per quarter, that is a real line item.
Support tickets for lockouts, resets and customer admins
Users forget passwords, lose their phones and get locked out by rate limiting, and a customer administrator will ask you to remove a departed employee or change someone’s role. If your product has no self-service screens for these cases, support asks engineering to run a script or edit a database row. Count the support time and the engineering time separately, because the second one is the more expensive and the easier to forget.
On-call and incident time
When login fails, customers cannot reach any other part of your product, so a login outage usually counts as a full outage. Include the time spent during incidents, the follow-up review afterward, and any on-call compensation or time off in lieu that your team receives because login pages them. If login has never paged anyone, write down zero, since that is a useful finding too.
How do you calculate your quarterly authentication cost?
The calculation is hours per quarter multiplied by the loaded hourly cost of the people who did the work, summed across the four categories above and then increased for interruption costs you measure yourself. Pull the hours from your issue tracker and support desk where you can, and estimate from team interviews where you cannot, marking each number as measured or estimated.
Step 1: Work out a loaded hourly cost
Loaded cost is what an engineer costs the company in total, which is more than salary. Ask finance for the annual figure that includes salary, employer payroll taxes, benefits, equipment, software seats and a share of office or remote-work costs. Divide by the hours your company actually expects them to work in a year, after holidays and leave, to get an hourly figure.
Step 2: Fill in the table
Copy this table into a spreadsheet and replace each blank with your own numbers.
| Category | Engineer hours per quarter | Loaded hourly cost | Quarterly cost |
|---|---|---|---|
| Security updates and dependency upgrades | ___ | ___ | hours x cost |
| Sales requests (SSO, MFA, audit evidence, questionnaires) | ___ | ___ | hours x cost |
| Support escalations (lockouts, resets, customer admins) | ___ | ___ | hours x cost |
| On-call, incidents and reviews | ___ | ___ | hours x cost |
| Subtotal | sum of the four rows |
To show the arithmetic only, suppose an engineer’s loaded cost were 100 per hour and the four rows added up to 150 engineer hours in a quarter. The subtotal would be 15,000 for the quarter, or 60,000 over a year. These are placeholder numbers and not a benchmark, so use your own.
Step 3: Add what teams usually forget
Several costs rarely appear in a tracker, and leaving them out understates the total.
- Interruptions to roadmap work. A forty-minute login question can cost more than forty minutes if the engineer needs time to get back into their previous task. Ask two or three engineers how long recovery takes them and record the answer as your own estimate, instead of borrowing someone else’s multiplier.
- Deals delayed or lost. If a prospect stalled because you could not offer SSO or an audit log, note the deal value and how long it waited. Treat this as a separate figure from engineering cost, since it is revenue and not hours.
- Knowledge concentration. If only one engineer understands the login code, include the hours that person spends answering questions, and note the risk if they leave.
- Compliance and review time. Time spent explaining login controls to auditors or customers counts, even when it falls outside engineering.
Leave these as a second block beneath the subtotal, so anyone reading the worksheet can see which figures are measured and which are estimated.
What changes if you buy instead of build?
Buying moves the standards tracking, the patching and the running of the login service to a vendor, while you keep the decisions about who has access to what in your own product. It does not remove your integration work, and it does not remove the need to own your access policy. The honest comparison is between the worksheet total and the price of the vendor plus the hours you will still spend.
Usually the work moves like this.
| Moves to the vendor | Stays with you |
|---|---|
| Patching and upgrading the identity software | Integrating your application with the vendor’s login |
| Building and maintaining the SSO and MFA features themselves | Deciding roles, permissions and what each customer may do |
| Running and monitoring the login service | Answering customers about your own access policy |
| Producing sign-in logs and standards support | Support for end users that your product owns |
| Operating the identity service day to day | Setting up each enterprise customer’s SSO connection |
Our post on how to pick an identity vendor when you have no identity team walks through the evaluation questions, and the self-hosted versus managed authentication cost comparison covers the case where you would run the software yourself.
How do vendors charge?
Vendors price in a few ways, and the model affects how the cost grows with your business. Per-user pricing charges for each registered account, per-MAU pricing charges for each monthly active user, and cluster-based pricing charges for the infrastructure that runs your identity service, so the bill follows capacity and not headcount. Which one suits you depends on how your user count behaves: per-user pricing counts every registered account, including people who signed in once, while per-MAU pricing counts only the accounts active that month, so a product with many occasional users pays for very different numbers under each. Check each vendor’s current pricing page and model your own user counts for the next two years. Skycloak runs managed Keycloak on cluster-based plans with unlimited users, and the plans are on the pricing page.
Switching later has a cost too, which the post on what it costs to switch identity providers estimates, so include a realistic exit plan in the comparison.
What should you decide this quarter?
Pick one of three outcomes after you have the worksheet total: keep building, buy, or keep building with a written trigger for revisiting. Each is reasonable depending on your numbers, and the point of the exercise is that the decision is made with a figure and not by default.
- Keep building if the subtotal is small, no enterprise customers are asking for SSO, and the engineers who maintain login are willing to continue. Re-run the worksheet next quarter so the number stays current.
- Buy if the subtotal is already a meaningful fraction of an engineer’s time, if deals are waiting on SSO or audit logs, or if login knowledge sits with one person.
- Revisit at a trigger if the cost is modest today but something specific will change it. A typical trigger is the next enterprise deal that requires SSO, or the first customer who asks for automatic user provisioning (SCIM, which creates and removes accounts from their directory). Write the trigger down, with a named owner and a date to check it.
If the discussion needs a leadership audience, the guide for engineering leaders frames the same trade-off for people who will not read the technical detail.
Frequently asked questions
What is the cost of building authentication?
It has two parts: the initial build, which is a project with a start and end date, and the recurring maintenance, which has neither. Maintenance includes security updates, customer-driven features such as SSO and MFA, support escalations and incident time. Most teams underestimate the second part, so measure it with the worksheet.
How do I estimate in-house authentication cost without industry benchmarks?
Use your own records. Count the engineering hours in your tracker labelled with login or auth work for the last two quarters, add the support escalations, and multiply by loaded hourly cost. Where records are missing, interview the engineers involved and mark those rows as estimates until you can measure them.
Does buying authentication remove all maintenance?
No. The vendor takes on running the service, patching it and building standard features, but your team still integrates it, defines roles and permissions, and answers customers about your access policy. Compare the vendor price plus your remaining hours against the worksheet total, not against zero.
When should a small SaaS company move off in-house login?
There is no single threshold, but common signals are an enterprise deal that depends on SSO, growing quarterly hours on login work, or knowledge held by one engineer. Pick a trigger in advance and review it at a fixed date, so the move is planned rather than urgent.
Conclusion
Run the worksheet this quarter with your own data, decide whether to keep, buy or revisit at a trigger, and write down the date you will check again. If you want to compare against a vendor, the posts linked above cover the evaluation questions and the cost of leaving later.