A homegrown identity system is a custom-built access management platform created and maintained internally. These systems can work for a while, but they often struggle as organisational size, application complexity, and compliance demands increase. Maintenance burden, inconsistent controls, and limited scalability are common long-term drawbacks.
Expanded Definition
A homegrown identity system is an internally engineered platform for authenticating users, issuing sessions, and enforcing access decisions across applications, APIs, and service accounts. In practice, it often bundles custom directory logic, token handling, authorization rules, and audit features into one stack rather than relying on a standard identity provider or broker.
Definitions vary across vendors and engineering teams because some organisations use the phrase for a narrowly custom login service, while others mean a full in-house IAM replacement. In NHI governance, the distinction matters because custom-built systems frequently lack the control depth needed for rotation, offboarding, and centralized visibility. The NIST Cybersecurity Framework 2.0 treats identity management as a core security function, but it does not endorse a homegrown approach as a default.
At NHIMG, the term usually signals operational debt: security logic embedded in application code, inconsistent policy enforcement, and limited evidence for auditors. The most common misapplication is treating a homegrown login portal as a complete identity control plane, which occurs when teams equate successful authentication with mature identity governance.
Examples and Use Cases
Implementing a homegrown identity system can preserve product-specific flexibility, but it also introduces long-term maintenance overhead, requiring organisations to weigh engineering autonomy against security and compliance cost.
- A startup builds a custom service to mint tokens for internal microservices, then later discovers it has no reliable rotation workflow for machine credentials. The risk pattern mirrors issues described in the Ultimate Guide to NHIs.
- An enterprise keeps legacy app authentication in a bespoke platform because migration seems disruptive, but every new integration adds another access policy exception. Over time, the system becomes harder to govern than a standards-based identity layer aligned to NIST Cybersecurity Framework 2.0.
- A DevOps team uses internally written logic to issue API keys for build pipelines, yet key inventory is fragmented across repos and scripts. NHIMG has documented how credential exposure patterns recur in incidents such as JetBrains GitHub plugin token exposure.
- A regulated business keeps authorization rules in application code to avoid platform dependency, then struggles to produce consistent audit evidence during reviews.
- A platform team extends a custom directory to cover both humans and NHIs, but the policy model becomes ambiguous when service accounts need tighter constraints than employees.
Why It Matters in NHI Security
Homegrown identity systems are risky because they often grow faster than the organisation’s ability to test, monitor, and retire them. When authentication, authorization, and secret handling are implemented differently across internal services, the result is uneven assurance and weak governance for NHIs such as service accounts, API keys, and automation agents. NHIMG research shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, which makes bespoke identity logic especially difficult to control.
The operational problem is not just technical debt. Custom identity stacks can hide privilege creep, delay offboarding, and make incident response slower because the system’s behavior is known only to a few developers. That is why the broader NHI lifecycle guidance in the Top 10 NHI Issues is so relevant here, especially where secret handling and access review are weak. Organisations also use the 52 NHI Breaches Analysis as a reference point for how identity shortcuts turn into breach pathways.
Organisations typically encounter the limits of a homegrown identity system only after a breach, audit failure, or platform migration, at which point the system becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Homegrown identity systems often drive weak lifecycle and governance controls for NHIs. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access management map to controlled, auditable access processes. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust depends on strong identity and policy enforcement, not bespoke trust assumptions. |
| NIST SP 800-63 | AAL2 | Assurance levels highlight the need for stronger, standardized authentication than custom flows. |
| OWASP Agentic AI Top 10 | A-04 | Custom identity systems can weaken tool-access governance for autonomous agents. |
Align authentication strength to assurance targets rather than relying on internally invented methods.
Related resources from NHI Mgmt Group
- When should organisations treat an AI system as a non-human identity?
- Who is accountable when a compromised identity system disrupts public services?
- What breaks when teams rely on system state restore for identity servers?
- How can organisations reduce identity risk without replacing every legacy system?
