Notifications
Clear all
Topic starter
19/08/2026 3:50 pm
TL;DR: Homegrown IAM systems still work for login and token issuance, but Ory argues they have become identity debt as modern applications, API-first architectures, and machine and AI identities demand governed identity signals, scalable access control, and safer reuse across teams. The structural problem is that access can persist while understanding, governance, and compliance context fragment.
NHIMG editorial — based on content published by Ory: Why It's Time to Move Beyond Homegrown IAM
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.
Questions worth separating out
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.
Q: What breaks when identity data is duplicated across applications?
A: Governance breaks first.
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.
Practitioner guidance
- 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.
- Inventory custom auth dependencies Identify every service, workflow, and downstream pipeline that depends on homegrown login, token, or authorization logic.
- Separate identity signals from application storage Stop treating exports and ad hoc replication as a governance strategy.
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.
👉 Read Ory's analysis of why homegrown IAM becomes identity debt →
Homegrown IAM and identity debt: what changes for security teams?
Explore further
19/08/2026 4:26 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Homegrown IAM creates identity debt in modern application stacks
