> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/programme/sequence.md). # Sequence: lifecycle before SSO Why identity lifecycle and governance are established before single sign-on, what goes wrong when the order is inverted, and the four situations where federating first is genuinely the right call. ## What this is, and when you need it There is one ordering decision in an identity programme that is worth arguing about, and this is it. **Establish identity lifecycle and governance first; add single sign-on to applications afterwards.** Not because lifecycle is more important, but because single sign-on has a precondition that lifecycle supplies: the person has to be known in OpenIAM *and* known in the target application before an assertion about them can mean anything. You need this page when a sponsor wants a visible first-quarter win, when a project plan has SSO in phase one and joiner-mover-leaver in phase three, or when an application team has offered to integrate next month and the identity model is not settled. It is the argument, its reasoning, what happens when the order is inverted, and the situations where inverting it is correct. ## The decision | Order | What it delivers first | What it costs | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Lifecycle, then SSO** (recommended) | Correct accounts in target systems, correlated to people, with a leaver path that works. Nothing users can see for several months | Political capital. The first deliverable is invisible to everybody except the people who used to raise tickets | | **SSO, then lifecycle** | A visible, popular change in weeks. Users stop typing passwords | Accounts created outside any governed process, a leaver path that ends sessions without ending access, entitlements decided inside applications where nobody can review them, and a correlation exercise that grows every month it is deferred | | **Both at once, per application** | Each integration is complete when it is done | Only workable where the identity foundation is already settled — which is to say, where lifecycle came first anyway, at the design level | ## Why the order is not a preference Single sign-on is a statement about a person made by one system to another. For the receiving application to act on it, the person must resolve to something the application already holds — an account, a profile, a set of entitlements. That resolution is what lifecycle produces. Take from the diagram that single sign-on sits at the end of a dependency chain, not at the start of one. ```mermaid flowchart LR KEY[A correlation key spanning the estate] --> ID[A governed identity in OpenIAM] ID --> ACC[An account in the target application] ACC --> SSO[Single sign-on to that application] ID --> GOV[Certification, requests, SoD, termination] ACC --> GOV ``` Read the arrows as "cannot work without". Two of them carry the whole argument. **Single sign-on depends on an account existing in the target**, and something has to create that account correctly — either lifecycle provisioning, or an existing directory synchronization you already trust, or an on-the-fly creation at first sign-in, which is the fallback discussed below. **And governance depends on both**: a certification campaign can only attest to accounts that were correlated to a person, and an account nobody could correlate is precisely an orphan. The precondition is lifecycle, not necessarily *OpenIAM's* lifecycle. Where a directory synchronization already creates and removes accounts reliably, and the population is correlated, single sign-on to those applications can proceed while OpenIAM's own lifecycle is being built. The failure case is not "OpenIAM did not provision it" — it is "nothing did, and nobody noticed". ## What goes wrong in the other order Five failures, in the order they surface. **Accounts appear that nobody can attach to a person.** Where the first sign-in creates the account, the account carries whatever the assertion supplied. If the estate has not yet settled what value identifies a person — and it has not, because that is a Part 2 decision the programme deferred — the accounts accumulate against usernames that differ between directories. Correlating them later is a re-matching exercise across every integrated application, and it gets larger every month. **Termination stops looking like termination.** Removing federated sign-in ends the assertion and the session. It does not remove the account in the application, its standing entitlements, its API tokens or its local password if the application kept one. In an estate with legacy applications that still hold their own credential store — which is most estates — the leaver retains a working route in. The programme will report the leaver process as complete, and it will be complete only for the applications that had no other way in. **Entitlements are decided where nobody can see them.** With single sign-on but no governed request path, access inside the application is granted by the application's own administrator. Those grants are invisible to OpenIAM, so they are invisible to certification, invisible to segregation-of-duties detection, and absent from the access report. The organization has bought an identity governance platform and is governing the front door. **Password synchronization gets confused with single sign-on, and both get confused with governance.** They solve three different problems. Synchronizing a password makes one credential work in several places; single sign-on removes the second prompt; lifecycle decides whether the account should exist at all. A programme that delivers the first two and defers the third has improved the experience of using access nobody is reviewing. **The evidence chain has a hole in the middle.** When the first audit asks who approved a person's access to an application and when it was removed, the answer for anything integrated in the SSO-first phase is a set of authentication events. Authentication events prove that somebody signed in. They do not prove that they were entitled to. ## The fallback, and why it is a fallback Creating the identity at first sign-in — just-in-time provisioning — is a real capability and it works. It is the right tool in specific places, and it is the wrong basis for a workforce programme, for reasons that are properties of the mechanism rather than of any product. Just-in-time creation **does not detect a leaver who simply stops signing in**. Nothing happens when somebody stops arriving; the identity persists, entitled, until something else removes it. It **does not reconcile a population** — you cannot ask it who exists, only observe who has turned up. And it **does not establish that a person is unique**, because it acts on whatever the assertion carried, which is exactly the value the identity foundation was supposed to decide. Synchronization, by contrast, gives you the whole population, on a schedule, with removals as well as additions and a record of both. **Prefer synchronization for workforce identity and treat just-in-time creation as the fallback**, most defensible where there is no authoritative feed to synchronize from — which is the normal condition in customer and partner identity, and the abnormal one in workforce. ## The exceptions Four situations genuinely justify federating before OpenIAM's lifecycle reaches an application. All four share a property: something else is already doing the lifecycle job, or there is no lifecycle job to do. **The application holds no local access state.** Where an application's authorization comes entirely from the assertion and it stores nothing about the person between sessions, there is no account to provision and nothing to certify. Federate freely; the governance happens in OpenIAM, which is where the entitlements live. **A trustworthy account lifecycle already exists elsewhere.** An application fed by an established directory synchronization, with a leaver path that has been proved, already has the precondition. Bring it into single sign-on and migrate its lifecycle later; just be honest about "has been proved" — somebody should have tested a leaver end to end rather than assumed one. **Customer, partner or consumer identity.** There is no HR feed, no joiner event and no authoritative source to synchronize. Creation at first sign-in is the design rather than a shortcut, and the governance obligations are different in kind. **A dated bridge during a merger or acquisition.** People need to reach the other organization's applications before the two estates can share a lifecycle. That is a legitimate tactical decision when it is bounded: a stated end date, a named compensating control for the leaver case — usually a manual cross-organization termination process with an owner — and the lifecycle integration already in the plan. Without those three, it is not an exception; it is the inversion this page argues against, with a better name. Note what is *not* on the list. "The users are asking for it", "it is the only thing they will notice", and "the application team is available now" are real pressures and they are not exceptions. They are the reason this position needs stating in a document that a sponsor has signed. ## What we recommend **Settle the correlation key before anything is federated.** It is the cheapest decision in the programme to make early and the most expensive to make late, and every account created before it is settled becomes a re-matching task. See Part 2, *Identity correlation: choosing a matching key*. **Deliver lifecycle for one population and one directory before the first application is federated.** Joiner, mover and leaver, proved end to end, with a leaver tested against a real target rather than a report. **Say out loud that phase one is invisible**, and agree a different first-quarter win with the sponsor — a self-service password reset, a request catalogue for a handful of applications, an access report that nobody could produce before. All three are visible, all three depend on the same foundation, and none of them commits you to federating before you are ready. **Where an application is federated ahead of its lifecycle, record it as a deviation with a date.** A list of applications that have single sign-on but no governed lifecycle is a useful artefact; it is exactly the list an auditor will ask for, and maintaining it deliberately is better than reconstructing it under pressure. **Never present password synchronization as single sign-on**, in either direction. The conflation survives into requirements documents and produces designs that satisfy neither. The circumstance that changes this advice is an estate where authentication is the acute problem and lifecycle is not: a merger where two workforces cannot reach each other's systems at all, or an authentication platform being decommissioned on a fixed date. There the sequencing is imposed from outside, and the right response is the dated-bridge exception above — take the deviation deliberately, name the compensating control, and keep the lifecycle work in the plan rather than behind it. ## What OpenIAM does not do here * **Nothing in the product enforces this order.** Federation can be configured against an estate with no authoritative source, no correlation key and no lifecycle, and it will work. * **Single sign-on does not deprovision.** Removing a federation trust or a user's ability to authenticate ends sessions; it does not remove accounts, entitlements or credentials in the target. * **Just-in-time creation does not detect leavers, reconcile a population, or establish uniqueness.** Those are properties of synchronization, and they do not arrive with federation. * **Authentication events are not access evidence.** The audit trail records who signed in; it does not record who was entitled to, which is a different record produced by a different mechanism. * **There is no report of applications that are federated but not governed.** That list is one you keep. ## Related * [Phasing a rollout](/solution-architecture/programme/phasing-a-rollout.md) — what the first, invisible phase should actually contain. * Part 2, *Identity correlation: choosing a matching key* — the decision this page says must come first. * Part 3, *Where authentication should live* and Part 3, *Password strategy* — the authentication design this sequencing defers, not cancels. * Part 5, *Cross-organization federation* — the merger case, where the dated-bridge exception usually applies. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/programme/sequence.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.