Reading Time: 2 minutes

When we talk about cybersecurity, we tend to focus on the perimeter—what’s outside, trying to get in.

But these days, that’s not really how attacks work anymore.

In many of the ransomware cases we’ve seen recently, attackers didn’t “hack” in. They just logged in—with real credentials. No alarms. No brute force. Just unused access that was still active… and connected to everything.

And once they’re in, access is the blast radius.

The Quiet Risk Hiding in Plain Sight

Most midsize manufacturing companies have dozens (if not hundreds) of accounts floating around their environment.

Some are personal logins. Some are service accounts. Some are old credentials left behind by vendors or former employees.

You end up with things like:

• 🔓 A backup script with admin privileges
  
• 🔁 DevOps keys reused across test and prod
  
• 🕳 A staging bucket linked to a forgotten CI pipeline
  
• 🎯 One engineer with access to production and the sandbox and the deployment tool
  

This stuff doesn’t look dangerous—until it is. Because ransomware doesn’t just lock your files. It follows access. And where your permissions lead, it goes.

IAM Should Be a Strategic Layer, Not Just IT Hygiene

In most orgs, identity and access management (IAM) is treated like back-office plumbing.
Necessary, but not critical.

That made sense when systems were slower-moving, and most access was local.
But now we’re operating in hybrid environments—cloud-connected, integrated across multiple vendors and internal tools. IAM is no longer a back-office problem. It’s the front line.

Because we’re not just talking about who can log into email. We’re talking about:

• 🌐 Who can spin up infrastructure in AWS or Azure
  
• 🏗 Who can deploy new builds to the factory floor
  
• 🛠 Who can change configurations in your CI/CD pipeline
  
• 🔄 And what access automatically propagates across environments (whether you meant to or not)
  

Four IAM Gaps We See All the Time

None of these are unusual. In fact, they’re common. But they’re also easy to fix—if you’re looking for them:

1. ✅ Too much access — service accounts or users with broad, unnecessary privileges
   
2. 📉 Stale credentials — contractors, vendors, or test users that were never deactivated
   
3. 🚫 Shared admin accounts — no visibility, no accountability
   
4. 🔍 Privilege escalation — no controls in place to stop someone from quietly gaining more access
   

These aren’t abstract issues. They’re usually hiding in your config files and IAM dashboards right now.

IAM Needs to Touch More Than Just IT

If you’re serious about ransomware resilience, you can’t silo IAM to the IT department.

It needs to extend to:

• Your infrastructure: cloud platforms, log systems, Kubernetes clusters
  
• Your product environments: build servers, staging areas, sandbox APIs
  
• Your factory-adjacent systems: MES, ERP access, monitoring tools
  

If a compromised key can access all three?
That’s where a small breach becomes a company-wide crisis.

So Where Do You Start?

You don’t need to rip everything out and start over. A few small moves go a long way:

• 🔒 Apply least privilege—give access based on actual need, not what’s easiest
  
• 📉 Audit and remove dormant users and accounts
  
• 🚫 Block unchecked privilege escalation
  
• 📋 Separate test/staging/prod environments at the access level—not just by folder
  
• 🔍 Add visibility: who has access to what, and what that access really means
  

📥 Want a Shortcut?

We put together an IAM Misconfiguration Risk Checklist for midsize product and infrastructure teams—especially in industrial environments.

It’s built on real-world breaches we’ve studied and helped teams recover from.