Why app modernization can leave you less secure

Enterprises typically “modernize” access patterns for an application by enabling industry standard protocols like OIDC or SAML to provide single sign-on (SSO) for legacy apps via a cloud identity provider (IDP). That’s a major step towards better user experience, improved credential hygiene, and centralized authentication, but it is not enough.

Most modernization projects stop at the authentication layer, believing that identity transformation is complete once SAML or OIDC is wired up. What’s often overlooked is one of the most critical components of application security: session management.

SSO protocols handle the front door. But once you’re in, session management governs everything that happens from that point forward: how long you stay logged in, how sessions are revoked, how access is revalidated, and how identity context is maintained.

Historically, these responsibilities were handled by web access management (WAM) systems. These centralized platforms managed authentication, session handling, authorization, and user directory integrations. They enforced consistent timeout policies, provided real-time session revocation, and gave security teams visibility across all user interactions. WAM tools weren’t perfect, but they provided enterprise-grade control.

With the rise of cloud identity systems and federated login protocols, we traded many of these baked-in WAM capabilities for the convenience of open standards and federation. The problem? Most cloud identity providers don’t manage sessions inside the application itself, that job is left to the app developers.

Decentralized session logic introduces risk

In most enterprises, session management is implemented using the capabilities native to the application’s framework. A Java app might use Spring Security. A JavaScript front-end might rely on Node.js middleware. Ruby on Rails handles sessions differently still. Even among apps using the same language or framework, configurations often vary widely across teams, especially in organizations with distributed development or recent acquisitions.

This fragmentation creates real-world risks: inconsistent timeout policies, delayed patching, and session revocation gaps

Also, there’s the problem of developer turnover: Many legacy applications were developed by teams that are no longer with the organization, and without institutional knowledge or centralized visibility, updating or auditing session behavior becomes a guessing game.

Security teams may assume that their identity provider can revoke access instantly. But unless the application is calling back to that identity system for session validation – which most don’t – it’s more of an illusion than a guarantee.

Centralized control matters more than ever

The lesson here isn’t that we should revert to legacy identity infrastructure. Rather, it’s that we must restore some of the centralized control and visibility that WAM systems once provided, particularly around session management.

Identity and access management (IAM) should be treated as a shared service, not something that gets implemented ad hoc in every application.

By restoring centralized session oversight, organizations gain:

• Immediate session revocation across all applications and environments
• Consistent timeout enforcement aligned with security and compliance policies and mandates
• Unified audit logging for identity-related activity
• Real-time integration with continuous access evaluation protocols (CAEP) and Zero Trust intelligence feeds

These aren’t theoretical concerns; they’re foundational requirements for modern enterprise security.

The role of standards in multi-cloud identity

As one of the original authors of the SAML standard, I’ve seen how identity protocols evolve and where they fall short. When we scoped SAML to focus exclusively on SSO, we knew we were leaving other critical areas (like authorization and user provisioning) out of the equation. That’s why other standards emerged, including SPML, AuthXML, and now efforts like IDQL (Identity Query Language).

The need for identity systems that interoperate securely across clouds isn’t new, it’s just more urgent now. And part of that interoperability includes consistent session behavior across heterogeneous environments.

What CISOs and identity architects should do now

If you’re leading a modernization initiative and relying on SAML or OIDC as proof of “being done,” it’s time to reassess. Here’s what I recommend:

1. Conduct a session management audit

Map how sessions are handled across your critical apps. Identify inconsistencies in timeouts, revocation capabilities, and patch hygiene.

2. Re-centralize session control

Whether through a centralized proxy, standardized SDK, or a service mesh-aware identity layer, find a way to bring session oversight under one roof.

3. Plan for continuous evaluation and revocation

Integrate with CAEP or build equivalent mechanisms to enable dynamic session control based on risk signals.

4. Treat IAM as infrastructure

Just like DNS, networking, or TLS, identity services should be globally managed, continuously validated, and resilient.

Application identity modernization is a journey, not a checkbox. Modern protocols like SAML and OIDC solve the front-door problem, but don’t secure the entire house. For that, we need the kind of centralized, consistent, and enforceable identity management that CISOs used to take for granted, and must now find new ways to deliver.

Until session management is standardized and controlled at scale, your identity architecture isn’t modern. It’s just incomplete.