Self-Hosting

Expanded Definition

Self-hosting in NHI security means operating an application, API, secret store, or identity dependency inside an organisation-controlled environment instead of consuming a provider-managed deployment. That choice shifts the trust boundary inward: the organisation controls placement, network exposure, logging, and lifecycle decisions, while also inheriting responsibility for patching, scaling, backup, and incident response.

For Non-Human Identity systems, self-hosting is often selected when data residency, segmentation, or integration with internal controls matters more than operational convenience. It can support tighter alignment with NIST Cybersecurity Framework 2.0 functions such as Identify and Protect, but no single standard governs every self-hosted implementation yet, and definitions vary across vendors when they describe “private,” “on-prem,” or “customer-managed” deployments. In practice, the security value comes from governance discipline, not from hosting location alone. Self-hosting does not automatically create isolation, zero trust, or stronger access control; those outcomes still require deliberate design and continuous validation. The most common misapplication is treating self-hosting as a security control by itself, which occurs when teams assume internal deployment removes the need for hardening, patching, and privileged access review.

Examples and Use Cases

Implementing self-hosting rigorously often introduces operational burden, requiring organisations to weigh control and sovereignty against maintenance cost and failure exposure.

• An engineering team self-hosts an internal API gateway so service-to-service traffic stays within a segmented network and never traverses a provider-managed control plane.
• A security team self-hosts a secrets platform to keep API keys and certificates inside a controlled environment, while enforcing local backup, rotation, and access logging policies. That concern is reinforced by the Ultimate Guide to NHIs, which documents how secrets often remain exposed outside secure vaults.
• An organisation self-hosts an agent runtime for internal workflows to ensure tool access, execution logs, and prompt data remain within its own boundary, then maps the deployment to internal NIST Cybersecurity Framework 2.0 processes.
• A regulated business self-hosts identity middleware in a private cloud region to satisfy data residency expectations, but still uses external key management and monitoring services for resilience.
• A platform team self-hosts a token broker for machine workloads so issuance rules, expiry policy, and audit trails remain under direct administrative control.

Self-hosting is also a common pattern when internal network policy forbids direct dependence on internet-facing identity endpoints or when high-value workloads require stronger containment than a shared SaaS model can provide.

Why It Matters in NHI Security

Self-hosting changes who is accountable when an NHI control fails. The organisation must manage patch cadence, host hardening, segmentation, certificate lifecycle, backup integrity, and privileged administration for the platform itself. That is especially important in an environment where NHI Mgmt Group reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, and only 5.7% have full visibility into their service accounts. Self-hosting can reduce exposure to third-party operational decisions, but it also concentrates risk if the internal team lacks maturity.

Security teams should also remember that self-hosted systems frequently become privileged targets themselves: if the host, control plane, or update path is compromised, every NHI issuing, validating, or storing secrets through that platform is exposed. This is why self-hosting must be governed as part of identity architecture, not treated as a procurement preference. The practical lesson is that the control plane needs continuous assurance, not just an initial deployment review. Organisations typically encounter the true cost of self-hosting only after an outage, a missed patch, or a secrets compromise, at which point the hosting model becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams reduce privilege when self-hosting web applications?
• When does sovereign cloud become an IAM problem instead of a hosting problem?
• What is the difference between self-service administration and safe delegated control?
• When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?