Self-hosted web infrastructure is application and service infrastructure operated by the customer rather than a SaaS provider. The operator owns patching, network exposure, and compensating access controls, which makes governance and reachability decisions part of the security design, not just operations.
Expanded Definition
Self-hosted web infrastructure refers to web-facing systems, application stacks, and supporting services that an organisation operates in its own environment rather than consuming them as a fully managed SaaS offering. That distinction matters because the operator controls patch cadence, internet exposure, TLS termination, secrets handling, logging, and the compensating controls that reduce risk when default vendor safeguards are absent.
In NHI security, self-hosted environments are where service accounts, API keys, deployment tokens, and machine certificates often accumulate the most privilege. The security boundary is therefore not just the server or cluster, but the identity model wrapped around it. Guidance varies across vendors on how much responsibility is “infrastructure” versus “application,” but NHI governance treats both as one operational control plane. The NIST Cybersecurity Framework 2.0 is useful here because it frames asset visibility, protective controls, and continuous monitoring as shared duties rather than one-time configuration tasks.
The most common misapplication is assuming “self-hosted” only changes deployment ownership, which occurs when teams neglect to reassess identity, patching, and network reachability as part of the same risk decision.
Examples and Use Cases
Implementing self-hosted web infrastructure rigorously often introduces operational overhead, requiring organisations to weigh sovereignty and control against the cost of patching, hardening, and lifecycle management.
- A customer-operated authentication portal runs in a private cluster, with ingress restricted to approved regions and machine-to-machine access mediated by short-lived credentials.
- An internal developer platform hosts build and release services on premises, where service accounts must be rotated and scoped to the minimum pipeline stage required.
- A regulated workload uses self-hosted object storage and web APIs so logs, keys, and certificates remain under direct tenant control rather than a vendor-managed boundary.
- A platform team runs its own reverse proxy and WAF, then binds operational access to Ultimate Guide to NHIs principles for rotation, visibility, and offboarding.
- An identity-aware gateway fronts legacy web services, aligning with NIST Cybersecurity Framework 2.0 expectations for least privilege and continuous monitoring.
These use cases are common where teams need control over residency, latency, or third-party exposure, but no single standard governs the exact boundary of “self-hosted” across all vendors.
Why It Matters in NHI Security
Self-hosted web infrastructure becomes an NHI governance issue because the organisation inherits the full identity burden for non-human workloads. Secrets, certificates, and service accounts are not automatically safe just because the stack is private. In fact, NHI exposure often expands in self-hosted environments when teams reuse static credentials, over-broaden network trust, or leave administrative endpoints reachable from the public internet.
NHI Management Group research shows that 97% of NHIs carry excessive privileges and 71% are not rotated within recommended time frames, which is especially dangerous when the operator also controls the surrounding web infrastructure. The Ultimate Guide to NHIs also reports that 96% of organisations store secrets outside secrets managers, a pattern that often shows up first in self-hosted deployment pipelines and admin tooling. That makes network segmentation, vaulting, and access review inseparable from hosting decisions.
Organisations typically encounter the consequence only after an exposed admin panel, leaked deployment token, or compromised service account turns infrastructure ownership into an active incident response problem, at which point self-hosted web infrastructure 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 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 stacks often fail through secret storage and access control gaps. |
| NIST CSF 2.0 | PR.AC-4 | Self-hosted infrastructure requires least-privilege access to systems and services. |
| NIST Zero Trust (SP 800-207) | SC-31 | Private hosting still needs explicit trust boundaries and controlled communication paths. |
Treat every self-hosted endpoint as untrusted until explicitly authenticated and authorized.
Related resources from NHI Mgmt Group
- How should security teams protect self-hosted AI runtimes from memory disclosure?
- How should security teams choose between managed and self-hosted CIAM?
- How should security teams govern AI cloud infrastructure differently from web apps?
- How do organisations decide between self-hosted open-weight models and hosted APIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
