Identity fabric cost: legacy apps, service accounts and MFA extension

Identity fabric is the Gartner-defined approach to identity for zero trust that treats identity as a layered architecture rather than a single identity provider. The fabric stitches together on-premise Active Directory, cloud identity providers (Microsoft Entra, Okta, Ping, ForgeRock), HR systems of record (Workday, SuccessFactors, BambooHR), customer identity platforms (Auth0, Entra External ID, Okta Customer Identity), workload identity for cloud-native (SPIFFE / SPIRE), and the secrets vaults that handle non-human credentials. The principle is that no single identity provider can serve every use case in a modern enterprise; the fabric makes the multi-provider reality work coherently for zero trust.

The fabric approach has emerged because the single-IdP fantasy never matches enterprise reality. Even in greenfield cloud-native organisations, customer identity is usually a separate platform from workforce identity (different scaling profile, different pricing model, different feature set). Even in Microsoft-centric organisations, the legacy applications that do not speak SAML or OIDC need something other than direct Entra integration. Even in modern devops shops, service accounts and workload identity sit outside the human-identity provider. The fabric makes these realities coherent rather than fighting them.

For zero trust specifically, the fabric is the foundation that makes the Policy Engine work across the full estate. A Policy Engine that only understands users from one IdP is blind to half the actual access requests in the environment. A Policy Engine that sits on top of a coherent fabric, with consistent identity primitives for workforce, customers, service accounts, and workloads, can make access decisions across the full estate. The fabric is what makes universal zero trust enforcement possible.

Legacy applications are the most common identity-fabric scope item. Mid-market and enterprise estates routinely have ten to fifty applications that do not support SAML, OIDC, or any modern identity protocol. These applications are often line-of-business critical (ERP, accounting, scheduling, manufacturing control), sometimes maintained by tiny vendor teams, sometimes built in-house decades ago. Direct integration with a modern IdP is not possible; the apps simply do not speak the protocols.

Three patterns work, in increasing order of long-term effectiveness. Identity-aware proxy places a reverse proxy in front of the app that handles authentication before traffic reaches the legacy back-end. Microsoft Entra Application Proxy, Google Identity-Aware Proxy, Cloudflare Access and Okta Access Gateway all offer this. Cost: $5 to $10 per user per month for users accessing the legacy app, plus one to three days of engineering per app for the proxy setup. This is the fastest path and the most cost-effective in year one. Legacy modernisation rewrites or wraps the app to speak modern identity protocols natively. This is the cleanest long-term solution but the highest one-time cost: budget $50K to $500K per app depending on its complexity. Compensating network controls wraps the legacy app in microsegmentation and ZTNA so that only authenticated identity-aware traffic ever reaches it, accepting that the app itself remains identity-blind. The compensating-control path is the cheapest in year one but the weakest in audit posture, particularly for SOC 2 and ISO 27001 audits that look for MFA enforcement.

Mature programmes use all three approaches in combination. Identity-aware proxy for the simple legacy apps where the proxy setup is straightforward and the app behaviour does not require deeper integration. Legacy modernisation for the strategic apps that will be in production for another five to ten years and merit the investment. Compensating network controls for the apps that will be retired or replaced within eighteen months and do not justify the modernisation cost. The portfolio approach is more expensive in total than any single approach, but it correctly addresses the heterogeneity of the legacy estate.

Service accounts are the most common audit finding in mid-market and enterprise environments and the most common lateral-movement vector in incident-response cases. Verizon's 2024 Data Breach Investigations Report found stolen credentials in 38 percent of breaches; service-account credentials are disproportionately represented in the lateral-movement phase of breach scenarios because they are long-lived, often shared, and rarely rotated.

The zero trust pattern for service accounts is migration to short-lived tokens issued from a secrets vault. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault and CyberArk Conjur all offer this. The consuming application requests a token from the vault on demand, uses it for the immediate call, and discards it. Token lifetimes are minutes or hours rather than years. Compromise of a single token has narrow blast radius; compromise of the vault itself is the new risk concentration, which is why vaults are treated as crown-jewel infrastructure with elevated security controls.

The cost is mostly engineering time, not licensing. A vault platform license runs $30K to $400K per year for mid-market scale, which is the visible cost. The hidden cost is the per-service-account migration work: every service account is a discrete task with its own application owner, its own consuming applications, and its own credential-rotation gotchas. A typical mid-market environment has 200 to 600 service accounts; allocating two to four hours of engineering per account works out to 400 to 2,400 hours of effort, or $80K to $400K loaded. That budget line does not appear on the licensing quote and is the most under-budgeted identity-pillar cost.

A useful sequencing trick: do the secrets vault rollout in parallel with universal MFA in Phase 1 of the zero trust rollout, rather than as a separate Phase 3 workstream. The two share most of the same engineering team (identity engineering) and benefit from the same change-management runway (everyone is paying attention to identity changes during the MFA rollout). Running them in parallel saves 20 to 30 percent of the engineering cost compared to running them sequentially.