Because the resource being protected is often not the server itself. Infrastructure teams use APIs, databases, cluster tools, and command-line interfaces whose access rules and audit trails differ from SSH and RDP, so a server-only model can miss real privilege use and make revocation inconsistent.
Why server-only access rules miss the governance problem
Server-only access models assume the server is the protected unit, but infrastructure work is usually executed through the interfaces that control the server, not through the box itself. API calls, database consoles, cluster tooling, and CLI access can all grant effective control while leaving SSH or RDP as only one small part of the access picture.
That mismatch creates governance risk because approval, review, and revocation are then judged against the wrong object. A team can look compliant on paper while still carrying standing permissions into platforms, control planes, and shared operational tools that are not visible in a server-centric review.
Why the audit trail becomes inconsistent across infrastructure paths
Server-centric models tend to produce one access story for host logins and a different story for everything else. The result is split evidence: host access may be logged in one system, while database actions, cluster administration, secrets access, and API usage are recorded elsewhere, if they are recorded consistently at all.
For infrastructure teams, that fragmentation matters because governance depends on being able to answer who had access, what they could do, when it was used, and how quickly it was removed. When those answers live in separate tools, reviews become incomplete and revocation can remove one path while leaving another active. NHIMG’s IAM and IGA Basics is useful background for the broader access-governance model behind that problem.
Server-only thinking also obscures privilege changes over time. A temporary debugging role on a cluster tool, a database admin grant, or a one-off CI/CD credential can outlive the server login that originally justified it. Without unified lifecycle control, the access record no longer matches operational reality.
What governance teams should treat as the real control boundary
The meaningful boundary is the set of actions an operator can perform, not the machine they can reach. If an engineer can modify data, deploy workloads, change networking, or retrieve secrets through platform tooling, then governance has to follow those permissions, not just the host account.
- Review access by function, such as admin, deploy, read-only, or secrets retrieval, not only by server login.
- Reconcile host access with platform, database, and API permissions before each recertification cycle.
- Require revocation to cover every control plane and service interface that can still exercise privilege after SSH or RDP is removed.
For teams designing that model, NHIMG’s Authorisation Models Guide helps frame the shift from server-centric permissions to policy-driven access across people, workloads, and tools. NHIMG’s Access Reviews and Certification Guide is equally relevant when the question is how to keep reviews tied to effective privilege instead of to a single login method.
Risk and Threat Considerations
Server-only access models create a blind spot that attackers and careless insiders can both exploit. If privileged work is actually performed through APIs, databases, or control-plane tools, revoking host access does not necessarily remove the ability to change configurations, extract data, or move laterally through the infrastructure stack.
Failure mechanism: Access is governed at the wrong layer, so privileged operations survive the removal of a server login and remain active in other systems with separate credentials, logs, and approval paths.
Impact: Organisations can miss standing privilege, delay incident containment, and fail audits because effective access is broader than the server-only record suggests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Server-only access models can leave excess privilege in non-host control planes. |
| AU-2 — Event Logging | Split access paths create incomplete audit evidence for privileged actions. | |
| IA-5 — Authenticator Management | Revocation consistency depends on lifecycle control of credentials across tools and services. | |
| Recommendation — Enforce least privilege across every infrastructure access path, not just server logins. Log privileged actions from servers, control planes, and APIs in a unified review stream. Track and revoke credentials consistently across all infrastructure access mechanisms. | ||
| CIS Controls v8 | CIS-5 — Account Management | Infrastructure teams need account governance beyond server-only logins. |
| Recommendation — Inventory and govern every administrative account and service credential that can alter infrastructure. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must cover all effective infrastructure interfaces, not just servers. |
| Recommendation — Define access control rules for every administrative interface and privilege path. | ||
Practitioner Guidance
What to verify: Confirm whether each infrastructure role maps to all real control paths, including cluster admin, database admin, CI/CD, cloud console, and secrets access. If the answer is no, the access model is incomplete even if server accounts are tightly controlled.
Decision rule: If a privilege can change production state without touching SSH or RDP, govern it as a first-class access path with its own approval, logging, and revocation evidence.
Practitioner takeaway: The safest model is the one that governs effective privilege, not the most visible login method. If your reviews only follow the server, your risk assessment is already behind the way infrastructure is actually operated.