On-prem doesn't mean secure - Avocado Consulting - deliver with certainty

It’s understandable. It’s also wrong, and the reforming Security of Critical Infrastructure Act is about to make that gap a lot harder to ignore.

The comfort of “not in the cloud” 

On-prem and legacy systems have a way of building a false sense of security over time. No public-facing login screen. No headlines about cloud misconfigurations. The system’s been running quietly in a server room or control centre for a decade, and nobody’s had a reason to look closely. 

But nobody looking closely is precisely the problem. In on-prem and legacy environments, it’s common to find: 

• Local admin accounts created years ago, for a project or a contractor, never reviewed and never removed. 
• No vaulting -passwords living in scripts, spreadsheets, or nowhere documented at all. 
• No rotation policy, meaning credentials that are decades-old in practice, if not in name. 
• Less modern tooling and less visibility than a comparable cloud environment would have by default. 

None of this is unique to on-prem. But on-prem doesn’t reduce this risk the way people assume. If anything, the lack of built-in visibility that cloud platforms provide by default means it often goes unnoticed for longer. The enhancements to the Critical Infrastructure Risk Management Program (CRIMP) are now in place. They move the bar from awareness to demonstrable management of legacy and unpatched system risk -“it’s old, it’s on our roadmap” won’t be a sufficient answer once the reformed rules commence. For the full detail on what’s changing and when, see our explainer on the SOCI Act reforms

Why “not in the cloud” feels safer than it is 

Part of why this blind spot persists is that the mental model most people use for risk was built by the cloud era. Cloud security horror stories such as misconfigured buckets, exposed APIs, leaked keys in a public repo are visible, documented, and constantly discussed. On-prem incidents rarely get the same airtime, not because they’re rarer, but because they’re quieter. A compromised local admin account on an internal server doesn’t show up in a Shodan scan or a security researcher’s blog post. It shows up, if at all, in an incident report months later. 

That invisibility gets mistaken for security. It isn’t. It’s just a longer fuse. The Colonial Pipeline attack didn’t start with a sophisticated zero-day – it started with a single compromised password on a legacy account nobody was monitoring. The systems that feel safest, because nobody’s looking at them, are often the ones with the least oversight of who can get in. Try our DevSecOps Self Assessment

The scale of the on-prem gap 

Identity is where this bites hardest, because it’s usually the least visible part of a legacy environment. Physical security gets audited. Network segmentation gets diagrammed. Privileged accounts – including who has them, whether they’re shared, whether anyone’s rotated a password in the last two years – often don’t get looked at until something goes wrong. 

And the blind spot compounds further with non-human identities. Many organisations have at least partial visibility over their human identities – an IAM tool, an access review cycle, someone who can produce a list of who has admin rights. Far fewer can say the same for the service accounts, API keys, machine credentials, and automation identities quietly running the plant. 

The scale of this problem is bigger than most risk registers reflect. CyberArk estimates machine identities now outnumber human identities by 82 to 1, driven by increased AI adoption and cloud native growth. Yet 88% of organisations still define “privileged user” as applying solely to human identities – even though 42% of machine identities actually carry privileged or sensitive access. Visibility into privileged access on operational technology systems and IoT devices remains particularly thin across the sector.  

For an on-prem or hybrid critical infrastructure operator, that combination – legacy systems, unmanaged accounts, and a definition of “privileged access” that quietly excludes most of what’s actually privileged –  is exactly the gap regulators are now asking operators to close. 

Where to start 

Closing this gap doesn’t require ripping out on-prem infrastructure or moving to the cloud. It requires the same discipline the enhanced CIRMP is asking for everywhere else:

Know what you have, control who and what can access it, and be able to prove it. 

In practice, that means: 

• Inventory first. A current, accurate list of every account with privileged access both human and machine, including the built-in local admin accounts most organisations forget to count. 
• Mitigate. Credentials centrally vaulted and automatically rotated, rather than static and manually tracked. 
• Monitor and audit. Session visibility and audit trails that can be produced on request, not reconstructed after the fact. 
• Govern. Centralise identity lifecycle management that extends to vendor and contractor access that’s provisioned just-in-time and switched off automatically, rather than standing indefinitely. 

None of this is a large transformation project on day one. It starts with an honest inventory, which is usually the step that reveals how large the gap is, and how much of it has been sitting in plain sight, protected only by the assumption that on-prem meant safe. 

That assumption was never quite true. Under the enhanced SOCI Act, it’s about to become expensive to keep believing it. 

The SOCI reforms have landed

Learn about the questions every board should ask management about privileged access, machine identities and CIRMP readiness. 

Most Australian businesses aren’t Essential Eight compliant

See why compliance isn’t the goal and what actually reduces your cyber risk.