What is a Self-hosted Application, Anyway?

The quick and easy definition of a self-hosted application

Generally speaking, a self-hosted application means that a company is responsible and accountable to manage and fully maintain the infrastructure it’s hosted upon, as well as the application’s components. What happens behind the scenes of the application are of utmost interest to the organization, from company standards, code optimization and of course, for security standards and regulatory purposes.

Quickly coming to mind are legacy applications, commonly hosted on-premises. But not only. They can be applications built on an Infrastructure as a Service (IaaS), for example, AWS / Azure / GCP VMs); Platform as a Service (PaaS), for example, Azure App Service, Google App Engine, etc.; or even a Container Orchestration Platform, like Kubernetes. It’s not necessarily even home-grown code. Take for example, ServiceNow installed on a bank’s private AWS instances. In this case, the ServiceNow application is running on the bank’s servers, so while ServiceNow is a third party, it’s still the bank that manages and fully maintains it. The same applies to any SaaS application that also provides self-hosted deployment within the customer’s private IaaS instances, for example.

A 2024 Team8 survey focusing on Fortune-2000 enterprises, showed that the average enterprise holds an average of 1,200 applications, and the vast majority of these applications are self-hosted. Specifically, the BFSI industry indicated that 73% of their applications are self-hosted, manufacturing reported 88%, and 92% of all applications at healthcare organizations were self-hosted.

Technology advancements add definition complexity

Before the cloud platform existed, it was easier to define an application since the deployment infrastructure was simpler. Applications were mainly hosted on a single on-premise server. For example, if a user accessed an application, they probably accessed a single host that ran this application.

As infrastructure and deployment platforms continue to evolve, also application architecture continues to evolve and, accordingly, has more modular components. Each component (which sometimes can be treated as another application or “sub-application”) is responsible for different functionality. It can be hosted on the same server or even distributed on multiple servers. These technology advancements gave rise to more complex situations, making professionals play “where is the application?”.

For instance, say there are two servers communicating with one another, as part of the ServiceNow self-hosted application we referred to earlier. If each server hosts a different component of the same application (e.g., the first one is responsible for user authentication, and the second one for the ticket creation), do we consider them as two? Or can we say there’s actually one application that is distributed across the servers?

As another example, let’s take a look at Web application servers. It makes sense to consider multiple web applications (where each one has a different URL) with distinct business logic as individual applications, even though they share the same infrastructure (i.e. they are hosted on the same server). However, what about fifteen web applications, each providing a different logic of the same business logic application? If we refer to the previous ServiceNow example, this would mean that both logics, authentication and ticket creation, are hosted on the same server. Then it seems to make sense to bundle them as a single application.

Standards and regulations require us to check user and data flow for applications, but this leads to the question: for which applications do we monitor flows?

Using requirements to help define self-hosted applications

When speaking to dozens of leading enterprises, a common theme emerged - the security, or identity team, were speaking of flows. They needed to know the application’s authentication and authorization flows. They didn’t really care which application ran what - their needs were elsewhere - discovering the flows. If they know of a flow, then they can tell you the application.

This made us turn the equation around – instead of defining an application by some characteristic in order to find the flows, let’s find the authentication and authorizations flows in the system, track back their journey, and consider the journey’s root as the single (self-hosted) application.

From the security - data and identity approaches - that makes a lot of sense. It means that we need a hierarchy of applications. There will always be a single root application that is reliant on components (“sub-applications”) for separate business reasons, those in turn are reliant on other components, and eventually these lead to tree leaves. The whole tree can give us the flow of, say, identity, from actual login, across all various authentication methods and apps, until the final access to a separate identity and authentication management program.

Looking back at the Team8 survey that showed that the enterprises have an average of 1,200 applications, this hierarchy makes sense. By contrast, in a flat hierarchy, where all applications were to be disjoint, there would’ve been x5 reported self-hosted applications.

The hierarchy of self-hosted applications: Benefits

Once you have the hierarchy of applications, you can:

• Facilitate the management of the enterprise applications inventory.  
• Quickly tell whether an application can be, say, accessed directly through a non-federated login portal, is using a local database for user provisioning and authentication, is using SSO (Single Sign-On) via an external identity provider, etc.
• Easily map the identity journey to figure what security controls are set for each application and how such controls are implemented.
• Provide a clear authorization and privilege-level flow.
• Enable continuous identification of compliance and security gaps as they evolve due to changes in applications, compliance frameworks, or the identity stack.

How does Orchid Security map self-hosted applications?

Orchid’s Identity-first Security Orchestration Platform does just that to define an application. It takes the mapping though one step further to visually map that flow. That way, within a glance it can pinpoint any exposure through any native control. What can be done manually is fully automated.

‍

Learn more how Orchid Security discovers applications and then compares them to the organizational identity security requirements here.