We built a desktop tool in 2024. Here is the boring reason why.

Article 2 of Field Notes, a series on what we learned selling an offline SAP access-risk tool.

Every piece of advice I received said build it as a service. Recurring revenue, one codebase, ship on Tuesday, see how everyone uses it. All of that is true and none of it survived contact with the actual working conditions of the people who needed the tool.

The decision to build MTC Skopos as a signed portable executable came from a problem I had personally, repeatedly, for years, on client engagements. It is not a philosophical position about the cloud. It is closer to plumbing.

The consultant's laptop problem

Here is the situation any external SAP security consultant will recognise.

You arrive at a client. You are handed a managed laptop from their IT department, or credentials to a VDI session, or a jump host. Your own machine is not allowed on their network and their SAP systems are not reachable from it. This is correct security practice and I would insist on it if I were them.

Now try to do your job. You need to run an authorization analysis. The tool you want requires installation. Installation requires local administrator rights, which you do not have and will not be given. Even if the software could install per-user, the endpoint protection blocks unrecognised executables, and getting an exception means raising a request with a security team who have never heard of you, for a product they have never heard of, on behalf of a project they may not know about.

In my experience that request takes between three weeks and never. Meanwhile the engagement is six weeks long.

So what everyone actually does is export the tables to Excel and work by hand. I have watched genuinely excellent consultants spend two days doing VLOOKUPs against AGR_1251, and the honest description of what comes out is not an SoD analysis. It is a transaction code cross-reference. The object and field level evaluation that determines whether a conflict is real never happens, because doing it manually across a few thousand role assignments is not feasible in the time available.

The client pays for two days of work and receives something weaker than what they asked for. Nobody involved is happy about it.

What "portable and signed" solves in practice

A single executable that needs no installer sidesteps most of that chain. No administrator rights, no MSI, no registry writes, no services, nothing to uninstall afterwards. It runs from the user profile or from a folder on the VDI.

The signing is the part people underestimate. An unsigned binary is stopped by SmartScreen, flagged by reputation-based endpoint protection, and blocked outright by AppLocker or WDAC policies. A code signature from a recognised CA with an established publisher identity means the file has a verifiable origin, and, more importantly, means a client security team can write a publisher-based allow rule once instead of hash-listing a file they have to re-approve at every release. Publishing a SHA-256 checksum alongside each release covers the teams who prefer to pin the exact build.

We went through the reputation build-up process for this and it was tedious. It was also the difference between a tool that can be used at a client and a tool that cannot.

There is a secondary benefit that I did not anticipate. Because nothing is installed and nothing persists, the conversation with the client's security team is short. There is no new server, no firewall rule, no service account in their SAP system, no tenant to provision, no data processing agreement to negotiate. The change footprint is a file that runs and then does not.

Where the market turned out to agree

I expected to spend a lot of time defending a desktop application in a SaaS market. Mostly I did not have to. Two things kept coming up instead.

The first is that a portion of this market never wanted a platform. They wanted a tool. There is a real difference: a platform requires a programme, an owner, an integration, and a budget line, and it will be reviewed against three competitors over nine months. A tool is something a specialist downloads on a Tuesday and uses on Wednesday. When the buyer's problem is episodic deep analysis rather than continuous monitoring, the platform overhead buys them nothing and costs them a year.

I heard versions of "we just want something that runs" often enough that I stopped treating it as a niche preference.

The second is displacement. A number of organisations are looking at replacing a commercial SoD product they have used for years, in some cases because the product is being wound down, in others because of cost or lack of visibility into the rule logic. Those buyers are not evaluating a category for the first time. They know exactly what they need, they can describe their current workflow precisely, and they are the easiest evaluations to run because the requirements arrive fully formed. They also tend to want the replacement to work the same way the original did, which for several of them meant locally.

Where SaaS wins, and I would say so to a prospect

I do not think we made a universally correct choice. There are things a hosted platform does that a local tool structurally cannot.

Continuous monitoring is the clearest one. If you need risk analysis running automatically against a live landscape, with alerting when a provisioning action introduces a conflict, that requires a connected system. A desktop tool analyses a point-in-time extract and it always will.

Workflow is the second. Access request approval, mitigating control assignment with owner sign-off, periodic recertification campaigns: these need a shared system of record with identities and notifications. A single-user executable is the wrong shape for that entirely.

Multi-user collaboration is the third. Several people working on the same remediation plan concurrently is a server problem.

When a prospect describes those needs, the honest answer is that they want a platform, possibly the one they already own. I come back to this in article four of this series, on why organisations that already own SAP GRC keep shopping anyway.

The general point

I do not think local software is making a comeback because of any broad trend. I think a specific set of working conditions was ignored while the industry moved to a delivery model that suited vendors better than it suited some users.

Consultants working inside locked-down client environments are one of those groups. Security teams handling data they are not permitted to send anywhere are another. Both were being served by tools designed for a network topology they do not have.

What they fall back to when the tool is unavailable is not a smaller version of the analysis. It is a different and much weaker thing. A spreadsheet can compare transaction code assignments. It cannot evaluate authorization objects and field values, which is where most real conflicts actually live. It cannot resolve derived roles against their org level assignments, expand composite roles, or reconcile a user's effective authorizations across everything assigned to them. Anyone who has tried knows the result is a list that is simultaneously too long, because it flags conflicts that the object level restrictions already prevent, and too short, because it misses conflicts that exist below the transaction.

That is the real cost of a tool that will not run in the client's environment. Not a slower analysis. A report that looks like an analysis, gets signed off, and is wrong in both directions.

Next in this series: how to tell a compliance-driven buyer from an efficiency-driven one before you spend three months on them.