Access doesn't disappear in the cloud - It just gets harder to see

Ask most critical infrastructure operators who has access to their systems, and they can tell you about their own staff with reasonable confidence. Ask about the specialist OT contractor who did a six-week project two years ago, or the managed service provider with standing admin rights to a cloud console, or the vendor whose support agreement quietly lapsed but whose login didn't - and the answer gets a lot less certain.

Third-party access sits inside supply chain risk. It is one of the four hazard categories the reformed Critical Infrastructure Risk Management Program (CIRMP) rules (in force since June 2026) called out alongside cyber and information security, personnel, and physical security and natural hazards. It's also one of the least visible, because it doesn't map neatly to any one environment. It's not an on-prem problem, and moving to the cloud doesn't solve it - it just changes what the gap looks like.

Why this gap persists everywhere

Critical infrastructure operators today run genuinely hybrid environments - some systems on-premises, some in the cloud, increasingly a mix of both for the same operation. Third-party access follows the same pattern, and the risk shows up differently depending on where you look:

• On-premises and OT environments: contractor accounts provisioned for a specific project, rarely tied to a hard end date, and rarely revoked when the work finishes. Specialist OT, SCADA vendors and engineering workstations in particular, often carry standing access because their expertise is scarce and re-provisioning feels like friction nobody wants to reintroduce.

• Cloud and SaaS environments: managed service providers, integrators, and platform vendors with persistent admin-level access to consoles and environments, often set up for convenience during an initial implementation and never revisited.

• Hybrid environments: the worst of both - vendor access that spans on-prem systems and cloud consoles, with no single place to see the full picture of what any one third party can actually reach.

The common thread isn't the environment. It's that third-party access tends to be provisioned once, under time pressure, and reviewed rarely, if ever.

What "good" looks like, regardless of environment

The reformed CIRMP doesn't ask operators to eliminate third-party access - that's neither realistic nor desirable, given how dependent critical infrastructure is on specialist vendors. What it asks for is the ability to demonstrate control over it. This includes:

• Time-bound, not standing. Access provisioned just-in-time for the specific work and switched off automatically when it ends; not left active because nobody remembered to close it out.

• Scoped, not broad. A vendor supporting one system shouldn't inherit access to unrelated systems because it was easier to grant broadly at setup.

• Visible, not assumed. A current, accurate answer to "which third parties can access what, right now" - not a list that was accurate when it was last updated, whenever that was.

• Auditable, not reconstructed. Session records and access logs for third-party activity that can be produced on request, rather than pieced together after an incident.

None of this depends on whether the underlying systems are on-premises, cloud, or both. It's a governance discipline, not an infrastructure decision, which is exactly why it sits awkwardly for organisations that have framed their security posture primarily around where their systems live rather than who can reach them.

Seeing it in practice

This isn't theoretical. A national critical infrastructure energy operator recently faced a version of this exact gap - credentials embedded across application servers, scripts, and configuration files, with no centralised way to see where secrets existed, who could access them, or whether they'd ever been rotated. The complexity was compounded by a hybrid estate spanning legacy OT, enterprise applications, and containerised workloads - no single off-the-shelf tool covered the full picture. Avocado Consulting designed and delivered an enterprise-wide secrets management capability built on CyberArk, replacing embedded credentials with centralised, RBAC compliant, fully audited access. The result? We closed the exact kind of visibility gap the reformed CIRMP rules are designed to surface.

Why this matters more as environments get more complex

The number of third parties with some form of access to critical infrastructure has grown over the years - driven by specialist skills shortages, the shift to managed services, and the ordinary accumulation of vendor relationships over a decade or more of operation. Each individual grant of access made sense at the time. Few organisations have gone back and asked whether it still does.

That accumulation is exactly what the reformed CIRMP rules are designed to surface. Supply chain risk, under the proposed rules, isn't just about the integrity of hardware and software you procure; it extends to who those suppliers, once engaged, can actually reach inside your environment, and for how long.

Where to start

The starting point is the same regardless of whether your environment is on-prem, hybrid, or fully cloud: a current inventory of every third party with access to your systems, what they can reach, and whether that access is still tied to active, necessary work.

For most operators, that inventory reveals more than expected - not because of any single dramatic gap, but because vendor access, unlike staff access, rarely gets swept up in routine reviews. It sits quietly in the background until someone goes looking.

Under the reformed SOCI Act, someone will be expected to go looking. Better that it's you, on your own timeline, than a regulator on theirs.

For an obligation-free identity security consultation, contact our team.