Accountability usually sits with IAM, security, and application owners together, because legacy systems and third party identities cross team boundaries. Leadership should assign clear control ownership for authentication, access review, privileged access, and exception handling. Without named accountability, gaps persist between modern policy and the older systems where risk often concentrates.
Why This Matters for Security Teams
Accountability for legacy systems and third-party identities is where modern identity programs either hold together or quietly fail. These environments rarely fit clean role models, yet they still carry privileged access, embedded tokens, shared service accounts, and exception paths that bypass current governance. The OWASP Non-Human Identity Top 10 makes clear that unmanaged NHI controls are not a niche issue, and NIST SP 800-53 Rev 5 still expects clear ownership for access control, identification, and auditability.
In practice, the problem is not that no one cares. It is that ownership is split across IAM, security, application teams, procurement, and sometimes vendor managers, so no single team feels responsible for enforcing modern controls on older platforms. That becomes especially risky when third-party identities are treated as contract artifacts instead of active security subjects. NHIMG research shows how often this gap translates into real exposure, including the Ultimate Guide to NHIs finding that 92% of organisations expose NHIs to third parties.
In practice, many security teams discover this accountability gap only after a legacy integration, vendor token, or service account has already been used outside its intended boundary.
How It Works in Practice
The accountable model starts by naming a control owner, a system owner, and a third-party owner for every legacy application and external identity path. That sounds basic, but it is the only way to make modern controls actionable when the target system cannot natively support them. Security teams usually define the policy, IAM teams operationalize identity lifecycle rules, and application owners accept the remediation work needed to make the legacy system comply.
For third-party identities, accountability should extend beyond onboarding. It needs ongoing review of authentication method, token scope, rotation cadence, offboarding, and exception approval. Where possible, use stronger authentication and replace shared credentials with distinct workload or user identities. Where not possible, compensating controls become the control baseline: network restriction, API gateway enforcement, privileged access management, logging, and explicit expiry dates.
- Assign one named owner for access decisions, one for technical enforcement, and one for exception approval.
- Inventory legacy systems that cannot support modern MFA, federation, or fine-grained RBAC.
- Treat vendor accounts, partner API keys, and support access as governed identities, not informal trust relationships.
- Require periodic recertification of third-party access and documented revocation triggers.
Modern identity controls should be mapped to the system’s actual capability, not to what the policy would prefer. That is why the 52 NHI Breaches Analysis is useful: it shows how repeated control failures tend to cluster around visibility, ownership, and lingering access. The OWASP guidance on Non-Human Identity Top 10 aligns with this operational reality by emphasizing credential exposure, lifecycle weakness, and weak authorization boundaries.
These controls tend to break down when a legacy platform is kept alive through undocumented vendor support accounts because no team can prove who is allowed to approve, rotate, or revoke access.
Common Variations and Edge Cases
Tighter accountability often increases coordination overhead, requiring organisations to balance faster vendor delivery against stronger control ownership. That tradeoff is especially visible in regulated environments, mergers, and outsourced operations, where ownership can be split across legal entities or inherited from prior architecture decisions.
There is no universal standard for this yet, but current guidance suggests that exceptions should be time-bound, reviewed, and explicitly owned rather than informally accepted. A vendor may insist that a shared admin account is operationally necessary, or a legacy application may only support static credentials. In those cases, the accountable team should not be the one with the most influence, but the one with authority to accept risk and drive remediation.
One useful pattern is to separate policy ownership from system administration. Security can define minimum identity controls, but the application owner must ensure the legacy platform or supplier contract can actually meet them. Where third-party access is involved, procurement and legal may need to enforce clauses for audit rights, revocation timelines, and incident notification. That is consistent with NHI Mgmt Group guidance that NHI governance fails when ownership is implied rather than assigned.
Best practice is evolving for agent-driven and outsourced ecosystems, but the accountable principle remains the same: if a control cannot be implemented directly, someone must own the compensating control and its expiry.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity ownership and lifecycle gaps are central to legacy and third-party access. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access management depend on clear accountability across systems. |
| NIST SP 800-63 | Federation and identity assurance are relevant when third parties access older systems. | |
| NIST AI RMF | GOVERN | Accountability is a governance requirement when identities span teams and suppliers. |
Assign named owners for legacy and third-party identities, then enforce lifecycle controls and revocation.
Related resources from NHI Mgmt Group
- What breaks when organisations do not extend identity security to third-party and machine identities?
- Who is accountable when banks onboard modern digital asset services through third-party integrations?
- Who is accountable for identity risk across employees, third parties, and non-human identities during a cyber incident?
- Which identity controls matter most when third-party access reaches production systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
