Teams often treat each platform as a separate identity problem and then manage access with manual updates, duplicated policies, and one-off exceptions. That approach slows operations and increases the chance of overprovisioning, stale access, and governance gaps. It also makes it harder to prove who has access to what when audit or compliance reviews arrive.
Why manual identity management breaks down across cloud and legacy stacks
Manual identity management usually fails because the two environments do not behave the same way. Cloud platforms expose fast-moving, API-driven access paths, while legacy applications often rely on older account models, hard-coded roles, or local privileges. If teams try to govern both with spreadsheets and ticket-by-ticket updates, they end up reacting after access has already drifted.
The real problem is not just speed, it is state accuracy. Manual processes struggle to keep provisioning, deprovisioning, recertification, and exception handling aligned across platforms, so the organisation loses a trustworthy view of effective access. That is why cloud IAM and legacy application access need a shared operating model, not separate human memory and duplicate records, as reinforced by the NHI Lifecycle Management Guide and the Top 10 NHI Issues.
Manual handling also breaks down when access is tied to change velocity. Cloud roles and entitlements can be created or modified quickly, but legacy systems often depend on slower administration cycles and fragile approval chains. The result is that teams compensate with one-off exceptions, which feels practical in the moment but creates hidden policy divergence across systems.
Where manual access handling creates the most damage
Overprovisioning is the most obvious failure mode, but stale access and governance blind spots are usually more damaging over time. When joiner, mover, and leaver events are not enforced consistently, former employees, contractors, service accounts, or application roles can retain access long after the business need is gone. That creates both security exposure and audit friction.
Manual review also tends to miss inherited access paths. In cloud, effective permissions can come from nested roles, group membership, or delegated admin relationships. In legacy systems, the same user may also carry direct entitlements, local admin rights, or application-specific overrides. If teams review only the visible account record instead of the full access path, they miss the actual authority that matters.
At scale, the operational cost grows nonlinearly. A small exception pattern in one application becomes a repeatable control gap when copied into every other platform. The longer that pattern persists, the more difficult it becomes to prove why a given identity still has access, especially when audit teams ask for evidence of ownership, approval, and review history.
A useful benchmark is that only 5.7% of organisations have full visibility into their service accounts, which shows how often manual processes fail once identities are no longer centrally observable.
What practitioners should do instead
What to prioritise: standardise the access model first, then automate the enforcement layer. Teams usually try to automate after they have already accepted inconsistent role design, inconsistent ownership, and inconsistent review cadence. That reverses the order of operations and bakes manual exceptions into the system.
What to verify: every identity should have an owner, an expiration or review point, and a clear rule for how access is removed. If a team cannot answer who approved the access, when it will be revalidated, and how revocation happens across both cloud and legacy platforms, the process is not operationally controlled.
Common mistake: treating cloud as “modern” and legacy as “special”. In practice, the risk comes from inconsistent governance, not from the age of the platform. A better approach is to define a single access policy model and adapt the enforcement mechanism per system, instead of reinventing the policy each time.
Practitioner takeaway: the goal is not perfect uniformity, it is a reliable source of truth plus repeatable enforcement. If access cannot be reviewed, revoked, and explained across both environments without manual reconstruction, the programme is already behind the risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | Manual identity sprawl is an account-management problem across cloud and legacy apps. |
| 6 — Access Control Management | The question concerns inconsistent access decisions and manual exceptions across platforms. | |
| Recommendation — Centralise account inventory, lifecycle events and exception handling to reduce stale access. Define and enforce least-privilege access rules consistently across cloud and legacy systems. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The issue is failed access governance, review and enforcement across heterogeneous applications. |
| GV.RM — Risk Management Strategy | Manual identity processes create governance and audit risk that needs explicit management. | |
| Recommendation — Standardise access enforcement and review so effective permissions stay current. Set ownership and review cadences for identity risk across all application types. | ||
| NIST Zero Trust (SP 800-207) | PL-8 — Remote Access | Cloud and legacy access paths often span different trust boundaries and enforcement points. |
| Recommendation — Apply consistent policy enforcement at each access boundary instead of relying on manual exceptions. | ||
| ISO/IEC 42001:2023 | 5.2 — AI policy | Manual identity management can involve AI-assisted workflows only when identity governance is formally controlled. |
| Recommendation — Document governance rules for any AI-assisted identity decisions before scaling them. | ||
Related resources from NHI Mgmt Group
- What do teams get wrong when they try to extend single sign-on across multiple portal applications?
- What do teams get wrong about ASPM when they try to operationalise it across code, cloud, and runtime controls?
- What do teams get wrong when they try to manage SaaS incident response manually?
- What do teams get wrong when they try to get FTR-ready for cloud applications?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
