Homegrown IAM creates identity debt in modern application stacks

At a glance

What this is: This is an analysis of why custom IAM implementations create identity debt as organisations move to API-first, machine-aware identity architectures.

Why it matters: It matters because IAM teams now need identity that is not only functional for authentication but also governable, reusable, and safe for downstream security, analytics, and compliance use.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Ory's analysis of why homegrown IAM becomes identity debt

Context

Homegrown IAM becomes identity debt when the system only proves that a user can log in, but cannot produce governed identity data that other teams can safely use. In modern application stacks, identity must support security, analytics, machine access, and compliance without fragmenting into one-off exports and duplicated records.

Ory's argument is that identity has moved from a narrow access-control function into a broader control plane for understanding how users, workloads, and AI-enabled systems behave over time. That is a real governance shift for IAM programmes, because the architecture has to serve more than authentication while still preserving clarity and control.

For teams that still rely on custom auth and bespoke token layers, the typical failure mode is not immediate outage. It is gradual operational drift, where identity remains present in every application but is no longer consistently governed across the organisation.

Key questions

Q: How should teams decide whether to keep custom IAM or move to a platform model?

A: Teams should keep custom IAM only where the identity model is tightly bounded, well understood, and not expected to support broad reuse across applications or actor types. If identity must feed security, analytics, compliance, and automation, a platform model usually creates less drift and more governable consistency than bespoke code.

Q: What breaks when identity data is duplicated across applications?

A: Governance breaks first. Duplicated identity data creates inconsistent policy decisions, weak auditability, and conflicting views of who or what the identity is. It also forces each downstream team to maintain its own interpretation, which makes access decisions harder to trust and much harder to defend in reviews.

Q: How do organisations know if their IAM architecture is becoming identity debt?

A: The warning signs are repeated local workarounds, inconsistent identity records, difficulty supporting new use cases, and growing dependence on exports or manual reconciliation. When teams keep solving the same identity problem in different systems, the programme is no longer scaling. It is accumulating debt.

Q: What should security teams do when IAM governance spans human and machine identities?

A: They should apply the same lifecycle discipline to both populations while preserving identity-specific review logic. That means ownership, offboarding, recertification, and entitlement scope must be defined consistently, even if the workflow steps differ between people and non-human identities.

Technical breakdown

Why custom auth breaks as a governed identity fabric

Homegrown IAM usually solves authentication first, then layers tokens, permissions, and user-profile logic around application needs. That works until identity has to become a shared system of record. At that point, the same custom code has to support auditability, policy consistency, and downstream consumption by analytics or automation. If identity data is not structured and versioned, every consuming system builds its own interpretation, which creates drift and weakens governance.

Practical implication: treat identity schema, policy, and event design as platform assets, not application-specific implementation details.

API-first identity and machine access at scale

An API-first identity fabric exposes identity services and signals in a way that other systems can consume consistently. That matters when workloads, service accounts, and AI-enabled processes need access patterns that change faster than manual admin workflows can handle. Scalability is not just performance here. It is also the ability to preserve decision quality as identity events, policies, and access checks move across many applications and regions.

Practical implication: design identity services for programmatic reuse before you scale new workload and machine-access use cases.

Identity as a system of record for behaviour and context

Modern IAM increasingly has to represent more than a login event. It must retain behavioural and contextual signals that help security, marketing, and data teams understand who the identity is, how it changes, and what actions are appropriate. If those signals are trapped inside application silos or ad hoc exports, the organisation loses both governance and analytical value. The result is a fragmented identity model that cannot support modern decision-making.

Practical implication: centralise identity events and metadata so access, governance, and analytics operate from the same trusted source.

NHI Mgmt Group analysis

Homegrown IAM becomes identity debt when identity cannot be reused safely outside the application that created it. A system built only to authenticate users often leaves no governed identity fabric for security, analytics, or compliance teams to consume. That turns each downstream integration into a custom workaround, which is how technical convenience becomes long-lived governance debt. Practitioners should view custom IAM as a control surface that can decay faster than the business changes around it.

Identity data fragmentation is the real failure mode, not just code maintenance overhead. When identity lives in duplicated tables, exported files, or application-local policy logic, no team has a complete view of subject, session, or privilege context. That weakens access governance and makes cross-domain decisions inconsistent. The important question is whether the identity programme can produce reliable, governed signals at enterprise scale, not whether the login flow still functions.

API-first identity changes the operating model for modern IAM because access is no longer the only consumer of identity. Marketing, analytics, and automated systems now depend on identity context that can be trusted, queried, and governed. That pushes identity architecture closer to a system of record than a front-end auth layer. The practitioner takeaway is that identity design must support reuse without creating uncontrolled copies of the same truth.

Machine and AI identities raise the bar for identity infrastructure even when the original use case was human login. Once workloads and AI-enabled services become first-class identity subjects, a custom IAM stack has to handle more dynamic access patterns, more machine credentials, and more policy complexity than most homegrown systems were designed for. That does not make bespoke identity impossible, but it does make governance assumptions much harder to sustain. Teams should judge architecture by whether it can govern multiple actor types without collapsing into application-specific exceptions.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That visibility gap is why the NHI Lifecycle Management Guide matters when identity sprawl begins to outgrow manual governance.

What this signals

Identity debt is now a programme risk, not just a developer convenience issue. Once identity data becomes fragmented across applications, teams lose the ability to govern access consistently or reuse identity signals with confidence. That is where identity architecture starts to constrain delivery velocity and audit readiness at the same time.

The practical next step is to treat identity plumbing as part of the control plane, not a sidecar to application engineering. If you are already seeing exceptions, exports, and local policy copies, the organisation is signalling that its identity model no longer matches its operating model.

The broader lesson is that modern IAM has to support both human access and non-human identity without forcing each new use case into a bespoke pattern. That makes lifecycle discipline and governed reuse more important than another round of incremental auth code.

For practitioners

• Define identity as a shared system of record Map which identity attributes, events, and policy decisions must be reusable across security, analytics, and customer-facing systems. Replace application-local copies with governed identity services that expose a consistent source of truth.
• Inventory custom auth dependencies Identify every service, workflow, and downstream pipeline that depends on homegrown login, token, or authorization logic. Rank them by maintenance burden, access sensitivity, and how difficult they would be to migrate to a controlled identity fabric.
• Separate identity signals from application storage Stop treating exports and ad hoc replication as a governance strategy. Keep identity events, metadata, and policy context in systems that can be audited, versioned, and consumed safely by other teams.
• Test whether the architecture supports non-human actors Check if the current identity model can support service accounts, workload identities, and AI-enabled automation without bespoke exceptions. If each new actor type requires a one-off pattern, the architecture is already leaking governance.

Key takeaways

• Homegrown IAM turns into identity debt when it cannot produce governed identity data that other teams can safely reuse.
• The main risk is fragmentation across applications, which weakens auditability, policy consistency, and downstream trust in identity signals.
• Practitioners should evaluate identity architecture by whether it can support humans, workloads, and automation as a shared governed fabric.

Key terms

• Identity Debt: Identity debt is the accumulation of unowned, over-permissioned, or poorly governed non-human identities that security teams cannot cleanly inventory or retire. It usually grows when experimentation outruns access governance, leaving service accounts and tokens active long after their original purpose has passed.
• Identity Fabric: An identity fabric is a connected control model that shares context across governance, privileged access, and access management. It is not a product category. The aim is to make identity decisions coherent across the full lifecycle so ownership, privilege, and enforcement reinforce each other.
• Identity System of Record: The authoritative source that shows what access an identity actually has. For human, machine, or agent identities, the system of record is the place where entitlement state should be reconciled after request fulfilment. Without it, ticket approvals can diverge from real access.

What's in the full article

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

• The article's deeper explanation of how Ory structures identity as a system of record for downstream teams.
• The engineering rationale for API-first identity foundations in global and modern application environments.
• The specific way Ory frames machine and AI identities inside the broader identity model.
• The business argument for why identity context can support engineering velocity without sacrificing control.

👉 Ory's full post expands on the structural shift from custom auth to a governed identity fabric.

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.