Is this the right starting point?
Good fit
Organizations that need to understand who can change a critical process and through which route.
What you receive
A process authority graph, unintended authority register, and baseline for future review.
Operating boundary
Records you already hold, OT-native data where it adds evidence, and agreed walkdowns. Access remediation can follow directly through AKTSecure™.
Level of authority
An illustrative graph, not a customer’s estate. Select an actor to trace the path from who they are to what they can physically cause. Note how many arrive at Configure without anyone having decided to grant it.
Watch
Four actors, traced to what they can physically do.
Fifty-three seconds on why an inventory is not an authority map — and why three of the four routes that matter never touch a plant network.
The scale
Six levels, because access lists only have one.
Every edge in the graph carries one of these. It is the difference between a permission model and an operational risk model.
Observe
Can read process values, alarms or engineering data. Cannot change anything — but can see enough to plan, and can leak what the process is doing.
Recommend
Can produce an output a human or a system will act on. An optimisation model, an advisory application, an analytics platform. The authority is real but borrowed.
Command
Can change a setpoint or start and stop equipment within the limits the configuration already allows. The normal authority of an operating console.
Configure
Can change what the limits are — logic, ranges, interlocks, alarm settings, I/O assignment. This is the level most vendor and engineering access actually sits at.
Override
Can force a value, defeat an interlock or place a loop in manual against the process state. Frequently available from more places than anyone expects.
Inhibit
Can suppress or bypass a protective function. The highest level on the scale, the smallest population, and usually the least logged.
Method
Built from records you already hold.
The graph is assembled from configuration and documentation, supported by OT-native tools on the production network where they add evidence, then confirmed against the plant by walkdown.
Where two records disagree, the walkdown decides. The disagreement itself is usually a finding.
- Directory groups and site domain trusts
- Firewall policy sets and routing
- Privileged access records and vault grants
- DCS, SCADA and HMI role tables
- OPC UA and historian access control
- Controller and engineering project configuration
- Engineering share and file permissions
- Remote access accounts, vendor contracts and support agreements
- Management of change records and the SIS audit trail
- Physical walkdown of panels, ports and marshalling
Fit
When this is the right engagement — and when it is not.
Use AKTAuthority™ when
- You already hold an asset inventory and a risk assessment, and the next honest question is who can act.
- Vendor, integrator or OEM access has grown through projects and nobody owns the total picture.
- You are introducing analytics, advisory models or AI agents and need to bound what they can cause.
- A regulator, insurer or board has asked who is able to change the process, and the answer is a shrug.
- An incident or near miss turned on an access path nobody had documented.
- You are consolidating identity between enterprise and plant and want to see what that inherits.
Start with another service when
- You do not yet know which functions are critical. Establish consequence first — see GoSecure™.
- You want to confirm that a specific boundary or control holds under test. That is ControlPulse™, run under written rules of engagement.
- You need the access cleaned up now. We deliver that work through AKTSecure™, and the graph sets its order.
- Nobody yet holds the mandate to revoke access. Establish the decision rights first — see AKTElevate™.
Outcomes
What is different afterwards.
A defensible answer
A named list of who and what can cause each consequential physical action, with the path and the level. It answers the board question in one page and the engineering question in the graph behind it.
The unintended set, separated
Authority that was deliberately granted is separated from authority that arrived by inheritance, convenience or an expired project. The second list is short and usually actionable within a quarter.
A bound for Industrial AI
Before an agent or advisory model is connected, its ceiling on the scale is decided and enforced rather than discovered later. Read access that feeds an approved action is still authority.
A baseline that can be re-run
The graph is a snapshot. The value compounds when the second one is taken and the drift is visible without repeating the whole exercise.
Questions we are actually asked
What gets asked before this is commissioned.
Is this a product we license?
No. It is a consulting engagement. InnovAKT maintains its own ingest workbench to assemble and compare graphs, and that tooling is under active development — it is how our consultants work, not something you buy, install or run.
If you would rather build the capability in house, the authority model and the collection method are part of the handover, and the InnovAKT Academy track covers the analysis.
How is this different from a privileged access review?
A privileged access review asks who holds elevated rights in a system. This asks what physical action a party can cause, through any route, including routes that involve no elevated rights at all.
An account with no administrative privilege anywhere can still hold Command authority over a unit if it can reach an operating console. Those two reviews find different things, and the second one is the one operations cares about.
Does anything touch the control network?
Only where you agree. Most of the graph comes from configuration exports, documentation, access records and walkdown, under your escort and your permit process. Where OT-native tools add live evidence, they connect at span or tap points under your change control. We make no change, place nothing in line with a control path, and cover safety systems from records only.
We have thousands of accounts. Is this tractable?
Yes, because the graph is scoped by consequence rather than by population. Two to four critical functions typically resolve to a few dozen actors with real authority over them, and that is the set worth arguing about.
The accounts that cannot reach a consequential function are recorded as out of scope, which is itself a useful statement to be able to make.
Where does AI fit?
An advisory model sits at Recommend. That sounds harmless until you look at what happens to its output — if a recommendation is accepted by an operator who has no independent way to check it, the effective authority is the operator's, exercised on the model's judgement.
The graph records that explicitly, which is what allows a sensible ceiling to be set before the integration is built rather than after.
How often should it be re-run?
Annually for a stable estate, and after any event that changes who can act: a major project, a vendor change, an identity consolidation, a turnaround, an acquisition. The re-run is a fraction of the first engagement because it is a comparison.
Next step
Start with one critical function.
One function, one graph. It establishes the method and the effort, and it almost always surfaces a path that changes how the rest of the programme is scoped.
- OT-native collection — records first, production-network data where it adds evidence, under your change control
- Scoped by consequence, not by account population
- Walked down with your engineers before anything is reported
- Baseline versioned so the next review is a comparison
Questions buyers ask
The three things we are asked before we start.
What is AKTAuthority™?
AKTAuthority™ is InnovAKT's review of who and what holds authority over an industrial control estate: identity, privileged access, remote access, vendor and third-party connections, and the engineering workstations from which changes are actually made. It answers a question most organizations cannot answer confidently — who can change the process, from where, and who approved it.
Why is vendor and remote access the focus of an authority review?
Because in most industrial environments it is the most capable path into the process and the least governed. Integrators, OEMs and service partners often hold standing access granted years ago, under agreements that predate the current security program, through tools the OT team did not select. AKTAuthority™ makes that inventory explicit and gives it an owner.
What does AKTAuthority™ deliver?
A documented access model for the estate — accounts, roles, paths, brokers and third parties — the gaps ranked by what each would allow someone to do to the process, and a remediation sequence that respects existing vendor agreements and maintenance obligations rather than assuming they can be torn up.