Who should own the decision when a vendor platform creates long-term migration friction?

Why This Matters for Security Teams

When a vendor platform makes migration difficult, the issue is not just technical lock-in. It becomes an identity governance problem because long-term platform constraints can shape how secrets are issued, how access is reviewed, how logs are retained, and how quickly controls can be replaced later. That means the ownership decision has to reflect operational risk, not only procurement preference. NIST’s NIST Cybersecurity Framework 2.0 treats governance as a core security function, which is exactly why migration friction belongs in cross-functional accountability.

For NHI programs, the trap is assuming a platform can be swapped cleanly after adoption. In reality, platform-specific credential formats, audit exports, policy engines, and integrations often become embedded in the control plane. NHIMG’s Ultimate Guide to NHIs — The NHI Market highlights how broadly NHIs spread across modern environments, which is why early architecture decisions have lasting consequences. In practice, many security teams encounter migration resistance only after a renewal has already locked in tooling, integrations, and operating assumptions.

How It Works in Practice

The decision should sit with a shared governance group, but each party owns a distinct part of the outcome. Identity leadership should own access model portability, secrets lifecycle requirements, and exit criteria. Security should own control effectiveness, data retention, and the ability to enforce least privilege after a platform change. Compliance should own evidence continuity, auditability, and retention obligations. The business sponsor should own budget, timeline, and the cost of delay if migration is deferred.

Current guidance suggests treating platform selection as a durable control decision, not a feature comparison. That means requiring the vendor to support exportable logs, documented revocation paths, standard protocols where possible, and an exit plan before purchase approval. NIST’s Cybersecurity Framework 2.0 is useful here because it anchors governance, risk, and supply chain accountability in the same decision process. For identity-specific depth, NHIMG’s NHI market guidance is a reminder that secrets, service accounts, and automation credentials rarely stay isolated to one system.

• Require a documented ownership matrix before contract signature.
• Define exit criteria for logs, secrets, and identity objects.
• Test migration paths during procurement, not after deployment.
• Map the vendor’s control assumptions to internal policy and audit needs.

These controls tend to break down when the vendor uses proprietary identity constructs, closed audit exports, or bundled workflows that cannot be recreated elsewhere without re-architecting the surrounding environment.

Common Variations and Edge Cases

Tighter ownership and exit requirements often increase procurement time and integration cost, so organisations have to balance portability against delivery speed. That tradeoff is real, especially when a platform is needed quickly or when the business wants a managed service rather than another internal system to operate.

There is no universal standard for this yet, but best practice is evolving toward “portable by design” requirements for identity-adjacent platforms. If a vendor manages secrets, tokens, or machine access, the contract should state who can extract configuration, how evidence is preserved, and what happens if the platform is replaced. The right answer can also differ by regulatory context. Regulated environments may need stricter documentation and longer retention, while smaller teams may prioritise interoperability and minimum viable exit paths.

NHIMG’s Ultimate Guide to NHIs — The NHI Market reinforces a practical point: once non-human identities proliferate, switching costs are no longer abstract. The ownership question should therefore be resolved at the point of platform adoption, not deferred to a later remediation cycle.

Related resources from NHI Mgmt Group

• Who should own PQC migration when multiple teams depend on the same trust assets?
• Who should own IAM decisions when friction and risk pull in different directions?
• Who should own identity governance decisions when selecting a platform?
• Who is accountable when PQC migration fails to protect long-term data?