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 we 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 and work outside the system, and there are two versions of that.

The common one is a spreadsheet. VLOOKUPs against AGR_1251, or a Power Query model, or an Access database once the extract outgrows Excel, which happens early: AGR_1251 on a mid-size system runs well past a million rows, so the row limit arrives at exactly the point the analysis starts to matter. What comes out of that route is a transaction code cross-reference rather than an SoD analysis. The object and field level evaluation that determines whether a conflict is actually real never happens, and neither does anything needing execution data, derived role resolution against org values, or a remediation proposal you could defend six months later.

The other version is to write the analysis properly, in SQL, in Python, or as an Alteryx workflow. That is what I did, and it does reach object and field level with an answer you can stand behind.

It also costs days, every time. The query is built around one client's naming conventions and one extract's column layout, so the next engagement starts from nothing. Nobody else can re-run it. When a control owner challenges a finding six months later, the analysis that produced it lives on one laptop in a form only its author can explain, which is a poor answer to give an auditor. The client pays for a correct result and receives no reusable asset, and neither does the consultant.

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.

If it is not SaaS, why is it a subscription?

This comes up in almost every commercial conversation, usually from someone in procurement rather than from the security team, and it is a fair challenge. There is no tenant to operate, no infrastructure bill, nothing running on our side. So what is the annual fee paying for?

Not hosting, obviously. It pays for what comes next.

An SoD ruleset is not a static asset. SAP keeps shipping transactions, Fiori apps, authorization objects and new business functions, and a ruleset that is not maintained drifts out of alignment with the systems it is supposed to be analysing. That maintenance is continuous and it is most of the reason the model is recurring rather than one-off. The rest is development and support.

The part I would want to know as a buyer is where the new work lands. Everything we ship goes into the build our customers already run: new checks, new analyses, performance work, changes to the ruleset. There is no version upgrade fee and no conversation about being on release 2 when release 3 is out. When a capability turns out to be substantial enough to get its own line on the price list, customers who were already subscribed get it inside what they already pay rather than as an upsell. That is deliberate. A customer who bought in year one carried more risk than a customer who buys today, and pricing them upwards for that would be an odd way to say thank you.

It also cuts against us in a way I think is healthy. A subscription with no hosting behind it has to be re-earned every twelve months on the strength of the product alone. If we stop shipping, the renewal conversation gets very short, and it should.

The other half of the answer is what happens if we stop entirely, which is a different question and gets its own article at the end of this series.

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 most teams 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 or a Power Query model 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.