It is an architecture you describe. It says which capabilities have to exist, who owns them and how they are consumed — and it deliberately separates that from which tool provides each one, because tools get replaced and the architecture should survive it.
Identity Fabric
Woven from what you already run.
A fabric is what you get when identity stops being a set of products bolted to each other and becomes a set of services anything can consume. The threads are the populations asking for access and the capabilities answering them — and the fabric only exists where they cross.
What it is, and is notA fabric is a product you buy A fabric replaces the IAM you have A fabric is one vendor consolidating everything
Three things the word is used to mean
The term arrived from the analyst world and then from every vendor's slide deck, which has left it meaning three incompatible things. Only one of them is useful.
The opposite. A fabric assumes the estate stays mixed: a directory that is not moving, an IGA implementation half rolled out, a legacy access manager in front of an application nobody will rewrite. What changes is that they stop being isolated.
Single-vendor consolidation is the failure mode, not the goal. The value is in the integration of services with clear boundaries; a supplier that widens its box until it covers everything has removed the property that made the architecture worth having.
The architecture
Four layers between whoever asks and whatever answers
Above them, everything that needs access: people, partners, customers, workloads and — a population that did not exist in the last version of anyone's diagram — software agents acting on somebody's behalf. Below them, the systems, including the ones that will never be rewritten.
Orchestration
The layer that decides the sequenceUser journeys and administrative flows drawn as diagrams: what happens first, what branches, what is asked for when the answer is not good enough. Because the flow is a picture rather than a call stack, the people who own the process can read it without reading code.
Authorization
Evaluated per request, not per loginRoles, attributes and entitlements held centrally and applied at the point of access, so each application stops keeping its own drifting copy of the rules. A session carries a scope and conditions, and can be narrowed or ended from outside the application.
Identity data and relationships
Who is who, and what they are to each otherMost fabric projects fail here rather than on protocols: duplicate identities, an HR feed a week behind reality, entitlement names that mean nothing to the person approving them. Automation inherits every one of those defects and applies them faster.
API layer and connectors
Standards first, connectors where standards endSAML, OpenID Connect, OAuth, SCIM, LDAP, RADIUS and WebAuthn natively; connectors for the systems that speak none of them. This is also where the honest limit sits: a fabric governs what it can reach, and nothing else.
Why services, not projects
Three clocks, and only one of them is yours
The argument for delivering identity as consumable services is not architectural elegance. It is that the other two clocks in this picture run faster than the project one, and they do not negotiate.
The projectQuarters
Scoping, approval, procurement, rollout. This is how long an identity initiative takes, and it is not obviously wrong — it is just a different unit of time from everything around it.
The incidentMinutes
Detection, exploitation, escalation. An attacker who reaches a valid session does not wait for the next phase of your roadmap, and neither does the response that has to cut it.
The workaroundImmediately
What a delivery team does when the identity service is not available on their timeline: its own login, a hardcoded token, a shared account. The organisation gets an identity layer either way; the only question is who built it.
A capability delivered as a service — an API, an owned flow, a documented level of service — can be consumed the week it is needed. A capability delivered as a project can only be waited for, and waiting is what produces the third lane.
Where Monokee sits in it
What we weave, and what stays where it is
Having said that single-vendor consolidation is the failure mode, the least we owe you is a boundary drawn on our own side of it.
Monokee provides
- Authentication and federationAs identity provider, as service provider, or as broker between the two — including in front of identity providers you keep.
- MFA and passwordlessWebAuthn, FIDO2 and passkeys as factors inside a flow, with step-up bound to the action rather than to the front door.
- Governance and lifecycleJoining, moving and leaving, provisioning with reconciliation, access requests, certification campaigns, segregation of duties.
- Credentials and walletsIssuing and verifying verifiable credentials on open standards, as steps in the same journeys that run the federation.
- Multi-domain and delegationSeparate populations with their own administration and their own credentials, without consolidating them into one directory first.
Stays with what you have
- Privileged access and secretsVaults, session recording, credential rotation. Monokee governs who may reach them and under what assurance; it does not replace them.
- Detection and responseSIEM, XDR, SOAR. The fabric contributes signals and consumes them — a risk verdict can change an access decision — but the security operations stack stays where it is.
- Service managementTickets remain the system of record for manual fulfilment, which is how applications with no connector stay inside governance instead of outside it.
- The applications themselvesA fabric does not remove application-level logic. It removes the need for each application to invent its own identity behaviour.
Getting there
Nobody arrives at a fabric by designing one
Target architectures are useful and they are not a starting point. Four steps, in this order, each one finishable.
- 01
Write down what is actually connected
Not what is planned. Governance and orchestration reach exactly as far as the integrations, and the gap between the diagram and the connected estate is the real starting position.
- 02
Pick the journey that hurts
Onboarding a partner, a joiner who waits four days, a step-up that annoys everyone and stops nobody. One flow, end to end, with a date — not a target architecture with a workshop.
- 03
Weave it, then leave the rest alone
The flow crosses the systems it has to cross and nothing else. A fabric earns its second project by finishing its first, which is the opposite of how identity programmes are usually scoped.
- 04
Measure what changed
Time to first access, time to revoke, number of accounts nobody owns, share of applications inside the process. Four numbers, all of them uncomfortable, all of them movable.
Bring us the flow that crosses four systems
The one where a person waits, or an approval gets lost, or nobody can say afterwards what was granted. That is the thread we would pull first.
Ask for a demo