Legacy web apps still expose identity gaps after IE11

At a glance

What this is: This is an Island blog post on supporting legacy web apps in a modern browser model, with the key finding that MFA, shared credential handling, and IE11 compatibility can be addressed without changing brittle application code.

Why it matters: It matters because IAM, PAM, and application owners still inherit legacy access patterns that weaken visibility, complicate offboarding, and leave shared credentials outside normal governance controls.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Island's blog post on supporting legacy web apps with modern identity controls

Context

Legacy web apps are not just a compatibility problem. They are an identity governance problem because many were designed before MFA, before strong session controls, and before modern offboarding expectations, so access often depends on shared credentials and browser workarounds.

The primary issue is that the application model and the identity model no longer match. When authentication cannot be modernised inside the app, teams still need a way to preserve accountability, enforce step-up verification, and prevent password disclosure at the point of use.

For organisations with older business-critical systems, this is typical rather than exceptional. The real question is whether access is being governed as a modern identity problem or left as a convenience exception.

Key questions

Q: How should security teams add MFA to legacy apps without changing the origin?

A: Place the authentication decision at the front door, such as CloudFront or another reverse proxy layer, and preserve only the minimum state needed to complete the login flow. Encrypt any temporary data, keep challenge state short-lived, and test the full redirect path so the origin remains unchanged but the sign-in policy is still enforced.

Q: What breaks when a legacy application still uses shared administrator credentials?

A: Individual accountability breaks first, then revocation and rotation become unreliable. The application sees one password, not one user, so offboarding can be missed and audit trails lose meaning. If access is shared, you need an external control layer that ties activity to named identities.

Q: How do security teams know whether browser-based legacy access is actually improving governance?

A: Look for three signals: named-user attribution for every login, password disclosure removed from the user workflow, and revocation that happens through identity controls rather than manual password resets. If those signals are absent, the organisation has only changed the front end.

Q: Who is accountable for identity controls around legacy web applications?

A: Accountability usually sits with both application ownership and IAM or PAM governance. The application team owns the business process, while identity teams own the access path, revocation design, and auditability. If shared credentials persist, ownership must be explicit or the control will drift.

Technical breakdown

Why legacy web apps resist native MFA

Older web applications often hard-code authentication logic or depend on form-based logins that were never designed for step-up verification. MFA usually requires the app to support a modern identity flow, but browser mediation can shift the control point to the access layer. In practice, the browser becomes the policy enforcement point, integrating with the enterprise identity provider and prompting for stronger authentication before the session reaches the application. This works because the browser can assert user identity without refactoring brittle code, while preserving legacy app behaviour behind the scenes.

Practical implication: place MFA enforcement at the browser or access layer when the application cannot support it natively.

Shared credentials and the loss of accountability

Shared administrator accounts create a governance problem because the application sees one credential, not one person. That means user attribution, revocation, and rotation all break down unless another layer records who authenticated and when. Browser-based credential mediation can hide the password from the user, bind use to named identities or groups, and preserve an auditable event trail for each login. This does not make shared credentials ideal, but it does restore some accountability where the application itself cannot.

Practical implication: wrap shared credential use in an access-control layer that records individual user activity and supports revocation without password disclosure.

IE11 compatibility without leaving identity controls behind

IE11 compatibility mode is a transport and rendering issue, not an identity solution. Organisations that move only to a compatibility layer risk preserving legacy access patterns without fixing authentication weakness or revocation gaps. The architectural value comes when compatibility is combined with identity-aware policy, so the same browser session can support old application behaviour while still applying modern verification, credential handling, and logging. That makes compatibility an enabler, not the end state.

Practical implication: do not treat compatibility mode as the security answer unless it is paired with identity enforcement and auditability.

NHI Mgmt Group analysis

Legacy application access is still an identity governance problem, not a browser preference issue. The article is about compatibility, but the real control gap is that old applications often sit outside modern authentication and offboarding design. When access survives because the application cannot be refactored, governance shifts to the surrounding access layer. Practitioners should treat these systems as exceptions that need explicit identity controls, not as harmless technical debt.

Shared credentials create accountability collapse because the application no longer knows who acted. Once multiple users share the same password, revocation becomes imprecise and audit evidence weakens. That is the same failure pattern seen in many NHI problems: one secret, many users, and no clean lifecycle boundary. Teams need to recognise that this is a governance failure at the identity layer, not merely an application convenience.

Browser-mediated authentication is a compensating control, not a licence to ignore the source system. It can restore MFA, recording, and credential concealment without modifying brittle code, which is useful when the legacy app cannot be replaced quickly. But the operating model still depends on clear ownership of the access path, periodic review of who is allowed to use it, and a plan to retire shared secrets where possible.

Legacy compatibility programmes should be measured by identity outcomes, not just uptime. Supporting IE11 mode or an enterprise browser may keep the business running, but the security test is whether user attribution improves, password exposure shrinks, and offboarding becomes enforceable. If those three do not change, the programme has modernised the interface without modernising access governance.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• The NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding controls need to be governed as one lifecycle, not separate tasks.

What this signals

Legacy application remediation programmes should be measured against identity outcomes, not compatibility outcomes alone. If a browser wrapper improves access continuity but leaves shared passwords, weak revocation, and poor attribution in place, the organisation has modernised the interface while preserving the control gap.

Shared-credential debt: this is the point where operational convenience becomes identity risk because one password now represents many users and many decisions. That debt shows up later as audit ambiguity, delayed offboarding, and unnecessary standing access in systems that should already have been retired.

The next governance step is to align legacy access patterns with the same lifecycle discipline used for NHI and privileged human access. For practitioners, that means reviewing whether the access path can support logging, rotation, and offboarding before it is accepted as a long-term exception.

For practitioners

• Enforce MFA at the access layer Use browser-mediated or proxy-mediated controls to require step-up verification before legacy applications are reached when native MFA is not feasible.
• Map every shared credential to named users or groups Create an access list that ties each legacy shared account to specific identities, with logging that records individual login events and business ownership.
• Remove password disclosure from shared access workflows Store shared credentials in a controlled browser or vault workflow so users can authenticate without ever seeing the underlying password.
• Make revocation a browser or IdP action Offboard access by removing the user from the identity provider or access list rather than asking teams to change passwords manually in the legacy app.
• Review compatibility mode as a security control Treat IE11 compatibility mode as an enablement layer only if it is paired with authentication enforcement, activity logging, and credential rotation.

Key takeaways

• Legacy web app support becomes an identity governance issue the moment authentication, attribution, or revocation falls outside the application itself.
• Shared credentials are the core control weakness because they collapse user accountability and make offboarding unreliable.
• Browser-mediated controls can reduce risk, but only if they restore MFA, logging, and enforceable revocation rather than just preserving access.

Key terms

• Legacy Application Access Mediation: A control pattern that inserts an identity-aware layer between the user and an older application. It allows modern authentication, logging, and revocation even when the application itself cannot support them natively.
• Shared Credential Governance: The management of a single account or password used by multiple people. In mature environments, this includes named-user attribution, controlled disclosure, rotation, and explicit offboarding because the application cannot distinguish users on its own.
• Browser-Mediated Authentication: An access model where the browser helps enforce identity checks before the target application is reached. It is useful for brittle or legacy systems because the security controls sit outside the app while still shaping user access.

What's in the full article

Island's full blog post covers the operational detail this post intentionally leaves for the source:

• How the enterprise browser integrates with the identity provider to enforce stronger authentication for legacy apps.
• How shared credentials are stored and auto-filled without exposing the underlying password to the user.
• How password rotation and revocation are handled from a single management console.
• How IE11 compatibility mode is positioned alongside identity controls for older business applications.

👉 Island's full post covers MFA handling, shared credential workflows, and IE11 compatibility in more detail.

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 building or maturing an IAM programme, it is worth exploring.