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.
Scope
Six questions the graph has to answer.
Consequence analysis asks what happens if a function is lost. This asks the question before it: who or what is able to cause that, and how.
Who holds authority over each critical function
Operators, engineers, maintenance, contractors, integrators, OEM support, enterprise administrators, service accounts, applications and — increasingly — agents. Named, not categorised.
How that authority is exercised
The actual path, hop by hop, from the actor to the physical element: console, workstation, protocol, conduit, controller, output card, final element. A path that cannot be drawn cannot be governed.
What level of authority it carries
Reading a value and inhibiting a trip are not the same privilege, and most access models treat them as one. Every edge in the graph is placed on a six-level scale so the difference is visible.
Where authority is transitive
An integrator holds access. The integrator subcontracts. The subcontractor uses a shared credential. Nobody granted the last party anything, and the last party can still download logic.
What is undocumented
The cable added during a turnaround, the default credential left in a packaged skid, the cellular gateway on a vendor's own contract. These appear in the graph because they are walked down and reconciled, not because a system reported them.
What changed since the last snapshot
Authority drifts quietly. A project ends and access does not close. The graph is versioned so the review is a comparison rather than a fresh assessment each time.
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.
Nothing is scanned and nothing is touched. The graph is assembled from configuration and documentation, 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.
Do not use AKTAuthority™ when
- You do not yet know which functions are critical. Establish consequence first — see GoSecure™.
- You want a penetration test. This maps what is permitted, not what an attacker could achieve today.
- You need the access cleaned up rather than mapped. The graph informs that work; it is not that work.
- Your estate is a single small site with one vendor and three named engineers. The answer will fit on a page.
- There is no appetite to revoke anything. An unenforced authority model is a diagram.
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.
Deliverables
What you receive.
Process authority graph
Per critical function: actors, paths, authority levels and physical effects, with the evidence behind each edge referenced.
Unintended authority register
Every path that exists without a decision behind it, with owner, route, level and what it would take to close.
Authority model and decision rights
The intended model: which role should hold which level over which function, and who approves an exception. This is what makes the next review a comparison.
Snapshot baseline for drift review
A versioned baseline and the method to re-run it, so a later review reports what moved instead of starting again.
Engagement process
Scoped per critical function, not per site.
Authority is easiest to map where the consequence is clearest. We start with the functions that matter and extend outward.
Select the functions
Two to four critical functions agreed with operations and engineering. If a consequence analysis already exists, it sets the list and this step is short.
Collect the records
Configuration exports, directory and policy extracts, role tables, access records and change history, under your data-handling rules. Read-only throughout.
Assemble the graph
Records are parsed into actors, paths and authority levels, and contradictions between sources are listed rather than resolved silently.
Walk it down
On site, with your engineers: panels, ports, marshalling and the routes that never appear in a configuration file. This step is where the graph becomes true.
Review and hand over
Findings walked through with the technical team, then an executive session on the unintended set, the intended model and the revocation sequence.
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?
No. Collection is configuration exports, documentation, access records and walkdown, under your escort and your permit process. We make no change and place nothing in line with a control path.
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.
- Read-only collection — no scanning, no agents, no change
- 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.