Who is accountable when a platform vendor changes ownership or branding?

The customer remains accountable for access, rotation, offboarding, and audit continuity. Vendor ownership changes may affect roadmap and support, but they do not transfer governance responsibility. Teams need documented exit paths, entitlement inventories, and control ownership so that a product change does not become an access-control blind spot.

Why This Matters for Security Teams

Ownership or branding changes at a platform vendor often look like a procurement event, but security teams should treat them as a continuity test for identity and access control. The vendor may change legal entities, support channels, product names, or contract terms, yet the customer still owns the risk of who can authenticate, what remains valid, and how quickly access is removed when services change. That is especially true for NHIs, where secrets and service accounts can outlive the product relationship.

This is why NHI governance cannot be delegated to marketing updates or vendor assurances. The control problem is not the logo on the portal; it is whether the customer can still rotate credentials, prove entitlement ownership, and offboard access without relying on a former supplier’s internal process. NHIMG research shows only 20% of organisations have formal offboarding and revocation processes for API keys, and 91.6% of secrets remain valid five days after notification, which underscores how easily change events become exposure windows. See the Ultimate Guide to NHIs — The NHI Market and the NIST Cybersecurity Framework 2.0 for the broader governance lens.

In practice, many security teams encounter lingering access only after a vendor transition has already changed support boundaries and delayed remediation.

How It Works in Practice

Accountability should be anchored to the customer’s control plane, not the vendor’s branding. That means documenting which team owns each secret, token, service account, certificate, integration, and support entitlement before a vendor changes ownership. If the relationship shifts, the customer should still be able to answer three questions immediately: what identities exist, where they are used, and how they are revoked.

Operationally, the strongest pattern is to maintain an entitlement inventory tied to business services, not vendor product names. Each entry should include the issuing authority, rotation method, expiration date, and break-glass path. Where possible, use centrally managed secrets managers, short TTLs, and automated rotation so that a company acquisition, rebrand, or service migration does not leave long-lived credentials behind. This also supports audit continuity, because logs and approvals remain attached to the customer’s internal control owner rather than to a supplier’s changing account structure. For implementation patterns, the Ultimate Guide to NHIs — The NHI Market is useful when mapping ownership across third-party dependencies.

• Keep a named internal owner for each non-human identity and vendor integration.
• Revalidate contracts, support contacts, and revocation procedures when ownership changes.
• Test offboarding before renewal, acquisition, or migration events.
• Preserve audit logs and entitlement records outside the vendor portal.

Where this guidance breaks down is in tightly coupled SaaS integrations that rely on vendor-managed support for token issuance or revocation, because customer-side control can be partial and delayed.

Common Variations and Edge Cases

Tighter offboarding and entitlement tracking often increases administrative overhead, requiring organisations to balance resilience against the cost of deeper inventory management. That tradeoff becomes more visible when a platform is resold, rebranded, or moved to a new parent company, because customer agreements, API endpoints, and support obligations may all shift at once. Best practice is evolving, but current guidance suggests the accountability model should remain unchanged: the customer retains responsibility for access review, secret rotation, and evidence preservation.

There are a few common exceptions to plan for. In reseller arrangements, one entity may provide billing while another operates the service, so the control owner must verify who can actually revoke access. In mergers and acquisitions, existing tokens may continue to work across renamed tenants, which creates a false sense of continuity if inventories are not reconciled. In regulated environments, audit evidence should be retained independently of the vendor because product changes can disrupt export formats or retention windows. The practical lesson is simple: treat branding changes as triggers for control review, not as proof that governance transferred. For a standards-based baseline, align the process to NIST Cybersecurity Framework 2.0 and maintain customer-owned offboarding evidence.

In short, vendor ownership changes can alter service delivery, but they do not transfer the customer’s accountability for NHI security.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• What problem does ownership attribution solve for service accounts and API keys?
• Who is accountable when an AI vendor changes an agent's capabilities without notice?
• Who is accountable when a compliance platform misses privileged access changes?