Identity security for manufacturing goes wrong where work has to move fast: SAP roles that build up one reasonable request at a time, valid logins that stay open, and vendor access granted for a job and never closed. In each case the access decision is made quickly and reviewed slowly.
Identity security for manufacturing means controlling who can log in to the systems that run the business and the plant, what they can do once they’re in, and how that access is reviewed and removed. It covers SAP and other business applications, remote access, and the people who need it: employees, contractors and vendors. OT networks need their own protections, and identity governs the accounts and rights around them.
A plant can run well-configured systems and still have the wrong people holding the wrong access, because systems enforce the access they’re given and don’t question it. The governance side of that problem is covered in more detail in identity governance for manufacturers, and the three sections below follow the places where control most often slips.
SAP conflicts form because each access request makes sense on its own and nobody checks the combination until a later review. SAP access control in a plant often grows through reasonable requests, each approved by someone who knew the person, while the review that looks at the whole picture comes after the access already exists.
Two illustrative situations, which are examples rather than data, show the pattern. A buyer moves into accounts payable and keeps the old purchasing role, and a planner covers for a colleague on leave and keeps the extra access after the colleague returns. Each request made sense on the day someone approved it.
The combination is what nobody chose. In one illustrative case, a person ends up able to create a vendor and approve payment to it, and neither permission looks unusual on its own line. The conflict only becomes visible when a quarterly review or an audit looks at everything the person can do, by which time it may have been live for months.
Rebuilding roles for S/4HANA gives a team a choice between copying the existing roles across, which carries every old combination into the new system, and resetting them against what each job needs today. Copying is often the easier path, because the roles already exist and people already work with them. A migration is one of the few moments when rebuilding roles is already on the plan, which makes it the natural point to reset them.
Teams that are also replacing a legacy provisioning tool can find a separate guide to that decision on the OpenIAM site.
Four practices keep conflicts from re-forming once roles have been reset:
For the rules themselves, see the SAP segregation-of-duties rules for manufacturing. The blog on why spreadsheet access reviews fail manufacturing teams covers manual reviews, and why SAP SoD isn’t enough for manufacturing compliance covers the limits of rules on their own.
Attackers often get into plants with a login that already works, taken from a real user. Dragos, an OT security services firm, reported in its 2026 OT/ICS Cybersecurity Report that about 3,300 industrial organizations were hit by ransomware in 2025, and that manufacturing accounted for more than two-thirds of the victims.
The report found that the most common way into observed networks was remote-access portals and virtualization services, including VPN portals, firewall interfaces and vendor tunnels. It traced the legitimate credentials attackers used to phishing, infostealer malware and initial access brokers.
Dragos described identity abuse as what allowed adversaries to move quickly and quietly through enterprise environments, and the report describes ransomware operators using that access to cross between IT and OT. It also put the industry-wide average dwell time for ransomware in OT environments at 42 days.
A credential stays useful for as long as the account behind it stays open, which in a plant can mean accounts nobody owns, accounts for people who’ve left, and accounts for contractors whose jobs have ended.
An illustrative scene shows how it happens: an engineer transferred to another plant two years ago and still holds the remote-access account used for the old line, and a commissioning contractor finished in the spring while the account they were given is still enabled. Each account was set up by one team and appears in no list that another team checks.
Three practices narrow the set of logins that still work:
A stolen credential can be less useful when the account behind it is closed or has expired.
Vendor access stays open after the job because granting is fast and owned, while reviewing and removing aren’t. The person who needs the line running grants the access, and the later steps of reviewing and removing it often have no named owner.
Ownership is the common thread. A maintenance supervisor, a plant IT team and a purchasing team can each hold a piece of the vendor relationship, and none of them holds the whole lifecycle of the account.
An illustrative scene, which is an example rather than data: a line goes down overnight, the equipment maker’s engineer needs to log in to diagnose it, and an existing login is shared to get production moving. The ticket closes the next morning with the login still active, and nobody is assigned to revisit it.
No neutral figure measures how often vendor accounts stay open after a job, so the evidence here is general and comes from a firm that sells OT security services. Dragos reported that nearly half of its services reports in 2025 (49%) included elevated findings related to remote access, and that ransomware and commodity malware incidents exploited well-known weaknesses including shared credentials. Its frontline write-up also describes third-party and downstream service providers that introduced ingress points into victim networks.
Those findings concern remote access in general rather than vendor accounts specifically. They show that remote access and shared credentials are recurring findings, and they don’t show how many of the accounts involved belong to vendors.
Three features keep vendor access useful for the job and closed afterwards:
The same request that opens the access can set its end date and scope, which keeps the grant quick and makes removal the default instead of an afterthought.
A manufacturer can test its process with five questions, each answerable by pointing to a system rather than to a habit. The checks cover the vendor and remote-access side of the plant.
| Check | Red flag | What to ask |
| Shared vendor logins | Vendor staff use a login shared among them or reused from a previous job | Which vendor accounts belong to a named person, and which are shared? |
| Vendor activity you can’t reconstruct | After a session, nobody can say who connected, to what, and what they did | Could the plant reconstruct last month’s vendor sessions from a record? |
| Credentials nobody reviews | Remote-access accounts have no review date and no owner who certifies them | When was each remote-access account last reviewed, and by whom? |
| Access opened for one job and never closed | Access granted for a repair or project has no end date | Which vendor accounts have an end date matched to the job? |
| No named owner across IT and OT | IT owns the directory, OT owns the remote-access tool, and neither owns the account end to end | Who is accountable for each vendor account across both environments? |
A red flag in any row means the control can’t yet be shown to work for that account.
OpenIAM addresses the SAP and contractor sides of these problems with governance controls that coexist with the access models a plant already runs. It provides SAP object-level authorization and SAP transaction-code governance, and a visual, simulated segregation-of-duties rule builder with functional packs for finance and SOX, HR, IT privileged access and procurement. A review campaign can be triggered when a violation is found, and exceptions expire automatically. A policy-based access control engine works alongside existing role-based access control, so it’s additive rather than a forklift replacement.
Access reviews include an AI assistant for reviewers, detection of rubber-stamp approvals and plain-English entitlement descriptions. Contractor and external identities have a named internal sponsor, scoped permissions and time-bound access with a hard expiry, extensions need explicit re-approval, and contractor populations can be uploaded in bulk and synchronized with vendor management systems. One lifecycle model covers employees, contractors, partners and AI agents, and an audit-ready decision log records each access decision.
The Manufacturing solution page covers how OpenIAM approaches SAP segregation of duties, joiner-mover-leaver lifecycle and access certifications for manufacturers, for teams ready to move from testing their process to evaluating a platform.
Q1. What is identity security for manufacturing?
A: Identity security for manufacturing means controlling who can log in to the systems that run the business and the plant, what they can do once they’re in, and how that access is reviewed and removed. It covers SAP and other business applications, remote access, and the employees, contractors and vendors who use them. OT networks need their own protections alongside it.
Q2. Why do SAP segregation-of-duties conflicts go unnoticed until an audit?
A: Conflicts are created when access is assigned, but they’re often checked only at a periodic review, so a combination can be live for months before anyone looks at it. Each request usually makes sense on its own, approved by someone who knew the person, and nothing evaluates the combination of permissions the person ends up holding.
Q3. How should manufacturers manage vendor and contractor access to plant systems?
A: Give each person who connects a named identity instead of a shared login, scope access to the job, and set an end date when the access is granted. Keep a record of who accessed what and when, and give every vendor account an owner who spans IT and OT so that someone is accountable for closing it.
Q4. Why are valid credentials a risk for manufacturers?
A: Dragos, an OT security firm, reported in 2026 that the most common way into observed industrial networks was remote-access portals and virtualization services, with attackers often using the legitimate credentials of a real user. A stolen credential can be less useful when the account behind it is closed or has expired, which is why owners and end dates matter.
Q5. What should a manufacturer do with SAP roles during an S/4HANA migration?
A: Reset roles instead of copying them: review what each job needs today and rebuild roles from that, because copying existing roles carries every old combination into the new system. Check combinations when access is requested as well as at review, and make exceptions expire so a justified conflict doesn’t become permanent.