A disconnected identity function usually shows up when teams learn one tool at a time, rely on vendor-specific knowledge, and lack a shared framework for governance or skills development. Another sign is slow maturity, where practitioners need years to feel proficient because there is no common body of knowledge to anchor the discipline.
What a disconnected identity function looks like day to day
The clearest sign is fragmentation in how people describe and operate the function. One team treats it as IAM tooling, another as governance, another as a vendor contract, and another as a help desk workflow. When the operating model is fragmented, the function behaves like a collection of products instead of a discipline with shared ownership, lifecycle rules, and a consistent control intent.
That fragmentation usually shows up in the basics: inconsistent naming, duplicated processes, uneven onboarding and offboarding, and no common way to explain who owns access decisions. A mature identity function should be able to answer the same questions across platforms, users, and credentials. When every answer depends on the product in front of you, maturity is still shallow.
It also creates a translation problem. Practitioners learn feature by feature, but not the underlying patterns that connect provisioning, authentication, authorization, review, and retirement. In practice, that means teams can operate a dashboard without being able to tell whether the underlying identity control is actually improving. The Identity Security Programme Guide is useful because it frames the function as an operating model, not a shopping list of tools.
Why tool-centric learning is a maturity warning
When the primary learning path is “how this vendor works,” instead of “how identity should work,” the organisation becomes dependent on product-specific knowledge. That is a warning sign because it slows portability, weakens cross-team understanding, and makes the discipline hard to scale. The function remains reactive, because people are always solving the next platform issue rather than building shared identity practices.
A second warning sign is that maturity stalls at the same points every time a platform changes. If the team has to relearn the basics after a migration, acquisition, or new cloud rollout, then knowledge has not been captured as a reusable body of practice. The issue is not simply poor documentation, it is that the organisation lacks a common model for identity lifecycle, governance, and control design.
This is where a broader lifecycle view matters. The NHI Lifecycle Management Guide shows why provisioning, rotation, offboarding, visibility, and recertification need to be treated as one connected system. Even when the implementation spans different products, the operational logic should stay consistent.
How to tell whether the function has a shared discipline or just shared tooling
Look for whether teams can move between products without losing the control model. In a connected function, people can explain what is being governed, why access is granted, how it is reviewed, and when it should be removed, regardless of platform. In a disconnected function, the conversation collapses into product features, tickets, and vendor terminology.
Another useful signal is whether identity decisions are repeatable across the portfolio. If one system has strong joiner, mover, leaver handling while another still relies on manual exceptions, the problem is usually not technology alone. It is that governance, skills, and ownership have not been standardised enough to outlast the tools themselves.
The broader pattern is visible in the Top 10 NHI Issues, where issues such as ownership gaps, excessive permissions, stale access, and credential sprawl often reflect process fragmentation rather than isolated product defects. If the same failures recur in different systems, the function is not yet operating as a coherent discipline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Fragmented identity work usually reflects unclear operating context and ownership. |
| GV.OV-01 — Oversight of the Cybersecurity Risk Management Strategy | A shared identity model depends on oversight beyond individual product teams. | |
| Recommendation — Define identity as a governed enterprise capability with clear ownership and scope. Review identity program performance as an enterprise risk and governance issue. | ||
| NIST SP 800-53 Rev 5 | PL-2 — System Security and Privacy Plans | A coherent identity function needs documented control intent, owners, and lifecycle handling. |
| Recommendation — Document identity control responsibilities and lifecycle expectations in a maintained plan. | ||
| CIS Controls v8 | CIS-5 — Account Management | Disconnected identity functions commonly fail in provisioning, review, and removal consistency. |
| Recommendation — Standardize account and access lifecycle handling across platforms. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Identity maturity requires consistent access control rules, not product-by-product exceptions. |
| Recommendation — Establish one access control model that applies across the identity estate. | ||
Practitioner Guidance
What to prioritise: Start by checking whether identity ownership, lifecycle handling, and access review are defined once and applied consistently, or whether every platform has its own local version. If the organisation cannot describe the control model without naming a vendor, the function is still product-led.
What to verify: Ask whether teams can explain identity work in terms of lifecycle, governance, and accountability, not feature names. A good test is whether a new hire could learn the operating logic of the function without first learning a specific tool stack.
Common mistake: Treating training completion or tool rollout as evidence of maturity. Those are adoption signals, not discipline signals. The stronger indicator is whether knowledge survives product change and remains useful across systems.
Practitioner takeaway: A connected identity function is recognisable by transferable practice, not by familiar tooling, if the organisation cannot explain identity consistently across products, it has not yet built a true identity discipline.
