Why do large organisations struggle with traditional access models when teams, subsidiaries, and projects expand?

Traditional access models often force a tradeoff between central control and operational speed. As organisations grow, merge, or spin up temporary teams, broad admin access creates risk, while overly centralised approval paths slow work. Fine-grained delegation helps preserve governance without making every access decision a bottleneck for security and operations.

Why This Matters for Security Teams

As organisations add subsidiaries, contractors, shared services, and temporary project teams, access stops being a simple joiner-mover-leaver problem. The real issue is delegation at scale: who can grant what, for how long, and under which business context. Traditional models built around fixed roles and central approvals tend to collapse under this pressure because they assume stable organisational boundaries, not constantly changing operating units.

NHIMG research shows how quickly this becomes a governance problem, not just an IT one. In the Ultimate Guide to NHIs, NHI Mgmt Group notes that excessive privileges are common across NHI estates, which is exactly what happens when teams respond to speed pressure by widening access rather than refining control. Current guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10 both points to least privilege and strong accountability, but the challenge is operationalizing those principles across business units that keep multiplying.

In practice, many security teams discover access sprawl only after a reorganisation, acquisition, or urgent delivery program has already made broad delegation the default.

How It Works in Practice

The practical fix is not to centralise every approval. It is to design delegation that is narrow, time-bound, and observable. Large organisations usually need a model where the parent enterprise sets policy, while subsidiaries and project leads can request or approve access within predefined bounds. That means separating authority to approve from authority to use, and logging both.

A workable pattern is to combine role-based control with context-aware restrictions. Static RBAC still has value for baseline entitlements, but it should be paired with policy rules that consider business unit, data sensitivity, environment, and time. For service accounts, API keys, and automation identities, organisations should prefer short-lived secrets and JIT issuance rather than standing access. That aligns with current best practice in the OWASP Non-Human Identity Top 10, which treats excessive privilege and weak lifecycle control as core risks.

• Use a central policy baseline, but delegate within bounded scopes such as project, region, or subsidiary.
• Issue credentials just in time and revoke them automatically when the task ends.
• Review access against business purpose, not only job title or team name.
• Track who approved access, why it was approved, and when it expires.

For identity governance, this works best when paired with service-account inventory, secrets rotation, and periodic entitlement review. NHIMG’s Ultimate Guide to NHIs is useful here because it frames the lifecycle problem: expansion creates more identities, more boundaries, and more chances for stale access to persist. These controls tend to break down when organisations treat temporary projects like permanent business units because the access model then accumulates exceptions faster than reviews can remove them.

Common Variations and Edge Cases

Tighter delegation often increases administrative overhead, requiring organisations to balance speed against assurance. That tradeoff becomes sharper in mergers, outsourced operations, and matrixed product groups, where multiple managers may believe they own the same access decision. Current guidance suggests that there is no universal standard for this yet; organisations should choose the smallest delegation scope that still allows work to proceed.

One common edge case is cross-entity access, where a shared service team supports several subsidiaries. Here, a single global role usually becomes too broad, but fully local roles create duplication and audit gaps. Another edge case is emergency access: if break-glass paths are too rigid, teams bypass them; if they are too loose, they become standing backdoors. Organisations should therefore keep emergency access separate, heavily monitored, and time-limited.

Expansion also changes the control objective. At small scale, the question is “who can access this system?” At enterprise scale, the better question is “who can delegate access safely, and how is that delegation revoked when the project, subsidiary, or vendor relationship changes?” The 52 NHI Breaches Analysis reinforces why this matters: once identity boundaries blur, incidents often spread through privileged accounts and overlooked trust relationships rather than through a single obvious failure.

Related resources from NHI Mgmt Group

• Why do organisations struggle to govern access effectively as identity estates grow across SaaS and hybrid systems?
• How should organisations compare privileged remote access and traditional VPN access for external partners?
• How should organisations structure user access management to reduce access creep in growing teams?
• How should security teams restrict new cloud permissions before they expand access to humans and machine identities?