Yes, where possible, because separate models create separate revocation paths, separate audit records, and separate policy exceptions. The practical goal is not one tool for everything, but one governance view that can enforce lifecycle control across different resource types without losing evidence or ownership.
One Governance View, Not One Tool for Every Asset
A single access model is usually the right target because it gives organisations one way to express ownership, lifecycle, exception handling, and audit evidence across servers, databases, and cloud tools. The point is consistency of control, not forcing every platform into the same native mechanism. When the governance layer is unified, revocation, approval, and review stop fragmenting by technology silo.
That distinction matters because the real failure mode is usually not “different protocols exist”, but that access decisions become inconsistent when each platform invents its own rules. A good access model can still map to different authenticators, privilege boundaries, and enforcement points, as long as the policy intent stays common and the evidence remains comparable.
For practitioners, the most useful question is whether the model can express the same control objective across all three environments without losing accuracy. If the answer is yes, separate server, database, and cloud-tool processes should be treated as implementation detail, not separate governance systems.
Where the Model Has to Stay Flexible
Uniform governance does not mean identical enforcement. Servers, databases, and cloud tools expose different privilege surfaces, so the access model must accommodate different subject types, such as human admins, service accounts, workloads, and delegated tooling. A model that cannot distinguish those actors becomes too coarse to govern safely, even if it looks simple on paper.
Good practice is to centralise the decision logic and standardise the review process while allowing resource-specific controls underneath. For example, the entitlement structure for a database may be narrower than for a server, and a cloud tool may need time-bound access or scoped delegation, but all three should still feed the same governance record and revocation workflow.
This is where Authorisation Models Guide is useful, because it shows how RBAC, ABAC, ReBAC, and policy-based access control can be combined into one decision layer without flattening away resource-specific differences. For privileged cloud access, Cloud PAM and CIEM Guide adds the operational view of effective permissions, JIT access, and rightsizing.
When the model cannot preserve those distinctions, the answer is not to accept fragmentation. It is to tighten the policy vocabulary so the common governance view can still describe the different levels of privilege, approval, and revocation needed by each system.
What Breaks When Access Becomes Siloed
Separate access models usually fail in three places: revocation, auditability, and exception management. A team may remove access from one platform but leave parallel permissions active elsewhere, or approve a one-off exception in a local tool without the exception ever appearing in the central review record. That creates a control gap even when every individual system looks compliant in isolation.
Databases and cloud services are especially prone to this problem because their permission models often drift from the surrounding identity process. A database admin role, a server login, and a cloud console grant may all belong to the same operational task, yet each can end up with different owners, different expiration rules, and different evidence trails. At that point, no one can answer a simple governance question cleanly: who can still do what, and under which approval.
That is why the underlying control objective should stay aligned to a single review and revocation logic. If a privilege cannot be discovered, explained, and withdrawn through the same governance path as the rest of the estate, it is effectively outside the model even if the platform technically supports it.
Risk and Threat Considerations
Fragmented access models increase blast radius because attackers and insiders can exploit whichever path is hardest to see or revoke. The danger is not just excessive privilege, but privilege that survives in one platform after it has been removed in another, which extends dwell time and weakens audit confidence.
Failure mechanism: Separate models create inconsistent entitlements, delayed revocation, and local exceptions that bypass central oversight, especially where server, database, and cloud-tool permissions are administered by different teams.
Impact: Organisations can end up with hidden access paths, unreconciled privileges, and incomplete audit evidence, which raises the likelihood of unauthorised action, failed containment, and control exceptions that are hard to close.
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-2 — Account Management | Unified access across systems depends on consistent account lifecycle control. |
| AC-6 — Least Privilege | A single model must still enforce resource-specific privilege limits. | |
| AU-2 — Event Logging | One governance view needs comparable audit evidence across all access paths. | |
| Recommendation — Centralize account provisioning, review, and revocation across servers, databases, and cloud tools. Apply least privilege consistently while tailoring permissions to each resource type. Standardize logging so access actions from each platform remain reviewable and comparable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is fundamentally about whether access can be governed under one control model. |
| A.8.2 — Privileged access rights | Privileged access is the main operational challenge in unifying access models. | |
| A.8.5 — Secure authentication | Different resources may use different enforcement methods under one common model. | |
| Recommendation — Define one access-control policy that spans servers, databases, and cloud tools. Review and restrict privileged access through one governance process across platforms. Use consistent authentication standards while keeping the governance layer unified. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The topic is about controlling access consistently across multiple resource classes. |
| CIS-5 — Account Management | Lifecycle control is central to avoiding fragmented access revocation. | |
| Recommendation — Consolidate access control management so permissions and exceptions are governed in one place. Maintain a single account management process for all resource types. | ||
Practitioner Guidance
What to prioritise: Build one governance layer for approvals, ownership, expiration, and review, then map each platform into it through resource-specific enforcement. The first implementation win is consistent lifecycle control, not a perfect abstraction of every permission type.
What to verify: Confirm that a single user, service account, or automation path can be revoked across servers, databases, and cloud tools without manual reconciliation. If revocation still depends on platform-by-platform cleanup, the model is not yet unified in practice.
Common mistake: Treating local admin groups, database roles, and cloud IAM roles as separate governance problems because they use different mechanisms. That usually produces duplicated approvals, inconsistent recertification, and gaps in ownership.
Practitioner takeaway: Use one control framework for the lifecycle and evidence, then let the technical enforcement vary by platform. If the governance view cannot answer access, ownership, and revocation consistently, the model is too fragmented to be trusted.
Related resources from NHI Mgmt Group
- Why do organisations lose control of access as environments expand across cloud, servers, and databases?
- What breaks when organisations try to use cloud-native IAM users and roles as their main just-in-time access model?
- What breaks when organisations try to rely on one on-prem directory model for cloud, endpoint, and application access?
- Should organisations treat third-party access, cloud entitlements, and data access as one control model?