What is an Identity Fabric? Composable identity architecture for hybrid environments

Few large organizations have one identity platform. They have a legacy directory, an IGA suite deployed to close audit findings, an SSO provider that arrived with the cloud, a privileged access vault, and dozens of SaaS applications with their own users. Each piece works on its own, but not together: an employee termination takes days to propagate from one system to the rest, and a compromised session is detected in one tool while nobody revokes it in the others.

Identity Fabric is the name the industry gave to the architectural answer to that problem.

What it is and what it is not

An Identity Fabric is an architectural approach, not a product. It means treating identity capabilities as interoperable services connected through APIs and open standards, operating consistently across on-premises data centers, public clouds and SaaS. Those capabilities are governance and administration (IGA), access management (SSO, MFA, federation), privileged access (PAM), directory, identity threat detection and response (ITDR) and analytics. Identity stops being a set of silos and becomes a cross-cutting layer, with explicit agreements on identity, context and policy.

Gartner popularized the term and in 2023 listed identity fabric immunity among that year's cybersecurity trends: identity infrastructure is fragile when its elements are incomplete, misconfigured or vulnerable, and it must be protected with ITDR while also being completed and properly configured. KuppingerCole publishes a Leadership Compass on Identity Fabrics with kindred principles: modularity, openness through APIs, and deployment flexibility.

Nor is it a rebranded suite, or collecting "best of breed" products for the sake of owning many tools. The fabric describes how the pieces are connected and governed, regardless of how many there are.

Why it matters now

Attacks that compromise identities and sessions are a central risk for any organization. If ITDR detects an anomaly but cannot tell the SSO provider to revoke the session or the PAM to rotate the credential, the detection is of limited use. A fabric is designed precisely for that response across components.

The standards have matured. SAML 2.0 and OpenID Connect have supported identity federation and user authentication for years; OAuth 2.0 is a delegated authorization framework, and SCIM (RFC 7643 and RFC 7644) standardizes identity data exchange and provisioning.

What is new is real-time exchange of risk signals. In September 2025 the OpenID Foundation approved the Shared Signals Framework and its CAEP (session and device events) and RISC (account compromise) profiles as final specifications. Its IPSIE working group, formed in 2024, is profiling those standards with secure defaults so that implementations actually interoperate.

Adopting them does not, by itself, eliminate adapters. Actual compatibility depends on the profiles each product implements, its capabilities, the data model and the operational agreements between components.

Buy one platform or weave a fabric?

Wouldn't a single suite be simpler? In a mid-sized, homogeneous environment, it can be. With tens of thousands of identities, sector regulation, legacy systems that will not be retired and mergers on the horizon, the question changes.

The difference lies in where the integration lives, more than in the number of tools. A suite can simplify integration among its own modules while also offering APIs and open standards to third parties. A fabric does not rule out suites; what it does is explicitly design the contracts between capabilities:

Documented APIs.
Standardized events.
A shared data model.
Agreements on how policy is decided and enforced, with traceability across the different decision points.

A suite can be an excellent node inside a fabric, provided it exposes its capabilities through standards rather than only consuming them. That lets you replace a component without redoing the rest, or add a new capability, such as ITDR, without waiting for your primary vendor.

The pieces you need

They do not have to come from different vendors, but they do have to be defined as services with clear boundaries.

Identity data and directory. The authoritative source for each attribute, correlation of one person's or one workload's accounts across every system, and a stable identifier. Without this, everything else governs accounts, not identities.
Governance and administration (IGA). Lifecycle, requests, certifications, segregation of duties. Platforms such as OpenText Identity Governance operate here; their value grows when their decisions are published as events that others consume.
Access management. Authentication, MFA, SSO and federation. A standards-based identity broker, such as Red Hat SSO, lets legacy applications and modern SaaS authenticate against the same policies.
Privileged access (PAM). Vaulting, rotation, monitored sessions, just-in-time access. CyberArk is the reference; what matters is that it receives signals from IGA and from ITDR.
ITDR and analytics. Anomaly detection and, above all, the ability to respond through the others: revoke sessions, force re-authentication, suspend accounts.
Orchestration and integration. SCIM connectors, an event bus, flows that cross systems. This is what turns isolated services into a fabric, and it is usually the most neglected layer.

Common pitfalls

Not solving correlation. If IGA believes a user has three accounts and ITDR sees five, no policy will be consistent. It is data work, unglamorous, and it is the foundation.

Orchestrating without governing. Moving accounts between systems does not replace certification, segregation of duties or audit evidence.

Custom connectors where a standard exists. Every proprietary integration is a dependency someone will have to maintain. If the system supports SCIM or OpenID Connect, use them.

Forgetting non-human identities. Service accounts, workloads and pipeline secrets already outnumber people in many environments, and they tend to fall outside governance.

A pragmatic path if you already have IAM

Nobody builds a fabric from scratch, and nobody needs to. The system with fifteen years in production will stay there; the fabric wraps and governs it. We recommend this order:

Inventory by capability, not by product. Which service covers each capability today and in which environments. You will usually find duplication in some layers and gaps in others, most often in correlation, ITDR and orchestration.
Data model and authoritative sources. Which system owns each attribute, how accounts are correlated and what the stable identifier is. Everything else rests on this model, so keep it versioned and under quality controls, because sources, applications and attributes change over time.
Expose legacy through standards. A SCIM facade in front of the directory; an OpenID Connect or SAML broker in front of applications that cannot federate on their own. The old system does not change; its contract with the fabric does.
Add the missing capability as a connected service. If ITDR is missing, integrate it from day one with SSO and PAM through events, not as an isolated dashboard. CAEP and the Shared Signals Framework make that exchange easier, provided the products implement compatible profiles and concrete response actions.
Harmonize policy and its traceability before consolidating tools. Define common rules, attributes, exceptions and responsibilities, then check how each component enforces them, because not every product shares the same engine or the same authorization semantics. That is more valuable, and more achievable, than bringing them into a single console.
Measure and retire by capability. When a better-connected service already covers a capability, retire the duplicate. That is how a fabric consolidates, not through a big-bang migration.

If you read our piece on the Identity Factory, the relationship is simple: the Factory is the operating model, that is, how identity processes are industrialized, and the Fabric is the architecture they run on. Each needs the other.

How a specialized consultancy helps

The hard part of an Identity Fabric is not primarily technical. You have to decide which capability lives where, what gets wrapped and what gets retired, and in what order, against the reality of licensing contracts, audits and the teams that already exist. An independent assessment that compares current capabilities against the target architecture and delivers a prioritized roadmap avoids buying what is not needed, and surfaces what is missing before an attacker or an auditor finds it. At Clear Intelligence we deliver that capability assessment and roadmap, with platforms such as OpenText, CyberArk and Red Hat SSO.

Sources and standards

Related services

IAM Health Check: capability inventory by layer and gaps against a composable identity architecture.
Integrations: connect directory, IGA, PAM and applications through SCIM, OpenID Connect and shared signals.
Hybrid Cloud: consistent identity policy across your data center, public clouds and SaaS.