The real cost of building authentication in-house

At a glance

What this is: This is an analysis of why authentication is harder than teams expect and where in-house builds most often break down.

Why it matters: It matters because authentication decisions shape both human IAM resilience and the trust boundaries that upstream NHI and platform controls ultimately depend on.

By the numbers:

• A 2024 Microsoft study found that over 40% of users who experienced account takeovers had MFA enabled at the time.
• A 2024 Microsoft study found that over 40% of users who experienced account takeovers had MFA enabled at the time.

👉 Read Authsignal's analysis of the real cost of building authentication in-house

Context

Authentication is the control plane for proving identity, but the real failure mode is often not the login itself. It is the recovery path, session lifetime, fallback factor, and audit gap that sit around it and quietly shape whether access can still be trusted after the first successful sign-in.

For IAM teams, the problem is broader than consumer login UX. Weak authentication design can undermine zero trust assumptions, make incident reconstruction difficult, and leave human and machine-facing identity programmes depending on a control that only appears complete on the surface.

Key questions

Q: How should security teams handle weak authentication fallback paths?

A: Treat fallback paths as the real control boundary, because attackers often target the weakest recovery option rather than the strongest login factor. Review SMS resets, security questions, and support-assisted recovery first, then remove or harden any path that lowers assurance below your stated authentication standard.

Q: Why do long-lived sessions create security risk even after a successful login?

A: Because authentication assurance persists for as long as the session or token remains valid. If logout is weak, refresh tokens live too long, or revocation does not propagate cleanly, an attacker can keep using access after the original event that should have ended it.

Q: What do teams get wrong about adaptive authentication?

A: They often focus on user convenience and ignore whether the decisioning is auditable. Adaptive auth only works as a control when the organisation can explain why a challenge was issued or skipped, and can reconstruct those decisions during incident review or compliance testing.

Q: Who is accountable when recovery flows are weaker than the primary login?

A: IAM and security leaders are accountable, because the recovery path is part of the authentication control set they approve and operate. If a weaker path can bypass a stronger factor, the organisation has accepted a lower assurance level than its front door appears to promise.

Technical breakdown

Why authentication fallbacks become the weakest trust path

A fallback path is only secure if it is at least as strong as the primary factor, which is rarely true in practice. SMS resets, security questions, and support-assisted recovery often reintroduce weaker identity proofing into an otherwise stronger flow. That mismatch creates a trust inversion, where the channel meant to restore access becomes the easiest route to bypass it. In identity architecture terms, the recovery surface is part of authentication, not a side concern. Once an attacker reaches the weak path, the strength of passkeys or phishing-resistant factors on the front door matters far less.

Practical implication: inventory every recovery and fallback path and treat the weakest one as the real control boundary.

Session management and token lifetime in authentication security

Authentication does not end at login. Session duration, refresh token lifetime, logout invalidation, and device recognition determine how long the authenticated state remains usable. If tokens survive too long or are not revoked cleanly, compromise lasts longer than the event that created it. This is where in-house builds often drift because the visible feature is finished before the revocation logic, telemetry, and edge cases are fully hardened. For practitioners, session security is a governance problem as much as a code problem, because it defines how quickly access assumptions can be withdrawn after risk changes.

Practical implication: set explicit token and session expiry rules, then test revocation paths under compromise and logout conditions.

Risk-based authentication and audit logging are control requirements

Risk-based authentication uses signals such as device familiarity, location, and behaviour to decide when to step up verification. That approach reduces friction without assuming every login is equal. But it only works if the decisioning is explainable and the audit trail is complete. Logging is what lets security teams reconstruct disputes, detect abuse patterns, and prove that authentication controls operated as intended. Without it, even a well-designed adaptive flow becomes hard to govern, because the organisation cannot show what happened or why a challenge was, or was not, issued.

Practical implication: require auditable decision logs for every step-up, recovery, and challenge event before treating adaptive auth as production-ready.

NHI Mgmt Group analysis

Authentication design debt is a governance problem, not just an engineering one. When teams defer recovery logic, session invalidation, and logging, they create invisible control gaps that only appear after compromise or audit pressure. The result is not simply a weaker login page, but a trust boundary the organisation cannot defend with evidence. IAM leaders should treat authentication as a governed control surface, not a feature backlog item.

Fallback paths are where auth programmes most often lose assurance. A strong primary factor cannot compensate for a weaker support channel that reopens access through SMS, security questions, or manual help-desk resets. That means the effective security level of the entire authentication stack is set by the least controlled recovery route. Practitioners need to judge auth by its weakest path, not its strongest method.

Session lifetime is the hidden privilege window in human IAM. Long-lived tokens and poorly revoked sessions turn a one-time login into persistent access, which is exactly the kind of residual trust zero trust tries to eliminate. The practical consequence is that authentication and access governance cannot be separated in programme design. Identity teams should evaluate how quickly trust can be withdrawn, not only how it is granted.

Auditability is part of authentication assurance, not an optional extra. If an organisation cannot explain why a challenge occurred, why a recovery path succeeded, or when a session was invalidated, it has no durable evidence of control effectiveness. That weakens incident response, dispute handling, and compliance attestation at the same time. Teams should treat authentication telemetry as governance evidence, not just operational noise.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how remediation delays preserve attacker opportunity.
• From our research: 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs, which makes trust withdrawal and least-privilege enforcement the decisive control problem.

What this signals

Authentication governance now has to be judged by the weak path, not the happy path. The practical test is whether recovery, session expiry, and telemetry remain trustworthy when the primary factor is unavailable. For identity programmes, that means authentication assurance should be reviewed alongside NIST SP 800-63 Digital Identity Guidelines and the organisation's own incident evidence, not as a UI feature checklist.

Session control is becoming the hidden policy layer of IAM. As login methods improve, attackers and careless implementations shift pressure onto recovery, token reuse, and logout gaps. The organisations that get ahead will be the ones that can prove their access can be withdrawn as quickly as it is granted, using telemetry that supports both human IAM and non-human identity governance.

Authentication design debt accumulates into identity blast radius. When fallback routes and audit gaps are left unresolved, they create a broader trust problem that affects upstream access governance, downstream incident response, and third-party integration risk. Teams should align authentication review with controls in NIST SP 800-53 Rev 5 Security and Privacy Controls and the Ultimate Guide to NHIs , The NHI Market.

For practitioners

• Map every fallback and recovery path Document each route that can restore access, including SMS resets, security questions, and support-assisted recovery. Compare the control strength of those paths with the primary factor and remove any route that meaningfully lowers the assurance level of the overall flow.
• Shorten and test session invalidation Define maximum session and refresh token lifetimes, then validate logout, password reset, and compromise-triggered revocation in real environments. The goal is to prove that access can be withdrawn quickly enough to matter when a compromise is detected.
• Make logging mandatory for every challenge event Record step-up decisions, recovery approvals, session termination, and failed authentications in a form that security teams can query. Without this evidence, authentication controls cannot be audited, investigated, or improved with confidence.

Key takeaways

• Authentication failures usually emerge in recovery, session, and logging controls, not the login screen itself.
• The Microsoft data shows that MFA alone does not eliminate takeover risk when the surrounding control design is weak.
• Practitioners should treat fallback assurance, token revocation, and audit evidence as core identity governance requirements.

Key terms

• Authentication Fallback Path: A fallback path is any alternative route that restores account access when the primary authenticator is unavailable. In practice, it is often the weakest part of the authentication design, because support processes, SMS resets, and security questions can lower assurance below the primary login method.
• Session Invalidation: Session invalidation is the act of ending an authenticated session so the token or cookie can no longer be used. It is a core assurance control, because long-lived sessions can preserve access long after the risk that justified it has changed or the account has been compromised.
• Risk-Based Authentication: Risk-based authentication adjusts verification requirements based on contextual signals such as device familiarity, location, and behaviour. Done well, it reduces unnecessary friction while preserving assurance. Done poorly, it becomes opaque decisioning with no audit trail, which weakens governance.
• Authentication Telemetry: Authentication telemetry is the log data produced by sign-in, challenge, recovery, and session events. It gives security teams evidence of how the control behaved, supports incident reconstruction, and makes authentication reviewable rather than just functional.

What's in the full article

Authsignal's full blog covers the operational detail this post intentionally leaves for the source:

• Pre-built authentication flow patterns for passkeys, TOTP, magic links, and fallback handling.
• Risk-based challenge logic and the signals used to decide when to step up verification.
• Audit logging and session management design details for production authentication programmes.
• Implementation considerations for teams replacing or augmenting in-house authentication code.

👉 The full Authsignal post covers fallback paths, session controls, and the maintenance burden of auth ownership.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.