How should organisations evolve identity governance without creating more vendor lock-in?

Organisations should treat identity governance as an architecture decision, not a single product purchase. The practical goal is to keep the IGA core stable, use open interfaces where possible, and avoid hard-coding workflows around one platform. That preserves control over lifecycle, access review, and policy changes while reducing switching costs and dependency risk over time.

Why This Matters for Security Teams

identity governance becomes fragile when organisations let one vendor define the data model, review workflow, and policy engine all at once. That approach looks efficient until the platform becomes the only place where lifecycle logic lives, making migration, audit evidence, and control tuning expensive. NHI risk amplifies the problem because service accounts, API keys, and tokens often outnumber people and change faster than human-centric workflows can handle.

NHIMG research shows the scale of the issue: in the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes. When governance is trapped inside a proprietary stack, those weaknesses are harder to correct because policy changes depend on one product’s limits. The safer design is to separate decisioning from enforcement, so the organisation can keep control even if tooling changes later. Current guidance from NIST Cybersecurity Framework 2.0 supports that direction by emphasising governance, risk management, and repeatable control outcomes rather than tool dependency. In practice, many security teams discover lock-in only after a merger, a cloud shift, or a breach review has already exposed how much control was outsourced.

How It Works in Practice

The practical pattern is to build an identity governance layer that can talk to multiple systems through open interfaces, while keeping policy logic portable. That means treating provisioning, review, and revocation as capabilities, not as features locked inside one vendor console. For NHI-heavy environments, this is especially important because the identity itself is often a workload identity, not a human account. Open standards such as SPIFFE for workload identity and policy engines such as Open Policy Agent help separate what the identity is from how a specific product manages it.

A resilient model usually includes:

• A canonical identity inventory that is owned by the organisation, not by the vendor database.
• Lifecycle workflows that can trigger across directory, cloud, CI/CD, and secrets systems.
• Policy-as-code for reviews, approvals, and revocation criteria so decisions are testable and versioned.
• Short-lived credentials and JIT access so the governance layer is not dependent on static long-term secrets.
• Exportable audit evidence, so control validation survives platform replacement.

This is where NHIMG guidance on lifecycle visibility matters. The lifecycle processes for managing NHIs reinforce that governance should follow the identity across creation, use, rotation, and offboarding rather than stop at one tool boundary. If the team can swap the review portal, policy engine, or vault without redesigning the control itself, lock-in is reduced materially. These controls tend to break down when legacy applications hard-code vendor-specific APIs and no neutral identity record exists outside the platform.

Common Variations and Edge Cases

Tighter governance often increases integration and operating overhead, requiring organisations to balance portability against implementation speed. That tradeoff is real, especially in smaller teams that want a single console for everything. The best practice is evolving, not settled: there is no universal standard for every identity workflow yet, so some vendor coupling may be acceptable where the business value is high and replacement risk is low.

Edge cases matter most in regulated or highly distributed environments. For example, some SaaS platforms only expose partial lifecycle APIs, which makes full portability difficult even with a well-designed architecture. In those cases, teams should isolate the dependency, document the exception, and avoid letting the exception become the control plane. The same logic applies to secrets governance, where platform convenience can hide exposure. NHIMG notes in the 52 NHI Breaches Analysis that compromise patterns often repeat across credential sprawl and weak revocation. That is why the goal is not tool independence at any cost, but control portability where it matters most. Organisations that need a standards-backed governance baseline should also align their operating model to the NIST Cybersecurity Framework 2.0 and keep the identity policy layer abstracted from any one vendor.

Related resources from NHI Mgmt Group

• How should organisations evaluate identity governance and administration platforms without over-weighting vendor ratings alone?
• How should healthcare organisations implement identity governance for clinicians, contractors, and devices without slowing care delivery?
• How should organisations expand Identity Governance and Administration delivery without weakening governance in regulated environments?
• How should organisations map identity attributes differently across applications without creating policy drift?