The attacker with the best chance of damaging your process already has a badge, a login, and a working knowledge of your P&IDs. Insider threat is the OT risk that perimeter security cannot touch: firewalls, outbound-only gateways, and segmentation all assume the danger is outside - but a disgruntled contractor, a careless operator sharing a login, or an engineer whose credentials were phished starts on the trusted side of every one of those controls. This guide covers the practical defenses that actually work in industrial environments: least-privilege roles, separation of duties on control actions, quarterly access reviews, same-day offboarding, tamper-evident audit trails, and detection tuned for insider behavior.
One of 60+ guides in our SCADA security and compliance series.
In IT, an insider who goes bad leaks documents or deletes files. In OT, an insider can open a valve, silence an alarm, or change a shutdown setpoint - the consequences are physical, and they can be irreversible. The canonical public case is still Maroochy Shire in 2000: a former contractor for an Australian sewage utility, angry after being turned down for a job, used insider knowledge and radio equipment to issue commands to pumping stations dozens of times, releasing raw sewage into parks and waterways. Every control he defeated was a perimeter control. What was missing were the insider controls: individual accountability, revoked access, and an audit trail that could attribute commands to a person.
Insiders are dangerous in industrial environments for three structural reasons. First, they start inside the perimeter - segmentation, firewalls, and gateway architecture do not apply to someone with a valid login. Second, they have process knowledge: they know which setpoint matters, which alarm the on-call operator ignores, and where the manual bypass is. Third, OT culture historically optimizes for availability and convenience - shared operator logins, passwords taped to HMIs, contractor accounts that outlive the contract - all of which turn one insider's bad day into an unattributable incident.
None of this means you should treat your workforce as suspects. It means your architecture should assume that any single account can eventually be misused - by its owner or by someone who stole it - and be built so that one misused account has limited blast radius and leaves indelible evidence.
Security teams - and CISA's Insider Threat Mitigation Guide - distinguish insider profiles along intent, because each one calls for different controls:
The encouraging news: the same small set of controls mitigates all three profiles. Here is how they map:
| Control | Malicious Insider | Negligent Insider | Compromised Account |
|---|---|---|---|
| Named accounts + MFA (no shared logins) | Every action attributable; deterrence | Removes the shared-login habit entirely | MFA blocks most credential theft outright |
| Least-privilege roles, scoped by site | Limits blast radius to their own scope | Can't accidentally change what they can't touch | Stolen account only reaches its own scope |
| Separation of duties + approval gates on control | One person can't act alone on critical changes | Forces a second look before risky changes | Attacker needs two accounts, not one |
| Immutable, chained audit trail | Evidence survives attempts to cover tracks | Undocumented changes become visible | Full forensic timeline of the intrusion |
| Quarterly access reviews + fast offboarding | Ex-employees and stale grants removed | Role sprawl trimmed before it causes harm | Dormant accounts - prime targets - closed |
| Behavioral detection + alerting | Off-hours and out-of-scope activity flagged | Repeated mistakes surface as patterns | Privilege probes and anomalies trigger alerts |
Least privilege is the single highest-leverage insider control, and in SCADA it has to operate on three axes at once: who (the role), where (the site), and what (the specific control action). A role hierarchy alone is not enough - a platform that gives every "operator" control over every site has quietly granted a single account the ability to disturb your entire operation.
A mature implementation looks like this. Every person gets a named account with one of a small set of roles - Merobix uses six: viewer, operator, manager, engineer, admin, and superadmin - and site-level authorization restricts each account to the facilities it actually works. On the control path, the platform goes further: only tags explicitly configured as writable can be written at all, every setpoint is validated against configured bounds before dispatch, and control actions require both the right role and, where configured, a competency check. An account that has no business writing to a compressor station cannot write to it, no matter what its owner intends - and site ownership is checked server-side before any operational or admin action, so the restriction is not just a hidden button in the UI.
Practical rules for assigning roles:
Separation of duties means no single person can both initiate and approve a consequential change. Finance teams have run on this principle for a century - and it is codified, alongside least privilege, in the control catalog of NIST SP 800-53 Rev. 5 - but control systems are only now catching up. In OT, the pattern shows up in a few places: the engineer who builds a configuration change should not be the only one who can push it to production; a change that affects a safety-relevant setpoint should pass through a management-of-change (MOC) review; and restarting a unit after work should require a pre-startup safety review (PSSR) sign-off from someone other than the person who did the work.
Software can enforce what policy alone cannot. Merobix supports MOC and pre-startup safety review gates on control workflows where configured, and applies step-up authentication to high-risk actions such as permit signing - the user must re-authenticate at the moment of the action, which defeats both the walk-up-to-an-unlocked-terminal problem and a hijacked session. Commands themselves are tracked through explicit states - pending, applied, verified, failed, expired - with idempotency protection against duplicates and read-back verification where the protocol supports it, so "I sent it twice by accident" and "I never sent that" are both answerable from the record. For the full picture of safe setpoint writes, see our guide to remote control security in SCADA.
Access rot is gradual and invisible. People join and get access quickly (business pressure guarantees that part works). People change roles and keep their old permissions - nobody's job is to take access away. People leave, and their accounts linger because deprovisioning spans three systems and two departments. Eighteen months later, your SCADA platform has accounts for two ex-employees, a contractor whose project ended last year, and an operations manager who can still write setpoints from a job she left in the spring. Every one of those is an insider-threat surface.
The fix is a quarterly access review: walk the complete user list and answer three questions per account - does this person still work here, does the role still match the job, and has the account actually been used recently? Remove or downgrade anything that fails. Document the review; ISA/IEC 62443, the NERC CIP standards, and virtually every cyber-insurance questionnaire expect periodic, evidenced access reviews. A platform with a small, legible role model and per-site scoping makes the review a 30-minute task rather than a spreadsheet archaeology project. We cover the full joiner-mover-leaver workflow in our SCADA user access review guide.
Ask yourself one question: if you terminated an employee this afternoon, how long would it take to remove every access path they have - and would you be sure you got them all? For many operators the honest answers are "days" and "no." Termination is precisely the moment when a malicious-insider risk peaks, and it is also when a compromised-account risk begins: dormant accounts of departed staff are prime targets because nobody notices when they log in.
A complete OT offboarding checklist, executed the same day:
Every control above reduces the odds of an insider incident; the audit trail is what tells you the truth when one happens anyway. For insider scenarios, an ordinary log is not enough - the most capable insider is an administrator, and an administrator can usually edit an ordinary log. The requirement is a tamper-evident trail: records of sensitive events that are immutable and cryptographically chained, so that deleting or altering an entry breaks the chain and becomes detectable. Merobix writes immutable, chained audit records for sensitive events and provides admin audit-chain verification, so even a privileged account cannot silently rewrite history - the property auditors and forensic investigators look for first.
Coverage matters as much as integrity. The trail should capture logins and failed logins, permission changes, configuration changes, every command and its acknowledgment, and alarm interactions - each attributed to a named individual with a timestamp. That is what turns "the pressure setpoint changed sometime last week" into "user, time, source, old value, new value." For what auditors specifically expect, see our deep dive on SCADA audit trails and immutable logs.
Insider incidents rarely begin with the damaging act. They begin with reconnaissance: trying screens outside one's role, probing for permissions, logging in at unusual hours, failing authentication repeatedly on someone else's account. Each attempt is a signal - if anything is listening.
This is where runtime detection earns its keep. Merobix monitors for exactly these patterns - privilege probes, repeated authentication failures, suspicious control activity, and denied cross-tenant access attempts - and pushes security notifications through a durable outbox to email, SMS, webhook, or your SIEM, with retry and dead-letter handling so an alert is not silently lost in transit. Brute-force detection with persistent account lockout closes off password guessing against your users' accounts. The design goal is simple: the gap between "an account started behaving strangely" and "a human found out" should be minutes, not months. Our guide to SCADA threat detection and SIEM integration covers how to wire these signals into your broader security operation.
Key takeaway: You cannot screen, train, or trust your way out of insider risk - you architect your way out. Named accounts with MFA, roles scoped to site and control action, separation of duties on consequential changes, quarterly access reviews, same-day offboarding, and an audit trail that even an administrator cannot rewrite: together they make any single account - misused by its owner or stolen by an outsider - limited in blast radius and impossible to hide. The Merobix security architecture implements this stack end to end, and you can pressure-test it against your own scenarios in a live demo.
An insider threat in industrial control systems is any risk that originates from someone with legitimate access - an employee, contractor, integrator, or vendor - rather than an external attacker breaking in. It covers three profiles: malicious insiders who deliberately misuse access, negligent insiders who cause harm through shortcuts like shared logins or unauthorized changes, and compromised insiders whose valid credentials are stolen and used by an outside attacker. Because insiders start on the trusted side of the firewall, perimeter defenses do little against them; the effective controls are least-privilege roles, separation of duties on control actions, immutable audit trails, and fast offboarding.
Least privilege in SCADA means every user gets a named account with the narrowest role that still lets them do their job - and permissions are scoped by site, by screen, and by control action, not granted platform-wide. A manager who reviews trends gets a read-only role; an operator gets control permissions only for the sites they run; setpoint writes are limited to tags explicitly configured as writable, with bounds checking on values. Merobix implements this with six roles (viewer, operator, manager, engineer, admin, superadmin), site-level authorization, explicit writable-tag configuration, and role and competency checks before any control action is dispatched.
Quarterly access reviews are the widely accepted baseline for SCADA and OT systems, with an additional review triggered by every role change, departure, or contractor engagement ending. A review walks the full user list and asks three questions per account: does this person still work here, does their role still match their job, and have they actually used this access recently. Dormant accounts and role sprawl - permissions accumulated through job changes but never removed - are the two most common findings. Frameworks such as IEC 62443 and NERC CIP expect documented, periodic access reviews, and cyber-insurance questionnaires increasingly ask for evidence of them.
An OT offboarding checklist should revoke every access path the person had, on the day they leave: disable their SCADA account, force logout of all active sessions on all devices, revoke any personal API keys, rotate any shared or device credentials they knew, collect badges and hardware tokens, and remove VPN or remote-access entitlements. It should also include a check for accounts on standalone equipment - local HMI logins and PLC passwords that live outside central identity management. Platforms with session revocation and logout-everywhere, API key lifecycle management, and named accounts for every user make this a minutes-long task instead of a forensic project.
Yes - but only if the audit trail is complete, attributed, and tamper-evident. Detection requires that every login, configuration change, setpoint write, and acknowledgment is recorded against a named individual account, so unusual patterns stand out: control actions outside someone's normal sites or hours, repeated permission-denied attempts that indicate privilege probing, or bursts of failed logins. Tamper evidence matters because a capable insider - especially an administrator - will try to edit the log. Immutable, cryptographically chained audit records make deletion or modification detectable, which is why auditors and forensics teams treat them as the minimum standard for control systems.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Six scoped roles, site-level authorization, step-up authentication on high-risk actions, and an audit chain no insider can rewrite - see how Merobix contains insider risk by architecture.