Who is accountable when third-party access to PHI is overbroad or unreviewed?

The covered entity remains accountable for governance, even when a business associate or vendor holds the access. Contracts help, but the organisation still needs entitlement scoping, review cadence, and offboarding evidence so external access is managed as part of the regulated environment.

Why This Matters for Security Teams

When third-party access to PHI is too broad or never reviewed, the risk is not just policy drift. It becomes a governance failure that can expose regulated data, undermine breach response, and leave audit evidence incomplete. Covered entities cannot transfer accountability to a vendor simply because the vendor holds the credentials. That is why NHI governance, entitlement visibility, and offboarding evidence matter as much for vendors as for internal service accounts.

NHIMG research shows the scale of the problem: 92% of organisations expose NHIs to third parties, and only 20% have formal processes for offboarding and revoking API keys in Ultimate Guide to NHIs. That lines up with current guidance from the OWASP Non-Human Identity Top 10, which treats overprivileged and unmanaged machine access as a core security issue rather than a procurement detail. In practice, many security teams encounter vendor access failure only after a review, incident, or audit has already exposed the gap, rather than through intentional governance.

How It Works in Practice

Accountability usually follows the covered entity, but operational control has to be distributed. Contracts define obligations, yet they do not verify whether the business associate has only the minimum PHI access needed, whether those entitlements are still in use, or whether old integrations were actually removed. The practical answer is a joint control model: procurement, security, privacy, and application owners each own part of the access lifecycle.

For third-party PHI access, strong programmes start with inventory. Every external service account, API key, token, certificate, and delegated application should be mapped to a business purpose, data scope, owner, and review date. That inventory then supports periodic access recertification, just-in-time approval for new access, and evidence-based offboarding when the relationship ends. The NHI lifecycle guidance in Ultimate Guide to NHIs — Key Challenges and Risks is especially relevant here because third-party access often persists long after the original need has expired.

• Scope access to named systems and specific PHI use cases, not broad environment-wide permissions.
• Set review cadences that match data sensitivity and vendor criticality, with evidence retained for audits.
• Require offboarding proof, including token revocation, key deletion, and service account disablement.
• Use policy-as-code and entitlement monitoring so overbroad access is detected continuously, not only during annual reviews.

Frameworks such as the OWASP Non-Human Identity Top 10 and the NIST control family for access review both support this model, but there is no universal standard for vendor PHI entitlement design yet. These controls tend to break down when the third party uses shared service accounts across multiple customers because individual accountability and clean revocation become operationally ambiguous.

Common Variations and Edge Cases

Tighter vendor access controls often increase onboarding time and administrative overhead, requiring organisations to balance PHI protection against business continuity and integration speed. That tradeoff becomes sharper with SaaS platforms, managed service providers, and healthcare data exchange partners where one vendor may support many workflows at once.

One common edge case is shared or inherited access. If a vendor subcontracts work or aggregates several client environments into one platform account, the covered entity still owns the risk of overbroad PHI exposure, even if the vendor manages the tooling. Another edge case is emergency access. Current guidance suggests emergency privileges should be time-bound, logged, and explicitly reviewed after use, because standing exception paths quickly become permanent.

NHIMG’s reporting on third-party exposure and leaked secrets in 52 NHI Breaches Analysis reinforces the point: weak external identity hygiene is usually discovered after exposure, not before. For regulated environments, the operational answer is not to trust the vendor’s assurances alone, but to verify scoping, recertify access, and retain revocation evidence. In healthcare environments with rapid supplier churn, these controls often fail when application ownership is unclear and nobody is accountable for the final deprovisioning step.

Related resources from NHI Mgmt Group

• Who is accountable when a third party keeps access after the work ends?
• What breaks when third-party access is not reviewed continuously?
• What breaks when third-party SaaS access is never reviewed?
• When should organisations treat third-party SaaS access as privileged access?