They often assume a single control model can cover every application, environment, and business unit. In practice, critical infrastructure spans on-premises, private cloud, and public cloud systems, each with different access patterns and maturity levels. The common mistake is trying to go big too early instead of starting with the most critical assets, compartmentalizing, and scaling deliberately.
Why a Single Access Model Breaks Down in Critical Infrastructure
A one-size-fits-all access model usually fails because critical infrastructure is not one environment. On-premises control systems, private cloud workloads, public cloud services, vendor remote access, and operator consoles all carry different trust assumptions, session durations, break-glass needs, and audit expectations. The access model has to reflect those differences, or it becomes either too permissive or too restrictive.
The practical error is treating access as a policy exercise instead of an operational design problem. If the same rules are applied everywhere, teams usually optimise for convenience and end up overextending trust, especially where legacy systems, emergency operations, and third-party dependencies meet.
What Organisations Miss About Environment, Criticality, and Compartmentalisation
Critical infrastructure tends to mix systems with very different failure consequences. A read-only analytics platform, a plant-floor control interface, and a privileged admin console do not deserve the same access path even if they sit under the same governance umbrella. Access should follow criticality, blast radius, and recovery requirements, not organisational neatness.
This is why compartmentalisation matters so much. The control objective is not uniformity, it is containment. When access boundaries are aligned to business function and operational risk, a compromise in one area is less likely to cascade into production control, safety systems, or cross-domain administrative reach.
Best practice is also evolving across hybrid estates. A policy that works for a stable on-prem environment may not be sufficient for cloud services with ephemeral roles, API-driven administration, or outsourced operations. Organisations often underestimate how much the environment itself changes the access pattern.
How to Scale Access Without Overreaching
The safer pattern is to start with the most critical assets and expand deliberately. That means defining the minimum viable access model for the highest-value systems first, then extending only where the same control logic still fits. It is easier to generalise from a disciplined core than to unwind broad exceptions later.
- Map access to asset criticality and operational dependency before trying to harmonise policies across the estate.
- Separate privileged administration, routine operator activity, and vendor support into distinct access paths.
- Use tighter boundaries for systems that can affect safety, continuity, or customer-facing production services.
- Review whether cloud, on-premises, and third-party access should share the same approval flow, or only the same governance standard.
The aim is not to create dozens of bespoke models. It is to avoid forcing one pattern onto every system when the operational realities are plainly different.
Risk and Threat Considerations
One-size-fits-all access creates both overexposure and hidden brittleness. If the model is too broad, a single credential or role can span environments that should have been separated. If it is too rigid, teams work around it with exceptions, shared accounts, or untracked vendor pathways, which weakens visibility and increases attack surface.
Failure mechanism: The access model overstates commonality across systems, so privileged paths, approvals, and credentials are reused across zones with different risk profiles. Attackers and insiders then benefit from excessive reach, weak compartmentalisation, and inconsistent enforcement.
Impact: A compromise in one domain can spread into higher-value systems, and operational teams may lose the ability to apply environment-specific controls where they matter most. The result is both greater blast radius and poorer resilience when incidents occur.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Access models must distinguish and govern privileged and routine access. |
| Recommendation — Separate and review accounts by privilege and function before broadening access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about avoiding overbroad access across critical systems. |
| AC-3 — Access Enforcement | Compartmentalisation depends on enforcing different access rules by system context. | |
| AC-5 — Separation of Duties | Critical infrastructure needs separation between operator, admin, and vendor actions. | |
| Recommendation — Limit each role to the minimum access needed for its environment and task. Enforce context-specific access decisions rather than a single uniform rule set. Split high-risk duties so one access path cannot perform every sensitive action. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is fundamentally about designing access control for mixed environments. |
| A.8.2 — Privileged access rights | The answer stresses privileged access should not be generalized across all systems. | |
| Recommendation — Define access rules by asset criticality, environment, and business function. Restrict privileged access paths and review them separately from routine access. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Hybrid infrastructure access models must account for cloud and on-premises control differences. |
| Recommendation — Align IAM controls to the distinct access patterns of each environment and workload. | ||
Practitioner Guidance
What to prioritise: Begin with the assets whose compromise would create the largest operational or safety consequence, then define access boundaries around those systems first. If a model cannot clearly distinguish between routine access, privileged access, and emergency access, it is not ready to scale.
What to verify: Check whether every exception is tied to a specific environment, function, and owner. The warning sign is a policy that looks consistent on paper but relies on informal trust, shared credentials, or broad cross-environment permissions in practice.
Practitioner takeaway: The right access model is the one that preserves containment under stress, not the one that looks simplest to govern on a slide deck.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they secure AI only at the model layer?
- What do organisations get wrong when they standardise one authorization model for all agents?
- What do organisations get wrong when they try to secure flexible work with legacy controls?
- What do organisations get wrong when they treat access requests as a one-time approval instead of an ongoing control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
