Service
Privilege and identity mapping
We build a living map of human, service, and vendor identities that can issue or approve control actions in the IoT application stack.
Privilege mapping starts with the identity sources the control application actually trusts: local users on the HMI, LDAP or Entra groups, API keys in gateways, MQTT ACLs, and the accounts vendors use for “temporary” remote support.
We reconcile those lists with who still works at the site. Former technicians, shared “operator” passwords on a laminated card, and integration accounts created for a one-off migration show up more often than novel exploits.
For each identity we record: what it can read, what it can write, where those rights are enforced (app, broker, controller), and whether the action is logged with a person attached. We flag break-glass accounts that have no owner and certificates that outlive the contractor who installed them.
The output is a privilege matrix operations can keep, plus a recommended joiners-movers-leavers path that does not assume the plant runs a full IAM programme.