You control the application. But you don't control the environment it runs in. So where does trust begin?
A customer’s phone may be rooted or instrumented. A shared laptop can have local tools and software running outside your control. A browser can be surrounded by extensions, developer tools, local proxies, automation frameworks, and a network that isn’t yours.
You can’t make those places completely safe. Neither can we.
Any security model that depends on the end user’s device being trustworthy will eventually meet an environment that is not. This isn’t an edge case. It’s the operating reality of client-side applications.
You can’t control the whole device or browser. But you can protect the application running inside it. So, we created a protected space inside the application where sensitive work can take place, even when the surrounding environment can't be trusted.
Promon calls this a Trusted Runtime Environment, or TRE: a hardened runtime created inside the protected application, even though that application is running on a device or browser you don’t control.
But building that environment is only the first step. The security model has three parts, and the order matters: Build it. Prove it. Then release the data.
Read more: Mobile app vs. mobile device security: What are the differences?
A Trusted Runtime Environment, on its own, achieves very little. A safe room only becomes valuable when you put something inside it that’s worth protecting. Its value comes from what you can place inside it and what you can safely do there.
The same applies to runtime protection. Its security value comes from what it allows your application and server to do safely.
Protection that can’t be verified remains an assertion. If that assertion comes from the client, it carries limited weight because the client is the environment you did not trust in the first place.
The protected runtime becomes useful when your server can verify it. The proof becomes useful when your architecture acts on it.
Picture a security van traveling along a public road. Nobody controls every vehicle, person, or junction around it. The cash it’s carrying isn’t safe because the road is safe. It is safe because the van creates a protected space around it.
But the van is only half of the design. Before the depot releases anything valuable, it checks that the van is genuine, that it has not been altered, that the right crew is operating it, and that there are no signs of outside interference. Only then does the depot release the cash.
Build the secure van. Check it. Then release what matters. This sequence is the security model.
Organizations control many important parts of an application service. For example, they control the source code, build process, deployment pipeline, backend infrastructure, APIs, access policies, and data stores. They decide what the application should do and what information it should receive.
The control weakens once the application reaches the customer.
The organization doesn’t own the customer’s phone or laptop. It doesn’t administer every browser. It can’t dictate which local tools are running, whether the operating system has been modified, or what is observing the application at runtime.
Existing security controls remain essential. They protect the server, identities, APIs, and data. But they don’t by themselves prove that the client code running in the browser is still the code you published.
That leaves a gap between the server you control and the client you don’t. A TRE addresses that gap without pretending the surrounding environment has become safe. Promon Shield operates inside the protected application, on the untrusted side of the boundary. It hardens the runtime where sensitive application assets and interactions are exposed. Server-side systems can then make decisions using evidence from that runtime rather than trusting claims from the wider device or browser.
The distinction is between trusting the browser and trusting a protected runtime inside it. We don't have to trust the browser itself. Instead, we’re establishing a runtime inside the browser that can be protected and verified.
Each part of the model depends on the one before it.
If you build a protected environment but can’t prove its state, the server still must trust a claim made by the untrusted client.
If you generate proof but don’t use it in an access decision, attestation becomes another signal that is collected but never changes an outcome.
If you release sensitive data before verification, the most important decision has already been made. The data has entered an environment whose state is unknown.
The complete sequence changes that relationship.
The server doesn’t release information simply because a client requests it. It first establishes whether the request comes from a genuine application running inside an acceptable runtime state.
The runtime proof becomes part of the release condition. This is what turns client-side protection into an architectural control rather than a standalone hardening feature.
The TRE protects the application locally. Attestation allows the server to verify that protection. Server-side policy decides what should happen next.
No single step carries the full model. Together, and in the right order, they create a defensible path between application integrity and data access
The model is simple enough to describe in three steps. Each step has a distinct job.
Promon Shield builds a hardened runtime inside the protected application. It is the part of the architecture that must operate in untrusted space, whether the application runs on mobile, desktop or, with Promon Shield for Web™, in a browser.
The TRE protects and observes the application while it runs. It is designed to defend the exposed runtime surface, not only the code artifact delivered at release. It does this without relying on trusted hardware or assuming the surrounding client is clean.
The surrounding device remains outside your control. But the application no longer has to depend on that control.
The protected environment is then attested from the server side.
Attestation establishes whether the application is genuine and whether its runtime state meets the required security conditions. This includes establishing that the expected code is running and checking for signs that the application has been altered, inspected, or controlled through outside tooling.
The proof can’t be treated as a one-off statement made at launch.
Runtime conditions can change after a session begins. A process may start clean and encounter manipulation later. A check performed thirty seconds ago can’t automatically describe the state of the application now.
The verification model therefore needs to remain active across the relevant part of the session, rather than treating trust as permanent once granted. This gives the server something stronger than a client claim or a behavioral guess. It receives cryptographically backed evidence about the application and its runtime state.
The attestation result can then inform a server-side release decision.
Your APIs remain under your control. Your team decides which requests, responses, or actions require proof of an acceptable runtime state.
When that proof is present, the server can proceed according to policy. When it is absent or invalid, the server can withhold the protected response or deny the action.
The important point isn’t that every API call must be treated identically. Rather, sensitive data no longer must be released to a client whose integrity is unknown.
The proof becomes a condition for access.
Because that proof is cryptographic, the decision does not have to depend on a probabilistic confidence score. For the defined security condition, the runtime either presents valid proof or it does not. Released, or not released.
A TRE doesn't work by turning the customer’s browser into infrastructure you own. Neither does it replace authentication, authorization, API security, fraud controls, secure development, or backend monitoring. Those controls answer different questions.
Authentication establishes who the user is. Authorization determines what that user is allowed to do. API security protects the services and interfaces through which the application communicates. Fraud systems identify patterns that may indicate abuse.
Runtime attestation addresses another question:
Is the expected application running in a state that can be trusted for this request?
A valid user account does not guarantee a valid client. Legitimate credentials prove identity, not client integrity. They can still be used through modified software, scripted tools, or a manipulated session.
Identity alone can’t prove application integrity. The TRE model adds that missing runtime assurance. It gives server-side systems evidence about the software that is asking for access, not only the identity associated with the request.
The browser remains untrusted. Sensitive work is placed inside a runtime that can be protected and proven.
Teams that have spent years hardening mobile applications often assume that web protection will demand a different vocabulary, a different security model, and a fresh round of internal education. That assumption creates delay.
The browser does introduce its own technical constraints. The implementation can’t simply be copied from mobile or desktop. But the underlying security problem isn’t new.
The application still runs in an environment the organization does not control. The organization still needs a protected place for sensitive execution. The server still needs proof before it makes a high-trust decision.
The sequence remains the same: Build the environment. Prove its state. Then release the data.
Mobile, desktop, and browser are different execution surfaces. They don’t require three unrelated security philosophies.
For security leaders, that reduces the conceptual burden. Existing thinking about runtime protection, attestation, and server-side enforcement can extend into the browser without starting again from first principles. There is less to relearn than the market currently assumes.
A protected runtime is necessary, but it is not the outcome. The outcome is a controlled relationship between application integrity and access to sensitive data.
Promon Shield for Web™ extends that model into the browser: Build a Trusted Runtime Environment inside the place you don’t control. Prove that the expected application is still running in an acceptable state. Then let your server decide whether to release what the application requested.
The next article in this series will examine what runtime attestation can establish, what evidence the server receives, and why verification must describe the application’s current state rather than the state it had when the session began.