TL;DR: Legacy web apps often remain dependent on shared credentials, brittle login flows, and browser-era assumptions that predate MFA, according to Island. The identity risk is not the old application itself but the governance gap around who can access it, how that access is authenticated, and whether revocation is actually enforceable.
NHIMG editorial — based on content published by Island: Supporting Legacy Web Apps in the Modern Era
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.
Questions worth separating out
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.
Q: What breaks when a legacy application still uses shared administrator credentials?
A: Individual accountability breaks first, then revocation and rotation become unreliable.
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.
Practitioner guidance
- 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.
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.
👉 Read Island's blog post on supporting legacy web apps with modern identity controls →
Legacy web apps and shared credentials: what IAM teams miss?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Legacy web apps still expose identity gaps after IE11