What should organisations do when remote access spans multiple protocols?

Why multi-protocol remote access needs one control model

When remote access spans VPN, RDP, SSH, VDI, vendor portals, bastions, or remote support tools, the main problem is not the protocol itself. It is the tendency for each channel to accumulate its own exceptions, credential handling, and approval logic. That creates inconsistent enforcement, uneven auditability, and hidden paths that are hard to govern as one access surface.

The practical fix is to treat remote access as a single governed capability with shared rules for who can connect, under what conditions, for how long, and to which administrative scope. A consistent model matters because the risk is usually introduced at the seams between systems, not inside one protocol alone.

Protocol diversity also changes how controls are applied. One channel may support MFA and device checks natively, another may rely on a gateway, and a third may expose interactive admin sessions directly. If policy is not standardised above the protocol layer, teams end up compensating with local workarounds that are difficult to review and easy to forget.

What “standardise governance” should mean in practice

Standardising governance means defining the control intent once and then enforcing it across every access path. The organisation should decide which identity is allowed, what administrative role it receives, whether the access is permanent or time-bound, and what proof is required before the session starts. That policy should be explicit enough to survive differences in transport, tooling, or vendor implementation.

It also means mapping every administrative path. Remote access is often broader than the obvious entry points: backup consoles, support portals, jump hosts, appliance web interfaces, and emergency channels may all bypass the intended access model if they are not inventoried and owned. For identity-centred remote access design, NHIMG’s Remote Access Identity Guide is a useful reference point because it frames VPNs, ZTNA, device posture, and dormant access accounts as one governance problem.

Time-bound access should be the default for elevated remote administration. If a session is meant to be temporary, the control should expire automatically, not depend on manual cleanup after the fact. Where the protocol supports it, organisations should prefer brokered access and session control over standing credentials or direct exposure of privileged services.

How to reduce exceptions without breaking operations

The hardest part is usually not writing the policy, but removing exceptions that have become operational habits. Legacy VPN accounts, vendor-maintained support paths, and direct admin logins often survive because they are convenient, not because they are defensible. The goal is to collapse those paths into the same approval, authentication, and review pattern so that “special case” access cannot quietly become the norm.

For administratively sensitive remote sessions, organisations should prefer controls that make the session visible and bounded. NHIMG’s Privileged Session Management Guide is relevant here because it focuses on brokering, recording, and controlling privileged sessions rather than assuming the protocol alone is enough. In environments such as OT or vendor support, OT and ICS Identity and Access Guide shows why shared accounts and remote maintenance paths need the same discipline as IT administration.

Consistency also depends on decommissioning obsolete routes. If a protocol or tool cannot meet the common governance baseline, retire it or isolate it rather than letting it remain as an unreviewed exception. The control model should make the exception cost visible, so that convenience is no longer mistaken for acceptable risk.

Risk and Threat Considerations

Multi-protocol remote access increases the chance that one weak channel becomes the easiest entry point into privileged systems. Adversaries do not need every path to be weak, only one overlooked account, one unaudited portal, or one direct login that sits outside the intended policy model. A single bypass can undermine the value of stronger controls elsewhere.

Failure mechanism: Different protocols often enforce different authentication strength, session handling, and approval flows, which creates gaps in review and inconsistent privilege boundaries. Attackers and insiders can exploit the weakest route, or reuse valid credentials against a channel that lacks the same checks as the others.

Impact: Once a remote administrative path is compromised, the exposure is usually broad because the access is already trusted and operationally privileged. That can lead to lateral movement, persistence, data access, or direct administrative control, especially when exceptions are not time-limited or session-recorded.

Practitioner Guidance

What to verify: Verify that every remote administration path is mapped to one owner, one approval model, and one expiration rule. If a route cannot be tied back to the standard policy, treat it as an exception that needs closure, not as a parallel operating model.

Decision rule: If a protocol cannot support the organisation’s baseline for identity proof, authorization, and session time limits, wrap it with a broker or retire it from privileged use. Do not allow protocol-specific convenience to override access governance for administrative actions.

Practitioner takeaway: The objective is not to make every protocol identical, but to make every privileged path behave as if it is governed by the same access standard, because that is what keeps operational convenience from becoming an untracked control gap.

Related resources from NHI Mgmt Group

• What should organisations do when access spans multiple systems and business units?
• How should healthcare organisations implement remote identity proofing when patients need access across multiple providers?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?