The challenge behind the engagement.
Identity Federation & Multi-Identity Solutions is for organizations with more than one identity boundary that must work together without merging. Typical cases: an acquired company with its own directory and sign-in system, partners who need shared applications, or a regulated environment kept separate from a commercial one. We map every trust relationship: federations between sign-in systems, directory trusts, cross-tenant access settings, guest collaboration, cross-environment synchronization, and automated provisioning. We then work a structured decision with you: keep separate with guest access, synchronize directories, form a shared organization, or consolidate by migrating one environment into another. You receive a trust map, per-relationship designs, a cross-boundary access policy set, and day-one and cutover runbooks. Federation design does not by itself make a system meet a compliance framework.
For IT and identity leads after an acquisition, before a joint venture or partner onboarding, or when regulated work adds a separate environment beside a commercial one. The trigger is users, mailboxes, and collaboration that need to work across the boundary.
What we do.
What you can use.
Map every trust relationship
With read-only access in each environment, we export cross-tenant settings, directory trusts, federation details, guest accounts, and synchronization jobs. We pull sign-in logs early, because some platforms keep cross-environment activity for only about a month. The trust map shows who trusts whom, for what, and on which claims.
Decide merge, sync, or coexist
We run the decision with your stakeholders per relationship: guest collaboration for shared applications, synchronization for directories in the same cloud, a shared organization for chat and collaboration, or a full migration into one environment. Environments in different clouds get a mesh design, since some collaboration features do not cross clouds.
Design, cut over, and decommission
Each relationship gets a design: protocol, signing keys and rotation, the values that identify the sender and audience, which attributes are shared, provisioning mappings, and the assurance level required. Day-one and cutover runbooks cover mail routing, calendar sharing, collaboration federation, and guest lifecycle. Retired trusts get a decommission plan.
Who it’s for.
When you need it.
- Organizations operating more than one identity boundary that must interoperate without merging
- Companies integrating an acquired business that keeps its own directory and tenant
- Regulated or defense contractors keeping a sovereign tenant separate from a commercial one
- IT teams onboarding partners who need access to shared applications and data
- An acquisition closed and users on both sides need each other's applications
- A joint venture or partner program requires federated access on a deadline
- Regulated work adds a sovereign cloud tenant beside the existing commercial one
- Aging federation services and stale cross-directory trusts are overdue for retirement
What the scope can include.
- 01
Trust inventory of federations, directory trusts, cross-tenant settings, and guest relationships
- 02
Review of inbound and outbound trust for sign-in strength and device claims per partner
- 03
Consolidate, synchronize, or coexist decision for each acquired environment and directory
- 04
Cross-cloud topology for regulated and commercial environments that must stay separate
- 05
Provisioning design covering account schema, synchronization scopes, and attribute mappings
- 06
Guest lifecycle through access requests and periodic reviews for partner users
What it typically costs.
One rate: $150/hour.
Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and the final deliverables included. Find the size closest to yours.
One partner or acquired company that needs access to shared apps
About 32–60 hoursAn acquisition with its own directory and sign-in system, a merge-or-coexist decision
About 80–140 hoursSeveral tenants or a regulated environment kept apart from the commercial one
About 160–260 hours- Number of identity boundaries and trusts to map
- Whether the decision is merge, sync, or keep separate
- Number of users and shared applications crossing the boundary
- Regulatory separation requirements between environments
2–3 weeks for a single trust; 6–10 weeks for multiple tenants or a regulated split
Get a fixed quote for your scopeRanges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.
What you take forward.
- Trust map showing every environment, directory, partner, and cloud relationship with the claims each accepts
- Per-relationship federation design with protocol, signing key rotation, attribute release, and assurance target
- Cross-boundary access policy set and a consolidation or coexistence decision record with topology
- Day-one and cutover runbooks plus a decommission plan for retired federation and stale directory trusts
Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.
Before we get started.
We acquired a company with its own environment and directory. Should we merge, sync, or leave it?
It depends on what has to be shared and how soon. If people mostly need each other's applications, guest collaboration delivers that quickly and keeps each side's administrators separate. If the acquired company will operate as one business unit with shared mailboxes and chat, synchronization or a shared organization is the interim step and a full migration the end state. Mailboxes on legal hold, custom applications tied to the old sign-in system, and license alignment drive the timeline, so we record the decision and its reasons before any cutover date is set.
Can a partner's sign-in requirements satisfy our access policies?
Yes, if you decide to trust them. Cross-environment settings on many platforms let you accept a partner's strong sign-in and managed-device claims, one partner at a time, so their users are not prompted twice. For a federated partner, the proof of strong sign-in must be passed through for your policies to accept it. We review the partner's registered methods first, because trusting a partner that still allows weak factors lowers your floor to theirs. We then document which partners you accept and which get your own prompt.
- NIST SP 800-63-4: Digital Identity Guidelines
- NIST SP 800-207: Zero Trust Architecture
- Zero Trust Maturity Model | CISA
- OWASP Non-Human Identities Top 10
- Securing privileged access Enterprise access model - Privileged access | Microsoft Learn
- What is Microsoft Entra Agent ID? - Microsoft Entra Agent ID | Microsoft Learn
- RFC 9700: Best Current Practice for OAuth 2.0 Security