A bespoke identity workflow or platform created in-house over time to solve local business needs. These systems often fit regional processes well, but they tend to make auditability, change management, and integration with modern governance controls harder as the environment grows.
Expanded Definition
A scratch-built identity system is an in-house identity workflow or platform assembled over time to meet local operational needs. It may begin as a pragmatic shortcut, but it gradually becomes a core control plane for authentication, authorization, provisioning, and offboarding.
In NHI environments, the term often covers homegrown service account registries, token-issuing scripts, bespoke approval flows, or internal portals that manage machine credentials outside a standard IAM product. The key distinction is not whether the system is “bad” or “good”; it is whether identity logic has been encoded into custom code without the lifecycle rigor expected for modern governance. Industry usage is still evolving, but the governance concern is consistent: a scratch-built identity system can bypass the controls typically associated with audited IAM, PAM, and Zero Trust programs. NIST SP 800-207 frames access as continuously evaluated trust, while homegrown identity stacks frequently hard-code exceptions that are difficult to prove or retire.
The most common misapplication is treating a temporary workaround as a permanent identity control plane, which occurs when operational fixes are never replaced by governed lifecycle management.
Examples and Use Cases
Implementing a scratch-built identity system rigorously often introduces maintenance debt, requiring organisations to weigh local flexibility against auditability, resilience, and security ownership.
- A regional operations team builds a custom portal for service account creation because the central IAM tool does not support its approval chain, then keeps that portal in production for years without standardized logging.
- A data platform uses bespoke scripts to issue API keys to pipelines, which makes rotation possible but leaves revocation, ownership, and expiry handling dependent on individual engineers.
- A startup creates an internal identity registry for agents and automation tools before adopting stronger controls, but later struggles to map those identities into the broader governance model described in the Ultimate Guide to NHIs.
- A legacy enterprise keeps custom authentication logic for vendor integrations because the original workflow is deeply tied to local business rules, even though the design no longer aligns with the NIST Zero Trust Architecture model.
- A development team embeds identity checks into CI/CD tooling, then discovers during a review that the code path has become the only place where offboarding occurs, a pattern repeatedly seen in the 52 NHI Breaches Analysis.
These use cases show why definitions vary across vendors and organisations: some teams mean a lightweight internal integration layer, while others mean a fully custom IAM replacement. The governance question is whether the system can reliably enforce identity lifecycle rules, not whether it was built internally.
Why It Matters in NHI Security
Scratch-built identity systems matter because they often accumulate privileged paths that are hard to inventory, hard to rotate, and hard to prove compliant. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, and that visibility gap becomes even more severe when identity logic is dispersed across custom code and unmanaged workflows. That is one reason the Ultimate Guide to NHIs highlights the operational value of centralized governance.
The risk is not just technical sprawl. Custom identity systems tend to outlive the people who built them, leaving ambiguous ownership, undocumented exceptions, and fragile emergency access paths. This can conflict with the control intent of the EU Cyber Resilience Act, which pushes organisations toward more accountable and maintainable security practices. When scratch-built systems manage secrets, tokens, or service identities, a single missed rotation or broken revocation flow can cascade into broad compromise.
Organisations typically encounter the consequences only after an audit failure, breach, or failed offboarding event, at which point the scratch-built identity 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 address the attack surface, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the technical controls, and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Scratch-built identity flows often create hidden NHI inventory and ownership gaps. |
| NIST CSF 2.0 | PR.AC-1 | Custom identity systems affect how identities are created, authenticated, and authorized. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous evaluation, which scratch-built exceptions often weaken. | |
| NIST SP 800-63 | IAL/AAL/FAL | DIY identity systems must still meet assurance, authentication, and federation expectations. |
| EU Cyber Resilience Act | The EU Cyber Resilience Act raises expectations for secure, maintainable product and software practices. |
Validate custom identity workflows against assurance requirements instead of assuming internal equals compliant.
