Look for repeated custom code around tenant setup, session handling, role assignment, and IdP configuration. If enterprise onboarding depends on engineering tickets rather than native workflows, the platform is pushing identity governance into the application layer. That is a sign the model may not scale cleanly.
Why This Matters for Security Teams
Hidden complexity is rarely a cosmetic problem. In B2B identity, it usually means the platform is not containing identity governance, it is exporting it into application code, customer-specific logic, and operational workarounds. That creates brittle onboarding, inconsistent policy enforcement, and a larger blast radius when something changes. NHI governance shows the same pattern: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, which is a reminder that complexity often hides in the places teams do not instrument well.
Security teams should be wary when tenant setup, session handling, role mapping, and IdP configuration all require bespoke code paths. That usually signals the product is not providing durable identity primitives, so every customer edge case becomes a maintenance burden. Current guidance from NIST Cybersecurity Framework 2.0 is useful here: if identity risk cannot be governed consistently, resilience suffers. In practice, many security teams encounter the failure only after onboarding stalls, audit exceptions pile up, or a privileged integration has already been copied across multiple tenants.
How It Works in Practice
The clearest signal of hidden complexity is when identity operations are not native to the platform. A clean model should support tenant lifecycle, session policy, role assignment, and IdP federation through configuration and policy, not through engineering tickets. If each enterprise customer needs a custom adapter or a one-off rule set, the platform is effectively turning identity into application logic. That makes access reviews, offboarding, and incident response slower because operators must reconstruct the effective policy from code, logs, and tribal knowledge.
Practitioners should examine whether the platform separates product behaviour from identity governance. Look for these questions:
- Can tenant creation, delegation, and deprovisioning be handled without shipping code?
- Are roles and entitlements reusable across customers, or are they hard-wired per tenant?
- Does the platform support standard federation and lifecycle patterns, or only the most common IdP?
- Can security policy be evaluated centrally, or is it embedded in application services?
This is where NHI thinking is useful. The governance gap described in the Top 10 NHI Issues and the breach patterns in 52 NHI Breaches Analysis both show the same root cause: identity sprawl becomes dangerous when ownership and lifecycle controls are fragmented. For engineering teams, that means preferring native workflows, policy-as-code, and explicit lifecycle hooks over custom auth glue. These controls tend to break down when the platform is multi-tenant but lacks a true separation between control plane policy and customer-specific application logic, because every exception becomes a permanent code dependency.
Common Variations and Edge Cases
Tighter identity abstraction often increases upfront integration work, requiring organisations to balance flexibility against operational simplicity. That tradeoff is real, especially in regulated or highly customised B2B environments where some amount of tenant-specific policy is unavoidable. Current guidance suggests the issue is not whether customisation exists, but whether customisation is isolated, observable, and reversible.
There is no universal standard for this yet, so teams should judge platforms by how much identity behaviour they can express without custom code. If a platform supports strong defaults but allows a small number of extension points, that is usually manageable. If it requires per-customer session logic, bespoke role provisioning, or manual IdP handling, complexity will accumulate quickly. This is especially important for secrets and privileged access, where the Ultimate Guide to NHIs shows that secrets and service identities often become persistent liabilities when they are embedded in code or managed outside governed workflows. The safest pattern is to keep identity rules external, auditable, and lifecycle-driven, aligned with NIST Cybersecurity Framework 2.0 and zero-trust principles. The model stops scaling when every new enterprise customer requires a different identity architecture just to log in, authorize actions, and offboard cleanly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Custom auth glue often hides poor NHI credential rotation and lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Role and entitlement sprawl maps directly to access control governance. |
| NIST AI RMF | Autonomous or dynamic identity decisions need accountable governance and oversight. |
Inventory service identities and rotate or revoke credentials through governed lifecycle workflows.
