What breaks when access centralisation does not cover every protocol and cloud?

When centralised access still fractures by protocol

Centralisation only works when the control plane reaches the places where work actually happens. If one layer authenticates entry but SSH, RDP, databases, and Kubernetes each keep separate policy, session, and log paths, the organisation has not centralised access control, it has centralised only a front door.

That creates a split between who was able to connect and what was actually governed after connection. The practical break is not login success, it is the loss of one consistent decision model for authorisation, revocation, and evidence across the estate.

Where this matters most is operational consistency. A shared access platform can still leave different protocol handlers, cloud consoles, and cluster paths enforcing different rules, so the same user or automation receives different treatment depending on which interface they used.

That is why teams often discover that “centralised access” was really a bundle of disconnected controls. The result is uneven enforcement, duplicate exceptions, and a review process that cannot answer a simple question: what did this principal do across every protocol and cloud control surface?

Why policy drift becomes an access governance problem

Once protocol coverage is incomplete, policy drift appears in the gaps between systems. An approved identity may enter through one path, but another path may still allow broader commands, weaker session handling, or a separate approval process that never feeds back into the central control model.

In practice, the governance failure is not just about privilege sprawl. It is about inconsistent revocation behaviour, because removing access in one plane does not guarantee that the same principal has been removed from every other plane that can still execute or persist access.

This is especially visible when cloud access and infrastructure access are governed differently. The platform may treat cloud roles, cluster permissions, and server access as separate domains, but the attacker or operator experiences them as one continuous path if any one of them remains reachable.

For a deeper treatment of cloud privilege trimming and entitlement control, see Cloud PAM and CIEM Guide. For the protocol and registry layer that underpins the internet’s addressing and service naming model, IANA is the authoritative reference.

In cloud environments, the same problem can also show up as an incomplete view of effective permissions. If the control plane cannot reconcile direct grants, inherited rights, and platform-specific exceptions, the organisation loses confidence that revocation or least-privilege decisions are actually true everywhere they need to be true.

What a complete centralisation model has to cover

Complete coverage means more than a shared login screen. It requires a unified decision and evidence model for authentication, authorisation, command execution, session control, and logging across the protocols and cloud services that matter operationally.

At minimum, that means the central access model must be able to answer three questions consistently: who accessed it, what they were allowed to do, and what they actually did. If any major protocol or cloud path cannot answer all three in the same way, centralisation remains partial.

The useful test is to follow the most sensitive workflows end to end. If SSH admins, RDP operators, database users, and Kubernetes principals are all subject to different approval, logging, or revocation mechanics, then the organisation still has multiple access regimes, not one.

That is why mature access design focuses on coverage, not branding. A single portal, vault, or broker is not the control. The control is whether every material protocol and cloud path is actually bound to the same policy intent and the same evidence trail.

For cloud-specific privilege and entitlement reduction, the most directly relevant NHIMG resource is still Cloud PAM and CIEM Guide. For broader cloud control mapping, the CSA Cloud Controls Matrix is a useful reference point because it separates IAM, audit, and cloud infrastructure control expectations.

Risk and Threat Considerations

Partial centralisation creates a blind spot at the boundary between authenticated entry and governed activity. The organisation may believe it has one revocation path and one audit model, while in reality some protocols or cloud control surfaces still permit access, persistence, or weakly governed actions after the central platform says the principal is removed.

Failure mechanism: A user or automation is deprovisioned in the central system, but a separate protocol handler, local role, or cloud-native path still accepts the same principal, allowing continued access, incomplete logging, or inconsistent session termination.

Impact: Investigations become fragmented, revocation becomes unreliable, and an attacker or insider can use the least-governed path to bypass the intended control model without needing to defeat the central platform itself.

Practitioner Guidance

What to prioritise: Inventory the protocols and cloud paths that can still execute meaningful actions, then decide which ones are in the central policy domain and which ones are not. The dangerous condition is not “some coverage missing”, it is “missing coverage on a path that can still change state, read data, or persist access.”

What to verify: Test revocation, session expiry, and audit completeness across the highest-risk paths, especially SSH, RDP, database access, and Kubernetes administration. If the same event cannot be traced from authentication through action in a single review flow, the access model is still fragmented.

Practitioner takeaway: Treat centralised access as successful only when the same policy and evidence model governs every path that can materially affect systems, data, or privilege; otherwise you have one front door and many back doors.

Related resources from NHI Mgmt Group

• What breaks when privileged session logging does not cover every protocol?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?