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. That's the operating reality of client-side applications.
What you can protect is 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 security value comes from what it allows your application and server to do safely.
A claim about protection that comes from the client carries limited weight, because the client is the environment you didn't 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.
This sequence is the security model.
Your organization controls many important parts of an application service. For example, you control the source code, build process, deployment pipeline, backend infrastructure, APIs, access policies, and data stores. You decide what the application should do and what information it should receive.
The control weakens once the application reaches the customer.
You don't own the customer’s phone or laptop, and administer every browser. You don'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.
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 has to 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 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. That 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.
Together, in the right order, they create a defensible path between application integrity and data access.
Each step in the model 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 or desktop, or in a browser with Promon Shield for Web™.
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 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, because 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.
Not every API all needs the same treatment, but sensitive data no longer has to go 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.
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 doesn't guarantee a valid client. Legitimate credentials can still be used through modified software, scripted tools, or a manipulated session. The TRE model gives server-side systems evidence about the software asking for access, as well as the identity behind the request."
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.
Mobile, desktop, and browser are different execution surfaces, but they share one security model. Existing thinking about runtime protection, attestation, and server-side enforcement extends into the browser, so there's less to relearn than the market currently assumes.
A protected runtime is necessary, but what matters 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 post 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.