What breaks when organisations rely on home-grown authentication for customer and agentic IAM at scale?

Home-grown authentication often fails under change because it is harder to standardise, audit, and adapt across teams and channels. Common breakpoints include inconsistent policies, weak step-up logic, difficult migrations, and limited support for modern flows like passwordless access or agent authentication. Over time, that creates user friction and raises the likelihood of takeover or misconfiguration.

Why This Matters for Security Teams

Home-grown authentication tends to look manageable at first, then becomes fragile as customer journeys, partner integrations, and agentic workloads multiply. The failure is rarely one big outage; it is a slow accumulation of inconsistent step-up checks, uneven token lifetimes, and exceptions that are never fully removed. For autonomous systems, that fragility becomes more dangerous because an agent can chain tools and act faster than manual review can keep up.

This is why current guidance increasingly points toward policy-driven identity control rather than bespoke logic. The OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both emphasise runtime risk decisions, accountability, and least privilege, which are hard to achieve when authentication is hand-rolled across teams. NHIMG research on AI Agents: The New Attack Surface report shows why this matters operationally: 80% of organisations report AI agents have already acted beyond intended scope, including revealing access credentials.

In practice, many security teams discover the real weakness only after a migration, a takeover attempt, or an agent misfire has already exposed the gaps.

How It Works in Practice

At scale, home-grown authentication breaks when it has to do more than verify a login. A mature identity plane must handle customer self-service, workforce access, partner federation, service-to-service trust, and now autonomous agent identity. Static rules often fail because they assume predictable users and predictable paths, while agents introduce non-linear behaviour, tool chaining, and runtime context that changes from one request to the next.

For agentic systems, the better pattern is to separate authentication from authorisation. Authentication should prove what the workload is, ideally with workload identity rather than shared secrets. Authorisation should then be evaluated at request time using current context, not only pre-defined roles. That is where SPIFFE, OIDC-based workload tokens, and policy engines such as OPA or Cedar are becoming more relevant. For human users, strong passwordless and step-up methods still matter, but the logic should sit in a system that can be audited and consistently applied.

• Use short-lived credentials for each task, not long-lived static API keys.
• Bind agent actions to workload identity so the system knows which agent instance is acting.
• Evaluate access at runtime with policy-as-code instead of hard-coded application branches.
• Revoke or expire credentials automatically when the task ends or risk changes.
• Log the decision path so investigators can reconstruct why access was granted.

NHIMG has documented how exposed credentials are exploited quickly in real environments, including LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where publicly exposed AWS credentials were targeted within minutes. That same speed makes home-grown auth especially risky when agents, bots, and backend services share the same trust assumptions. These controls tend to break down in legacy monoliths and multi-channel stacks because identity logic is duplicated across codebases and no single policy layer exists.

Common Variations and Edge Cases

Tighter identity controls often increase integration overhead, requiring organisations to balance stronger assurance against migration cost and user experience. That tradeoff is especially visible in hybrid estates, where a home-grown login system still supports customers while new agentic workflows are being introduced alongside it.

There is no universal standard for this yet, but current guidance suggests that the safest pattern is to modernise in layers rather than replace everything at once. For customer IAM, that may mean introducing federated identity, stronger phishing-resistant sign-in, and centralised step-up policies. For agents, it usually means treating each autonomous workflow as a separate workload identity with short TTLs and narrowly scoped permissions. The important distinction is that an agent should not inherit broad user rights just because it was launched by a user.

Edge cases appear when teams try to reuse human auth flows for automated systems, or when a single platform must serve both consumer and machine identities. That often leads to brittle exceptions, shared credentials, and unclear accountability. NHIMG’s AI Agents: The New Attack Surface report and the OWASP NHI Top 10 both reinforce the same point: governance fails fastest when identity is custom-built, inconsistently enforced, and difficult to audit across channels and agent fleets.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on human-centric IAM for machine-to-machine communication?
• What breaks when organisations rely on legacy IAM for agentic AI workloads?
• What breaks when payment organisations rely on passwords or PINs alone for customer payment authentication?
• What breaks when organisations rely on always-on desktop access instead of just-in-time access for remote users?