What breaks when each tenant uses a different identity workflow?

Why This Matters for Security Teams

When each tenant uses a different identity workflow, the problem is not just inconsistency. It becomes impossible to apply one control model across onboarding, access review, secret issuance, rotation, and revocation. That weakens governance, slows incident response, and makes it harder to prove that access decisions were made consistently. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign when every tenant is running a different process.

Security teams also lose comparability. One tenant may use short-lived tokens, another may rely on long-lived keys in CI/CD, and a third may route approvals through a different IAM stack entirely. That makes it difficult to answer basic audit questions such as who can create identities, how privileges are granted, and whether revocation actually happens. The NIST Cybersecurity Framework 2.0 is built around repeatable outcomes, and tenant-specific workflows undermine that repeatability unless the operating model is normalised above the tenant layer.

In practice, many security teams discover workflow drift only after a failed access review, a secrets incident, or a customer audit request that exposes how differently each tenant is being managed.

How It Works in Practice

The core failure is that identity governance becomes translated rather than controlled. Instead of a single policy for provisioning, review, and deprovisioning, the team maintains a mapping table across tenant systems, approval paths, and credential stores. That mapping is brittle. Small differences in workflow quickly become control gaps, especially when one tenant allows manual overrides while another enforces automated approvals. The result is uneven enforcement of least privilege and inconsistent evidence for auditors.

A stronger model is to standardise the control plane while allowing tenant-specific implementation details underneath it. That usually means:

• One identity lifecycle policy for all tenants, with tenant metadata used for scoping rather than rewriting the workflow.
• Shared rules for approval, TTL, rotation, and revocation, even if the target systems differ.
• Central logging and evidence collection so access events can be compared across tenants.
• A single definition of ownership for each non-human identity, secret, or service account.

This is especially important because the Top 10 NHI Issues research shows how often organisations lose control of rotation, visibility, and offboarding when identity handling is fragmented. The practical fix is not to force every tenant into the same vendor tool. It is to enforce the same control intent everywhere, using policy-as-code where possible and documented compensating controls where not. Current guidance suggests that control consistency matters more than interface consistency, but there is no universal standard for this yet.

That approach aligns with NIST Cybersecurity Framework 2.0 by making governance measurable across tenants instead of dependent on local process variation. These controls tend to break down in fast-moving multi-tenant environments where each customer can customize its own IAM stack because evidence collection becomes fragmented at the point of policy enforcement.

Common Variations and Edge Cases

Tighter standardisation often increases implementation overhead, requiring organisations to balance tenant autonomy against auditability and operational consistency.

Not every tenant needs an identical user experience, but the underlying security outcome should remain the same. The edge case is a regulated customer that requires separate identity tooling, separate logs, or a distinct approval chain. In those cases, the control objective must still be preserved through compensating evidence, explicit ownership, and periodic equivalency testing.

Another common exception is acquisition or partner environments, where inherited identity workflows cannot be changed quickly. Best practice is evolving here: teams often begin with a translation layer that normalises reporting before they fully converge the workflows. That reduces immediate risk without creating a disruptive migration program.

For multi-tenant SaaS, the safest pattern is to avoid tenant-by-tenant identity exceptions at the secret and service-account layer. The Ultimate Guide to NHIs — What are Non-Human Identities is useful here because it frames non-human identity as a lifecycle problem, not a per-tenant tooling preference. Where workflows must differ, the organisation should document the variance, define a compensating control, and test whether revocation, rotation, and access review still work the same way across tenants.

Related resources from NHI Mgmt Group

• What breaks when SaaS app rationalisation is not tied to identity reviews?
• What breaks when access management is separated from identity governance?
• What breaks when identity connectors do not cover the full application estate?
• What breaks when identity sprawl is not continuously reconciled?