Who is accountable for identity controls around legacy web applications?

Why This Matters for Security Teams

Legacy web applications often blur the line between business ownership and identity governance. The application team understands the workflow, but identity controls such as credential issuance, session revocation, and audit evidence are often managed elsewhere. That split matters because shared accounts, embedded secrets, and outdated admin paths can survive long after the business owner believes access has been retired. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

The practical risk is that no one owns the full control path. Application teams may approve access for continuity, while IAM or PAM teams may assume the app owner will handle revocation and exception review. That gap becomes especially dangerous in older web stacks where credentials are reused across environments or hard-coded into deployment jobs. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports clear accountability and auditable access governance, but legacy systems often lack the hooks needed to enforce it cleanly. In practice, many security teams discover this only after a stale shared credential is exploited rather than through intentional control testing.

How It Works in Practice

For legacy web applications, accountability should be assigned to the party that can actually change the control, not just the party that benefits from it. The application owner is typically responsible for defining which human and non-human actors need access, which workflows still require shared accounts, and which business exceptions are unavoidable. IAM, PAM, or identity governance teams are responsible for making those access paths enforceable, reviewable, and revocable.

A workable model usually breaks the control into ownership layers:

• Application owners approve and periodically attest business necessity for each legacy account or service path.
• Identity teams manage credential lifecycle, MFA or PAM wrappers where possible, logging, and revocation workflows.
• Security governance sets review cadence, exception handling, and evidence requirements.

This is where NHIs become the deciding factor. If a web app uses a service account, API key, or local admin credential, that identity should be treated as an NHI with a named owner, a documented purpose, and a retirement plan. NHI Mgmt Group’s 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce the pattern: when ownership is vague, secrets linger, privileges expand, and offboarding is delayed.

Practitioners should document the accountable owner in the control register, not just in a project ticket. That owner should be able to answer four questions: who requested the access, who approved it, how is it enforced, and who can revoke it today. If the answer depends on a retired vendor admin, a forgotten developer, or a server-side config file, the control is already drifting. These controls tend to break down when legacy apps rely on embedded credentials and no central inventory exists for service accounts or shared logins.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance stronger control against uptime, release speed, and support burden. That tradeoff is most visible in older applications that cannot support per-user authorization, modern federation, or clean secret rotation. In those cases, current guidance suggests assigning compensating accountability rather than pretending the app can meet modern identity standards.

Some common edge cases include:

• Shared break-glass credentials where PAM may manage the vault, but the application owner still owns the business justification and review outcome.
• Vendor-supported legacy platforms where the vendor controls technical changes, but the internal service owner remains accountable for access approval and recertification.
• Batch jobs and integration accounts where the application team owns function and the identity team owns lifecycle controls such as rotation and revocation.

Where an application cannot support granular roles, best practice is evolving toward compensating controls, short-lived credentials where feasible, and stronger logging around use of privileged paths. There is no universal standard for this yet, but the direction is clear: ownership must be explicit, evidence must be reviewable, and exceptions must expire. For broader governance patterns, the Ultimate Guide to NHIs is useful for mapping lifecycle and control expectations to legacy environments.

Related resources from NHI Mgmt Group

• Why do browser-based applications need different identity controls than legacy SAML websites?
• Who is accountable when CUI handling controls fail?
• Why do agentic attackers change the way identity controls should be designed?
• How can teams tell whether their identity controls are still gate-based?