How to stop treating OEM software like a security liability

COMMENTARY: Somewhere right now, an IT admin at a manufacturing company will type local admin credentials into a workstation on the shop floor so a machine operator can update software.

They will do this again in an hour for a different machine. And again after lunch. By the end of the week, they’ll have handed out full admin access to dozens of endpoints, each one an open door for ransomware. It’s not carelessness. It’s the reality of using specialized legacy OEM software in 2026.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

Manufacturers, auto dealerships, and construction firms all share the same problem: the software that keeps operations running demands admin-level privileges that no security framework would ever recommend granting.

The legacy software trap

Most enterprise security guidance assumes we can update our software, move to the cloud, or at least control what gets installed on endpoints. Manufacturing and automotive environments break all three of those assumptions.

Diagnostic tools on a dealership service bay get updated multiple times a week. CAD software on an engineering floor expects admin rights because it was designed 15 years ago when nobody thought twice about it. CNC machine interfaces and production monitoring tools follow the same pattern: they need elevated access to function, they update constantly, and there is no modern replacement.

I’ve talked to IT teams managing 200 to 300 endpoints in these environments. They’re not running security operations centers. They’re fixing printers and keeping production lines moving. When a technician on the shop floor can’t update their OEM diagnostic software, production slows down. So the IT admin does the practical thing: grants local admin rights and moves on to the next fire.

Why the standard playbook doesn’t fit

The main concern as reported in Forrester’s research on OT security is that it creates the conflict between protecting special industrial equipment from cyber threats and maintaining the operation of the equipment. It’s essentially the primary goal for both manufacturers and auto dealers.

In corporate environments using traditional privilege management techniques work because users have standard corporate applications such as Microsoft Office and a web browser. Users have such standard corporate applications the workflows are relatively predictable and we can remove administrative rights for all users and address exceptions via a support desk ticket.

However, the exception represents the actual workflow for the technicians working on a manufacturing floor. Technicians may need to have administrative access to install OEM firmware updates at 7 a.m. and use diagnostic tools at 10 a.m. In addition, they may need to install production software prior to their shift starting at 12 p.m. Each of these requests are legitimate and timely. However, if it takes 45 minutes for each of these requests to go through a ticketing process it will quickly become abandoned by the first week.

A practical path forward

The answer isn’t blanket admin access. But it also isn’t pretending that a standard corporate security model will survive contact with an OEM-heavy environment.

Start by running the environment in observation mode for a few weeks to identify which applications actually need elevated access, how often, and who’s requesting it. Most organizations discover that a handful of OEM applications account for the vast majority of requests. The diagnostic software that updates three times a week. The CAD program that needs admin for license validation.

Once we know the pattern, build rules around it. Grant temporary, application-specific elevation for known good software. The technician clicks to update their diagnostic tool, the elevation happens in the background for that specific process, and access returns to normal once it’s finished. No blanket admin rights. No help desk call. No disruption to production.

The user doesn’t notice a difference. But we’ve removed standing admin rights from every endpoint on the floor while keeping the line running at full speed.

Why the compliance angle gets harder to ignore

For auto dealerships, the FTC Safeguards Rule has made this more than a security conversation. Penalties can run $100,000 per infraction for non-compliance with access control requirements. Cyber insurance questionnaires are asking tougher questions about who has admin access. And the answers that worked two years ago aren’t satisfying underwriters anymore.

Manufacturers face similar pressure from SOC 2 audits and NIST frameworks. Auditors don’t want to hear that the company has a policy. They want to see who had access to what, when, and for how long.

So, after 40 years in IT infrastructure, the biggest lesson I’ve learned about security is that the controls that stick are the ones people don’t fight. If a security model makes it harder for a technician to do their job, they’ll work around it. Every time.

Most OEMs software aren’t going away. The admin requirements built into it aren’t going away either. But handing out permanent admin rights to deal with it should have ended years ago.

Temporary elevation for specific applications, automatic removal when the task gets finished, and a clear audit trail for compliance. The approach exists today. The big question: Will the company adopt it before the next audit, the next insurance renewal, or the next breach forces the issue?

David Bellini, co-founder and CEO, CyberFOX

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.