Identity services that the organisation installs, upgrades, secures, and operates itself. In practice, this means the team owns availability, patching, integration maintenance, and policy drift, which can become a material operating burden as authentication requirements expand.
Expanded Definition
Self-hosted identity infrastructure is the organisation-run stack that issues, stores, authenticates, and governs identities for humans, workloads, and agents. Unlike managed identity services, the operator owns patching, resilience, policy enforcement, integration upkeep, and auditability. That ownership matters because identity drift, outdated dependencies, and weak recovery procedures become the organisation’s direct responsibility.
In NHI practice, the term usually covers directory services, federation brokers, token services, secrets systems, and policy layers that support machine access. It also intersects with agentic AI governance, because autonomous software increasingly depends on identity controls that must be configured, monitored, and rotated by internal teams. Guidance varies across vendors, but the security expectation is consistent: the organisation must be able to prove who or what has access, why it has it, and how quickly access can be revoked. For a baseline governance lens, NIST Cybersecurity Framework 2.0 remains a useful external reference for managing identity-related risk.
The most common misapplication is treating self-hosted identity infrastructure like a simple IT platform lift, which occurs when teams migrate the technology without assigning explicit ownership for secrets rotation, service-account lifecycle, and emergency revocation.
Examples and Use Cases
Implementing self-hosted identity infrastructure rigorously often introduces operational overhead, requiring organisations to weigh control and customization against patching burden, uptime responsibility, and security staffing cost.
- An enterprise runs its own identity provider so internal service accounts can be governed under local policy rather than a third-party roadmap.
- A platform team self-hosts federation for workloads because API access to production systems must follow internal approval and logging rules.
- A security group manages its own secrets service to enforce rotation cadences, rather than relying on ad hoc storage in code or CI/CD variables, a pattern highlighted in the Ultimate Guide to NHIs.
- A regulated organisation keeps identity infrastructure in-house so incident response can revoke credentials immediately without waiting on an external support queue.
- An AI operations team self-hosts identity controls for agents so access can be constrained per task, per tool, and per environment, consistent with Ultimate Guide to NHIs — What are Non-Human Identities and identity guidance in NIST Cybersecurity Framework 2.0.
Because self-hosted stacks require sustained tuning, teams often adopt them only when identity governance, data residency, or integration control is more important than operational simplicity.
Why It Matters in NHI Security
Self-hosted identity infrastructure becomes a security issue when it is assumed to be “just internal infrastructure” instead of a high-value control plane. In NHI environments, weak patch discipline, stale tokens, and poor revocation can expose service accounts, API keys, certificates, and agent permissions across multiple systems. NHIMG research shows how often this becomes material: in the 52 NHI Breaches Analysis, identity compromise repeatedly appears as a root enabler rather than a side effect. The risk is amplified when organisations store secrets outside controlled systems or allow policy drift to accumulate unnoticed.
One particularly relevant stat from 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 pattern turns self-hosted identity infrastructure into the only reliable control boundary if it is actually governed. The challenge is not merely availability, but proving that every credential path is accounted for and recoverable under pressure.
Organisations typically encounter the consequences only after a token leak, service-account abuse, or failed incident containment, at which point self-hosted identity infrastructure becomes operationally unavoidable to fix.
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 and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Self-hosted identity stacks must control secret storage, rotation, and revocation. |
| NIST CSF 2.0 | PR.AC-1 | Identity management and access control are core CSF governance expectations. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust assumes strong identity enforcement for every request and workload. |
Use self-hosted identity controls to authenticate each workload, limit privilege, and continuously validate trust.
Related resources from NHI Mgmt Group
- How should teams choose between managed and self-hosted identity platforms?
- How should teams decide between Authentik and Keycloak for self-hosted identity?
- How should security teams decide between a lightweight gateway and a full identity provider for self-hosted apps?
- What do teams get wrong about proxy mode in self-hosted identity setups?
