Identity Fabric Solutions

Most organizations do not have an identity system. They have several: an on-premises Active Directory, a cloud directory, a customer identity service, a privileged access vault, a governance tool bolted on for the auditors, and a few applications with their own user stores that nobody has had time to migrate. Each one works. Together they do not, and the gaps between them are where access goes stale, policies disagree, and incidents start.

"Identity fabric" is the name the analyst firms gave to the alternative: not one product that replaces everything, but an architecture in which the identity services you already have are connected, governed and observed as one system. This article explains what that means in practice, which components matter, where vendors fit, and how to get there incrementally.

Why the Fragmentation Happens

Nobody designs a fragmented identity estate. It accumulates:

• Hybrid infrastructure. Active Directory stays because legacy applications and Windows need it; a cloud directory arrives with Microsoft 365 or Google Workspace; the two are synchronized rather than unified.
• Customer identity is built separately because it has different scale, privacy and user-experience requirements than workforce identity.
• Mergers and acquisitions bring whole second estates, often on a different vendor.
• Best-of-breed purchases: a PAM product for the auditors, an IGA product for access certification, an MFA product chosen before the directory vendor offered one.
• Multi-cloud: AWS, Azure and GCP each have their own IAM model, and workloads in each need identities.

The symptoms are familiar. A leaver is disabled in one directory and active in three others. A Conditional Access rule protects Microsoft 365 but not the application behind the legacy SAML gateway. Audit evidence takes weeks to assemble because every system reports differently.

What a Fabric Is

The idea has four properties. If an architecture has them, it is a fabric regardless of how many vendors are involved.

1. Consistent policy. The same access rules (who may sign in, from where, with what assurance) apply across every application and every directory, including the ones you cannot modify.
2. Orchestrated flows. Sign-in, registration, step-up and recovery are composed from services rather than hard-coded in each application. Change the MFA provider once and every flow changes.
3. Standards at the seams. Components talk OpenID Connect, SAML, SCIM, OAuth 2.0 and, increasingly, the Shared Signals Framework (CAEP and RISC) for events. Proprietary connectors are allowed; proprietary interfaces between core components are not.
4. Observability. One place to see who has what, how they got it, and what they did with it, feeding analytics that can flag anomalies and drive remediation.

flowchart TB
  subgraph Sources__Identity_so ["Sources["Identity sources"]"]
    AD["Active Directory"]
    HR["HR system"]
    CL["Cloud directory"]
  end
  subgraph Fabric__Identity_fab ["Fabric["Identity fabric"]"]
    ORCH["Orchestration: sign-in, registration, step-up flows"]
    POL["Policy: authorization and risk decisions"]
    GOV["Governance: lifecycle, certification, entitlements"]
    OBS["Observability: logs, analytics, signals"]
  end
  subgraph Consumers__Consumers ["Consumers["Consumers"]"]
    SAAS["SaaS apps (OIDC/SAML)"]
    LEG["Legacy apps (via proxy or gateway)"]
    API["APIs and workloads"]
    CUST["Customer-facing apps"]
  end
  Sources --> Fabric
  Fabric --> Consumers
  Consumers -->|"events (SSF, logs)"| OBS
  OBS -->|"risk signals"| POL

The Components

Directories and sources of truth. The fabric does not require a single directory, but it requires knowing which system is authoritative for each attribute. HR for employment status, the workforce directory for workforce accounts, the CIAM store for customers. Everything else is a copy, and copies need a sync with a defined direction.

Orchestration. An orchestration layer lets you define journeys (for example, "password, then push MFA, unless the device is managed, then passkey") as configuration, with the individual steps provided by whichever services you have. This is the component most organizations are missing. Without it, each application's login page is a separate implementation, and policy changes become projects.

Authorization and policy. Coarse-grained decisions (can this user reach this app) live in the access management layer; fine-grained ones (can this user approve this invoice) increasingly move to a policy service using a standard such as OpenID's AuthZEN, OPA, or Cedar, so the rules are not re-implemented in each application.

Governance. Joiner, mover and leaver automation, access requests, certification campaigns and separation-of-duties checks, applied across every connected system, including the ones that only speak SCIM through a proxy.

Privileged access. Vaulting, session brokering and just-in-time elevation for administrators and for machine credentials. In a fabric, PAM is wired to the same policy and governance layers, so an admin's standing privilege shows up in the same certification campaign as everyone else's access.

Workload and machine identity. Service accounts, API keys, certificates and cloud workload identities outnumber humans by a wide margin in most estates. Treating them as first-class identities, with owners, expiry and review, is part of the fabric rather than an afterthought.

Observability and signals. Centralized logs, an identity analytics capability (what Gartner calls identity threat detection and response), and event exchange between components. When the CIAM system sees a credential-stuffing wave, the workforce side should learn about it.

Where the Vendors Fit

Every large vendor now describes its portfolio as a platform or a fabric. The honest summary is that each one covers some of the components natively and relies on standards for the rest. Treat the list below as a starting point for your own evaluation rather than a scorecard; products change quarterly and the right answer depends on what you already run.

Two categories are worth calling out because they are what make a multi-vendor fabric work. Orchestration specialists (Ping's DaVinci, Strata's Maverics, and the orchestration features in IBM Verify and Microsoft's External ID) let you compose journeys across vendors and, in Strata's case, retrofit modern authentication onto applications that cannot be changed. Identity security posture and threat detection tools consume logs from all of the above and are where the "observability" property usually comes from in practice.

Choosing: Questions That Decide It

• What is the anchor? Most organizations end up with one access management platform as the anchor (often Microsoft or Okta, because of the application integrations they already have) and attach governance, PAM and CIAM to it. Decide the anchor first; it constrains everything else.
• Which components must be best-of-breed? Regulated environments frequently need a PAM product the auditors already know; large customer-facing businesses need CIAM scale and privacy features that workforce products lack. Everything else can be "good enough from the anchor".
• Can every application reach the fabric? Count the applications that speak neither OIDC nor SAML nor SCIM. If the number is large, the orchestration or proxy layer is the first purchase, not the last.
• Who owns the policy? A fabric that spans vendors needs one team that owns authentication and access policy across them. Without that, consistent policy is a slide, not a property.
• What does the audit need? If the evidence auditors ask for cannot be produced from one place, the observability component is missing, whatever the vendor diagram says.

Getting There Without a Big Bang

A fabric is reached by sequencing, not by replacement.

1. Inventory and classify. Every application, its protocol, its user store, its owner. Every non-human identity and who owns it. This is dull and it is the step most programs skip.
2. Pick the anchor and the standards. Declare that new applications integrate through OIDC or SAML and provision through SCIM, and that exceptions need sign-off.
3. Put orchestration in front of the long tail. Move the sign-in journeys of legacy and bespoke applications behind the orchestration or proxy layer so policy applies to them without code changes.
4. Connect governance to everything that is connected. Access reviews and lifecycle automation only count for systems the governance tool can see; expand its connectors in the order of risk.
5. Wire the signals. Centralize logs, enable event exchange (Shared Signals, where supported), and build the handful of detections that matter: dormant privileged accounts, impossible travel across systems, access granted outside the request process.
6. Retire by attrition. Decommission redundant directories and local user stores as their applications are migrated, not as a separate project that never gets funded.

Common Mistakes

• Buying a "platform" and calling it a fabric. A single-vendor estate still needs orchestration, observability and an application inventory; the vendor logo does not supply them.
• Starting with the directory consolidation. Merging directories is the hardest, longest step and delivers the least on its own. Start with policy and orchestration, which deliver while directories still coexist.
• Ignoring machine identities. Secrets in pipelines and cloud workload identities are where the attacks have moved; a fabric that governs only people governs the minority of identities.
• Letting each application keep its own authorization model. Fine-grained rules re-implemented per application are the next generation of fragmentation.

Key Takeaways

• An identity fabric is an architecture, not a product: consistent policy, orchestrated flows, standards at the seams, and one view of who has what.
• Decide the anchor platform first, then attach best-of-breed governance, PAM or CIAM where the business genuinely needs them.
• Orchestration and application inventory are the usual missing pieces; without them the long tail of applications never joins the fabric.
• Governance and detection are only as complete as the systems they can see; expand connectivity in the order of risk.
• Sequence the change: policy and orchestration first, governance connectivity second, directory consolidation last and by attrition.