What should security teams do after a manufacturing ransomware event?

Why This Matters for Security Teams

After a manufacturing ransomware event, the operational question is not just how the malware entered, but which identities allowed it to move from IT into production, backups, vendor channels, and maintenance tools. In industrial environments, service accounts, API keys, remote access paths, and shared admin credentials can outlast the incident and keep the same failure pattern alive. NIST’s Cybersecurity Framework 2.0 is useful here because recovery and governance must be treated together, not as separate workstreams.

NHIMG research shows that 80% of identity breaches involve compromised non-human identities such as service accounts and API keys, which is especially relevant when plants depend on long-lived access for uptime and vendor support. The same issue appears in real incidents such as the Cisco Active Directory credentials breach, where identity exposure amplifies the blast radius. In practice, many security teams discover these identity paths only after recovery work has already re-opened the same doors for the attacker.

How It Works in Practice

The first post-incident task is to map the identities that mattered during the attack path, not just the endpoints that were encrypted. That means service accounts used by MES, ERP, historians, remote support tools, backup agents, EDR exceptions, and contractor VPN or jump-host access. Teams should then revoke or constrain standing access, rotate affected secrets, and confirm that recovery workflows do not depend on shared credentials that survive beyond the event.

For manufacturing, this usually requires coordination across IT, OT, and third parties. A pragmatic sequence is:

• Identify all non-human identities touched by the ransomware path, including machine accounts and automation tokens.
• Check whether the same credentials were used across multiple plants or environments.
• Rotate secrets and certificates, then verify the old values are no longer accepted.
• Review remote maintenance access, vendor OAuth grants, and backup service permissions.
• Replace shared standing access with just-in-time access and time-bound approvals where possible.

This aligns with the Ultimate Guide to NHIs, which highlights that only 20% of organisations have formal offboarding and revocation processes for API keys. It also connects to the Codefinger AWS S3 ransomware attack, where cloud identity and access weakness can accelerate disruption. Current guidance suggests treating these identities as recovery-critical assets, with rotation and revocation validated before systems are returned to production. These controls tend to break down when plants rely on shared vendor accounts because the business fears downtime more than it fears repeat compromise.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance recovery speed against the risk of reintroducing standing privilege. That tradeoff is especially sharp in plants with 24/7 production, legacy OT protocols, and contractors who need rapid access during outages. Best practice is evolving, but there is no universal standard for this yet: some environments can move to per-task access quickly, while others need staged cutovers and compensating monitoring.

Edge cases usually appear where identity is embedded into equipment or vendor workflows. For example, backup software may use one privileged token across multiple sites, or a maintenance vendor may authenticate through a shared account that cannot be traced to a person or a task. In those cases, the right response is not to preserve the old model indefinitely, but to create an interim control set with strict expiry, logging, and approval rules while migration is planned.

The underlying lesson is simple. If the post-incident review stops at malware cleanup, the same identity path will likely remain available for the next intrusion. Security teams should use the event to reset access assumptions, especially where remote operations, third-party support, or industrial automation depend on credentials that were never designed for resilience.

Related resources from NHI Mgmt Group

• How should security teams prioritise restoration after a ransomware event?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?