Multi-Org Strategy in Okta
When one Okta org is enough, when it is not, and how to connect, govern, and secure several orgs without creating a tangle that nobody can manage.
Granite Peak Holdings began as one company with 2,000 employees and one Okta org. Life was simple. One list of people, one set of policies, one place to look when something went wrong. Then the company grew the way many companies do: it bought a software firm in Germany, a logistics business in Texas, and a small healthcare startup. Each came with its own Okta org, its own administrators, its own habits, and its own opinions about how sign-in should work.
Suddenly the leadership team asked questions that sounded easy and were not. “Can a Texas manager approve access for a German employee?” “Can we show the auditor one list of every administrator?” “Why does the healthcare startup have a completely different MFA rule?” “If we merge them all into one org, will the German privacy team accept it?” The answers depended on a decision that most companies make by accident: how many Okta orgs to have, and how they should relate to each other.
That decision is called a multi-org strategy. It is one of the most important design choices in an Okta deployment, because it shapes security boundaries, administrative power, costs, and the experience of every user. It is also difficult to reverse. Merging two orgs, or splitting one apart, can take months of work.
This guide explains the topic from the ground up. We start with what an org really is and what is locked inside its walls. Then we look at good and bad reasons to use more than one, the building blocks that connect orgs together, the common patterns, and a framework for deciding. After that we cover governance, security, reliability, monitoring, migration, and the mistakes that cause the most pain. You do not need prior experience with multiple orgs, and every new term is explained as we go.
1Why One Org Is Sometimes Not Enough
Most companies should start with one org, and many should stay there. But a handful of real-world pressures push companies toward more. Understanding those pressures first helps you tell a real need from a passing preference.
The Default Is One
An Okta org is your private space inside Okta, with its own users, groups, apps, policies, administrators, logs, and web address. For most companies, one org is the right answer. One org means one place to define rules, one set of administrators to train, one log to search, and one bill to read. Every additional org multiplies the work: more policies to keep aligned, more administrators to secure, more integrations to repeat, and more places for things to drift apart.
Five Pressures That Change the Answer
Mergers and acquisitions
A bought company arrives with its own org and its own staff. You cannot merge them overnight, and you may need them to coexist for a year or more.
Legal and data location rules
Some laws or contracts require that identity data stays in a certain region, which can force a separate org in that region.
Different audiences
Employees, partners, and millions of customers have very different needs. Mixing them in one place can create risk and clutter.
Safe testing
You need a place to try changes that is not your live system. That alone justifies at least one extra org.
Independence of business units
Some units must run on their own rules, with their own administrators and their own risk appetite, even though they belong to the same group.
Two Common Failures
Companies go wrong in opposite directions. Some cling to one org long after it makes sense, stretching it with exceptions until it is a tangle of special cases that no one dares to touch. Others create new orgs too quickly, each time a team asks for independence, and end up with a dozen orgs that cannot be compared or controlled. A good strategy avoids both. It chooses the smallest number of orgs that meets the real boundaries, and connects them in a way that can be understood and governed.
Think of buildings on a campus. One large building is easy to look after: one front door, one reception desk, one fire plan. But if you run a hospital, a school, and a factory, you may need separate buildings because their rules, hazards, and visitors differ. Too many tiny buildings, though, and the campus becomes a maze of doors and keys. An org is a building, and strategy is campus planning.
Okta changes its features, names, and limits over time, and licensing differs between customers. This guide focuses on lasting ideas and patterns. Always confirm specific features, limits, and costs with Okta’s current documentation and your account team before committing to a design.
2Core Concepts: What an Org Really Is
To design several orgs, you must first know what a single org contains, and which of those things can never be shared directly across the wall.
The Walls of an Org
An org is a hard boundary. Inside, everything is connected: users belong to groups, groups are assigned to apps, policies apply to groups, and administrators manage all of it. Outside, nothing is shared by default. Another org cannot see your users, cannot use your groups, and cannot read your policies, unless you deliberately connect them.
Universal Directory
The org’s own list of users and their attributes. A person who exists in two orgs is two separate records that Okta does not automatically link.
Groups and group rules
Collections of users used to assign apps and policies. Groups are local to one org.
Applications and integrations
Each app connection belongs to one org, with its own certificates, secrets, and settings.
Policies and authenticators
Sign-in rules, factors, and enrollments are per org. A person enrolls factors separately in each org.
Administrators and roles
Admin powers are per org. Being a super administrator in one org says nothing about another.
System Log and settings
Each org has its own record of events, its own rate limits, its own custom domains, and its own branding.
The Org URL and the Cell
Each org has an address, such as a name followed by an Okta domain. Behind that address, the org lives in a particular cell, which is a regional group of Okta’s infrastructure. Okta runs cells in different parts of the world, and the choice of cell is generally made when the org is created. It determines where the org’s data is hosted, which matters a great deal for data location rules. Moving an org to a different cell is not something you can casually do later, so treat the choice as long-term.
The Word “Tenant”
People use the words tenant and org almost interchangeably. Both mean one customer’s isolated space on a shared platform. In this guide we use “org” to match Okta’s own language. The key idea is multi-tenancy: many customers share Okta’s platform, but each lives in its own sealed space. A multi-org strategy simply means that your company holds more than one of those sealed spaces.
What Crosses the Wall
Only a few things move between orgs, and only when you set them up on purpose.
- Sign-in proof. One org can trust another org to authenticate a user and tell it who signed in. This is called federation.
- Account records. One org can create or update accounts in another org through provisioning.
- Tokens and claims. A token issued in one place can carry facts to an app that trusts it.
- Events. Logs and events can be sent from each org to a shared tool.
- Configuration. You can apply the same settings to many orgs using automation, but each org still holds its own copy.
Each org is like a separate bank vault with its own door, its own key holders, and its own ledger. Two vaults can agree to honor each other’s signed letters, such as “this person was verified by us.” But the ledgers stay separate. If you want one ledger, you must copy the entries yourself.
Do not assume that two orgs from the same company share anything automatically. There is no built-in “company-wide” user list that spans orgs. Every link between orgs must be created, secured, and maintained.
3The Kinds of Orgs You May Own
Not all orgs are equal. Some are for real users, some are for experiments, and some belong to different Okta products. Knowing the types helps you plan the minimum set.
By Purpose
| Type | Typical purpose | Who uses it | Notes |
|---|---|---|---|
| Production org | The live system with real users and apps | All staff or customers | Most carefully controlled |
| Preview org | A close copy for testing before production | Administrators and developers | Uses a separate web domain for previews, and Okta can refresh it from production on request, depending on your agreement |
| Developer or trial org | Learning, quick experiments, proof of concept | Individual engineers | Not for real data; limits and lifetimes differ |
| Sandbox or integration org | Building and testing integrations and hooks | Application teams | Keep sample data only |
| Business unit or subsidiary org | Run a part of the company independently | That unit’s staff | Requires governance and linking |
| Customer-facing org | Sign-in for customers and partners | External users | Different scale, risk, and rules from workforce |
Workforce and Customer Products
Okta serves two broad audiences. Workforce identity is for employees, contractors, and partners reaching business apps. Customer identity is for the people who use your own products and websites, often in very large numbers, with a focus on sign-up flows, social login, and smooth experience. Okta offers customer identity through both its Okta platform capabilities and through Auth0, a separate product family that Okta owns, and it has its own tenants and its own concepts. When people say “multi-org” in a workforce context they mean several Okta orgs. When they say it in a customer identity context, the answer may involve different tools, so make sure you know which product family you are discussing.
The Minimum Sensible Set
A very small company can run with one production org and one developer org. A typical mid-size company has at least a production org and a preview org. A larger company often adds a sandbox for integrations, and, if its structure demands it, further production orgs for regions, subsidiaries, or customers. The question for strategy is not “how many environments,” which is a testing question with a nearly universal answer. The question is “how many production orgs,” because that is where the real complexity and risk live.
flowchart LR
DEV["Developer orgs: experiments"] --> SBX["Sandbox org: integration testing"]
SBX --> PRV["Preview org: pre-production checks"]
PRV --> PRD["Production org: real users"]
PRD -.->|"Refresh copy on request"| PRV
A restaurant has a test kitchen where chefs try new dishes, a rehearsal dinner for staff before opening a new menu, and the real dining room. Nobody serves untested food to paying guests. The test kitchen, the rehearsal, and the dining room are three orgs for one restaurant, and all three are normal.
Count production orgs and non-production orgs separately in every planning conversation. People often say “we have five orgs” when they mean one production org and four test ones, and the difference changes the whole discussion.
4How Far One Org Can Stretch
Before creating a second production org, ask a simple question: could the same goal be reached inside one org? Okta has many tools for dividing a single org into manageable parts.
Tools That Divide One Org
Delegated administration
Custom admin roles and resource sets can limit an administrator to certain groups and apps. A regional team can manage its own people without touching anyone else’s.
Brands and custom domains
Different business units can have their own logos, colors, sign-in pages, and web addresses inside one org.
Group-based policies
Policies can target groups, so different units can have different sign-in rules even though they share an org.
Profile attributes
Attributes such as company, region, and cost center let rules and reports separate units cleanly.
App assignments
Each app is assigned only to the groups that should see it, so a unit never sees another unit’s tiles.
Multiple sources
One org can import from several directories and HR systems at once, each feeding its own set of users.
What One Org Cannot Do
These tools divide administration and experience, but they do not divide fate. Everything in one org shares certain things.
- A single rate limit budget. One busy unit can use up the API allowance that others depend on.
- A single set of super administrators. Those with top-level power can change everything for every unit.
- A single hosting region. The data lives in one cell, so you cannot split a single org across two regions.
- A single set of global settings. Some settings, such as certain security defaults, apply across the org.
- A shared incident. A mistake in a global policy, or a compromised top-level admin, can affect all units at once.
| Need | Can one org handle it? | How |
|---|---|---|
| Different logos and sign-in pages for each unit | Yes | Brands with custom domains |
| Each unit manages its own people | Yes | Delegated admin roles and resource sets |
| Different MFA rules for each unit | Yes | Group-targeted policies |
| Separate legal ownership of data | Usually no | Separate orgs |
| Data kept in two different regions | No | One org per region |
| Independent super administrators | No | Separate orgs |
| Independent API rate limits | No | Separate orgs |
| Trial of a risky change | No, not safely | A preview or sandbox org |
An office floor can have separate rooms, separate name plates, and separate keys for each team. That is delegated administration inside one org. But all rooms share one roof, one electrical supply, and one master key held by the building manager. If you need a team to have its own roof and its own electricity, you need a separate building.
5Good Reasons to Run Multiple Orgs
These are the reasons that stand up under scrutiny. If your situation matches one of them, a multi-org design is likely justified.
Data location and legal separation
When law or contract requires identity data to stay in a given region, or to be controlled by a separate legal entity, a separate org in the right cell is the cleanest answer. An auditor can see a hard boundary rather than a set of settings.
Blast radius control
If the security of one unit is weaker than the rest, or the unit is exposed to higher risk, separating it ensures a breach there cannot hand an attacker the keys to the whole group.
Workforce versus customer separation
Employees and consumers have different risk profiles, scales, and compliance needs. Keeping them in separate systems prevents customer-side incidents or traffic spikes from touching employee access.
Acquisitions that cannot merge yet
A newly acquired company needs to keep working while you plan the merge. A temporary second org, connected to yours, is a safe landing zone.
Genuine administrative independence
Some units, such as a joint venture or a newly sold-off division, must hold their own top-level admin keys and cannot be subject to another company’s administrators.
Environment separation
Testing needs its own org. This is the one reason that applies to almost every company.
Capacity isolation
When one unit makes extremely heavy use of Okta’s APIs, a separate org gives it its own rate limit budget so that others are not slowed.
Production example: a group with a European subsidiary
A global manufacturer with a European subsidiary was contractually committed to keeping employee identity data within the European region. It kept its main org in a US cell and created a second production org for the subsidiary in a European cell, linked to the main org for shared apps. The legal team could show a clear boundary, and the identity team kept policies aligned using shared configuration templates.
Write the reason for each production org on a single line in your architecture document, such as “Org B exists because of regional data rules.” If you cannot write the line, you probably do not need the org.
6Weak Reasons That Lead to Regret
For every good reason, there is a weaker one that sounds persuasive in a meeting and causes years of work afterward. Learn to spot them.
The claim
“This team wants control, so give them their own org.”
The problem
Control over daily tasks can be delegated inside one org. A separate org gives them control over a whole identity system, including responsibilities for security that they may not be ready for.
A better answer
Use delegated admin roles and resource sets, and revisit only if a true legal or risk boundary appears.
The claim
“The acquired company’s org already exists, so let us leave it alone.”
The problem
“Temporary” arrangements often become permanent. The second org drifts further from your standards each year, and its administrators and policies are never reviewed by your team.
A better answer
Treat the acquired org as a landing zone with a planned end date, and plan consolidation from day one.
The claim
“Different brands need different looks.”
The problem
Brands, custom domains, and email templates give every unit its own look inside one org.
A better answer
Use brands and domains. Branding alone is not a reason for a separate org.
The claim
“We want to avoid a single point of failure.”
The problem
Splitting into several orgs does not remove dependency on Okta, and linking the orgs together can create new chains of dependency. Resilience is better handled through break-glass plans, careful change control, and Okta’s own availability.
A better answer
Plan for failure of the single org with emergency access and continuity procedures, and add separate orgs only when a genuine boundary requires it.
The claim
“It is easier than cleaning up our existing org.”
The problem
A fresh org starts tidy but picks up the same bad habits. Meanwhile, the old org still exists, so you now have two messes.
A better answer
Fix the habits and the structure first. A cleanup of groups, policies, and admins is almost always cheaper than running two orgs.
Moving to a second house because the first one is cluttered rarely solves the clutter. You carry the same boxes, and now you pay two mortgages. Tidy the first house, and move only when you truly need a different place.
7Architecture: The Building Blocks That Connect Orgs
Orgs are sealed rooms. To make them work together, Okta offers a small set of connectors. Understanding each one is the key to every multi-org design.
Block 1: Identity Provider Federation
An identity provider, or IdP, is a system that proves who a person is. In Okta, an org can be set up to trust another system, including another Okta org, as an external identity provider. When a user tries to sign in, the receiving org can send them to the other system to prove themselves, and then accept the signed answer. This is called inbound federation. The two languages commonly used are SAML and OpenID Connect. The receiving org is sometimes called the service provider in this relationship, because it provides access to apps, while the sending org is the identity provider.
Block 2: Routing Rules
If an org trusts several identity providers, it must decide which one to use for a given person. Okta provides identity provider routing rules, which look at facts such as the person’s email domain, group, or network, and send them to the correct source. A person with an address at one company’s domain can be routed to that company’s org, while another domain goes elsewhere. Good routing rules make the sign-in feel seamless. Bad ones send people in circles.
Block 3: Org-to-Org Integration
Okta provides a ready-made connector, commonly called Org2Org, designed to link two Okta orgs. It sets up single sign-on from one org into the other and can also provision accounts and push group membership across. Because both ends are Okta, the setup is smoother than linking with an arbitrary third-party system, and many companies use it as the foundation of hub-and-spoke designs. Check current documentation for the exact capabilities and supported protocols.
Block 4: Provisioning
Provisioning creates, updates, and removes accounts in another system automatically. In a multi-org design, one org can act as the source of truth and push accounts into the other orgs. A common industry standard for this is SCIM, short for System for Cross-domain Identity Management. Another approach is just-in-time provisioning, often shortened to JIT, in which an account is created the first time the user signs in through federation. JIT is simple but leaves less control over removal.
Block 5: Shared Services
Some things should not be repeated in every org. A central log collector, a ticketing system for approvals, a secrets vault, and a shared automation platform are shared services. Each org plugs into them, so that the group sees one picture even though identity data lives in several places.
| Block | What it moves | Direction | Main risk |
|---|---|---|---|
| IdP federation | Proof of sign-in | From source org to receiving org | Chain of trust: a weak source weakens the receiver |
| Routing rules | Decision of where to send a user | Inside the receiving org | Wrong rule loops or leaks users to the wrong source |
| Org2Org connector | Sign-in, accounts, and groups between Okta orgs | Usually one way, hub to spoke | Over-broad group pushes and admin rights |
| Provisioning and JIT | Account records | Source to target | Orphan accounts, attribute drift |
| Shared services | Logs, tickets, secrets, automation | Orgs to service | One service becomes a high-value target |
The Map
flowchart TB
subgraph SRC["Source of truth"]
HR["HR system"]
end
subgraph HUB["Hub org"]
HUD["Universal Directory"]
HPOL["Central policies"]
end
subgraph SPK["Spoke orgs"]
S1["Spoke org: Europe"]
S2["Spoke org: Subsidiary"]
end
subgraph SHR["Shared services"]
SIEM["Log collector"]
ITSM["Ticketing"]
VAULT["Secrets vault"]
end
HR --> HUD
HUD --> HPOL
HUB -->|"Federation and provisioning"| S1
HUB -->|"Federation and provisioning"| S2
HUB --> SIEM
S1 --> SIEM
S2 --> SIEM
HUB --> ITSM
HUB --> VAULT
Think of several countries, each with its own passport office. The countries sign treaties: “we accept your passports at our border” is federation, “send us a list of your citizens who work here” is provisioning, and a border guard’s rule book about which passports to accept is a routing rule. Shared services are like an international police database all countries report to.
8Internal Working: How a Cross-Org Sign-In Happens
Let us follow one person through a federated sign-in, step by step. It makes the abstract blocks concrete, and shows where problems can hide.
The Story
Jonas works in the German subsidiary. His identity lives in the hub org, which is the company’s central Okta org. The subsidiary has its own org, called the spoke, which holds the apps used locally. On Tuesday he opens the local time-tracking app, which is connected to the spoke.
The app asks the spoke
The time-tracking app does not know Jonas, so it redirects his browser to the spoke org to find out who he is.
The spoke checks its routing rules
The spoke sees the email domain on Jonas’s request and finds a rule that says people from this domain are managed by the hub. It sends his browser to the hub.
The hub authenticates Jonas
The hub applies its own policies. It checks his session, asks for a strong factor, and evaluates his device and network. Here the central rules do their work.
The hub sends a signed answer
The hub returns a signed message to the spoke: “this is Jonas, here are his attributes.” The message is signed so the spoke can verify it truly came from the hub.
The spoke matches the account
The spoke looks for a local account that matches the identifier in the message. If it exists, it is used. If it does not and JIT is allowed, the spoke may create it. If neither, the sign-in fails.
The spoke applies its own app policy
Even though the hub proved identity, the spoke can apply its own authentication policy for the app, such as device checks, depending on how the trust is configured.
The spoke issues a token to the app
The spoke creates the assertion or token for the app and redirects Jonas back. He is in. Both orgs record the events in their own logs.
sequenceDiagram
participant J as Jonas
participant A as Time-tracking app
participant S as Spoke org
participant H as Hub org
J->>A: Open app
A-->>J: Redirect to spoke
J->>S: Sign-in request
S->>S: Evaluate routing rules
S-->>J: Redirect to hub
J->>H: Authenticate at hub
H->>H: Apply hub policies and factors
H-->>J: Signed assertion for spoke
J->>S: Present assertion
S->>S: Verify signature and match account
S-->>J: Redirect with token for app
J->>A: Present token
A-->>J: Access granted
Why This Matters for Design
Notice three things. First, the user crosses two orgs, so two sets of logs and two sets of policies are involved. Second, the sign-in depends on both orgs being healthy at the same moment. Third, the trust between them is only as strong as the weakest link, so the hub’s authentication quality is inherited by the spoke. These facts shape the reliability, security, and monitoring chapters that follow.
Imagine entering a partner company’s building. The receptionist checks your name against a list of partner companies, calls your home company’s security desk to confirm it is really you, and receives a signed note back. Only then does she hand you a visitor badge that works in her building. The note proves who you are. The badge decides which doors open.
It is easy to forget that the receiving org still needs its own policy. If the spoke blindly accepts the hub’s answer for everything, a weakness in the hub, or a misconfigured rule, flows straight through. Apply meaningful policy at the point where access is granted as well.
9Data Flow and Lifecycle Across Orgs
Signing in is only one moment. Accounts are born, change, and end. In a multi-org setup, every one of those events must reach each org, or access becomes inconsistent.
The Joiner, Mover, Leaver Story, Across Orgs
Joiner
HR records a new hire. The central org creates the person, assigns groups, and, through provisioning, creates or links an account in each org where the person needs access. A new employee should see all their apps on day one, whichever org holds them.
Mover
The person moves from one unit to another. Their central profile changes. Groups update, and the move must also remove access in the old unit’s org and add access in the new one. This is where many multi-org designs leak: the add happens, but the remove does not.
Leaver
The person leaves. Deactivation in the central org must cascade to every connected org and every app inside them, and active sessions must end. A gap of days in any one org is a security hole.
The Flow of Data
flowchart LR
HR["HR system: master for people"] -->|"Create, update, terminate"| HUB["Hub org"]
HUB -->|"Provision account and push groups"| SPA["Spoke org A"]
HUB -->|"Provision account and push groups"| SPB["Spoke org B"]
SPA --> APPA["Apps in org A"]
SPB --> APPB["Apps in org B"]
SPA -.->|"Events and logs"| SIEM["Central log collector"]
SPB -.->|"Events and logs"| SIEM
HUB -.->|"Events and logs"| SIEM
Choosing Who Is the Master
For every attribute, one system must be the source of truth. If two orgs both edit a person’s department, they will fight each other, and the winner depends on timing. A clean rule is: people are mastered in one place, usually HR or the hub, and every other org receives, but never edits, those core attributes. Local attributes, such as a local badge number, can be mastered locally as long as they do not conflict.
Provisioning (planned accounts)
- Accounts exist before the first sign-in, so access is ready.
- Removal can be driven centrally and quickly.
- Group membership can be pushed to match.
- Easier to audit who should exist where.
Just-in-time (created on first sign-in)
- Simple to set up, with no connector needed.
- Account may never be removed when the person leaves.
- Attributes may go stale after creation.
- Harder to know who exists before they sign in.
Consider a hospital group with several hospitals. When a nurse is hired by the group, the central office issues a badge and tells each hospital’s security desk to add the nurse to their list. When the nurse transfers or leaves, the central office must tell every desk again. If one desk misses the message, the nurse’s badge keeps opening doors there long after it should stop.
Measure the time between “HR records a departure” and “account disabled in the last org.” Track it as a metric per org. The slowest org defines your real offboarding time.
10Identity Correlation: One Person, Many Accounts
The hardest everyday problem in a multi-org world is recognizing that two accounts in two places belong to the same human being.
The Correlation Problem
Priya works for the parent company, and for three months a year she supports a subsidiary. She has an account in the hub org and an account in the subsidiary’s org. Nothing in Okta automatically links them. If her email changes in one place and not the other, the link breaks. If she has two accounts with different spellings, the auditor sees two people. Any system that must treat her as one person, such as access reviews or security investigations, struggles.
The Global Identifier
The usual cure is a global identifier: a stable value, such as an employee number or an internal person ID, assigned once and stored as an attribute in every org. It never changes, even if names, emails, or departments do. All matching, provisioning, and reporting use this value instead of an email address.
| Candidate | Stable? | Unique across orgs? | Comment |
|---|---|---|---|
| Email address | No, changes with names and mergers | Mostly | Convenient but fragile |
| Username | No | Per org only | Often just the email again |
| Okta user ID | Yes, within one org | No, different in each org | Cannot be used to match across orgs |
| Employee number from HR | Yes | Yes, if HR is a single system | Good choice for staff; contractors may need their own scheme |
| Assigned global ID | Yes | Yes by design | Best when several HR systems exist, as after an acquisition |
Account Linking Strategies
Link by global ID
Federation and provisioning match on the global ID. Changes in email or name do not break the link.
Link by verified email at first contact
Acceptable for a one-time setup, as long as the email is verified and the global ID is then stored for the future.
Manual linking for exceptions
A small, audited process for odd cases such as a person with two employment records.
Reconcile regularly
A scheduled report lists accounts in each org with no global ID, or with an ID that appears twice.
Factors and Devices Are Per Org
Another surprise: a person’s enrolled factors, such as a phone app or a security key, belong to the org where they enrolled. If Priya has accounts in two orgs that each authenticate her directly, she must enroll in each. Okta Verify on a phone can hold accounts for several orgs, but each is a separate enrollment. In a hub-and-spoke design, where the spoke trusts the hub for proof, she enrolls only in the hub. This is a major usability benefit of federation.
A person who joins two clubs gets two membership cards with two numbers. If the clubs ever need to know it is the same person, they need something both can check, like a national ID number. A global identifier is the national ID of your identity world.
What it looks like
After a company merger, accounts are matched by email. A year later, the company changes its email domain. All matches break, and hundreds of people get duplicate accounts in the other org.
Why it hurts
Duplicates split permissions, histories, and audit trails. Cleaning them up manually takes weeks.
Better approach
Assign a global ID from the start, store it in every org, and use it for all matching.
11Pattern 1: The Environment Ladder
The most common multi-org design is not about business structure at all. It is about safety. A ladder of environments lets changes be tested before they reach real users.
The Rungs
A typical ladder has three to four rungs. Developers play in their own small orgs. An integration or sandbox org is where application teams test hooks and apps. A preview org is a near copy of production, used for final rehearsal. Production is the live system. Changes climb the ladder one rung at a time and never skip a rung.
| Rung | Data | Purpose | Who may change |
|---|---|---|---|
| Developer | Fake only | Learning and quick experiments | Individual engineers |
| Sandbox | Fake or masked | Integration and hook testing | Application teams |
| Preview | Copy of production configuration, test users | Pre-production verification | Identity team with review |
| Production | Real | Live service | Identity team via approved change only |
Promotion, Not Copying
The danger in a ladder is drift. Each rung is a separate org, so settings made by hand in one place do not appear in the next. Over time, preview no longer matches production, and a test that passes in preview proves nothing. The remedy is promotion: describing the configuration in files, using tools such as Terraform with Okta’s provider, and applying the same files to each rung. The code is the single record of how the org should look. A reviewer can compare changes before they are applied.
flowchart LR
CODE["Configuration in version control"] --> D["Apply to sandbox"]
D --> T1{"Tests pass?"}
T1 -->|"No"| FIX["Fix and retry"]
FIX --> CODE
T1 -->|"Yes"| P["Apply to preview"]
P --> T2{"Checks and review pass?"}
T2 -->|"No"| FIX
T2 -->|"Yes"| PR["Approve and apply to production"]
PR --> M["Monitor and log"]
What Cannot Be Promoted Easily
- Real users and factors. Test orgs hold fake users. Factor enrollments cannot be copied.
- Secrets and certificates. Each org has its own app secrets and signing keys. Never copy production secrets down to lower rungs.
- Org-specific identifiers. App IDs, group IDs, and policy IDs differ between orgs, so configuration must refer to things by name or by a mapping.
- Some newer features. Not everything is covered by automation, so a small manual checklist may remain.
An airline does not train pilots on passenger flights. It uses a flight simulator first, then supervised training flights, then real passengers. Each step uses the same checklist. An environment ladder is the simulator-to-cockpit path for identity changes.
Never use real employee data or real secrets in lower rungs “to make tests realistic.” Test orgs are usually less protected, and a breach there should never expose real people.
12Pattern 2: Hub and Spoke
When a group has several production orgs, a hub-and-spoke design brings order. One org is the center, and the others connect to it like spokes on a wheel.
The Shape
The hub holds the master list of people and the strongest authentication rules. Each spoke is a separate org, perhaps for a region, subsidiary, or business unit, that trusts the hub to prove who people are. People enroll factors only in the hub. Spokes hold local apps, local administrators, and any local rules that must differ.
flowchart TD
HR["HR system"] --> HUB["Hub org: people, factors, core policies"]
HUB --> SA["Spoke: Europe org"]
HUB --> SB["Spoke: Subsidiary org"]
HUB --> SC["Spoke: Healthcare org"]
SA --> AA["Local apps"]
SB --> AB["Local apps"]
SC --> AC["Local apps"]
HUB --> HAPP["Group-wide apps"]
Why It Works
One place for people and proof
Users enroll factors once. Leavers are disabled once at the center.
Consistent baseline
The hub’s strong sign-in rules set a floor for every spoke.
Local freedom where it counts
Spokes keep local apps and local admins, within limits.
A path to consolidation
Because identities are already central, merging a spoke into the hub later is easier.
Where It Gets Hard
- The hub is critical. If the hub has trouble, every spoke sign-in that depends on it has trouble. It needs the strongest protection and the most careful change control.
- Admin rights across the wall. It is tempting to let hub administrators manage spokes. Do this only with explicit, narrow roles, because it joins their fates.
- Group pushes. Pushing group membership to spokes is powerful, and also a way to accidentally give someone access in many places at once.
- Local exceptions grow. Spokes ask for special rules. Without a clear baseline, each spoke slowly drifts.
- Latency of change. A change in the hub takes time to reach all spokes. Plan for the delay.
Good fit when
- One central team sets identity standards for the group.
- People move between units or work across them.
- There is a single authoritative HR source.
- You want a clear path to merge orgs later.
Poor fit when
- Units are legally or politically separate and distrust each other.
- No one can own the hub with proper resources.
- Spokes need full independence of administrators.
- The hub’s region conflicts with data rules of the spokes.
An airline alliance has one shared loyalty program at the center and many member airlines around it. Passengers carry one membership number and earn points anywhere, while each airline runs its own planes, crews, and local rules. The alliance’s central system is the hub, and each airline is a spoke.
Production example: a retail group with regional brands
A retail group with a dozen regional brands uses one hub org for all staff identities and strong sign-in rules. Each region has a spoke org for local store systems, with a regional IT team trusted to manage local apps. Central security sees one sign-in log for authentication and one list of all staff, and regions keep control over what they run locally.
13Pattern 3: Separating Workforce and Customer Identity
Employees and customers both need to sign in, but they are very different crowds. Many companies discover that mixing them in one system causes trouble, and separate them on purpose.
Two Different Worlds
| Aspect | Workforce identity | Customer identity |
|---|---|---|
| Who | Employees, contractors, partners | Shoppers, subscribers, app users |
| Scale | Thousands to hundreds of thousands | Thousands to hundreds of millions |
| Account creation | HR-driven, controlled | Self-service sign-up, social login |
| Main concern | Security, least privilege, compliance | Smooth experience, conversion, fraud control |
| Traffic shape | Predictable work-hour peaks | Spikes from sales, launches, and attacks |
| Admin population | Small IT and security team | Developers and product teams |
| Typical tools | Single sign-on, MFA, lifecycle management | Sign-up flows, progressive profiling, consent |
Why Separate Them
Different threat models
Customer systems face credential stuffing, fake sign-ups, and bots at huge volume. Workforce systems face targeted phishing. Mixing them lets one world’s attacks disturb the other.
Load isolation
A product launch should never slow employees’ access to payroll. Separate orgs have separate capacity budgets.
Different administrators
Product developers need to change customer sign-up flows often. You do not want them anywhere near employee security policy.
Different rules
Consumer privacy law, consent records, and data deletion requests apply to customers in ways that differ from employee records.
Which Product for Which Side
For workforce needs, Okta’s workforce identity org is the usual choice. For customer needs, Okta offers customer identity capabilities, including through Auth0, which is designed for high-scale consumer and business-customer sign-in. The two have different tenants, different consoles, and different concepts. If your company uses both, you effectively have a multi-tenant estate of two product families, and your strategy must cover both. Check with Okta about current product naming, packaging, and licensing, since this area has evolved.
flowchart LR
EMP["Employees and contractors"] --> WF["Workforce org: SSO, MFA, lifecycle"]
WF --> BA["Business apps"]
CUS["Customers and partners"] --> CI["Customer identity tenant: sign-up, social login, consent"]
CI --> PA["Product apps and websites"]
WF -.->|"Staff access to admin of product"| CI
The Shared Boundary: Staff Who Support Customers
Staff who support customers need access to the customer system, for example to reset a customer’s account. Handle this with care. The staff sign in through the workforce org, with strong factors and device checks, and are authorized to the customer tenant through narrow roles. Never create customer-tenant admin accounts with passwords stored in a shared sheet.
A bank has a staff entrance with badge scanners and a public entrance with a welcoming lobby. Staff badges never work as customer cards, and the public lobby never opens the back office. A bank teller can serve customers at the counter, but she enters through her own door with her own badge.
If you provide software to other businesses, be careful with the idea of one org per customer. For software makers, a single customer identity tenant that models each business customer as a sub-unit is usually easier to run than thousands of separate tenants. Review current guidance for your product choice.
14Pattern 4: Regional Orgs and Data Residency
When laws or contracts say where identity data must live, geography becomes a design input. Okta’s cells let you put an org in the right region, and a multi-org design lets one group respect several sets of rules.
What Data Residency Means
Data residency is the requirement that certain data be stored, and sometimes processed, within a particular country or region. Identity data, such as names, emails, and sign-in records, is personal data in most laws. Regulations like the European Union’s data protection law, as well as some national and industry rules, can limit where it may be kept or sent. Some customers, especially in government and finance, add such conditions in contracts.
Cells and Their Role
Okta hosts orgs in regional cells, such as separate cells for the United States and Europe, and others as the company has expanded. An org’s cell is normally chosen at creation. If your data must live in Europe, you create the org in a European cell. If another unit needs data in the US, it gets a US-cell org. Features available and certifications held can differ by cell, so check carefully for each one you plan to use. There are also specialized offerings for government customers with their own compliance programs.
flowchart TB
subgraph US["United States cell"]
U1["Global hub org: US-based staff"]
end
subgraph EU["European cell"]
E1["Europe org: EU staff identity data"]
end
subgraph AP["Asia-Pacific region"]
A1["APAC org if required by local rules"]
end
U1 -->|"Limited attributes only"| E1
U1 -->|"Limited attributes only"| A1
E1 -.->|"Aggregated, non-personal metrics"| U1
The Design Questions
What exactly must stay local?
Ask legal teams for the real rule. Sometimes only certain attributes, or only logs, must stay. Separate orgs are heavy tools, so use them only when the requirement truly demands it.
Who is authoritative for each person?
A European employee should be mastered in the European org. The global hub may receive only the facts it needs, such as an ID and a name.
What crosses the border?
Federation messages carry attributes. Minimize them. Provisioning copies records. Pushing a full profile to another region may break the very rule that created the separate org.
Where do logs go?
System Logs contain personal data like names and IP addresses. If your log collector sits in a different region, you may be moving personal data anyway. Choose the collector location with the same care.
Who can administer?
Administrators viewing data from another region can themselves be a transfer. Define who may administer which org, and consider local administrators for sensitive orgs.
A multinational keeps each country’s customer files in a locked cabinet inside that country’s office. Head office may receive summary reports, but not the files. If head office staff were allowed to freely copy any file home, the locked cabinets would mean nothing. Data residency design is the policy about which papers may leave the cabinet.
Okta cannot give you legal advice. Treat this chapter as engineering guidance, and involve your legal and privacy teams to define what the rules truly require before you design around them.
15Pattern 5: The M&A Landing Zone
Acquisitions are the most common reason a company wakes up with a second Okta org. A landing zone pattern gives that second org a safe place to land and a plan for leaving.
The Situation
On the day a deal closes, the acquired company has its own org, its own apps, and its own staff. The business wants synergies, such as shared email and shared tools, within months. The identity team usually has less time than it needs. Rushing a merge can break the acquired company’s operations. Doing nothing leaves an unmanaged island in your security picture.
Three Stages
Stage 1: Contain and see (days 1 to 30)
Take inventory of the acquired org: administrators, apps, policies, integrations, and users. Secure the top administrators with strong factors. Stream logs to your central tool. Do not change how staff sign in yet.
Stage 2: Connect (months 2 to 6)
Link the acquired org to your hub by federation. Give staff access to group-wide apps through the hub, and give your staff access to the acquired company’s apps if needed. Align core policies, such as stronger MFA for administrators.
Stage 3: Consolidate or keep (months 6 to 18)
Decide, based on the decision framework, whether to merge the acquired org into the hub or to keep it as a permanent spoke. If merging, plan the migration carefully and move in waves.
flowchart LR
D["Deal closes"] --> S1["Stage 1: inventory, secure admins, stream logs"]
S1 --> S2["Stage 2: federate with hub and align core policies"]
S2 --> Q{"Is a separate org still justified?"}
Q -->|"No"| S3A["Stage 3: migrate users and apps into hub"]
Q -->|"Yes"| S3B["Stage 3: keep as governed spoke"]
S3A --> E["Retire old org"]
S3B --> G["Apply governance and baseline reviews"]
The First 30 Days Checklist
- List all administrators in the acquired org, and remove any no longer needed. Require strong factors for those who remain.
- Find all API tokens and secrets, and note owners.
- List all apps and their connection methods, certificates, and expiry dates.
- Stream logs to your central tool and set alerts for admin changes.
- Identify break-glass accounts and make sure they exist and work.
- Document custom hooks and automations and their owners.
- Agree communication with the acquired staff so they know what is changing, and what is not.
When a new family moves into a house, you do not immediately knock down walls. First you check the locks, find where the fuse box is, and learn which switch controls which light. Only after you understand the house do you decide what to renovate and what to keep.
Production example: a software firm absorbing a startup
A software company acquired a small startup that had run its own Okta org for two years. In the first month, the security team found five super administrators, three of whom had left, and an API token created by a former contractor. They cleaned these up, federated the startup into the main org, and within eight months had migrated its users and apps. The startup’s org was retired once the last app moved.
16Pattern 6: Federated Autonomy, and the Mesh to Avoid
Some groups really are loose federations of independent companies. In that case, a strict hub may not be possible, but a tangle of cross-links is not the answer either.
Federated Autonomy
In a federated autonomy model, each unit runs its own org and its own policies, but all units agree on a small shared baseline: minimum MFA strength, administrator protection rules, log streaming to a shared collector, and a naming standard. A small central team holds the baseline and checks compliance but does not run the orgs. This model suits conglomerates and joint ventures where units are truly independent in business and in legal terms.
Minimum controls
All orgs must meet a written baseline, such as phishing-resistant factors for administrators and no shared admin accounts.
Central visibility
All orgs stream logs to the same place so the group can see across units.
Local operations
Each unit chooses its apps, its HR source, and day-to-day rules within the baseline.
Periodic assurance
The central team reviews each org against the baseline on a schedule, and units fix gaps.
The Mesh Anti-Pattern
A mesh is what you get when every org trusts every other org directly. With four orgs there are twelve one-way trust links. With ten orgs there are ninety. Each link has its own certificates, routing rules, and attribute mappings, and every one of them is a path an attacker could follow. Nobody can draw the full picture, and a change in one place has surprising effects elsewhere.
flowchart LR
subgraph MESH["Mesh: every org trusts every org"]
direction TB
M1["Org 1"] M2["Org 2"]
M1 M3["Org 3"]
M1 M4["Org 4"]
M2 M3
M2 M4
M3 M4
end
subgraph HUBS["Hub and spoke: each org trusts the hub"]
direction TB
H["Hub"] --> N1["Org 1"]
H --> N2["Org 2"]
H --> N3["Org 3"]
H --> N4["Org 4"]
end
| Number of orgs | Mesh trust links (one way) | Hub and spoke links (one way) |
|---|---|---|
| 3 | 6 | 2 |
| 5 | 20 | 4 |
| 8 | 56 | 7 |
| 12 | 132 | 11 |
The numbers show why. A mesh needs n times n minus one links for n orgs, while a hub needs only n minus one. Even if you do not use the hub for everyday sign-in, a hub-shaped trust structure is much easier to reason about.
What it looks like
Each time a team needs access to another unit’s app, someone adds a direct trust link between their orgs. After two years, there are dozens of links, no diagram, and no owner.
Why it hurts
An attacker who compromises one org can walk along trust links. Offboarding and certificate rotation become guesswork.
Better approach
Route cross-org access through a hub or a shared broker, and require every new link to be recorded in a register with an owner and a review date.
A mesh is like a town where every house has a key to every other house. At first it feels friendly. After a while, nobody knows who can enter where, and one lost key puts everybody at risk. A hub is like a neighborhood office where visitors check in once, and the office phones the right house.
17A Decision Framework: How Many Orgs, and Why
By now you have seen the building blocks and the patterns. This chapter turns them into a method for choosing.
Start With Constraints, Not Preferences
The best question is “what rules are we forced to follow?” Hard constraints, such as laws, contracts, and legal ownership, come first. Soft preferences, such as team autonomy and branding, come later and can often be met inside one org. Walk through the following questions in order.
flowchart TD
Q1{"Does law or contract require data in separate regions or entities?"} -->|"Yes"| A1["Separate org per region or entity"]
Q1 -->|"No"| Q2{"Are customers and employees both in scope?"}
Q2 -->|"Yes"| A2["Separate workforce and customer tenants"]
Q2 -->|"No"| Q3{"Must a unit hold fully independent top-level admin keys?"}
Q3 -->|"Yes"| A3["Separate org for that unit with baseline"]
Q3 -->|"No"| Q4{"Is a separate rate limit budget essential?"}
Q4 -->|"Yes"| A4["Consider separate org for heavy unit"]
Q4 -->|"No"| A5["Use one production org with delegated admin and brands"]
A1 --> T["Always add preview and sandbox orgs"]
A2 --> T
A3 --> T
A4 --> T
A5 --> T
A Scoring Table
For harder cases, a simple scoring table helps teams discuss trade-offs openly. Score each factor from 0 (no pressure) to 3 (strong pressure) for a possible split.
| Factor | Question | Score 0 to 3 |
|---|---|---|
| Legal separation | Is the unit a separate legal entity with its own obligations? | 3 if yes |
| Data location | Must its data stay in a different region? | 3 if yes |
| Risk profile | Is its risk much higher or lower than the rest? | 0 to 3 |
| Administrative independence | Must it hold independent top-level control? | 0 to 3 |
| Scale and capacity | Does it have very different traffic or API needs? | 0 to 3 |
| Operational maturity | Does it have staff able to run an org safely? | 3 if no, count against splitting |
| Shared users | How many people need access in both places? | High overlap argues against splitting |
| Expected lifetime | Is the unit permanent or temporary? | Temporary favors a landing zone with an end date |
Add the scores for splitting factors and subtract those against. A result near zero means “stay together.” A strong positive result, especially if legal separation or data location is at 3, supports a split. The point is not mathematics. It is forcing a team to name reasons and compare them.
Write It Down as a Decision Record
Decision
Create a separate production org in the European cell for European subsidiary staff, linked to the global hub for shared apps.
Reasons
Contract requires staff identity data to remain in Europe. The subsidiary has its own IT team. Overlap with global staff is under five percent.
Consequences
Additional administrators to secure, a second set of policies to keep aligned, duplicated integrations for shared apps, and a monthly drift review. Review this decision again in two years.
Choosing the number of orgs is like choosing the number of bank accounts. A person with one account has simplicity. Adding a savings account has a clear purpose. Opening a separate account for every purchase turns life into a spreadsheet. You add an account when there is a reason you can state in one sentence, and you write it down.
18Governance: Who Owns What Across Orgs
Technology connects orgs. Governance keeps them from drifting apart. The more orgs you have, the more important clear ownership becomes.
The Operating Model
Choose how decisions are made across orgs. There are three common models.
Centralized
One identity team runs all orgs, sets all policies, and does all administration. Strong consistency, but the central team can become a bottleneck.
Federated
Each unit runs its own org within a shared baseline set by a central group. Balance of speed and control, but needs good coordination.
Decentralized
Units run independently with little shared control. Fast locally, but weak group-wide assurance and costly to fix later.
Roles and Responsibilities
| Activity | Central identity team | Org owner | Security team | App owner |
|---|---|---|---|---|
| Set group-wide baseline | Responsible | Consulted | Approves | Informed |
| Run day-to-day operations of an org | Supports | Responsible | Informed | Consulted |
| Approve new cross-org trust link | Responsible | Consulted | Approves | Informed |
| Assign super administrators | Approves | Responsible | Approves | Informed |
| Review configuration drift | Responsible | Fixes gaps | Reviews | Informed |
| Manage an application integration | Consulted | Consulted | Informed | Responsible |
| Respond to an identity incident | Supports | Supports | Leads | Informed |
Core Governance Artifacts
- Org register. A list of every org with its purpose, cell, owner, backup owner, contract details, and linked orgs.
- Trust link register. Every federation or provisioning link, with its owner, purpose, certificate expiry, and review date.
- Administrator register. All super administrators across all orgs in one place.
- Baseline document. The minimum standards every org must meet.
- Decision records. Why each org exists and when to revisit it.
- Change calendar. A shared calendar of planned changes across all orgs, so teams do not collide.
A franchise restaurant chain lets each location run its own kitchen and staff, but every location must follow the brand’s food safety rules, buy approved suppliers, and pass regular inspections. The head office does not cook the food, but it keeps the brand safe. Federated governance of orgs works the same way.
Give each org an accountable human, called the org owner, with a named backup. Orgs without owners are the first to fall behind on security updates, certificates, and reviews.
19Keeping Configurations Consistent
If five orgs should follow the same security rules, how do you make sure they do? Without a plan, each drifts in its own direction.
The Golden Baseline
A golden baseline is a reference set of settings that every org should have: the policy for administrators, the standard authentication tiers, the approved factors, the default session lengths, the naming convention, and the log streaming setup. It lives in one place, maintained by the central team, with a version number and a change history.
Layers of Configuration
Mandatory layer
Settings that must be identical in every org, such as phishing-resistant factors for administrators. These are applied by automation and any change by hand is flagged.
Recommended layer
Settings that most orgs should follow but may vary with a written reason, such as session lengths for low-risk apps.
Local layer
Settings owned by the unit, such as its own apps, branding, and local groups.
Tools for Consistency
Infrastructure as code
Describe settings in files, using the Okta provider for tools such as Terraform. One set of files can be applied to many orgs, each with its own connection settings kept separate.
Reusable modules
Package the baseline as a module that every org includes, so that a fix in one place reaches all orgs after review.
Scheduled drift checks
Run a regular comparison of the live org with the files. Any difference becomes a ticket. Manual edits are noticed within days, not years.
Separate state per org
Keep the records of what has been applied separate for each org, so a mistake in one cannot touch another.
Separate credentials per org
Each org needs its own automation credentials, stored in a vault, with narrow permissions. Never reuse one credential across orgs.
Peer review for every change
A second person checks every change before it is applied to production.
flowchart TD
BASE["Golden baseline module"] --> ORGA["Org A configuration"]
BASE --> ORGB["Org B configuration"]
BASE --> ORGC["Org C configuration"]
LA["Local settings A"] --> ORGA
LB["Local settings B"] --> ORGB
LC["Local settings C"] --> ORGC
ORGA --> DR["Drift check"]
ORGB --> DR
ORGC --> DR
DR -->|"Difference found"| TKT["Ticket to org owner"]
A hotel chain gives every hotel the same fire safety plan, the same sign design, and the same emergency exits, but lets each hotel choose its restaurant menu and its local art. Inspectors visit regularly to check that the fire plan has not been quietly changed. The baseline is the fire plan, and the drift check is the inspector.
Applying one configuration to many orgs is powerful and dangerous. A single mistake in the shared module reaches every org at once. Roll out baseline changes in waves: sandbox, then one low-risk org, then the rest.
20Security in a Multi-Org World
Several orgs can make a company safer or less safe. Walls reduce the spread of an attack, but each new org also adds administrators, secrets, and trust links to protect.
Blast Radius
The blast radius of a problem is how far the damage spreads. In a single org, a compromised super administrator can change everything for everyone. With separate orgs, the same compromise is limited to one org, if the orgs are not strongly linked. This is the biggest security argument for splitting. But the benefit holds only if the links between orgs are narrow. A spoke that trusts a hub for everything, with administrator rights flowing downward, is only as safe as the hub.
The Chain of Trust
flowchart TD
A["Attacker steals a hub administrator session"] --> B["Hub policies weakened"]
B --> C["Spokes accept weaker proof from hub"]
C --> D["Attacker signs in as any person in any spoke"]
D --> E["Access to apps in every spoke"]
F["Defense: spoke applies its own app policies"] -.->|"Breaks chain"| D
G["Defense: strict admin protection and alerts at hub"] -.->|"Breaks chain"| A
H["Defense: no admin rights flow from hub to spokes by default"] -.->|"Breaks chain"| C
Security Controls to Apply in Every Org
Strong admin sign-in
Phishing-resistant factors and managed devices for every administrator, in every org, with the same standard.
Few super administrators
A small, named, reviewed list in every org. Count them across all orgs and watch the total.
Separate admin identities
Administrators of the hub should not automatically be administrators of spokes. Grant spoke rights deliberately and narrowly.
Narrow trust links
Federate only the users who need it. Limit the attributes sent. Avoid group pushes that grant powerful roles.
Vaulted credentials per org
Every org’s API tokens and signing keys are stored in a vault, tracked, and rotated. One leaked token should touch one org.
Break-glass per org
Each org keeps its own emergency accounts, not dependent on the hub, because the hub may be the thing that failed.
Central alerts
Admin changes, new trust links, and new API tokens in any org raise an alert in one place.
Joint reviews
Review trust links and admin lists across all orgs together, every quarter.
Trust Direction and Account Takeover
Think about who trusts whom. If a spoke trusts the hub, then anyone who can sign in as a hub user can reach the spoke. If the hub also trusts the spoke, then a break-in at the spoke can reach the hub. Two-way trust doubles the risk. Prefer one direction, from the stronger org to the weaker, and avoid mirrored links unless there is a clear reason.
Just-in-Time Account Creation Risks
Allowing JIT creation in a spoke means any person the hub vouches for can have an account created automatically. If the hub’s routing is too loose, strangers may gain accounts. Limit JIT to specific groups, require a matching rule for each, and review created accounts regularly.
| Threat | How multi-org helps | How multi-org hurts | Control |
|---|---|---|---|
| Stolen administrator session | Limits damage to one org | More admin accounts to steal | Strong factors, alerts, few super admins |
| Phishing of staff | No change | Users confused by multiple sign-in pages | Hub-based sign-in, custom domains per org |
| Weak spoke policy | Spoke contained from the rest | Spoke may still inherit trust | Baseline and drift checks |
| Leaked API token | Token limited to its org | More tokens overall | Vault, rotation, owner register |
| Insider misuse | Smaller admin populations per org | Harder to see everything at once | Central logging and review |
| Slow offboarding | No change | More places to forget | Provisioning, metrics per org |
Ships are built with watertight compartments. If one fills with water, the others stay dry. But if the doors between compartments are left open “for convenience,” the compartments protect nobody. Orgs are compartments, and trust links are doors. Keep the doors narrow, and close them by default.
21Performance, Scalability and Rate Limits
Okta protects itself and its customers with limits on how many requests an org may make. Multi-org design changes how you meet those limits, for better and for worse.
Limits Belong to the Org
Rate limits apply per org and per kind of endpoint. Every org has its own budget. If one org is overloaded with API calls, the other orgs are not slowed. This is a real benefit for units with very heavy usage, such as a customer-facing system with automated activity, or a unit running large nightly jobs.
The Cost of Splitting
Repeated integrations
An app used by users in two orgs is connected twice, once in each org, or through federation from one. More integrations mean more API calls, more certificates, and more places where things can fail.
Provisioning traffic
Pushing accounts and groups from a hub to spokes creates a steady flow of calls. A bulk change in the hub, such as a department rename for ten thousand people, can create a storm of updates in every spoke.
Cross-org sign-in hops
Each federated sign-in involves two orgs and extra redirects. The delay is small, but at login peaks, both orgs carry the load.
Management automation
Drift checks, reports, and configuration tools call the management API of every org. Combined, they can use up a large part of each org’s budget if poorly scheduled.
Design Habits That Help
- Stagger heavy work. Do not run bulk updates in all orgs at the same time. Spread them across the night and across orgs.
- Throttle bulk changes. Break large changes into batches and watch for rate limit responses.
- Use events instead of polling. Let Okta tell your tools when something changes instead of asking every minute.
- Separate critical and casual traffic. Keep sign-in dependent calls away from reports. Give heavy reporting its own org if it is large enough to justify one.
- Monitor usage per org. Use the rate limit dashboards and alerts in each org and bring them into the central view.
- Test at scale in a preview org. Before a big change, simulate the load.
flowchart LR
BULK["Bulk change in hub: 10000 users updated"] --> Q["Queue with batches"]
Q --> B1["Batch to spoke A"]
Q --> B2["Batch to spoke B"]
B1 --> R1{"Rate limit warning?"}
B2 --> R2{"Rate limit warning?"}
R1 -->|"Yes"| W1["Slow down and retry"]
R2 -->|"Yes"| W2["Slow down and retry"]
R1 -->|"No"| OK1["Continue"]
R2 -->|"No"| OK2["Continue"]
Each building in a city has its own water pipe with its own capacity. A factory using huge amounts of water does not make the neighboring homes run dry. But if the factory’s owner also sends all deliveries through the one gate of a small shop, that shop’s door jams. Separate orgs give separate pipes, while shared automation can still jam shared gates.
Specific rate limit numbers depend on your plan and change over time. Look up your current limits for each org, record them in the org register, and design with a safety margin.
22High Availability and Failure Scenarios
A multi-org design changes what happens when something fails. Some failures become smaller. Others become harder to predict because of chains of dependency.
Okta’s Own Availability
Okta runs its service across several data centers within each cell and publishes an availability target in its agreements. Your orgs benefit from this without extra work. However, an incident that affects one cell can affect every org in that cell. An org in another cell may carry on working. This is one real reason to place a critical org in a separate cell, but weigh it against the data location and complexity costs.
Dependency Chains
In a hub-and-spoke design, many sign-ins need both the spoke and the hub. If the hub is down, the spoke cannot verify people through federation, even though the spoke itself is fine. The chance that a sign-in works is the product of the chance that each link works. More links mean lower overall reliability, unless you design fallback paths.
| Failure | Who is affected | What users see | Mitigation |
|---|---|---|---|
| Hub unavailable | All users who sign in via the hub, in all spokes | Sign-in fails or hangs on redirect | Existing sessions continue; break-glass local access for critical roles; clear status page |
| One spoke unavailable | Users of that spoke’s apps | Those apps fail; others fine | Spoke-level monitoring and support |
| Expired federation certificate | All users on that link | Signed answers rejected | Certificate register and renewal alerts |
| Routing rule mistake | Users whose domain matched wrongly | Redirect loops or wrong sign-in page | Test rules in preview; change control |
| Provisioning failure | New and changed users in the spoke | Missing accounts or stale access | Provisioning alerts; reconciliation reports |
| Cell-level incident | All orgs in that cell | Sign-in problems in that region | Know which orgs sit in which cell; communication plan |
Designing for Failure
Emergency local access
For the most critical roles, such as the people who fix outages, keep a way to sign in that does not need the hub, protected with strong factors and tight monitoring.
Session resilience
Existing sessions keep working during a short hub outage. Avoid forcing re-authentication more often than needed for low-risk apps.
Dependency map
Draw which apps depend on which org, and which orgs depend on which other orgs. Keep it current.
Failure drills
Practice a hub outage and a certificate expiry. Time the response and fix gaps.
flowchart TD
U["User signs in to spoke app"] --> S{"Spoke org healthy?"}
S -->|"No"| F1["Fail: spoke incident process"]
S -->|"Yes"| H{"Hub reachable and responding?"}
H -->|"Yes"| OK["Sign-in succeeds"]
H -->|"No"| E{"Does user have a valid session or emergency path?"}
E -->|"Yes"| OK2["Limited access continues"]
E -->|"No"| F2["Fail: hub incident process"]
A relay race depends on every runner. If any one drops the baton, the team stops. A single long-distance runner has one failure point but no handoffs. More orgs means more handoffs. Practice the handoffs, and keep a spare baton for the runs that matter most.
Production example: a certificate that took down a region
A group connected its regional spoke to the hub using a federation certificate that quietly expired. All sign-ins for that region failed at 8 a.m. on a Monday. Because nobody tracked the link in a register, it took two hours to find the cause. Afterward, the group added every trust link to a register with expiry alerts at 60, 30, and 7 days.
23Monitoring, Logging and Metrics Across Orgs
Every org has its own System Log. With several orgs, the first job of monitoring is to bring them into one picture.
One Collector, Many Orgs
Stream each org’s logs into a single security tool. Add a field to every event that says which org it came from, so analysts can filter. Without this, an analyst investigating a person must log in to each org’s console in turn, and may miss that the same person did something suspicious in two places.
flowchart LR
O1["Org A System Log"] --> C["Central log collector"]
O2["Org B System Log"] --> C
O3["Org C System Log"] --> C
O4["Preview and sandbox orgs"] --> C
C --> N["Normalize and tag by org"]
N --> R["Detection rules"]
N --> D["Dashboards and reports"]
R --> T["Alerts to owners"]
D --> L["Monthly review"]
Cross-Org Detections Worth Building
Same person, many orgs, short time
A person who suddenly signs in to several orgs from a new location is a stronger signal than activity in one.
New trust link or routing rule
Any new identity provider, routing rule, or federation setting in any org raises an immediate alert.
Admin role assigned
A new super administrator in any org is reviewed the same day.
Hub change followed by spoke activity
A weakened policy in the hub followed by unusual sign-ins in spokes may mean an attack through the chain.
Provisioning error spikes
Many failed provisioning events show a broken link before users complain.
Break-glass use
Any sign-in with an emergency account in any org triggers an urgent alert.
Metrics That Show Health
| Metric | Per org or global? | What it tells you |
|---|---|---|
| Number of super administrators | Both | Exposure, and drift in privileged access |
| Share of administrators with phishing-resistant factors | Per org | Whether the baseline is real |
| Time from HR departure to account disabled | Per org | Offboarding speed; slowest org defines the group |
| Configuration drift items open | Per org | How far each org has moved from the baseline |
| Trust links without owner or review date | Global | Governance gaps |
| Days until nearest federation certificate expiry | Per link | Risk of a sudden outage |
| Rate limit usage at peak | Per org | Headroom for growth |
| Accounts without a global ID | Per org | Quality of identity correlation |
| Orphan accounts in apps | Per org and app | Lifecycle failures |
A company with several branch offices that each keep their own security camera recordings in a back room has a weak security picture. A company that streams every camera to one control room, labeled by branch, can see a stranger who walked through three branches in one afternoon. The control room is the central collector.
Include non-production orgs in your logging too. Attackers like weakly protected test orgs, and a sandbox with copied production secrets is a favorite target.
24Migration and Consolidation Playbook
Sooner or later most multi-org companies face the question of merging two orgs into one. It is a project, not a click. Here is a method that reduces surprises.
What Moves Easily, and What Does Not
| Item | Moves easily? | Notes |
|---|---|---|
| User profiles | Yes, with planning | Export and import through APIs or tools; map attributes first |
| Groups and memberships | Yes, with mapping | Group IDs change; rebuild assignments by name |
| Passwords | Sometimes | Okta supports importing certain password hash formats through its API; otherwise users reset |
| MFA enrollments | No | Factors are tied to the org; users must enroll again in the target org |
| App integrations | Partly | Each app must be reconfigured: new entity IDs, certificates, or client IDs may require changes in the app |
| Policies | Rebuild | Use this chance to adopt the baseline instead of copying old rules |
| Custom domain and branding | Re-create | A domain can serve only one org at a time; plan the cutover |
| Logs and history | No | Export and archive what you need for audit before retiring the old org |
The Waves Method
Plan and map
Decide the target org. Map attributes, groups, apps, and policies. Choose a global ID. Write a communication plan. Agree on a freeze period for unrelated changes.
Federate as a bridge
Link the orgs so people can reach apps in both while the migration goes on. This avoids a risky single cutover.
Pilot with a small group
Move a few dozen volunteers and a few low-risk apps. Fix what breaks.
Migrate users in waves
Move by department or region. Each wave brings users, groups, and their apps. Help users re-enroll factors, with a support desk ready.
Move apps and notify owners
For each app, coordinate a window to switch the connection to the target org, then verify sign-in. Update documentation and certificates in the register.
Cut over the domain and branding
Move the custom domain and email settings. Test with a small group before the full cutover.
Freeze, archive, retire
Make the old org read-only, export logs and configuration, wait for a safety period, and then retire it. Keep an archive for audits.
flowchart LR
P["Plan and map"] --> B["Bridge by federation"]
B --> PI["Pilot group"]
PI --> W1["Wave 1"]
W1 --> W2["Wave 2"]
W2 --> W3["Wave 3"]
W3 --> DC["Domain cutover"]
DC --> A["Archive and retire old org"]
W1 -.->|"Problem found"| FX["Pause and fix"]
FX -.-> W1
Common Migration Traps
- Forgetting that factors cannot move. Plan the support load for re-enrollment, especially for people without their devices handy.
- Changing identifiers. If an app identifies users by an Okta-generated ID or a value that differs in the new org, users may appear as new people. Keep matching identifiers stable.
- Moving too many apps at once. Each app has its own quirks.
- Hidden integrations. Scripts and hooks that refer to the old org’s address break silently. Search for the old address everywhere.
- No rollback plan. Decide in advance how to return users to the old org if a wave fails.
Merging two orgs is like moving two households into one home. You do not carry everything on the same day. You plan rooms, move boxes in stages, keep both phone lines for a while, and change addresses with banks and friends. The old house is sold only after the last box and the last bill have moved.
25Advantages, Disadvantages and Trade-offs
Multi-org designs trade simplicity for separation. Here is the honest ledger.
Advantages of multiple orgs
- Hard boundaries. Legal, regional, and administrative separation is clear and easy to show to auditors.
- Smaller blast radius. A problem in one org does not automatically spread to all.
- Independent capacity. Each org has its own rate limit budget.
- Safe testing. Environment orgs let you rehearse changes.
- Flexibility after acquisitions. A landing zone keeps operations steady while you plan.
- Different risk profiles. Customer and workforce worlds can follow their own rules.
Disadvantages of multiple orgs
- More to run. Every org needs administrators, reviews, and monitoring.
- Configuration drift. Orgs drift apart unless actively controlled.
- Duplicate work. Integrations, policies, and branding repeated per org.
- Harder user experience. Multiple sign-in pages and enrollments confuse people.
- Complex trust. Federation links need protection, and chains create new risks.
- Higher cost. More licenses, more tools, more staff time.
The Trade-off Table
| Question | One production org | Several production orgs |
|---|---|---|
| Simplicity of operations | High | Lower; needs governance |
| Strength of separation | Soft: roles and policies | Hard: separate walls |
| User experience | One sign-in and one enrollment | Good with a hub; confusing without |
| Blast radius of top-level compromise | Whole company | One org, if links are narrow |
| Rate limit headroom | One shared budget | One budget per org |
| Data location options | One region | Different regions per org |
| Configuration consistency | Naturally high | Needs automation and review |
| Cost | Lower | Higher; confirm licensing with Okta |
| Path to merge later | Not needed | Easier with a hub and global IDs |
The Hidden Costs
People time
The largest cost is usually staff time to keep orgs aligned, reviewed, and monitored, not the licenses.
Tooling
Configuration tooling, log collectors, secret vaults, and drift checks scale with the number of orgs.
Training
Each additional org adds a set of administrators to train, and users to teach.
Licensing
Licensing terms differ between customers and products. Confirm with Okta how users, orgs, and environments are counted before you design around cost assumptions.
26Anti-patterns and Common Mistakes
Experience in this area teaches the same lessons again and again. These are the mistakes that cost the most.
Org sprawl
A new org is created every time a team asks, with no owner, no register, and no baseline. After two years nobody knows how many there are.
Why it hurts
Unseen orgs hold unreviewed administrators and forgotten API tokens. Attackers love islands nobody watches.
Better approach
Require a written decision record and an owner before any production org is created. Keep an org register, and review it each quarter.
The permanent temporary org
An acquired company’s org is kept “for now” and still exists five years later, with its own differing rules.
Why it hurts
The gap with the main org grows each year. The cost of consolidation rises, and the audit risk stays.
Better approach
Give every landing zone an end date or a formal decision to keep it, and track progress against the date.
Matching people by email
Accounts in different orgs are linked by email address alone.
Why it hurts
Emails change, and people can end up with duplicate or wrongly merged accounts.
Better approach
Assign and store a stable global ID in every org, and use it for all matching.
Hub admins are admins everywhere
Hub administrators are given super administrator rights in every spoke for convenience.
Why it hurts
One compromised hub admin account becomes a key to every org. The walls between orgs vanish.
Better approach
Use narrow, specific roles in spokes, assigned by name, with separate strong sign-in, and alert on use.
Testing in production because preview drifted
The preview org no longer resembles production, so teams stop trusting it and test live.
Why it hurts
Every change is a gamble with real users.
Better approach
Apply configuration to both from the same files, and run a scheduled check that compares them.
Production secrets in test orgs
Real API tokens, signing keys, or user data are copied into test orgs for convenience.
Why it hurts
Test orgs are less protected, so they become a back door into production.
Better approach
Use separate credentials and fake data in every lower environment.
More Mistakes in Brief
No diagram of the whole estate
If nobody can draw all orgs and links on one page, nobody understands the risk.
Two masters for the same attribute
Hub and spoke both edit job titles, and the values flip back and forth.
Federating everyone by default
Every person in the hub gets a spoke account, though most never need it. This enlarges the attack surface and inflates costs.
Ignoring the user experience
People face several sign-in pages with different looks and addresses. Phishing becomes easier.
No break-glass in spokes
All spoke admin access depends on the hub. When the hub fails, nobody can fix anything.
Splitting for the wrong reason
Creating a new org to avoid a politically awkward cleanup rather than a real boundary.
27Best Practices Checklist
A practical list you can adapt to your own estate. It follows the order in which most teams need it.
Strategy
- Start with one production org and add more only for hard boundaries: law, region, legal entity, administrative independence, or major differences in risk or scale.
- Write a decision record for every production org, with reasons, consequences, and a review date.
- Always have non-production orgs for testing, and keep them in step with production through code.
- Prefer a hub shape for trust, and avoid meshes.
- Plan the exit. For temporary orgs, set an end date. For permanent ones, set a review date.
Identity
- Choose a global ID and store it in every org.
- Pick one master for each attribute. Receivers do not edit what they receive.
- Use provisioning where you can, and limit JIT to well-defined groups.
- Federate only those who need cross-org access.
- Measure offboarding time per org.
Security
- Use the same strong standard for administrators in every org.
- Count and review super administrators across all orgs together.
- Keep trust links narrow and one-directional where possible.
- Apply meaningful policy at the point where access is granted, even if another org proved identity.
- Hold break-glass accounts per org, independent of the hub, and test them.
- Vault every secret and track every certificate with an owner and expiry date.
Operations
- Stream all logs to one place with an org tag, including non-production orgs.
- Use configuration as code with peer review, and separate state per org.
- Check drift on a schedule and turn differences into tickets.
- Roll out baseline changes in waves.
- Stagger bulk jobs and watch rate limits in each org.
- Practice failures: hub outage, certificate expiry, administrator compromise.
Governance
- Keep four registers: orgs, trust links, administrators, and decisions.
- Name an owner and backup for every org and every link.
- Review everything quarterly and record the outcome.
flowchart LR
S["Strategy: why this many orgs"] --> I["Identity: global ID and masters"]
I --> SE["Security: baseline and narrow links"]
SE --> O["Operations: code, logs, drift checks"]
O --> G["Governance: registers and reviews"]
G -.->|"Findings feed back"| S
Running several orgs well is like managing several restaurants under one brand. You need a clear reason for each location, one shared recipe book, one inspection routine, and a head office that checks the books. The recipe is the baseline, the inspection is the drift check, and the books are the registers.
28Real-World Scenarios and a Worked Example
The scenarios below are blended from patterns that identity teams commonly describe. Names are invented, and numbers are illustrative.
Scenario 1: The conglomerate with three acquisitions
Granite Peak Holdings, our company from the start of this guide, built a hub org for the parent company and gave each of the three acquisitions a spoke org. The German software firm and the healthcare startup each stayed separate for a legal reason: one had a data location commitment, the other handled regulated health records. The Texas logistics business had no such reason, so it was migrated into the hub over nine months. The group ended with one hub and two spokes, plus a sandbox and a preview org.
Scenario 2: The software company with employees and customers
A software company with 1,500 employees and 4 million end users kept its employee identity in a workforce org and moved customer sign-in to a separate customer identity tenant. After a product launch drove sign-ups to ten times the normal rate, employee access was unaffected. Support staff reached the customer tenant through narrow roles assigned to their workforce identities, with alerts when they used them.
Scenario 3: The global manufacturer with regional rules
A manufacturer with plants in four regions had one org in a US cell. A new European contract required employee data to stay in Europe. The company created a European org, mastered European staff there, and federated to the global hub for group-wide apps with a minimal attribute set. Logs from the European org were streamed to a collector in Europe, while a smaller set of anonymized metrics went to the global dashboard.
Scenario 4: The cautionary tale
A fast-growing company created a new org for every product team over three years. By the time the security team noticed, there were eleven production orgs, none with a baseline, with 37 super administrators, many of whom had left the company. An attacker used a stolen API token from one org to create new administrators, and the incident took weeks to understand because logs lived in eleven places. The company spent a year consolidating to three orgs.
A Worked Planning Example
Let us walk through the arithmetic for Granite Peak’s final design, using invented numbers.
| Org | Purpose | Users | Administrators | Super admins |
|---|---|---|---|---|
| Hub (US cell) | Parent and Texas staff, group-wide apps | 3,400 | 9 | 3 |
| Spoke Germany (EU cell) | Software subsidiary, data in Europe | 900 | 5 | 2 |
| Spoke Health | Regulated healthcare startup | 250 | 3 | 2 |
| Preview | Pre-production rehearsal | 40 test users | 6 | 2 |
| Sandbox | Integration testing | 25 test users | 8 | 2 |
| Total | 4,550 real users | 31 | 11 |
The numbers tell a story. Four orgs and one sandbox serve about 4,550 real people. There are 11 super administrators across five orgs, which is still too many for a company of this size, so the first review goal is to cut the total to about 8, with at most 2 in each production org and 1 or 2 in the lower environments. The trust links are three: hub to Germany, hub to Health, and the sandbox federated to the hub for test sign-ins. That is a small, drawable number. If the company had built a mesh among the three production orgs, it would have six one-way links instead of two.
The best multi-org designs are boring when drawn: a small number of orgs, each with a stated reason, a few trust links, and a short list of administrators. If your diagram looks complicated, that is a sign to simplify before you build.
29Frequently Asked Questions
Quick answers to the questions that come up most often when teams plan several orgs.
30Summary and Key Takeaways
A multi-org strategy is a set of deliberate walls and doors. Build as few walls as your real constraints require, and make every door narrow, owned, and watched.
Key Takeaways
- Start with one production org. Add more only for hard boundaries such as law, region, legal entity, independent administration, or large differences in risk and scale. Always add non-production orgs for testing.
- An org is a sealed room. Users, groups, policies, factors, admins, limits, and logs do not cross the wall unless you connect them with federation, provisioning, or shared services.
- Use patterns with a clear shape. The environment ladder, hub and spoke, workforce and customer split, regional orgs, and the M&A landing zone cover most needs. Avoid a mesh of direct trust links.
- Identity needs a stable spine. Assign a global ID, give each attribute one master, provision where you can, and measure offboarding time in every org.
- Security means narrow links. Apply the same strong standard for administrators in every org, keep trust one-directional and minimal, vault secrets, and give each org its own break-glass path.
- Consistency comes from code and review. Use a golden baseline applied through configuration as code, run drift checks, and roll out changes in waves.
- Governance keeps it simple. Maintain registers of orgs, trust links, administrators, and decisions, name owners, stream all logs to one place, and review everything on a schedule.