What breaks when organisations try to manage cloud applications with the same tree-based model used for LDAP?

The model breaks when cloud services enforce their own security boundaries and role structures that do not map cleanly to a single directory tree. Teams then lose precision over who can see, change, or delegate what. The result is mixed identities, coarse administration, and weak containment across applications, tenants, and business units.

Why LDAP Tree Thinking Breaks in Cloud Application Governance

LDAP encourages a hierarchical view of identity: users live in a directory tree, groups inherit structure, and administration often follows a neat parent-child model. Cloud applications do not usually behave that way. They split permissions across tenants, projects, APIs, service principals, and application-specific roles, so a single tree cannot represent the real control surface without hiding important differences. When teams force that model anyway, they lose precision in who can administer, delegate, or review access. NHI Management Group research on non-human identity operations shows that consistent access across hybrid and multi-cloud environments is already a top challenge for 35.6% of organisations, which is a strong signal that the old directory mindset does not scale cleanly into cloud control planes.

The practical problem is not just organisational neatness. A tree-based model assumes the directory is the primary source of truth for authority, but many cloud services enforce their own trust boundaries and delegated admin rules. That means one parent node can look orderly while the underlying applications still disagree about scope, inheritance, and privilege. The more the model tries to simplify, the more it encourages coarse role assignment and weak containment across business units, tenants, and workloads. In practice, many security teams discover this only after access reviews become untrustworthy or an over-broad role has already crossed an application boundary.

How Cloud Permissions Actually Map in Practice

Cloud governance works better when identity is treated as service-specific authority rather than as a single directory branch. Each application usually defines its own objects, role scopes, and delegation rules. Some use tenant-wide administrators, some use project or subscription boundaries, and some expose fine-grained permissions through policies, claims, or resource tags. That means the question is not merely where an account sits in a tree, but what action it can perform, against which resource, under which context, and with what delegation path.

This is why organisations often shift from tree thinking to a combination of workload identity, local application roles, and central policy guardrails. The directory may still authenticate the human or workload, but authorisation is increasingly decided at runtime by the target service. That separation matters because it prevents one global hierarchy from becoming a false map of authority. It also helps teams manage the difference between users, service accounts, and automated systems, which is especially important when cloud apps rely on short-lived tokens, federated access, or ephemeral credentials.

Use the directory for authentication and lifecycle ownership, but let each cloud service define its own authorisation boundary.
Model access by resource scope, tenant, and delegation path instead of assuming parent-child inheritance will hold everywhere.
Review administrative roles separately from operational roles, because the right to manage a service is not the same as the right to use it.
Prefer short-lived credentials and explicit policy evaluation when applications support them, because static directory membership is too blunt for cloud operations.

That is why many teams see the most value when they map actual permission edges, not just directory structure. NHI Management Group’s lifecycle guidance on non-human identities is useful here because cloud access usually depends on ownership, issuance, rotation, and revocation discipline rather than on directory shape alone. The NIST Cybersecurity Framework 2.0 also helps by pushing teams to organise governance around outcomes such as access control, oversight, and recovery rather than around a single identity tree. These controls tend to break down when a shared directory is assumed to govern many cloud-native services that each enforce different resource and tenancy semantics.

Common Failure Patterns When Teams Keep the LDAP Mental Model

Tighter directory centralisation often increases administrative convenience, but it also creates a tradeoff: the more you compress cloud permissions into a tree, the more you obscure real authority boundaries. That is why one of the most common failure patterns is over-reliance on inherited membership. A group may look correct in LDAP terms while the target cloud app has its own nested roles, shadow admins, or cross-tenant delegation path that the directory cannot express cleanly.

Another failure pattern is treating application access as if it were static and human-like. Cloud services often mix human users, workloads, automation, and API-driven actions under different trust rules. If teams use one directory hierarchy for all of them, they usually end up with mixed identities, broad exception handling, and manual review processes that do not match operational reality. Best practice is evolving toward explicit scoping and service-specific control views, because there is no universal standard for flattening every cloud app into one LDAP-style tree without losing important security meaning.

Practitioners should also expect review fatigue. When the model does not fit, recertification becomes a paperwork exercise instead of a real verification of access. At that point, the organisation may still believe it has central control, but it no longer has accurate containment or delegation clarity across its cloud estate.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Identity Management, Authentication, and Access Control	Cloud app access must be scoped to actual authority boundaries, not just directory structure.
Recommendation — Map access to service-specific boundaries and enforce least privilege across cloud applications.
CIS Controls v8	6 — Access Control Management	The issue is mis-scoped access and weak control over who can administer or use cloud services.
	5 — Account Management	Directory-centric models obscure ownership, lifecycle, and revocation across cloud identities.
Recommendation — Review and remove over-broad roles that inherit beyond the application boundary. Track ownership and lifecycle for each cloud identity rather than relying on tree membership.
NIST Zero Trust (SP 800-207)	3.2 — Least Privilege Access	Cloud services need explicit, bounded authorisation instead of inherited trust from a directory tree.
Recommendation — Apply least-privilege policy at the resource and application layer.
MITRE ATT&CK	T1098 — Account Manipulation	Over-broad cloud delegation can be abused to change roles, ownership, or access paths.
Recommendation — Monitor for role changes and privilege edits that expand access across cloud tenants.

Practitioner Guidance

What to prioritise: Start by inventorying where cloud applications define their own roles, tenants, and delegated admin paths. If a service can grant authority outside the directory tree, treat that service as a separate access domain rather than forcing it into inherited LDAP structure.

What to verify: Confirm that each high-value cloud app has a clear owner for role design, privilege review, and break-glass access. Verify that directory groups are not being used as a substitute for application-native scoping, especially where workload or automation access is involved.

Practitioner takeaway: The right mental model is not “how does this fit the tree?” but “where does this application actually decide authority?” Once that question is answered, the access design becomes more precise, reviewable, and containable.