Build or buy authentication: a decision guide for engineering managers

For most product teams, using an established identity service or well maintained library beats building authentication from scratch. Build it yourself only when identity is your core product or your requirements truly cannot be met otherwise. The cost of building is not the first release. It is owning it for years as attacks and standards change.

What "authentication" includes

Login looks small until you list it. Password storage, reset flows, multi-factor enrollment and recovery, session handling, device trust, rate limiting, account lockout, social and enterprise single sign on, audit logs, and abuse monitoring. Each piece has well known failure modes, and attackers test them constantly.

Questions for the decision

1. Is identity our product? If you sell identity, build. If you sell something else, your engineers' time is better spent there.
2. Who will own it in two years? Code without a named maintainer ages badly. Ask who handles the next change in recommended practice.
3. What do enterprise customers need? Single sign on, provisioning and audit logs are common asks. Building each is substantial.
4. How much security expertise do we have? Subtle bugs in session or reset flows are common even among experienced engineers.
5. What is the exit path? If you buy, can you export users and credentials in a usable form, and how hard is migration?

Three approaches compared

Build everything. Maximum control and no external dependency. Highest ongoing cost, highest chance of subtle mistakes, and you must keep up with changing guidance yourself.

Use a maintained library inside your app. You keep data and flow in your own stack and reuse well reviewed code for the tricky parts. You still own the integration, configuration and upgrades.

Use a hosted identity service. Least build effort and usually the fastest route to features like single sign on. You depend on a third party for availability and data handling, and you need to understand its failure modes and contract terms.

None is universally right. The middle option fits many teams that want control without writing crypto-sensitive code.

Whatever you choose, check these

• Passwords stored with an approved slow hashing method, never reversible encryption.
• Multi-factor authentication available and, for staff, required.
• Rate limiting and lockout on login and reset.
• Session tokens that expire, rotate, and can be revoked.
• Logs for sign in, failures and changes to credentials.
• A tested recovery path that does not become the weakest link.

Plan for the dependency

Any library or service becomes part of your supply chain. Track it in your inventory, watch for advisories, and budget regular upgrades. Safeguard's dependency scanning and SBOM features can show which packages in your stack handle authentication and flag known issues in them, and the free scan is a quick way to start.

Decide and record

Write a short decision record: the options considered, why you chose one, what would make you revisit. See ADR template with a security section.

Quick check

Last reviewed: 19 October 2026.