How should security teams handle SaaS vendor lock-in in identity governance programmes?

Treat lock-in as a lifecycle risk, not just a procurement issue. Build exit readiness into vendor selection, document data portability requirements, and align renewal review with access governance so that switching can happen without losing audit evidence or operational continuity. If the service cannot be removed cleanly, the control design is incomplete.

Why This Matters for Security Teams

SaaS lock-in becomes a security problem when identity governance depends on vendor-specific workflows, logs, and entitlement models that cannot be replicated elsewhere. Procurement may approve the tool, but security teams own the audit trail, access reviews, offboarding evidence, and revocation outcomes. If those controls are trapped inside a platform, exit becomes a business risk and not just a commercial nuisance.

This is especially important for NHIs because vendor integrations often outlive the original use case. The Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, while 96% store secrets outside of secrets managers in vulnerable locations. That makes portability and clean decommissioning part of the control design, not a later migration task. NIST also frames identity and access as an ongoing governance function in the NIST Cybersecurity Framework 2.0, which aligns with treating exit readiness as a lifecycle requirement.

In practice, many security teams discover lock-in only after renewal pressure, an audit request, or a vendor outage has already exposed how much evidence and access state cannot be moved.

How It Works in Practice

Teams should evaluate SaaS identity tools on three dimensions: portability of identity data, portability of governance evidence, and portability of control logic. The goal is to ensure access reviews, approval history, entitlement mappings, and revocation records can be exported in a usable format without depending on the original user interface or proprietary report model.

A practical programme usually includes:

• Contractual exit clauses that define export format, timelines, and vendor assistance for migration.
• Documented ownership of entitlements, service accounts, tokens, and delegated admin roles so the security team can recreate the governance model elsewhere.
• Periodic test exports to confirm that audit evidence is complete and readable outside the platform.
• Renewal reviews that compare current lock-in risk against control coverage, not just feature satisfaction.
• Offboarding runbooks that include revocation order, evidence retention, and validation that dormant access is actually gone.

For control design, current guidance suggests aligning the programme to vendor-neutral identity principles such as least privilege, traceable approvals, and revocation assurance. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it frames lifecycle management as continuous, including offboarding and rotation. In parallel, the NIST Cybersecurity Framework 2.0 supports tying identity governance to risk management rather than to one platform’s administrative model.

Where possible, insist on data schemas and export paths that preserve timestamps, approvers, entitlement deltas, and revocation status. These controls tend to break down when the SaaS service only exports partial logs or when access decisions are encoded in vendor-specific metadata that cannot be reconstructed after migration.

Common Variations and Edge Cases

Tighter portability requirements often increase implementation and procurement overhead, requiring organisations to balance exit readiness against speed of deployment. That tradeoff matters most when the SaaS product is deeply embedded in HR, IAM, or cloud operations, because migration friction can create temporary gaps in review cadence or deprovisioning.

One common edge case is a platform that manages both human and non-human access. Best practice is evolving, but the safest pattern is to separate the evidence model from the enforcement model so that audit history can be retained even if enforcement must move first. Another case is a vendor that allows API export but not full lineage for approvals or workflow states; in that situation, the governance team should treat the missing lineage as a control deficiency, not a documentation inconvenience.

Security teams should also pay attention to third-party connections. The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes SaaS lock-in harder to see until an integration fails or is inherited through acquisition. NHIMG’s 52 NHI Breaches Analysis also shows how quickly access sprawl turns into an incident when identities and tokens are not governable outside the primary platform.

There is no universal standard for exit readiness yet, so organisations should define their own minimum export, revocation, and evidence retention requirements before they commit to long-lived SaaS governance dependencies.

Related resources from NHI Mgmt Group

• How should security teams get buy-in for identity governance programmes?
• How should security teams handle identity governance when full IGA still leaves blind spots?
• How should security teams evaluate vendor consolidation for identity governance?
• How should security teams handle GDPR requirements in identity programmes?