IAM cycle in action: a mid-market IT consultancy

A guest account nobody remembered

A bank’s security team runs its quarterly review of external accounts in its cloud tenant and finds a guest identity belonging to a Northcape consultant. The engagement it was created for ended four months ago. A quick search turns up something worse: the consultant is now working on a project for one of the bank’s direct competitors. Nobody did anything wrong on purpose. The consultant moved on, the project closed, and the guest account in the bank’s tenant simply stayed. The bank’s call to Northcape that afternoon is not a friendly one.

Sara leads IAM at Northcape, and this article closes the module somewhere between the two previous extremes. The hospital was heavy with regulation; the startup was light on governance and fast on its feet. A consultancy is neither. It’s a mature, consolidated organization whose defining trait is constant internal movement. Its people don’t sit in fixed roles touching fixed systems; they rotate between client engagements, and each rotation reshapes their access. If the JML article said the mover is the step most programs neglect, this is the organization where the mover is the main event.

Northcape is a 2,000-person IT consultancy serving mid-sized and large clients in application development, cloud migration and managed services. It’s well established and profitable, with a real IT function and mature tools. Its challenge isn’t capability but the speed of change: at any moment, hundreds of consultants are rolling off one engagement and onto another, and a large share of their access lives not in Northcape’s systems but inside clients’ tenants. In most organizations access follows your job. In a consultancy it follows your current engagement, and engagements change far faster than jobs. Design for the assignment, not the title, or your access model will always describe where people used to be.

Populations shaped by the work

Northcape’s identities are organized around how people relate to the work, not just to the firm. About 1,500 billable consultants rotate constantly between projects, with their identity coming from the HR system and their assignments from the project staffing system, the PSA. About 150 are on the bench between engagements, with reduced access while they wait for the next one. About 200 subcontractors are tied to engagements from outside, recorded in supplier management and the PSA. About 150 internal staff in HR, finance and IT have stable, conventional roles from the HR system alone. And thousands of guest identities live in clients’ own directories, federated into their tenants.

The interesting groups are the first two. A billable consultant on a project has that project’s access. A consultant on the bench between projects should have reduced access, internal systems only and no client environments, because they aren’t serving anyone right now. The move between billable and bench, in both directions, is a mover that happens all the time, and treating the bench as a real state with its own smaller access set is what stops idle consultants from carrying live client access they have no current reason to hold.

Two sources: who you are and what you’re on

A conventional organization can run JML from the HR system alone. Northcape can’t, because HR knows who someone is and their grade but not which engagement they’re on this week, and access depends on the latter. So Northcape runs a second authoritative source, the project staffing system, which owns assignments, roles within each engagement and project end dates. The firm’s identity, grade and employment come from HR. The current engagement and its end date come from the PSA, because staffing decides who’s on what and until when. Subcontractor status comes from supplier management, because subcontractors aren’t on the payroll. And access inside a client’s tenant is authorized by the client’s own directory, through federation.

The IGA platform combines those feeds. HR establishes the identity and its baseline, the PSA drives engagement-specific access with firm end dates, and the result is access that reflects current reality. The key rule built into it is that engagement access expires with the engagement. Because the PSA carries an end date for every assignment, access can be limited to disappear when the project closes, just-in-time access at the scale of a whole engagement.

Rolling onto an engagement

At Northcape, the joiner, a new consultant joining the firm, is the rare event, and the mover, a consultant rolling between engagements, is the constant one. Both use the same machinery, so the rotation is the flow to study.

flowchart TB
  accTitle: A consultant rotating between client engagements
  accDescr: A PSA assignment-change event fires when a consultant rolls off engagement A onto engagement B. The IGA platform revokes the engagement A access set, including federated guest access to client A's tenant, then provisions the engagement B access set with federated access to client B's tenant and a time-box set to engagement B's end date. The change is logged for both the firm and the affected clients.
  PSA[PSA assignment change<br/>roll off A, onto B] --> REVOKE[Revoke engagement A access]
  REVOKE --> DEFED_A[Remove federated guest<br/>in client A tenant]
  PSA --> GRANT[Provision engagement B access]
  GRANT --> FED_B[Add federated guest<br/>in client B tenant]
  GRANT --> BOX[Time-box to engagement B end date]
  DEFED_A --> LOG[Log for firm + clients]
  FED_B --> LOG
  BOX --> LOG

This is the JML article’s rule that every mover is a small leaver plus a small joiner, made literal and unavoidable. Rolling onto engagement B without rolling off engagement A doesn’t just create privilege creep. It leaves the consultant with standing access to a client they no longer serve, which in consulting is a breach of confidentiality and of conflict-of-interest rules, not just untidy access. The removal half is the one that protects the firm’s contracts, so it can’t be optional or manual. The bank’s phone call was about exactly this half.

Access that lives in clients’ tenants

The structural twist in consultancy IAM is that much of a consultant’s access isn’t in systems Northcape controls. It’s inside the client’s environment. A consultant building software for a client signs into the client’s cloud tenant, repositories and ticketing system. How does Northcape govern access it doesn’t own?

The answer is federation. The consultant authenticates with their Northcape identity and is admitted to the client’s tenant as a guest or external user, for example through Microsoft Entra B2B collaboration. Authentication stays with the employer and authorization is granted by the client. It’s elegant, but it creates a sharp responsibility for removal. When a consultant rolls off, Northcape has to remove the guest access in client A’s tenant, not wait for client A to notice. When a consultant leaves Northcape altogether, every federated guest identity in every client has to be revoked, or the person keeps live access to several clients after leaving. And the home identity is the linchpin: disabling it at the source should cut federated access everywhere, which is why the firm has to drive offboarding rather than leaving it to each client.

It’s tempting to assume that because the access lives in the client’s tenant, the client owns offboarding. In practice they don’t. They can’t see your staffing changes and have no incentive to chase your departed consultants. If Northcape doesn’t remove its own people from client environments, federated guest accounts become orphans that cross organizations: live access to a client’s systems held by someone who left the firm months ago. Federation moves the door; it doesn’t move the responsibility.

Leavers spread across many environments

A consultant leaving Northcape is a more complicated leaver than in a company with one tenant, because their access is spread across the firm’s systems and an unknown number of client tenants collected over their career. Straight away, the Northcape home identity is disabled, sessions are revoked and federated guest access is removed from every client tenant the identity reaches. Then the departure is reconciled against the PSA, checking the consultant’s engagement history to confirm no client environment was missed, because the engagement record is the map of where to look. The account is disabled and kept for the contractual and regulatory retention period before it’s deleted, because consulting work and audit obligations often outlive the consultant by years. And subcontractors lapse rather than resign, so a missing end date from the supplier is treated as an exception, just like the hospital’s contractors.

Reconciliation matters more here than anywhere else in the module. In a consultancy, the list of places someone has access is itself hard to know, and the PSA’s engagement history is the only reliable map of the federated footprint to take apart.

Contracts, audits and conflicts of interest

Northcape works under ISO/IEC 27001 and SOC 2 and, unusually, under the security clauses of its own client contracts, which often set stricter access requirements than any general framework. A client may require by contract that access be removed within hours of a consultant rolling off, that no consultant working for a competitor keeps access, and that the firm produce evidence of both on demand.

That adds something missing from the other two cases: access hygiene becomes a conflict-of-interest control, not just a security one. The same mover discipline that prevents privilege creep also keeps client A’s data out of reach of a consultant now embedded at client A’s competitor. In consulting, removing access isn’t only about shrinking the attack surface; it’s about keeping the wall between clients that the firm’s reputation depends on. The evidence a consultancy has to produce is the same JML evidence everyone needs, provisioning tied to assignments, prompt removal and periodic reviews, but the bar is set by client contracts, which are stricter and less forgiving than a generic framework. Build the loop to the strictest client’s standard and every audit becomes easy; build it to the framework minimum and you’ll renegotiate it client by client forever.

The bench is a state, not a gap

The control that most clearly marks a mature consultancy is treating the bench, consultants between engagements, as a proper lifecycle state rather than “still on the last project until the next one starts”. When a consultant rolls off and isn’t staffed again straight away, the right behavior is a mover into a reduced state: internal systems only, every client guest account removed, billable-project entitlements taken away.

Practitioners insist on it because the alternative is the quiet build-up the JML article warns about, in its most contractually dangerous form. A consultant who spends six weeks on the bench while keeping live access to three former clients’ tenants is a walking conflict of interest, and the longer the bench, the staler and harder to defend that access becomes. Tying the access state to the PSA’s assignment status, so that “unassigned” automatically means “internal only”, removes both the judgment call and the delay. The bench is also where periodic certification is easiest: a consultant with no current engagement should have no client access, which is the simplest access review there is to decide and the most embarrassing one to fail.

Subcontractors and offshore delivery

Northcape doesn’t deliver every engagement with its own employees. Subcontractors and offshore delivery centers extend the workforce, and the identity perimeter, well beyond the firm, and that’s where the lifecycle is hardest to enforce.

Subcontractors lapse rather than resign, like the hospital’s contractors, so their identities need a firm end date from supplier management and the PSA, and a missing or extended date is an exception. Offshore delivery adds two more things practitioners handle explicitly. One is the device: access from an offshore center’s managed workstations is treated differently from access through an unmanaged personal laptop. Conditional access policies gate sensitive client environments on device compliance and location, so identity isn’t the only signal and the context of the request counts too, an early taste of the risk-based authentication covered in access management. The other is data residency: some client contracts require that their data never leave a country, which limits which delivery center can be staffed on the engagement at all. The access decision then depends on where the person physically sits, a constraint the PSA has to carry along with the assignment.

A consultancy’s identity perimeter is porous by design, and its controls have to reach people the firm doesn’t employ, on devices it doesn’t own, in countries where the data isn’t allowed to travel.

What mature consultancies run

Mature consultancies end up with a recognizable stack built around time-limited access packages that are requested and approved rather than standing grants. Entitlement management with expiry, such as access packages in Microsoft Entra Entitlement Management, bundles the access an engagement needs and assigns it with an expiry tied to the project end date, so removal at roll-off happens automatically rather than when someone remembers. Governed external collaboration, Microsoft Entra External ID and B2B on the client side with the home firm driving the guests’ lifecycle, means the federated access shown in the rotation diagram is created and removed under control rather than left to each client. Recurring access reviews, through Entra Access Reviews or a full IGA suite such as SailPoint or Saviynt, have engagement leads confirm who still needs client access, catching anything automated roll-off missed. And conflict-of-interest rules in the same IGA tools model ethical walls: rules that stop a consultant on client A from being granted access to a direct competitor’s environment, the access-control expression of the confidentiality the firm owes by contract.

Those map neatly onto ISO/IEC 27001 Annex A, identity management, access provisioning and review, and access for external parties, which is why a consultancy running this stack tends to get through both its certification audit and its clients’ security assessments. The idea practitioners keep coming back to is expiry over revocation. In an organization where people move all the time, access that defaults to ending on a known date is far safer than access someone has to remember to remove. The industry’s tools have converged on that principle precisely because the mover never stops.

David’s quarter

Follow David, a senior cloud engineer, through three months to see it work. In January he’s staffed on client A, a bank, with a federated guest identity in the bank’s tenant and an entitlement package that expires on the engagement’s planned end date. He works inside the bank’s cloud every day, signing in with his Northcape identity.

In mid-February the engagement finishes early. The PSA records the roll-off, and three things happen automatically: the entitlement package for client A expires, his guest access in the bank’s tenant is removed and his status changes to bench, internal access only and no client environments. He isn’t carrying live access to a bank he no longer serves, and the audit trail shows the exact moment each access ended. This is the version of events in which the bank never has to call.

Two weeks later he’s staffed on client B, a retailer. The new assignment in the PSA triggers a fresh entitlement package, federated access to the retailer’s tenant, scoped to his role and expiring on the new project’s end date. Nobody ever had to file a ticket to remove his bank access; it expired by design when the engagement did. That one property, access that defaults to ending, is what lets Northcape rotate hundreds of Davids every quarter without drowning in standing grants or confidentiality breaches. The contrast with the startup’s struggle is telling: where Rebate fights to remember to remove access, Northcape engineers the removal to happen by itself.

What Sara measures

Northcape’s metrics lean towards the removal side, because that’s where both the contractual risk and the conflict-of-interest exposure live. Sara watches how quickly client access disappears after a roll-off, which should be within the hours the contract specifies, not days; how many guest accounts sit in client tenants with no current engagement behind them, which should be close to zero; what share of access ends by expiry rather than by someone acting, which should be the overwhelming majority; whether consultants on the bench hold any client access at all, which should be none; and whether engagement leads complete their access reviews on the cadence the contracts require.

The count of orphaned guest accounts is the one unique to this sector and the one practitioners watch hardest. A guest identity in a client’s tenant with no matching current engagement is the cross-organization orphan that federation makes possible, the bank’s guest account from the start of this article, and it stays invisible unless you reconcile into each client’s directory, not just your own. The time to remove access at roll-off is where the audit and the contract meet: a client’s security clause may set a hard number, and Northcape has to prove it met that number for every consultant who ever rolled off that client. When access expires by design at the end of a project, both numbers look after themselves; when removal is manual, both slowly get worse with every rotation, which across hundreds of consultants guarantees a breach sooner or later.

When a consultant joins the client

A case peculiar to consultancies is rebadging: a consultant is hired by the very client they were serving, or a managed-services transition moves a whole team from Northcape’s payroll to the client’s. It’s a leaver from Northcape and a joiner at the client at the same time, and the dangerous moment is the seam between the two.

Done well, the consultant’s Northcape identity is offboarded, including the guest access into the client, while the client gives them a native identity in parallel, so access continues but its basis changes hands cleanly. Done badly, the guest account lingers next to the new native account, and the person has two ways into the client’s systems, one of which Northcape still nominally owns but has no reason to keep. That leftover guest is a textbook cross-organization loose end.

The good practice is to treat rebadging as one coordinated double event with an explicit cutover, not as two unrelated transactions that happen to involve the same person. Northcape’s leaver flow has to run to completion, guest access removed everywhere, precisely because the person remains reachable in the client’s world through a different door. It echoes the hospital’s rule for doctors who work in both wings: when one person’s relationships change hands, govern each relationship’s access on its own terms rather than assuming that continuity of the person means continuity of access.

What the consultancy teaches

Northcape’s lessons apply to any project-based or matrix organization where people move faster than the org chart. Access follows the engagement, so drive it from the current assignment, not the title. When HR can’t answer “on what?”, add a second authoritative source that can. Every rotation removes and grants, so make both halves of the mover automatic. You own offboarding from other people’s systems, because federation moves the door, not the responsibility. And engagement history is the map for removing access, because you can’t remove what you can’t list.

The deepest lesson closes the whole module. Across a regulated hospital, a chaotic startup and a consultancy driven by rotation, the same truth holds: the value and the risk both live on the removal side of the lifecycle. Granting access is easy and popular everywhere. What separates a real IAM program, in every sector, is how reliably it takes access away when the relationship, the role or the engagement that justified it comes to an end. The bank’s guest account wasn’t a technology failure; it was a removal nobody owned.

Three questions to test yourself

1. A consultant rolls from client A onto client B, a direct competitor. List exactly what has to be removed and what has to be granted, and explain why the removal is a contractual obligation here and not just good hygiene.
2. A consultant leaves Northcape. How do you make sure every federated guest account in all their past clients’ tenants is removed, and which authoritative record tells you where to look?
3. Northcape’s HR system says a consultant is a “Senior Developer”, but that title says nothing about what they can reach today. Which second authoritative source settles this, and what specific attribute does it provide that HR can’t?