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.
At a glance
What this is: This is an Okta analysis of application modernization that argues identity should be the control plane for cloud migration, legacy integration, and microservices scale.
Why it matters: It matters because IAM teams often inherit modernization risk through SSO, API access, MFA, and hybrid identity design long before infrastructure decisions feel finished.
By the numbers:
- 50% of respondents are worried about the security of their data as they migrate to the cloud.
- 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.
- 43% see these costs as a barrier to innovation.
Context
Modern infrastructure modernization is the process of replacing or refactoring legacy systems so applications can scale, move faster, and rely on current security controls instead of inherited trust. In this article, Okta frames the core issue as identity and access management, not infrastructure alone.
The article argues that cloud migration, microservices, and API adoption all fail faster when legacy identity patterns are carried forward unchanged. For IAM teams, the question is whether authentication, authorization, and lifecycle control can be modernized without leaving old trust assumptions embedded in new architectures.
Key questions
Q: How should teams modernize legacy infrastructure without carrying old access assumptions forward?
A: Start by making identity the control plane for the migration. Every inherited trust path should be replaced with explicit authentication, authorization, and policy enforcement so that cloud adoption does not preserve hidden shortcuts from the old environment.
Q: Why do legacy security systems create more risk as organisations adopt cloud and mobile tools?
A: Legacy systems create risk because they are often patched poorly, configured insecurely, or forced to sit between older and newer environments. That increases blind spots, weakens control over application access, and makes breach response harder. As organisations connect more services and users, outdated controls become a bottleneck that can undermine both security and business agility.
Q: What breaks when legacy applications cannot support modern authentication methods?
A: Organisations often create permanent exceptions, alternate login paths, or password-based recovery for those systems. Over time, those exceptions become the real control plane for access. That is why legacy compatibility has to be tracked as an identity risk, not just a project dependency.
A: Migration moves the workload, while refactoring changes the way the application is built and governed. Refactoring into cloud-native services reduces monolithic dependencies, but it also requires stronger identity and API controls because the access surface becomes more distributed.
Technical breakdown
Identity as the modernization control plane
Modernization succeeds when identity becomes the control plane for access, not a bolt-on after migration. That means authentication, authorization, directory integration, and session policy have to travel with the workload as systems move from on-premises to cloud or hybrid environments. SAML and OpenID Connect matter here because they let modern apps federate access without reusing legacy sign-in patterns. The real architectural shift is that access decisions need to be centrally governed even when applications are refactored, decomposed, or distributed across platforms.
Practical implication: treat identity integration as a migration dependency, not a post-move cleanup task.
Why legacy trust assumptions break in hybrid cloud
Legacy environments often assume that network location, static infrastructure, or long-lived application trust can stand in for modern authorization. That assumption breaks in hybrid cloud because applications, users, and backend services no longer sit inside a single perimeter, and access has to be explicit at each layer. The article points to API security and modern authentication frameworks as weak spots because many teams still lack the skills or controls to manage access consistently across older and newer systems. In practice, modernization fails when old trust shortcuts remain invisible inside the new architecture.
Practical implication: re-map every inherited trust path to an explicit identity and authorization control.
Microservices and api access management change the control surface
Microservices reduce the blast radius of change, but they also multiply the number of service-to-service and application-to-API decisions that must be governed. API access management is therefore not just a convenience layer, it is where policy-based grant and revoke decisions happen for machine-to-machine access. That becomes especially important when legacy applications are retained alongside cloud-native services, because each boundary needs a different access pattern. Without that governance layer, modernization can increase flexibility while also increasing the number of exposed paths.
Practical implication: enforce policy-based API access management before decomposing monoliths into services.
Threat narrative
Attacker objective: The attacker objective is to exploit inconsistent access control across legacy and modern systems to reach applications, data, or backend services that should have been isolated.
- Entry occurs when legacy applications, directories, and APIs are brought into hybrid cloud environments without rebuilding the access model around modern identity standards.
- Credential or access exposure emerges when old sign-in patterns, inconsistent policies, or weak API controls are reused across newer services.
- Impact follows when modernization expands the control surface faster than identity governance can constrain it, increasing the chance of security gaps and operational mismanagement.
Breaches seen in the wild
- Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.
- MGM Resorts breach 2023: A help desk call gave attackers Okta and Azure admin access at MGM, leading to ransomware, ten days of outages and a $100 million hit.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legacy trust assumptions, not cloud migration itself, are the real modernization hazard. The article is strongest when it shows that the failure mode is inherited trust, not infrastructure change alone. Static perimeter thinking, long-lived application assumptions, and inconsistent policy enforcement all become weaker as systems move into hybrid cloud. Practitioners should treat modernization as a trust-model rewrite, not a lift-and-shift exercise.
Identity-first modernization works because it collapses access logic into a governable layer. SAML, OpenID Connect, and API access management are doing more than connecting systems. They create a way to centralize access decisions while still allowing legacy and modern applications to coexist. The implication is that IAM becomes the mechanism for preserving continuity without preserving the old security model.
Microservices increase the need for authorization discipline even as they improve agility. The article correctly ties decomposition to scale, but each new service boundary also adds another place where access can go wrong. That makes policy consistency more important than platform count. Practitioners should measure modernization success by whether authorization is still understandable after the architecture changes.
Inherited trust debt: legacy systems do not just carry technical baggage, they carry access assumptions that modern architectures cannot safely inherit. Once those assumptions are embedded in cloud migration plans, they become a governance problem as much as a technical one. The right question is not whether the stack is modern, but whether the access model has been modernized with it.
Customer identity and internal application modernization are linked by the same control requirement. The article frames customer experience and developer agility as separate pains, but both depend on identity that can flex across old and new systems without reintroducing weak trust paths. That is why IAM and lifecycle governance sit at the center of modernization, not at the edge. Practitioners should design for coexistence, not dependency on legacy exceptions.
What this signals
Inherited trust debt: modernization programmes fail when access shortcuts from legacy environments are allowed to survive the migration. The governance task is to remove implicit trust, not just move infrastructure.
Identity teams should expect more pressure on API authorization, federation, and lifecycle control as monoliths split into distributed services. That shift makes policy consistency a core programme metric, not an implementation detail.
For practitioners
- Map inherited trust paths Inventory where legacy applications still rely on network location, static directory trust, or broad backend permissions. Replace each assumption with an explicit identity control tied to authentication, authorization, and session policy.
- Prioritise API access management Apply policy-based grant and revoke logic to service and application APIs before expanding microservices or hybrid integrations. This reduces the chance that modernization simply multiplies exposed access paths.
- Separate modern and legacy access patterns Keep high-sensitivity systems on the tightest controls while migrating less sensitive applications or frequently accessed services into modern identity flows. Do not allow old sign-on shortcuts to persist by default.
- Retire applications that block modern authentication Flag legacy homegrown systems that cannot support MFA, OIDC, or consistent policy enforcement. If a system cannot be modernized, place it on a retirement track rather than letting it dictate the access model.
- Measure modernization by access consistency Check whether the same user or service can be authenticated, authorized, and governed consistently across cloud and on-prem environments. If access rules diverge by platform, the modernization programme is incomplete.
Key takeaways
- Legacy modernization is an identity governance problem as much as an infrastructure problem, because the old trust model can survive inside new architectures.
- Okta’s survey shows that security concerns, legacy costs, and policy misalignment are already blocking modernization decisions for many large organisations.
- The practical response is to modernize access controls alongside applications so that cloud, hybrid, and microservice environments share the same authorization logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on explicit access control across hybrid modernization. |
| Recommendation — Align modernization plans to PR.AA-05 so access stays governed as applications move across environments. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Legacy modernization often preserves broad, inherited access that should be narrowed. |
| Recommendation — Reduce inherited privilege paths and reissue access under least-privilege identity rules. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | The article flags API access management as a weak point in modernization. |
| Recommendation — Apply function-level authorization checks to APIs before exposing legacy services to modern clients. | ||
| CIS Controls v8 | CIS-5 — Account Management | Modernization depends on centralised account and access governance across old and new systems. |
| Recommendation — Use account management controls to standardize access across legacy and cloud environments. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Principles — Zero Trust Principles | The article's core message is to remove implicit trust during migration. |
| Recommendation — Adopt zero trust principles so modernization does not rely on network location or legacy perimeter trust. | ||
Key terms
- Identity-first modernization: An approach to infrastructure change that treats identity and access management as the primary control layer for migration. The goal is to preserve business continuity while replacing legacy trust assumptions with explicit authentication, authorization, and policy enforcement across cloud, hybrid, and modern application architectures.
- Legacy trust assumptions: Security assumptions inherited from older systems that depend on static network boundaries, monolithic application design, or broad internal trust. In modernization programmes, these assumptions become risk factors because distributed architectures need explicit identity controls instead of implied trust.
- API Access Management: API Access Management is the control of who can call an API, what they can do, and under what conditions. It combines authentication, authorization, token handling, rate limits, logging, and policy enforcement to protect machine-to-machine interactions, reduce abuse, and ensure each request is traceable, least-privileged, and compliant.
- Hybrid Cloud Identity Control: Hybrid cloud identity control is the practice of enforcing consistent access and visibility rules across on-premises and cloud environments. It becomes difficult when identity telemetry, policy enforcement, and data protection are split across platforms that do not share a common governance model.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org