Why do legacy permission problems still matter when organisations move from mainframes to cloud and SaaS?

Why legacy permission models keep surfacing after platform migration

Permission debt does not disappear when the hosting model changes. Mainframes, private data centres, cloud platforms and SaaS all still rely on identities, roles, entitlements and delegated authority to decide what is allowed. If the old model depended on broad access, manual exceptions or unclear ownership, those patterns usually reappear in the new environment, just with different control surfaces and APIs.

That is why migrations often expose the same weakness in a new wrapper. Teams may replace host-level administration with cloud roles or application admin consoles, but the underlying question remains whether each identity has only the access it genuinely needs. When that question was never tightened, the migration simply preserves inherited risk.

What changes, and what does not, when the stack moves

The technical implementation changes a lot: native accounts become federated users, batch jobs become service identities, and coarse host permissions become cloud policies or SaaS admin scopes. But the security logic is still the same. Access must be attributable, bounded and reviewable, or a newer platform will magnify older permission problems rather than solve them.

Migration also tends to hide old assumptions. A right that was acceptable on a mainframe because only a small operations team used it may become dangerous once the same role can reach cloud storage, CI/CD pipelines or SaaS administrative functions. The control objective is not preserving the old entitlement model, it is re-evaluating whether the entitlement still makes sense in the new blast radius.

For a useful migration review, start by separating permissions that are truly required from permissions that survived by habit. The strongest pattern is to compare granted access against actual use, then remove standing access that no longer maps to a current business function. NHIMG’s Privileged Access Management Guide is a practical reference for that sort of rightsizing, especially where admin access, break-glass use and standing privilege are all mixed together.

Why old permission debt becomes a cloud and SaaS problem faster

Cloud and SaaS increase the speed at which a weak permission model causes damage. They make it easier to create accounts, attach roles, share data and connect systems, which is useful when governance is strong and hazardous when it is weak. The result is often overprivilege at scale, excessive trust between services, and access that persists long after the original need has disappeared.

That risk is especially visible where legacy systems are integrated into cloud estates without a full entitlement redesign. A migration may move data and applications, but keep the same approval habits, the same service accounts, and the same emergency access paths. Once those old patterns land in a more dynamic environment, they become harder to notice and easier to exploit.

Cloud entitlement reviews are therefore not just a configuration exercise, they are a governance reset. A good baseline is to ask whether each role, token or delegated path is still justified in the new architecture, and whether the access is time-bound, scoped and monitored. NHIMG’s Cloud PAM and CIEM Guide is useful here because it connects cloud permissions, effective rights and right-sizing to the actual access surface seen in cloud estates.

Risk and Threat Considerations

Legacy permission problems matter because attackers rarely need a novel exploit if they can find an old entitlement that still works. Excessive permissions, dormant accounts, weak delegation and inherited admin access can all turn a migration into a larger attack surface, especially when one identity can reach multiple environments or control planes.

Failure mechanism: the organisation preserves broad or unclear rights while changing platforms, so the same account can pivot from an inherited permission to a materially more valuable asset in cloud or SaaS. That can support lateral movement, privilege escalation, data exposure or destructive action without breaking an explicit technical control.

Impact: the compromise of a single legacy role can affect more systems than it did before migration, because cloud and SaaS permissions often span data, automation, support tooling and administrative functions. Once the permission model is stale, incident response also becomes harder because the team must first work out what the identity was meant to be able to do.

Practitioner Guidance

What to verify: check whether each migrated role still has a current owner, a current business purpose and a current access scope. If the answer is vague, treat that entitlement as a remediation candidate rather than a tolerated exception.

What to prioritise: focus first on privileged access, cross-environment access, service accounts and any entitlement that can reach production data or administrative consoles. Those rights create the fastest route from inherited permission to material impact.

Common mistake: teams often assume that replacing a mainframe role with a cloud role or SaaS admin setting is a security improvement by itself. It is not, unless the new design reduces standing privilege, narrows scope and gives you clear review evidence.

Practitioner takeaway: migration is the moment to retire permission history, not preserve it. If access was never re-justified, the new platform usually inherits the same weakness with more reach and less visibility.

Related resources from NHI Mgmt Group

• Why do identity governance frameworks matter more as organisations move to cloud and hybrid IT?
• Why do sensitive data sharing controls matter when organisations move more work into cloud and AI tools?
• Why does identity centralization matter when organisations move to multi-cloud and hybrid architectures?
• How should transportation organisations govern AI data across cloud, SaaS, and legacy systems?