OT Credential Abuse: They Logged In. They Didn’t Break In
✨ NEW GUIDE -- CIP-015 Compliance Guide helps industrial operators prepare for INSM requirements View the Guide X
Search
Blog
Contact Us
FREE PCAP Analyzer
Company
About EmberOT
Leadership
Our Partners
Events
Product
EmberOT In-Depth
Asset Inventory & Insights
Vulnerability & Risk
Detection
PCAP Analyzer Free Tool
Firewatch Assessment
IgniteOnsite
Resources
Resources
Blog
Documents
Podcasts
Newsroom
ICS Vulnerability Report
CIP-015 Compliance Guide
Solutions
Solutions
Oil & Gas
Electric Utilities
Industrial IoT
Manufacturing
Rural Co-ops
Request a Demo
Company
About EmberOT
Leadership
Our Partners
Events
Product
EmberOT In-Depth
Asset Inventory & Insights
Vulnerability & Risk
Detection
PCAP Analyzer Free Tool
Firewatch Assessment
IgniteOnsite
Resources
Resources
Blog
Documents
Podcasts
Newsroom
ICS Vulnerability Report
CIP-015 Compliance Guide
Solutions
Solutions
Oil & Gas
Electric Utilities
Industrial IoT
Manufacturing
Rural Co-ops
Request a Demo
Home1 > Resources2 > Blog3 > OT Credential Abuse: They Logged In. They Didn’t Break In
Blog
OT Credential Abuse: They Logged In. They Didn’t Break In
The dangerous intruder in OT today isn’t bombing the wall. They walked through the front door with a key that shouldn’t be in their hand.
OT credential abuse happens when an attacker uses a legitimate account, vendor connection, remote-access pathway, or service credential to enter an industrial environment without exploiting a software vulnerability. The login looks authorized, but the behavior afterward does not. Here’s why your scanner never sees it, and what does.
Half of dungeon design in the old Zelda games is locks and keys. You find a small key, you open a locked door, you go deeper. The whole system works on one quiet assumption: the key belongs to the person holding it. Nobody designed those dungeons for an intruder who already had a copy.
That assumption is exactly where OT security is getting hurt right now. The image we carry of an attacker is someone smashing through a barrier, exploiting a flaw, breaking something to get in. The reality across the threat data is quieter and more uncomfortable. More and more, attackers don’t break in at all. They log in. They use a valid credential, a vendor’s remote-access path, a service account that was set up years ago and never retired. As one summary of the landscape put it, threat actors increasingly exploit valid credentials rather than software flaws, so they log in rather than break in.
The door wasn’t forced. It was opened, by a key, exactly the way it was designed to be.
Why OT Credential Abuse Often Starts with Vendor Access
The keys that matter most in OT are rarely the ones your own team holds. They’re the ones you handed out. Compromised vendor credentials, poisoned software updates, and abused remote-access connections show up again and again as the leading way into industrial environments. That makes sense the moment you think about how OT actually runs. Integrators, OEMs, and maintenance vendors need access to keep the process healthy, and that access is legitimate, necessary, and standing. It is a key to your dungeon held by someone outside your walls.
We’ve written before about why the vendor relationship in OT is so different. Every legitimate key is a key that can be copied, stolen, or misused, and when it is, nothing about the entry looks wrong. The lock wasn’t picked. The window is intact. The logs say a known account opened a known door at a plausible time.
This is what makes credential abuse so effective in OT specifically. The whole environment is built on trust between known parties. An attacker using a real key isn’t triggering the trust model. They are using it.
Why Vulnerability Scanners Miss OT Credential Abuse
Here is why so much of our tooling misses this entirely.
A vulnerability scanner is built to find broken things. Unpatched software, exposed services, weak configurations. It is looking for the smashed window and the forced lock. That is genuinely useful work, and it is also completely blind to a valid key in the wrong hand. There is no CVE for a stolen credential. There is no patch for a vendor account being used by someone who is not the vendor. The flaw, if you can even call it that, is that the system did exactly what it was told by something that looked authorized.
If your security program is organized around finding and fixing vulnerabilities, the entire category of log-in attacks slips through the gap. You can be fully patched, fully scored, fully compliant on paper, and still have an intruder walking your halls with a borrowed key.
You Know the Dungeon. They Don’t.
So how do you catch a key you cannot un-issue, used by a hand you cannot see at the door?
You stop watching the door and start watching what happens after it opens.
A stolen key gets someone into the dungeon. It doesn’t...