Who should own identity risk when attacks target both people and third-party access?

Why Identity Risk Becomes Shared the Moment Attackers Blend People and Third Parties

When attackers target both staff and external access paths, identity risk stops being an IAM-only problem. The control failure is usually a handoff failure: phishing, impersonation, contractor access, service accounts, and offboarding all intersect. OWASP’s OWASP Non-Human Identity Top 10 is a useful reminder that identity exposure is not limited to employees, while NHIMG’s 52 NHI Breaches Analysis shows how often weak identity governance becomes operationally visible only after compromise.

In healthcare, the risk is sharper because access paths often cross patient-facing workflows, vendor support channels, and delegated admin privileges. Security leadership can own the policy model, IAM can own the control plane, and operational owners must own the business process, but none of those groups can reduce identity risk alone. Current guidance suggests shared accountability is the only workable model when identity proofing, approvals, and revocation all happen in different systems. In practice, many teams discover the ownership gap only after an impersonation campaign has already moved from message to access.

How Shared Ownership Works in Practice

The cleanest operating model is to split responsibility by decision type, not by system boundary. Security leadership defines risk tolerance, IAM implements authentication and lifecycle controls, and operational owners validate who should be onboarded, re-approved, or removed. That matters because attackers do not care whether access belongs to a person, a consultant, or a third-party integration; they exploit the weakest identity path and then pivot across it. CISA’s cyber threat advisories and the NIST Cybersecurity Framework 2.0 both support this kind of cross-functional governance, even if they do not prescribe a single ownership chart.

• Security owns policy, exceptions, and escalation thresholds.
• IAM owns identity proofing, provisioning, conditional access, and revocation.
• Business and operational managers own approval, role fit, and timely deprovisioning.
• Third-party risk teams own vendor due diligence and access recertification.

The practical test is whether every identity can be traced to a named business owner, a technical owner, and a revocation path. NHIMG’s Ultimate Guide to NHIs is especially relevant here because external and machine identities often inherit process gaps that human IAM reviews miss. These controls tend to break down in matrixed organisations where contractors, shared mailboxes, and vendor-managed accounts are approved in one workflow and removed in another because no single team owns the full lifecycle.

Where Ownership Models Break Down and What to Watch

Tighter ownership often improves accountability, but it also increases coordination overhead, requiring organisations to balance speed against assurance. That tradeoff is most visible in regulated environments, where emergency access, temporary contractors, and delegated admin rights are common. Best practice is evolving, not settled, for how to assign ownership when one identity is used across multiple business units or when a third party operates within a semi-trusted enclave.

Two failure modes matter most. First, “shared” ownership becomes no ownership if no one is measured on review and revocation timeliness. Second, third-party access can outlive the business relationship if renewal checks are manual or tied to procurement rather than IAM. The operational answer is to force a single accountable owner for each identity record, while allowing separate approvers for security, business, and vendor risk. For background on how identity issues compound across attack paths, the 2024 ESG Report: Managing Non-Human Identities notes that 72% of organisations have experienced or suspect a breach of non-human identities, and attack paths frequently span more than one control domain.

Where this model fails fastest is in healthcare systems that still rely on manual offboarding, decentralized vendor sponsorship, and exception-based access for clinical operations because identity risk gets distributed across too many owners to respond quickly.

Related resources from NHI Mgmt Group

• Who should own third-party access risk in an identity programme?
• Should organisations treat third-party access as a privileged identity risk?
• Who should own third-party access risk in a banking GRC programme?
• Why do third-party vendors create identity and access risk?