What breaks when third-party access is not standardised after a healthcare merger?

Third-party access becomes harder to govern when vendors and contractors keep uneven permissions across inherited systems. Monitoring breaks down first, followed by inconsistent enforcement and a higher chance that non-employees retain access longer than intended. In a merged environment, that weakens the organisation’s ability to track activity, validate need to know access, and apply the same controls to external users as to employees.

Where third-party access stops being governable after a merger

When inherited vendors, contractors, and partners are left on different access models, the merged organisation no longer has one reliable way to decide who should have access, what they can reach, or when that access should end. That makes third-party access a governance problem first, then an operational one, because the merged estate inherits inconsistent sponsorship, review, and revocation practices.

Standardisation matters because third-party access is not just another user population, it is the part of the environment most likely to span multiple business units, legacy directories, and contract relationships. A merged organisation can technically keep the systems running without standardising, but it will struggle to answer basic control questions with confidence.

What control failures appear first

The first failure is usually visibility. Without a common access model, teams cannot quickly tell which non-employees are active, which inherited permissions are still justified, and which accounts belong to the same external firm across multiple systems. That is why a merger often exposes gaps in inventory, ownership, and review cadence rather than an immediate technical outage.

The second failure is inconsistent enforcement. If one legacy company used time-bound sponsorship and another relied on informal approvals, the merged organisation cannot apply the same rules to all third parties. The result is drift in access reviews, uneven least-privilege enforcement, and weaker offboarding when contracts change or end.

A useful baseline is to anchor third-party access governance to a single enterprise model for access request, approval, review, and removal. IAM and IGA Basics is relevant because mergers usually fail at the control layer before they fail at the directory layer: the organisation needs one access governance approach, not several inherited ones.

For external users specifically, the control problem is even sharper because contractors and suppliers often need narrower, time-limited access than employees. Third-Party, B2B and Contractor Access Guide maps directly to the merged-access problem, since sponsorship, federation, reviews, and expiry are the mechanisms that keep external access from becoming permanent by accident.

Why the risk grows instead of normalising over time

Unstandardised third-party access does not merely create administrative friction, it creates persistence risk. Once permissions are uneven across inherited systems, non-employees can retain access longer than intended, particularly where account ownership is unclear or revocation depends on a local team remembering to act. In practice, that weakens accountability and increases the chance that access outlives the business need.

It also raises the blast radius of a compromise. If a supplier account, contractor account, or shared external credential remains active in one of the inherited environments, an attacker only needs the weakest access path to reach data or workflows that were never meant to be uniformly exposed. That is why standardisation is not just about tidiness, it is about reducing the number of exceptions an attacker can exploit.

Where the merger leaves federated SaaS access, token governance becomes part of the same risk surface. Inherited third-party integrations can keep working even when the business relationship changed months earlier, so access review must cover both named users and the connected applications or tokens they rely on. SaaS-to-SaaS and OAuth App Governance Guide is a useful companion because merger control failures often include forgotten connected apps, not just forgotten people.

For the broader threat pattern, standards that emphasise token scope, audience restriction, and revocation support the same conclusion. RFC 6749: The OAuth 2.0 Authorization Framework and RFC 8707: Resource Indicators for OAuth 2.0 matter here because third-party access often survives through tokens and scoped grants long after the original human relationship should have ended.

How to tell whether the merger control is actually working

The best signal is whether the organisation can answer, quickly and consistently, three questions: who the external user is, who owns the relationship, and when the access expires or is reviewed. If any of those answers require local knowledge from an inherited team, the merger has not standardised third-party access yet.

Practitioners should also check whether the same third-party roles are treated the same way across systems. If the same vendor has privileged access in one inherited environment, standard user access in another, and no clear owner in a third, the merge has produced control fragmentation rather than integration.

At the technical level, unified logging and periodic review matter because they let security teams detect dormant, overbroad, or orphaned external accounts before they become a breach path. The merged organisation should be able to prove that third-party access is time-bound, reviewed, and removable without relying on manual memory or local exceptions.

For a broader identity control lens, NIST Cybersecurity Framework 2.0 supports the governance, protection, and detection aspects of this problem, while CIS Controls v8 reinforces the need for account management, access control, and logging to stay consistent across the merged estate.

Risk and Threat Considerations

Unstandardised third-party access after a merger creates a classic exposure pattern: exceptions accumulate faster than they are reviewed, and external accounts become harder to see, harder to revoke, and easier to abuse. The organisation may think it has inherited access under control, when in reality it has inherited multiple versions of the same control with different strengths.

Failure mechanism: Different legacy approval, review, and offboarding practices leave contractors and vendors with inconsistent permissions, stale accounts, and unmanaged token or federation paths across systems.

Impact: Monitoring degrades first, enforcement becomes uneven, and the merged organisation faces higher odds of persistent unauthorised access, overprivilege, and delayed detection of misuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-8 — Identification and Authentication (Non-Organizational Users)	Third-party access after merger hinges on controlling external user authentication.
	AC-2 — Account Management	Merged third-party access needs unified provisioning, review, and removal of external accounts.
	AC-6 — Least Privilege	Uneven inherited permissions create overprivilege risk for third parties.
Recommendation — Require consistent external-user authentication and account governance across inherited systems. Standardise account lifecycle rules for vendors and contractors across all inherited platforms. Limit third-party access to the minimum permissions needed in each system.
ISO/IEC 27001:2022	A.5.15 — Access control	A merged organisation needs one access-control model for external users.
	A.5.18 — Access rights	Inherited third-party permissions must be reviewed and removed consistently after merger.
Recommendation — Define and enforce a single access-control policy for third-party identities. Review, adjust, and revoke third-party access rights on a fixed schedule.

Practitioner Guidance

What to prioritise: Start with a single inventory of all external users, third-party groups, and connected applications across both merger populations. If you cannot produce that list with owners and expiry dates, do not begin with policy clean-up, begin with discovery and ownership assignment.

What to verify: Confirm that every external access path has a sponsor, a business justification, a review date, and a removal route that works across both legacy environments. The control is not real until revocation can be executed without a local exception.

Common mistake: Treating third-party access as a vendor-management issue only. In a merger, the access problem is operational, because inconsistent entitlement models and missing offboarding processes are what keep old access alive.

Practitioner takeaway: Standardising third-party access after a merger is less about consolidation for its own sake and more about restoring the ability to answer, enforce, and revoke access consistently before inherited exceptions turn into lasting exposure.