Identity-first modernization needs fewer legacy trust assumptions

At a glance

What this is: This survey argues that modernising infrastructure depends on putting identity at the centre of cloud migration, API access, and legacy application retirement.

Why it matters: It matters because IAM teams must support hybrid estates, modern authentication, and application refactoring without creating new access gaps across human, workload, and service identities.

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.
• 38% of businesses are spending their IT budget on maintaining legacy infrastructure, and 43% see these costs as a barrier to innovation.

👉 Read Okta's article on identity-led infrastructure modernization

Context

Identity is the control plane that lets modern applications authenticate users, broker access to APIs, and keep legacy systems usable during migration. The article’s central claim is that modernization only works when identity moves from an add-on to the core of the stack, especially in hybrid environments where old and new systems must coexist.

For IAM teams, the practical question is not whether to modernize, but how to avoid carrying old access patterns into cloud services, microservices, and customer-facing flows. The article frames common blockers such as security concerns, customer friction, and developer agility as identity problems as much as infrastructure problems.

That is a familiar pattern for large enterprises: they do not fail modernization because the destination is unclear, but because the transition period exposes weak identity governance. The starting point described here is typical for organisations with entrenched legacy estates and a growing cloud footprint.

Key questions

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. A hybrid identity layer can broker access across old directories, cloud services, and modern applications without forcing a disruptive cutover. The key is to reduce duplicated trust paths and make every access route visible and revocable.

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. They also resist modern controls such as federation and MFA. That combination turns identity into a barrier to migration, because each application requires bespoke exceptions to keep the business running.

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. That creates access that is difficult to audit and easy to overextend. Modernisation then increases the number of identity connections without improving the control over them, which undermines the point of refactoring.

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.

Technical breakdown

Identity as a control plane for hybrid-cloud migration

Identity as a service lets organisations separate authentication and authorisation from the underlying application stack. In hybrid environments, that means legacy directories, modern federation protocols, and application-specific access policies can coexist without forcing a full rip-and-replace migration. The architectural value is not simply convenience. It is the ability to centralise access decisions while the workload estate remains mixed, which reduces drift between old applications and cloud-native services. When identity is inconsistent across those layers, security controls become uneven and hard to audit.

Practical implication: Use a single identity layer to govern access across legacy and cloud applications before expanding migration scope.

OIDC and OAuth 2.0 in application modernization

OpenID Connect handles authentication, while OAuth 2.0 handles delegated authorisation to APIs and services. Together, they let application teams move away from hard-coded sessions and bespoke login flows toward standard federation and scoped access. That matters in modern architectures because APIs become the connective tissue between services, customers, partners, and internal systems. If teams do not understand token scope, consent boundaries, and revocation paths, modernisation can replace one brittle access model with another, especially when older apps are adapted without redesigning their identity flows.

Practical implication: Map API access to explicit scopes and revocation paths instead of reusing legacy authentication patterns.

Microservices, refactoring, and least privilege

Microservices break a monolith into smaller services that can be updated and scaled independently. That improves delivery speed, but it also increases the number of identities, permissions, and service interactions that need governance. Each service call becomes an access decision, which makes least privilege and access lifecycle management more important, not less. Refactoring without identity discipline can create a large mesh of over-entitled services that are difficult to inspect, especially when development teams prioritise speed over control boundaries.

Practical implication: Treat every new service boundary as an access boundary and recertify permissions as applications are decomposed.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Legacy infrastructure creates an identity debt problem, not just an infrastructure cost problem. When 38% of budget is consumed by maintenance and 43% of organisations see cost as a barrier to innovation, the programme is already paying for delay. That delay usually preserves old authentication paths, old trust assumptions, and old admin models inside newer systems. The implication is that modernisation work must retire inherited access patterns, not simply move them.

API access management is the real control point in modern application stacks. The article’s emphasis on OAuth 2.0 and API access management reflects a broader industry reality: most application trust now moves through machine-mediated calls. That makes scope design, token revocation, and policy consistency more important than perimeter controls. Practitioners should shift governance attention from the interface to the permission model behind it.

Microservices expand governance surface area faster than many IAM programmes can inspect it. The move from monoliths to loosely coupled services increases the number of identities, entitlements, and trust relationships that must be reviewed. Without a lifecycle model for service access, decomposition can create more risk than resilience. The practitioner takeaway is to align service decomposition with access governance, not after it.

Customer identity is part of infrastructure modernisation, not a separate UX project. The article links seamless sign-in, biometric convenience, and authentication standards to business outcomes such as agility and customer experience. That is the right framing. If the identity layer cannot support modern sign-in patterns, the organisation will either add friction or keep brittle legacy dependencies alive. Teams should design customer identity as a core modernization dependency.

From our research:

• 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.
• For lifecycle and access governance, 52 NHI Breaches Analysis shows how exposure and over-privilege turn into incident paths when controls lag behind change.

What this signals

Identity modernisation is becoming a governance programme, not a platform upgrade. As enterprises move toward hybrid-cloud and microservices models, the deciding factor is whether access can be made visible, reviewable, and revocable across old and new systems. Teams that treat identity as architecture, not tooling, will find it easier to reduce legacy risk without freezing delivery.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey, the modernisation lesson extends beyond traditional applications. The next wave of platforms will fail if identity programmes stay human-centric while machine-driven access expands.

Identity blast radius: the real modernization risk is how far a mis-scoped identity can travel once cloud APIs, legacy connectors, and service accounts are tied together. The programme signal to watch is not just migration progress, but whether each new integration reduces or expands the trust surface.

For practitioners

• Inventory identity dependencies before migrating workloads Map every legacy directory, application login flow, API, and service account that will be touched by the migration. Identify where authentication, authorisation, and provisioning are still embedded in the application rather than centrally governed.
• 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. If an app cannot participate in modern identity controls, treat it as a risk to the wider programme rather than a standalone technical debt item.
• Align refactoring with access recertification When decomposing monoliths into microservices, recertify the permissions, service relationships, and admin paths created by the new architecture before expanding the rollout.

Key takeaways

• Modernisation succeeds or fails on identity architecture, not infrastructure ambition alone.
• Legacy systems create cost pressure, security friction, and governance debt that compound as cloud adoption grows.
• Teams should refactor access models, retire incompatible applications, and govern APIs and services as first-class identity boundaries.

Key terms

• Identity as a Service: Identity as a service is a delivery model where authentication, federation, and access policy are provided centrally rather than built into each application. In modernization programmes, it helps legacy and cloud systems share one control layer, which reduces duplicated logic and makes access governance easier to inspect and change.
• Microservices Architecture: A microservices architecture splits an application into smaller services that communicate over defined interfaces. This improves update speed and scaling, but it also increases the number of identity relationships, access scopes, and service-to-service permissions that must be governed consistently.
• API Access Management: API access management is the control of who or what can call an API, under what scope, and for how long. It is a core modernization control because APIs often become the main trust boundary between cloud services, legacy systems, partners, and internal applications.
• Hybrid-cloud Identity: Hybrid-cloud identity is the governance pattern that lets an organisation operate legacy and cloud systems under a shared access model. It matters when migration is gradual, because the identity layer must bridge old directories, modern federation, and application-specific permissions without creating parallel trust structures.

Deepen your knowledge

Identity modernization and hybrid access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are managing legacy systems alongside cloud services, it is a relevant place to build that control model.

This post draws on content published by Okta: Modern Infrastructure and Development, focused on using identity to scale modernization. Read the original.