How should manufacturers govern third-party privileged access?

Why This Matters for Security Teams

Third-party privileged access is one of the fastest ways a manufacturer can inherit risk it did not directly create. Vendors often need elevated access to production lines, OT-adjacent systems, ERP platforms, or maintenance tooling, but broad standing privilege turns a temporary service need into a persistent attack path. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward least privilege, visibility, and recoverability, but manufacturers still struggle to apply those ideas to external technicians, integrators, and managed service providers.

The risk is not only misuse. Third-party access also expands the blast radius of stolen secrets, weak offboarding, and shared accounts that no one can cleanly attribute. NHIMG research shows that Ultimate Guide to NHIs reports 92% of organisations expose NHIs to third parties, which makes supplier access a governance issue as much as a technical one. In practice, many security teams encounter vendor abuse or forgotten access only after a maintenance window, outage, or incident has already exposed the gap.

How It Works in Practice

Manufacturers should treat every vendor path as a separate trust decision, not as a blanket exception. The practical starting point is inventory: which vendors can reach which systems, through which accounts, with what session duration, and under what approval chain. That map should include remote support tools, API integrations, service accounts, jump hosts, and any credential handoffs used by contractors. The goal is to convert opaque third-party access into named, reviewable, and revocable entitlements.

Operationally, the best pattern is a combination of named accounts, delegated approval, session recording, and time-bounded access. Use task-specific entitlements so a vendor can perform one maintenance action without inheriting broader administration. Issue access only when needed, then revoke it automatically at the end of the task. Where possible, require multi-party approval for production changes and enforce full session logging so reviewers can reconstruct what happened, not just that a login occurred.

• Use named accounts, never shared vendor credentials.
• Grant only the minimum system, command, and data scope for the job.
• Time-box access and revoke it immediately after the work window closes.
• Record privileged sessions and retain logs for audit and incident response.
• Review vendor entitlements on a fixed cadence and after each contract change.

This approach aligns with the governance direction in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which emphasises onboarding, rotation, and offboarding discipline across non-human access. For manufacturers, the control objective is simple: prove who accessed what, why they accessed it, and how quickly that access disappeared when the work ended. These controls tend to break down when vendors rely on shared jump boxes with permanent local admin rights because attribution and revocation become unreliable.

Common Variations and Edge Cases

Tighter vendor control often increases operational friction, requiring manufacturers to balance production uptime against auditability and response speed. That tradeoff is real in plants that run 24/7, where maintenance delays can affect throughput or safety. The current guidance suggests that the answer is not to relax controls globally, but to tier them by risk: low-risk support tasks may use narrower approvals, while access to production controllers, quality systems, or recipe data should require stronger review and shorter session windows.

One common edge case is emergency access. Best practice is evolving, but emergency elevation should still be named, logged, approved after the fact, and automatically reviewed. Another edge case is managed service providers that need recurring access across many sites. In those environments, standing access can be reduced without eliminating availability by using just-in-time provisioning, session brokering, and contract-bound access reviews. Shared accounts, long-lived secrets, and undocumented “temporary” access paths remain the main failure modes.

NHIMG’s 52 NHI Breaches Analysis is a useful reminder that identity failures are rarely isolated events; they usually combine poor inventory, weak rotation, and delayed revocation. Manufacturers should also align vendor governance with the Ultimate Guide to NHIs — Regulatory and Audit Perspectives when evidence retention, change approval, or segregation of duties must be demonstrated to auditors. The model breaks down most sharply in legacy OT environments where tools cannot record sessions or issue per-task access without disrupting operational continuity.

Related resources from NHI Mgmt Group

• How should security teams govern third-party remote access without creating standing privilege?
• Who is accountable when third-party access outlives the task under CJIS 6.0?
• Why do third-party access relationships create HIPAA risk?
• How should security teams govern non-human identities that have persistent access?