Notifications
Clear all
Topic starter
07/06/2026 8:13 pm
TL;DR: Cloud migration, security concerns, and legacy system costs are the main blockers to modernization, according to Okta’s survey of 100 IT and app development leaders. The real issue is not just infrastructure change, but whether identity and access controls can carry modern applications without preserving legacy trust assumptions.
NHIMG editorial — based on content published by Okta: Modern Infrastructure and Development, focused on using identity to scale modernization
By the numbers:
- 50% of respondents are worried about the security of their data as they migrate to the cloud among several other challenges.
- 32% of those polled said they’re struggling with security due to their aging, on-prem systems.
Questions worth separating out
Q: How should teams modernise identity when cloud and legacy systems must coexist?
A: Start by centralising authentication and policy decisions while leaving workloads in place during transition.
Q: Why do legacy applications slow down modernization efforts?
A: Legacy applications often embed authentication, authorisation, and admin logic inside the app itself, which makes change slow and risky.
Q: What breaks when API security is treated as an afterthought in modernization projects?
A: Teams usually end up with inconsistent token handling, unclear scopes, and weak revocation paths across services.
Practitioner guidance
- Inventory identity dependencies before migrating workloads Map every legacy directory, application login flow, API, and service account that will be touched by the migration.
- Standardise API authorisation on scoped federation Replace bespoke API access patterns with OAuth 2.0 scopes and revocation controls so that access can be reviewed and withdrawn consistently across services and partners.
- Retire apps that cannot support modern authentication Prioritise legacy applications that block MFA, federation, or reliable policy enforcement.
What's in the full article
Okta's full blog post covers the operational detail this post intentionally leaves for the source:
- Direct integrations with legacy directories such as Active Directory and LDAP for hybrid migration planning.
- The five-step modernization sequence with practical examples of when to migrate, refactor, or retire applications.
- Platform-specific implementation details for API access management, MFA rollout, and identity-as-a-service integration.
- The Motorists Insurance Group example showing how application choices were assembled across a modernised service stack.
👉 Read Okta's article on identity-led infrastructure modernization →
Legacy infrastructure modernization: what IAM teams need to know?
Explore further
07/06/2026 10:02 pm
Identity modernisation fails when organisations treat access as a migration detail rather than the migration path. The article shows that cloud adoption, API security, and app refactoring all depend on the same underlying identity decisions. Once identity is inconsistent across legacy and modern systems, security and usability both degrade. Practitioners should treat identity architecture as the first design decision in any modernisation programme.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means many modernisation programmes still lack basic machine-identity inventory discipline.
A question worth separating out:
Q: How do security teams decide which legacy systems to retire first?
A: Start with the applications that cannot support modern authentication, consistent policy enforcement, or reliable access review. Those systems create the most friction and the most governance debt. If a platform cannot safely participate in hybrid identity management, it should move to the front of the retirement queue.
👉 Read our full editorial: Identity-first modernization needs fewer legacy trust assumptions
