What ‘proven’ actually means in application attestation

Not all forms of application attestation provide the same assurance

In the first post in this series, we set out a simple sequence: build a Trusted Runtime Environment, prove it, then release the data. In this post, we’ll give the middle step a closer look. This “prove it” step relies on attestation: evidence about the state of the protected runtime that can be verified at the back end.

‘Attestation’ can describe very different levels of assurance. At one end, it can mean hardware-backed evidence about a device or runtime. Or on the other, it can amount to little more than a value the client sends to the server saying everything is fine.

The difference between verifiable evidence and a client’s own assertion becomes vitally important when attestation informs a security decision.

For Promon Shield for Web™, proving a Trusted Runtime Environment (TRE) means establishing more than whether an application looked legitimate when a session started. It means answering three separate questions about the application while it is running.

1. Is this the application you intended to run?

2. Has it been altered while running?

3. Is there someone who is inspecting or controlling the runtime?

One: Is this the application you intended to run?

The first question is about application authenticity. Is the application running inside the protected session the one you intended to run, rather than a copied, re-hosted, or otherwise unauthorized version?

Most people associate application attestation with verifying that the running application is genuine. In security terms, part of that assurance concerns provenance: whether the running code can be tied back to the application you published.

For every protected session, Shield for Web creates a new Bootloader specifically for that session and delivers it to the browser. This Bootloader establishes the Trusted Runtime Environment and creates an authenticated, encrypted channel back to Shield for Web. The protected application code is then delivered through that trusted channel into the TRE. Because the delivery path is authenticated, Shield for Web has a basis for verifying the provenance of the application code loaded into the TRE, rather than simply trusting code already present in the browser.

Application authenticity and provenance only answer the first question. A genuine application can still be altered or interfered with after it starts running.

Two: Has it been altered while running?

Runtime integrity addresses what happens after the application starts running.

Many attacks happen after an application has loaded. An attacker may try to alter execution, interfere with the runtime environment, or bypass controls while the application is already active.

A one-time integrity check at startup can’t tell you what happened afterwards.

Shield for Web therefore performs runtime checks inside the Trusted Runtime Environment. Anti-tamper controls detect attempts to interfere with that environment. Anti-debugging controls detect attempts to debug the protected application.

Runtime integrity checks continue during execution. What this means is that a client that passed an integrity check at the start of a session is not automatically trustworthy for the rest of that session. Trust must reflect what is happening now.

Shield for Web succeeds in coupling continuous runtime validation with attestation as protected requests are made. The server doesn’t have to rely on a clean bill of health issued earlier in the session. It can decide based on the current state of the protected runtime.

Three: Is someone inspecting or controlling the runtime?

This third question goes beyond whether the application itself has been modified.

An attacker may not need to rewrite the application if they can observe how it works, step through its execution, or manipulate what happens around it. On the web, the distinction between modifying an application and observing or controlling its execution is especially critical.

Browsers are designed to be inspected. They give users tools for examining application code, network activity, execution state, and application behavior. Those capabilities are useful for developers, but they also give an attacker a ready-made environment for understanding how an application works.

The same principle applies to app shielding more broadly. AI can accelerate parts of an attacker’s analysis and workflow. But techniques such as debugging, instrumentation, and runtime manipulation still have to interact with the running application. Protecting that runtime therefore remains critical, regardless of how quickly the attacker gets there.

Read more: AI-powered mobile app attacks: What app shielding can and can't stop

The goal isn’t to make the browser itself trustworthy. It remains an environment the application owner doesn’t control. Shield for Web establishes a protected runtime inside it and checks whether the conditions required for trust still hold. Anti-debugging controls detect and actively interfere with debugging attempts, while attestation provides evidence about whether the runtime remains trustworthy.

Attestation therefore goes beyond confirming that the right code was delivered. It also reflects whether the protected runtime still meets the conditions required for trust while the session is active.

Why runtime observation matters more in a browser

On mobile, an attacker often must create the conditions needed to inspect or manipulate an application. They may use a rooted device, attach instrumentation, distribute a modified build, or compromise someone else's device. The browser removes much of that distance.

The person using the application can also be the person studying it. They may be a legitimate, authenticated user. They may have valid credentials and an authorized session.

The security question is no longer whether the user is legitimately authenticated. The key issue now centers on whether the application itself is still operating as intended while that user is interacting with it.

Authentication and transport security can establish who is connecting and protect data in transit, but they don't establish whether the client application handling the session is still trustworthy. A valid session can still originate from a runtime that is being inspected, manipulated, or otherwise interfered with.

Attestation adds evidence about the state of the protected client, so back-end controls do not have to infer trust from credentials or a secure connection alone. In the Trusted Runtime Environment model, attestation carries that runtime assurance to the back end.

Read more: What is RASP and how does it secure web apps vs. mobile apps?

How attestation proof informs access decisions

Taken together, the three questions give ‘proven’ a much more specific meaning.

1. Is this the application you intended to run?

2. Has it been altered while running?

3. Is someone inspecting or controlling the runtime?

Shield for Web continuously validates the client runtime and binds that trust to the protected session. Per-request attestation lets the back end determine whether the client remains in a state that should be trusted. Evidence about runtime integrity can then inform whether the client should be trusted.

The same principle already applies on mobile through Promon Verify™, which authenticates individual API requests and verifies the integrity of the app and its runtime environment. Shield for Web extends this model of verified client trust to browser-based applications, applying the same underlying principle across another application surface.

The important distinction is between evidence and inference. Instead of treating client integrity as one more behavioral clue to be scored, attestation can provide a direct verdict about whether the protected runtime meets the conditions required for trust.

And that is where the next part of the sequence begins. Because proving the client only matters if you decide what should depend on that proof. In the next post, we'll look at why protecting the client is only half the job, and how API access can depend on proof that the client is genuine and untampered.