Why do recent attacks keep targeting suppliers, automation, and operational systems?

They target those paths because they already carry legitimacy, privileged access, and business dependence. That lets attackers bypass noisy perimeter defences and operate inside systems that were built to trust automation and partners. In environments with NHIs or service credentials, the same weakness multiplies because machine access is often broad, persistent, and poorly reviewed.

Why This Matters for Security Teams

Supplier, automation, and operational environments are attractive because they already sit on trusted paths. Attackers do not need to smash through the perimeter when a partner integration, service account, or control system already has legitimate reach. That is why recent campaigns keep gravitating toward machine-to-machine trust, especially where NHIs are broad, persistent, and rarely reviewed. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks notes that 97% of NHIs carry excessive privileges, which helps explain how fast a compromise can turn into lateral movement.

The strategic problem is that suppliers and operational systems are designed for reliability, not skepticism. Once attackers get a valid token, API key, or service credential, they can blend in with normal automation and avoid the alerts that legacy perimeter tools are tuned to catch. That is especially dangerous in environments where third-party access is always-on and operational uptime is treated as sacrosanct. In practice, many security teams encounter the compromise only after a partner account, automation chain, or plant system has already been used as the entry point.

How It Works in Practice

These attacks succeed because legitimacy is inherited, not earned at every request. A supplier’s integration token may be trusted across multiple systems, an orchestration account may have broad API scope, and an operational service may be exempt from the controls that would slow down a human user. Once inside, attackers can chain tool access, enumerate adjacent systems, and expand privilege without needing unusual malware. MITRE ATT&CK helps model those post-compromise behaviours, while CISA cyber threat advisories routinely show how real intrusions pivot from initial access into internal systems through trusted accounts.

For NHI-heavy environments, the practical controls are familiar but often poorly enforced:

• Inventory every supplier integration, service account, robot, and API key, then tie each one to an owner.
• Replace long-lived static secrets with short-lived, JIT credentials wherever the workflow allows it.
• Scope access to the smallest possible workload, endpoint, and time window.
• Separate operational credentials from user IAM so one compromise does not expose both paths.
• Continuously review high-risk trust relationships, especially third-party and machine-to-machine dependencies.

NHIMG’s 52 NHI Breaches Analysis shows how often compromised non-human identities become the real foothold, not the side issue. That aligns with the current guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasizes account management, least privilege, and monitoring as baseline hygiene. These controls tend to break down when third-party access is deeply embedded in production workflows and no team can easily interrupt the trust chain without disrupting operations.

Common Variations and Edge Cases

Tighter access controls often increase operational overhead, requiring organisations to balance resilience against production friction. That tradeoff is especially visible in OT, manufacturing, logistics, and managed service ecosystems, where uptime, vendor support, and safety constraints limit how aggressively credentials can be rotated or segmented. Current guidance suggests that exception handling should be time-bound and reviewed, but there is no universal standard for this yet.

Some environments also blur the line between supplier access and internal automation. A contractor-managed script, a CI/CD runner, or an agentic workflow may sit in the same trust domain as core business processes, which makes simple allowlists ineffective. The better pattern is to treat each machine identity as a distinct workload with explicit context, not as a permanent extension of the organisation. That is one reason NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now stresses visibility and lifecycle control, not just vaulting secrets.

For emerging autonomous systems, the risk grows because behaviour is less predictable than in traditional automation. An agent can decide to call additional tools, request new permissions, or chain actions in ways that static policy models do not anticipate. That is why the industry is moving toward runtime authorization and context-aware policy evaluation, but best practice is still evolving.

Related resources from NHI Mgmt Group

• What is the main risk when automation systems store ServiceNow credentials?
• How should security teams govern on-prem data that is also accessed by automation and AI systems?
• How can organisations tell whether workflow automation is actually reducing operational burden?
• How should security teams defend enterprise AI systems against jailbreak attacks?