Custom authentication creates hidden IAM debt and security drag

At a glance

What this is: This is an editorial argument that building authentication in-house creates avoidable identity, security, and maintenance debt.

Why it matters: It matters because IAM teams still own the risk when custom auth breaks, and those failures affect human identity, machine identity, and emerging agentic access patterns alike.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Ory's analysis of why custom authentication creates hidden IAM debt

Context

Custom authentication looks controllable at the start because teams see only the login screen, not the full identity lifecycle behind it. In practice, the work expands into credential issuance, session handling, password recovery, MFA, account linking, abuse detection, auditability, and platform resilience, all of which have to function under real attack pressure.

For IAM programmes, the hidden cost is not merely development effort. Every bespoke decision about auth becomes a governance decision about assurance, recovery, logging, and exception handling, and those decisions become harder to revisit once product teams depend on them.

The article argues that this complexity is why teams often underestimate the true cost of rolling their own authentication. That starting position is typical for product teams that optimise for speed first and governance second.

Key questions

Q: Why do custom authentication implementations create governance risk?

A: Custom implementations spread identity logic across multiple codebases, which makes review, testing, and incident response harder. They also increase the chance of inconsistent session handling, weak token management, and policy drift. In practice, the more bespoke the implementation, the less reliably security teams can enforce standards.

Q: Why do bespoke auth flows create so much hidden cost?

A: Bespoke auth flows create hidden cost because every edge case needs to be designed, tested, supported, and revisited as the product evolves. The initial login build is only a small part of the burden. The larger cost comes from maintaining security controls, exception handling, and lifecycle management over time.

Q: How should security teams evaluate a custom auth stack?

A: Security teams should evaluate it by asking whether it can be operated, audited, and recovered like a shared control. If MFA, session revocation, account recovery, and logging are all implemented differently across applications, the environment is already carrying unnecessary identity fragmentation.

Q: What is the difference between built-in IAM and custom authentication?

A: Built-in IAM standardises common identity controls such as sign-in, recovery, and session handling, while custom authentication embeds those controls inside application-specific code. The difference matters because standardised IAM is easier to govern at scale, whereas bespoke auth creates more places for policy drift and control failure.

Technical breakdown

Why custom auth accumulates identity debt

Custom authentication creates identity debt when a team builds narrowly for the first release and then keeps layering exceptions onto the same path. That usually means password reset flows, account linking, MFA recovery, device trust, session revocation, and token handling are all maintained separately. Each added exception increases the number of places where policy can drift from implementation. The result is not just technical complexity but a governance surface that becomes harder to audit, harder to harden, and harder to migrate later.

Practical implication: treat every bespoke auth exception as a lifecycle liability and inventory it before it becomes hard to unwind.

How auth sprawl affects IAM and access control

Once authentication is custom, access control is rarely the only problem. Identity proofing, session duration, privilege changes, service integration, and deprovisioning all need consistent rules, but bespoke systems often implement them unevenly. That creates drift between the intended access model and the actual runtime model. In IAM terms, the organisation ends up with fragmented enforcement that is difficult to align with zero trust, least privilege, and access review processes because the identity layer itself is not standardised.

Practical implication: map custom auth decisions to your IAM and zero trust controls before you assume the application layer is enforcing them.

Why supportability matters more than initial flexibility

A custom auth stack can look flexible because it fits the application’s immediate use case. Over time, however, supportability becomes the real control point: patching, recovery, monitoring, audit logging, scalability, and incident response all need sustained ownership. If that ownership sits inside a product team rather than an identity function, the organisation effectively turns authentication into an app-specific exception instead of a shared control. That is why many programmes discover the risk only after an outage or a security incident.

Practical implication: evaluate auth architecture by its support model, not by how quickly it shipped.

NHI Mgmt Group analysis

Custom authentication is identity debt, not just engineering work. The moment a team builds its own login and recovery paths, it inherits a long tail of governance obligations that platform IAM normally standardises. Those obligations include assurance, revocation, audit logging, recovery, and exception management, and they persist for the life of the product. The practical conclusion is simple: bespoke auth should be treated as a risk-bearing identity control, not a feature decision.

Authentication sprawl weakens the discipline of lifecycle governance. When different applications implement their own session, recovery, and access rules, identity policies stop being portable across the environment. That makes recertification, offboarding, and privilege management harder to apply consistently, especially in organisations that already struggle with fragmentation across IAM and secrets tooling. The field lesson is that lifecycle governance fails fastest where authentication logic is least standardised.

Security teams should see custom auth as a control duplication problem. Every team that rebuilds the same primitives creates a second policy surface that must be monitored, tested, and incident-tested independently. This is where governance overhead compounds: the organisation is no longer managing one access model, but many slightly different ones. The practitioner takeaway is that standardisation is a control strategy, not just an architecture preference.

Auth decisions now affect human, machine, and agentic identity programmes alike. Even when the current article is about human login flows, the same pattern repeats across service accounts, API access, and AI-driven systems when teams improvise identity logic locally. The governance implication is that identity architecture should be designed for reuse across actor types, or every new identity class will recreate the same debt. Practitioners should therefore plan for shared identity primitives rather than app-specific exceptions.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why application-level identity shortcuts persist.
• The governance lesson is reinforced in our research on secrets in AppSec, where fragmentation and remediation lag show up as structural control debt.

What this signals

Custom auth is becoming less defensible as identity stacks expand across apps, APIs, and AI-enabled workflows. The more identity logic is distributed into product code, the harder it becomes to maintain a consistent control plane for review, revocation, and incident handling. Teams that still treat auth as a local engineering choice will find that the operating model, not the framework, becomes the source of risk.

Identity teams should watch for auth logic that cannot be reused across actor types. The same design weakness that complicates human login paths often reappears later in machine access and agentic access if the organisation lacks shared primitives. That is where the programme becomes expensive: every new use case inherits the same architectural exceptions instead of a governed baseline.

For practitioners

• Inventory bespoke authentication dependencies List every custom login, recovery, token, MFA, and session path in production, then classify which ones carry audit, recovery, or revocation risk. Prioritise the flows that would be hardest to reproduce in a standard IAM service.
• Map auth decisions to lifecycle controls Check how account creation, password reset, privilege change, and offboarding are handled across each application. Flag any product path where access can persist after the intended identity state has changed.
• Reduce duplicated identity logic Move common authentication requirements into shared IAM services where possible, especially for MFA, session management, and revocation. Keep application code focused on product rules, not on recreating security primitives.
• Test supportability under failure conditions Exercise the auth stack for recovery, rollback, monitoring, and incident response, not just happy-path sign-in. If the team cannot explain who owns an outage, the architecture is too bespoke.

Key takeaways

• Custom authentication creates long-lived identity debt because it pushes assurance, recovery, and revocation into application-specific code.
• The real cost appears over time in auditability, supportability, and inconsistent enforcement across the identity lifecycle.
• Teams should standardise shared identity controls wherever possible and treat bespoke auth as a governed exception.

Key terms

• Authorization debt: Authorization debt is the accumulation of local rules, duplicated policy logic, and exception handling that builds up when access decisions are implemented ad hoc. It is an identity governance problem because the organisation eventually cannot explain, verify, or maintain its own permission model reliably.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.
• Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.

What's in the full article

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

• Specific product and platform examples that show where custom authentication becomes operationally brittle.
• The implementation trade-offs behind recovery, session handling, and MFA when teams build auth themselves.
• The article's detailed explanation of why platform support changes the maintenance burden over time.
• The supporting context around scalability, deployment, and product-team ownership of authentication.

👉 Ory's full post expands on the maintenance, scaling, and security trade-offs behind building authentication yourself.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.