A desktop application is code running on a machine its owner controls, which makes every check inside it advice rather than enforcement. B-52 works the package you distribute — what it contains, what it writes to the machine — and then works the protocol, because the finding is never that a check can be removed. It is that the server relied on it.
Class and boundary
A thick client is anything that runs locally and talks to a server. The runtime changes what can be recovered from it; it does not change the question being asked.
Managed and unmanaged binaries: what the assembly gives up when it is decompiled, what the process holds while it runs, and what the installer put on disk and with which permissions.
Bytecode that decompiles very close to source, archives whose signature is checked once and trusted thereafter, and configuration shipped alongside the application rather than fetched.
A desktop application built out of web technology, where the renderer can reach the operating system and the package is a filesystem that anybody can open and read.
What the client sends and what the server trusts it for; and what is cached, logged, written to the registry or left in a temporary file, including what is still there after a logout.
The boundary
Each of these answers a question this class does not, which is why they are scoped apart rather than folded in.
Where that interface has consumers of its own it is the API class, with its own routes and a credential for each role. This class asks what the server accepts from a modified client; that one asks what it accepts from anybody.
AdjacentThe host and the network around it are the internal network class. A thick client assessment answers a question neither of them asks: what this application can be made to do once somebody else controls the computer running it.
AdjacentReading the repository is a different piece of work with a different denominator, and the two are strongest bought together — one says what the package gives up, the other says why.
Out of scope for the platform entirely, in every class. It is the only exclusion, and it is stated the same way everywhere on this site.
Who this page is for
Both are answered here. Where they should start is not the same.
By phase
The phase names are the platform’s. On this class two of them run against different material — one against the package, one against the wire — and the findings come from comparing the two.
| Phase | What enters | What leaves |
|---|---|---|
| Discovery | The installer or package exactly as you distribute it. | What it writes to the machine, what it registers, what it talks to, and which runtime it was built on — read from the artefact rather than from a document describing it. |
| Planning | The surface discovery found. | A test plan for this client: which local artefacts, which protocol operations, which trust assumptions. Signed off in writing before anything is exercised. |
| Scanning | The binary, and the traffic it produces in normal use. | Candidates from both. Nothing leaves this phase as a finding, and nothing is reported from it. |
| Exploitation | A candidate, and a client that can be made to behave differently. | A finding where the server accepted what a modified client sent, and a drop where it did not. On this class that distinction is the whole assessment. |
| Reporting | Confirmed findings. | The artefact or the exchange that proved each one, with steps written for a machine your engineer controls. |
| QA | The finished report. | A gate that can send it back to reporting. It is where a client-side control that was only ever advisory is separated from a server-side control that failed. |
Discovery
Planning
Scanning
Exploitation
Reporting
QA
The question underneath
Almost every thick client finding reduces to one question: what does the server believe because the client told it so? The licence state, the role, the price, the account number, the amount — each of them is checked somewhere in the application, and every one of those checks is running on hardware the user owns. Establishing that a check can be removed is easy, and on its own it is not a finding; it is a property of desktop software. Establishing that removing it changes what the server does is the finding. That is why this class is worked against the protocol as well as against the binary, and why a report that only lists what the package gives up has stopped one step short.
The boundary
The same three as every coverage class. On this one most of them barely arise, because the assessment runs on a machine we control — and the block below says what happens when that is not enough.
| State | What it means | What follows |
|---|---|---|
| Destructive or state-changing actions | Anything that creates, alters or removes a record on the live server behind the client, rather than demonstrating that a modified client could have made it do so. | Stops and waits, in writing. |
| Live credentials or real customer data | A desktop client caches more than most people expect, and what is on the disk of a machine a real user has logged into is real data. Test accounts on a test machine avoid this entirely. | Stops and waits, in writing. |
| Persistence and movement past the entry host | Where a client finding yields execution on the machine, going any further is an internal network question rather than an application one. | Stops and waits, in writing. |
| Everything else inside the authorised scope Terminal | Unpacking and analysing the distributed application, observing and modifying what it sends, reading what it writes locally, chaining and reporting. | Runs without asking. |
Where the assessment runs
That arrangement is why the gates above rarely come up on this class: there is no real user profile to read and no production record to alter. It matters for a second reason too — a finding established on a clean machine with a known build is a finding your engineer can reproduce, and a finding recovered from somebody’s working laptop usually is not. Where something can only be established on a machine that has been in real use, that is a scoping conversation held beforehand rather than a decision taken during a run.
What the assessment reaches
Two of these are the class. The rest are the ones that turn a client finding into a server one.
| Class | What it looks like in a real application |
|---|---|
| Checks the server relies on the client to make | A restriction enforced in the interface and nowhere else — a disabled control, a role the menu hides, a value the form will not let you type. Removing it is trivial. Whether the server notices is the finding. |
| The protocol between client and server | What the client sends, what the server will accept from it, and whether a message the official client would never construct is honoured anyway. |
| What the package gives up | Endpoints, credentials, keys and logic recovered from the distributed artefact. Managed and bytecode runtimes give up nearly everything; native builds give up less, and seldom nothing. |
| Local storage and leftover artefacts | Configuration, caches, logs, registry values and temporary files: what is written, in what form, readable by which accounts on the machine, and what survives a logout. |
| Credentials and sessions on the device | Where a token or a password lives between sessions, and what protects it beyond whatever the operating system does by default. |
| Update and integrity | How the application decides an update is genuine, where it fetches one from, and what it does when that decision cannot be made. |
| What was bundled with it | Third-party components inside the package, at the versions actually shipped rather than the versions the build was meant to pin. |
| Privilege at install and at run | What the installer grants, what the application asks for afterwards, and whether either is more than the work it does requires. |
Checks the server relies on the client to make
The protocol between client and server
What the package gives up
Local storage and leftover artefacts
Credentials and sessions on the device
Update and integrity
What was bundled with it
Privilege at install and at run
Three of them, worked
Each of these is unremarkable on one side and decisive when the two sides are put together.
Methodology
There is no desktop counterpart to the mobile testing standard. Rather than cite something that does not fit, the methodology is assembled from the general verification standard and the report names which requirement each finding fails.
| Standard | Version | What it carries here |
|---|---|---|
| OWASP ASVS | 5.0.0, May 2025. 17 categories | The verification requirement a finding fails. Most of the standard is about what the server must not delegate, which is exactly the question this class asks. |
| The first major release in six years; 4.0.3 is superseded. | ||
| CWE | Current | The weakness identifier on every finding, so a desktop defect can be tracked in the same register as a web one. |
| NIST SP 800-115 | Final, September 2008. Read 2026-09-13 | The structure of a technical assessment, and the handling rules for what the attack phase turns up. |
| Still the current edition: it has been neither withdrawn nor superseded. | ||
| CVSS | v4.0, November 2023. Read 2026-09-13 | The severity vector on every finding, so your team can recompute against its own environmental metrics instead of taking ours. |
OWASP ASVS
The first major release in six years; 4.0.3 is superseded.
CWE
NIST SP 800-115
Still the current edition: it has been neither withdrawn nor superseded.
CVSS
Before a run starts
Deliberately excluded
Per finding
For a protocol finding, the message as sent and the response as returned. For a local finding, the file, key or value itself — with its path and the accounts that can read it.
Platform, runtime and application version. A desktop finding that does not say which build it was found on cannot be retested against the build that claims to fix it.
Written for a machine your engineer controls, and described by what has to be done rather than by which tool we happened to reach for.
Severity with its CVSS v4.0 vector, the CWE, and the ASVS requirement the defect fails.
In the model with no auditor in it, findings pass a second automated gate before they are reported. It is a check on top of the exploit, not a substitute for it.
Where this sits
No vendor is named here — these are categories of work. The second column is the usual substitute, and it is the one worth being precise about.
| Endpoint protection | Testing the server only | A scheduled desktop engagement | B-52 | |
|---|---|---|---|---|
| What it is looking at | Known-malicious behaviour on the machine. | The interface the client happens to call. | The client and the protocol, for the days bought. | The distributed package, what it writes locally, and everything it sends. |
| Sees a check that exists only in the client | No. It is not a defect in its terms. | Only where a tester thought to send what the official client would not. | Yes. | Yes, and then establishes whether the server relied on it. |
| Sees what is left on the machine after use | Not as a finding. | No. | Yes. | Yes, artefact by artefact, with the accounts that can read each one. |
| Coverage of the class | Not a testing product. | Excludes the client entirely. | Whatever was scoped into the days. | Windows native, Java desktop, Electron, and the protocol and local storage in each. |
| What a finding costs you to confirm | Not applicable. | Usually nothing; it was proved. | Usually nothing; it was proved. | Nothing. The artefact or the exchange arrives with it. |
| Whose signature it carries | None. | The firm that ran it. | The firm that ran it. | Security Brigade’s, in the two models with an empanelled auditor in them. |
What it is looking at
Sees a check that exists only in the client
Sees what is left on the machine after use
Coverage of the class
What a finding costs you to confirm
Whose signature it carries
On testing the server instead
Assessing the server the client calls is worth doing, and it is frequently all that gets done. What it leaves out is everything that is only true because a desktop application exists: what the installer wrote, what the package contains, what is cached after a session — and above all, what the server will accept from a client that has been changed. A test that only ever sends what the official client sends is measuring the client’s good manners rather than the server’s checks, and the two are not the same measurement.
Filing
Coverage is identical across the three delivery models. What differs is whose signature the report carries.
Annexure L of the circular dated 20 August 2024 names applications alongside infrastructure, APIs, operating systems, databases and cloud. A trading terminal or a branch application is an application. Read 2026-09-08.
Bespoke and custom software is reviewed prior to release into production to identify and correct potential coding vulnerabilities. A desktop client written for you is bespoke software. Requirement text read 2026-09-13.
Each finding carries through open, fixed, retested and closed, and closes on a retest against the build that claims to fix it — which is why the finding records the build it was found on.
Where the report goes to a regulator or an assessor, start with the expert-verified model.
Worked example
Four steps, and the first three are things a desktop application does by its nature. The fourth is the defect.
| Link | Alone | In sequence |
|---|---|---|
| 1 A package anybody can open | An installer, unpacked. | It carries the configuration the application ships with. |
| 2 An operation the interface never offers | A string in a configuration file. | It is a server operation the user interface draws for nobody. |
| 3 A message the official client would not send | A well-formed request. | It calls that operation, from an account that should not reach it. |
| 4 A server that agreed | A success response. | The check that should have stopped it only ever existed in the client. |
Measured
The benchmark put B-52 and Security Brigade’s expert assessment team on the same targets at the same time and pooled what both produced into one set, each item counted once. B-52 reached 90–95% of that pooled set, and part of what it reached the team had not — which is why the pool is larger than either side’s own output, and why the expert-verified model is offered as a real choice rather than as a compromise.
One scan is one application or target, and the entry tier is $500. Send the package as you distribute it — a build with the protections taken out answers a question nobody is asking.