What is the difference between defining a self-hosted application by infrastructure and defining it by identity flow?

Infrastructure-based definition asks where the code runs, while identity-flow definition asks how users, credentials, and authorization decisions move through the system. The second view is more useful for security teams because it exposes the real trust boundaries, dependencies, and control points. It supports better mapping of access, compliance, and privilege across distributed components.

Identity flow reveals the security model, not just the deployment location

Defining a self-hosted application by infrastructure tells you where the software lives, but defining it by identity flow tells you how access is actually granted, propagated, and constrained. That difference matters because security failures usually occur at the trust boundaries between users, service accounts, API keys, tokens, and downstream systems, not at the server rack or cloud account label. For teams managing distributed applications, the identity view is the one that exposes who can act, on whose behalf, and with what level of privilege.

This is especially important in modern environments where applications are split across containers, pipelines, internal APIs, and external services. A host-centric view can make a system look simple and controlled even when credentials, delegated access, and machine-to-machine trust are sprawling. The identity-flow view also helps teams see where authentication is static, where authorisation is implicit, and where trust is being reused in ways that are hard to audit. The OWASP Non-Human Identity Top 10 is useful here because it focuses attention on the credential and trust relationships that infrastructure diagrams often hide.

In practice, many teams discover the real security boundary only after a service account, token, or delegation path has already been over-scoped across multiple components.

How identity flow changes design, review, and incident response

An infrastructure definition starts with runtime placement: VM, cluster, subnet, or hosting account. That is useful for operations, but it answers only part of the security question. An identity-flow definition starts with the actors and trust links: a human signs in, an application exchanges a token, a service calls another service, and the system decides whether the request is allowed. Once you model the application that way, you can evaluate where authentication happens, whether authorization is contextual, and whether credentials are short-lived or reused long after their intended scope.

That shift changes several practical decisions. It becomes easier to identify where least privilege is broken, where secrets are stored outside a managed lifecycle, and where a downstream component inherits authority it should not have. It also improves incident response because investigators can trace access by identity chain instead of asking only which host was involved. When a token is abused, the important questions are often which identity minted it, which service accepted it, and whether the same credential can reach multiple environments. NHIMG’s Ultimate Guide to NHIs is a useful reference for the lifecycle issues that emerge once those machine identities are treated as first-class assets.

Infrastructure-based diagrams are strongest for capacity, topology, and change management.
Identity-flow diagrams are strongest for trust boundaries, privilege review, and blast-radius analysis.
Self-hosted systems often look secure when the server is hardened but the token chain is wide open.
Credential provenance matters as much as location when systems delegate across internal and external services.

For security reviews, the identity-flow view also makes it easier to test whether access is deliberate or merely inherited from how the application was assembled. That matters when teams rely on static credentials, broad service roles, or implicit trust between internal components. The guidance in the OWASP and NHI materials aligns with a broader industry shift toward treating identity as the control plane, not an afterthought. These controls tend to break down when a self-hosted application spans many internal hops and teams cannot map which identity is actually authorizing each step.

When the identity view matters most, and where the trade-off appears

Tighter identity modelling often increases documentation and operational overhead, so teams have to balance clarity against maintenance cost. The trade-off is worth it when the application has delegated access, automation, multiple service accounts, or any path where one credential can unlock many actions. In those cases, an infrastructure-only definition can miss the real security boundary entirely.

There are a few common edge cases. A small internal tool with one host and one operator may not need a full identity-flow map to be understandable. But once the system authenticates users, calls internal APIs, uses CI/CD automation, or accesses shared data stores, the identity flow becomes the more durable way to describe the application. It also scales better when the deployment moves, because the security model travels with the identities rather than the server name. The core question is not where it runs, but which identities can cause meaningful change and how that authority is constrained.

One useful rule is to treat infrastructure as the control surface and identity flow as the security narrative. If the two do not match, the identity story usually tells you where the hidden risk is.

Risk and Threat Considerations

The main risk in an infrastructure-only definition is false confidence. Teams may believe they understand the application because they can name the host, cluster, or environment, while the actual exposure sits in long-lived tokens, delegated service trust, or excessive machine privilege. That creates visibility gaps, weak blast-radius assumptions, and poor accountability when something goes wrong.

Failure mechanism: Attackers and abuse paths often succeed by taking over a credentialed identity rather than a server. If the application’s trust is spread across multiple service accounts, API keys, or exchanged tokens, compromise of one identity can unlock several downstream actions even when the infrastructure itself is intact.

Impact: The result can be unauthorized data access, lateral movement across internal services, broken segregation between environments, and incident response that cannot quickly tell which authority was abused.

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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Identity-flow definitions expose machine credentials and trust paths.
	NHI-02 — Authentication and Trust Boundaries	The question is about where authorization decisions really occur.
Recommendation — Inventory and scope every non-human credential to the identity path it authorizes. Map trust boundaries around each authentication hop and remove implicit trust.
NIST CSF 2.0	PR.AA-01 — Identity and Access Management	Identity-flow modelling supports access governance across the application.
Recommendation — Document and enforce who or what can act in each application trust boundary.
CIS Controls v8	5.1 — Account Inventory and Control	Self-hosted apps are often misread when accounts and service identities are not inventoried.
Recommendation — Inventory all human and non-human accounts that can influence the application.
MITRE ATT&CK	T1552 — Unsecured Credentials	Identity-flow weaknesses often hinge on exposed or reused credentials.
Recommendation — Hunt for exposed credentials and trace which downstream systems they can reach.

Practitioner Guidance

What to prioritise: Model the identities that can read, write, deploy, approve, or call downstream services before you finalise the infrastructure diagram. If the same application component can act in more than one trust context, record those contexts separately instead of collapsing them into one host-based label.

What to verify: Check whether each credential has a single clear owner, a defined expiration or rotation expectation, and a narrow authorization scope. If you cannot explain which identity is responsible for each privileged action, the system is not ready for a security review.

Practitioner takeaway: Infrastructure tells you where an application lives, but identity flow tells you how it can actually be abused, which is the view that matters when you need to judge trust, privilege, and blast radius.