Before drawing any architecture, we need to be clear about the word “hybrid” and the problems it brings. Everything later in this guide is a response to these problems.

Old, new, near, and far

Think of the places where a company’s software can live. Some of it runs in the company’s own rooms, called on-premises or “on-prem”, meaning on machines the company owns and looks after. Some runs in huge shared data centers rented from cloud providers, a style called infrastructure as a service, where the company rents raw computers. A lot of software is simply rented as a finished product over the internet, known as software as a service, or SaaS, such as email, chat, or customer-tracking tools. A hybrid setup uses several of these at the same time.

Companies end up here for good reasons. Some systems are too old or too expensive to move. Some data must stay in a particular building or country because of rules or contracts. Some machines must sit next to physical equipment, like factory robots, where a slow internet link would be dangerous. And some teams simply bought what they needed over many years, one decision at a time. Hybrid is not a mistake. It is the normal result of a company living through time.

The identity problem hybrid creates

Each kind of system often keeps its own list of users and passwords. The old file server trusts the company’s internal directory. The cloud tool has its own accounts. The partner website has yet another set. This leads to a familiar mess: people juggle many passwords, administrators create and remove accounts in a dozen places, and former employees may keep access somewhere that was forgotten. Every extra list of users is another place to make a mistake or to be attacked.

What a good hybrid identity design achieves

• One identity per person that all systems rely on, so there is a single place to create, change, and remove access.
• Consistent protection such as multi-factor checks, applied the same way to old and new systems.
• A smooth experience where people sign in once and reach what they need without repeated passwords.
• A safe path of change that lets the company move old systems to the cloud slowly, without a risky big bang.
• Clear evidence of who accessed what and when, across the entire mixture.

Okta is not one single gadget. It is a set of parts that work together. Knowing each part by name makes every later chapter easy to follow.

An identity provider

Okta is an identity provider, often shortened to IdP. This is a service that keeps track of who people are, checks their proof when they sign in, and then tells other applications, “Yes, I have checked this person, you may trust them.” The applications that rely on the identity provider are called service providers or simply apps. The whole idea of single sign-on, or SSO, is that a person proves who they are once to the identity provider and then reaches many apps without proving it again for each one.

How the blocks combine

In a typical hybrid design, the Universal Directory holds the profile of every person. Agents link it to the company’s existing on-premises directory. Single sign-on opens modern apps directly. The Access Gateway opens older web apps. RADIUS and LDAP support let network devices and old software ask Okta for decisions. Lifecycle management keeps accounts tidy everywhere. Policies and multi-factor checks sit on top, giving the same protection to all of it.

Now we place the building blocks on one page. This picture is a common starting shape that real companies adapt to their own needs.

Four zones

It helps to divide the hybrid world into four zones. The identity zone is Okta itself, running as a cloud service. The corporate network zone holds the company’s own data center, its directory, and its older applications. The cloud platform zone holds rented computing environments from providers such as Amazon Web Services, Microsoft Azure, and Google Cloud. The SaaS zone holds finished online products. People reach all four from many places: offices, homes, and phones.

flowchart TD
    USER["Employees on laptops and phones"] --> OKTA["Okta: sign-in, MFA, policies, Universal Directory"]
    OKTA --> SAAS["SaaS apps: email, chat, CRM"]
    OKTA --> CLOUD["Cloud platforms: AWS, Azure, Google Cloud"]
    OKTA --> GW["Access Gateway in corporate network"]
    GW --> LEG["Legacy web applications"]
    OKTA --- AG["Okta agents in corporate network"]
    AG --- AD["Active Directory"]
    AG --- ONP["On-premises apps and provisioning targets"]
    OKTA --> NET["VPN and network devices via RADIUS"]
    

Reading the picture

Notice what sits at the center: not a server, not a directory, but the decision point. People do not walk directly to each system and prove themselves again and again. They go to Okta, and Okta either passes them through to the right place or stops them. The systems on the right side of the picture become simpler, because they no longer have to run their own sign-in machinery.

Notice also the dotted-style lines labeled “agents”. Those lines always start from inside the company network and reach out to Okta, a detail we will explore soon, because it is the secret to why this design is acceptable to security teams.

Two directions of flow

There are two main kinds of traffic in this picture. The first is sign-in traffic: a person proves who they are and receives access. The second is identity data traffic: information about people moving between the company directory, Okta, and the apps, such as “a new person joined, create an account”. Beginners often mix these up, yet they have different speeds, different failure effects, and different security needs.

For many companies the heart of hybrid is a directory that has served them for decades. Understanding it is the key to connecting Okta properly.

What Active Directory is

Active Directory, usually written AD, is Microsoft’s directory service for company networks. It stores users, groups, and computers, and it checks passwords for people who sign in to Windows machines and many internal applications. A group of linked AD servers forms a domain, and one or more domains can be arranged into a forest. The servers that answer sign-in questions are called domain controllers. Millions of organizations rely on AD, which is why connecting to it is the first big task in most hybrid projects.

What the Universal Directory adds

Okta’s Universal Directory is a cloud-based store of user profiles. Rather than replacing AD at once, it usually sits alongside it. Okta connects to AD through an agent and imports users and groups into the Universal Directory. Each person then has one Okta profile, which can also receive details from other places, such as the human resources system. This combined profile is what drives access to cloud and SaaS apps.

flowchart LR
    HR["HR system: hire, move, leave"] --> UD["Okta Universal Directory"]
    AD["Active Directory"] -- "import via agent" --> UD
    UD -- "push changes" --> AD
    UD --> APPS["Cloud and SaaS apps"]
    UD --> GRP["Groups and policies"]
    

The idea of a source of truth

For every piece of information about a person, exactly one system should be the source of truth, the place where that fact is officially kept and changed. The HR system might own the job title and manager. AD might own the Windows username and group memberships used by on-premises apps. Okta might own the multi-factor settings. This is called profile mastering. When two systems both think they own the same fact and they disagree, strange bugs appear, such as a title that keeps flipping back and forth.

Imports and how fresh the data is

Data does not teleport. Okta pulls changes from AD through the agent on a schedule, and some kinds of changes can be picked up faster than others. A full import reads everything and takes longer. An incremental import reads only what changed and is faster. Because of this, a change made in AD may take a short while to appear in Okta. Good designs account for that delay, especially for urgent actions like removing a departing person’s access, where a separate fast path or a manual step may be used.

The same person may sign in from an office laptop on the company network, from a phone at home, or from a shared computer. Okta offers several paths, and the right one depends on where the password lives.

Where is the password checked?

In hybrid environments, a big design decision is where passwords are verified. There are two main choices, and both are common.

In the first, people keep a password in Active Directory, and Okta asks AD to check it. This is called delegated authentication. The person types their password into the Okta sign-in page, Okta passes the check to the agent in the corporate network, the agent asks a domain controller whether the password is right, and the answer comes back. The password itself is not stored in Okta in this model. The big advantage is that one password continues to work for both the Windows login and Okta, and existing AD password rules keep applying.

In the second, the password is stored and checked by Okta. This removes the dependency on the corporate network for the password step, and it fits companies that are reducing their use of AD. Okta can also be configured so that users move from one model to the other over time.

sequenceDiagram
    participant P as Person
    participant O as Okta
    participant A as Okta AD agent
    participant D as Domain controller
    P->>O: Enter username and password
    O->>A: Ask agent to verify password
    A->>D: Check password with Active Directory
    D-->>A: Valid or not valid
    A-->>O: Result
    O->>P: Ask for MFA if the policy requires it
    O-->>P: Access granted
    

Desktop single sign-on

When a person is already signed in to their Windows computer on the company network, they have already proved who they are to AD. Desktop single sign-on lets Okta take advantage of that, using Windows’ own method called Kerberos or integrated Windows authentication, so the person is not asked to type a password again for Okta. Okta provides an agent component for this purpose. The result feels magical to users: they open a browser at the office and land inside their apps.

Multi-factor authentication on top

Whichever way the password is checked, multi-factor authentication, or MFA, adds a second proof. Examples are a prompt in the Okta Verify phone app, a code, a fingerprint, or a physical security key. Policies decide when to ask: perhaps never on a trusted office device for low-risk apps, but always for the finance system and always from unknown locations. Because MFA happens in Okta, it can protect both modern apps and, through the gateway and other bridges, older apps that could never do MFA on their own.

Systems need a shared language to say “I vouch for this person”. A few standard languages cover nearly all of it. Learn their jobs, not their details.

SAML

SAML, short for Security Assertion Markup Language, is an older but widely used standard for single sign-on in business apps. After Okta checks a person, it sends the app a signed message called an assertion that says who the person is and a few facts about them. The app trusts the message because it is signed with a key it knows Okta holds. SAML is common in older enterprise software, which makes it extremely important in hybrid setups.

OpenID Connect and OAuth 2.0

OpenID Connect, called OIDC, is a newer standard built on top of OAuth 2.0. It is friendly to modern web apps, mobile apps, and programming interfaces. It uses compact tokens instead of large messages, and it works well where apps run in browsers or on phones. Most new software chooses OIDC first.

WS-Federation

WS-Federation is another older standard, strongly tied to the Microsoft world. It still appears when connecting Okta to some Microsoft services and older on-premises applications. You may meet it in hybrid projects even though newer apps rarely use it.

SCIM

The first three languages are about sign-in. SCIM, the System for Cross-domain Identity Management, is about accounts. It is a standard way for Okta to tell an app, “create this user”, “change this user’s title”, or “remove this user”. It is the engine behind automatic provisioning, the creating and removing of accounts as people join and leave.

When an app speaks none of them

Some applications, especially very old ones, speak none of these languages. They might check a password against a directory themselves, or read a special header in the web request, or use an old protocol. That is exactly where the bridges come in: the access gateway for web apps, RADIUS for network devices, LDAP for directory-style lookups, and password-vaulting methods as a last resort. The next chapters take these one at a time.

Agents are the small programs that make hybrid possible. They are easy to overlook, yet they carry a huge amount of weight. Treat them as part of your core infrastructure.

What an agent is

An agent is a small program that you install on a server inside your own network. Its job is to be a trusted messenger between Okta in the cloud and a system in your building that Okta cannot reach directly, such as Active Directory. Okta provides different agents for different jobs: one for connecting to Active Directory, one for desktop single sign-on, one for network sign-in through RADIUS, and one for on-premises provisioning, among others.

The outbound-only trick

Here is the clever part. Security teams dislike opening holes in the company firewall that let the internet connect inward. Okta agents avoid that. The agent makes an outbound connection from inside your network to Okta, over the standard secure web port, and keeps it open. When Okta needs something, such as “check this password”, it sends the request down that already-open connection, and the agent answers. No inbound door was opened. The firewall only needs to allow the agent’s outgoing secure web traffic to Okta’s addresses, which your security team can control and monitor.

flowchart LR
    subgraph CORP["Corporate network"]
        AG["Okta agent server"]
        DC["Domain controller"]
        AG --- DC
    end
    subgraph CLOUD["Internet"]
        OK["Okta cloud service"]
    end
    AG -- "outbound secure connection on port 443" --> OK
    OK -. "requests travel back on the same connection" .-> AG
    

Why you need more than one

A single agent is a single point of failure. If its server restarts for updates, crashes, or loses its network link, everything that depends on it stops, and that may include password checks for the whole company. Standard practice is to install at least two agents for each directory, on separate servers, ideally in separate locations, so one can take over when the other fails. Okta spreads requests across healthy agents and notices when one disappears.

flowchart TD
    OK["Okta cloud service"] --> A1["Agent 1: site A"]
    OK --> A2["Agent 2: site A"]
    OK --> A3["Agent 3: site B"]
    A1 --> DC1["Domain controller A"]
    A2 --> DC1
    A3 --> DC2["Domain controller B"]
    

Looking after agents

• Place them well. Install each agent on a dedicated, domain-joined server that is not used for other jobs. Check Okta’s current guidance on whether an agent may share a machine with a domain controller, since recommendations favor separate servers.
• Protect them. An agent server can reach your directory, so treat it as a highly sensitive machine, with limited administrators, patching, and monitoring.
• Keep them updated. Okta releases new agent versions with fixes and improvements, and old versions eventually stop being supported. Stagger updates across agents so there is always one healthy agent online.
• Watch their health. The Admin Console shows agent status. Alert when an agent becomes inactive, long before users notice.
• Give them only the permissions they need. The account an agent uses in AD should have narrow rights, not a broad administrator role.

The hardest applications to modernize are often the oldest ones. The Access Gateway is a way to bring them under Okta’s protection without rewriting them.

Why old apps are different

Modern apps happily accept a signed message from an identity provider. Many older web applications cannot. They were built when each application checked its own users, or relied on the internal network to decide who was trusted. Rewriting them may be impossible, because the vendor is gone, the source code is lost, or the cost is too high. Yet these applications often hold the most important business data, so leaving them with weak sign-in is risky.

The reverse proxy idea

The solution is a reverse proxy, a server that stands in front of an application and receives all visits on its behalf. The Okta Access Gateway is such a component. A person visits the application’s address and arrives first at the gateway. The gateway sends them to Okta to sign in, with full multi-factor checks and policies. After Okta approves, the gateway forwards the visit to the old application and adds whatever the old application needs to recognize the person. That may be a special header added to the request, a cookie, or a Kerberos ticket, depending on how the application was built.

sequenceDiagram
    participant P as Person
    participant G as Access Gateway
    participant O as Okta
    participant L as Legacy application
    P->>G: Open legacy application address
    G->>O: Redirect person to sign in
    O->>O: Check password, MFA, policy
    O-->>G: Signed confirmation of identity
    G->>L: Forward request with identity header or ticket
    L-->>G: Page response
    G-->>P: Show page
    

The ways a gateway can introduce identity

Strengths and limits

Not everything is a website. Network devices, remote-access gateways, and older software ask for identity in older ways. Okta can answer them too.

VPN and the RADIUS protocol

A VPN, or virtual private network, lets someone outside the office connect securely into the company network. Many VPN servers, wireless network controllers, and firewalls ask for identity using an old protocol called RADIUS. Okta provides a RADIUS server agent that you install in your network. The VPN server sends its sign-in questions to this agent, the agent asks Okta, and Okta applies its usual checks, including multi-factor authentication. This lets you add modern MFA to a VPN that was never designed for it.

sequenceDiagram
    participant P as Remote person
    participant V as VPN server
    participant R as Okta RADIUS agent
    participant O as Okta
    P->>V: Connect and enter credentials
    V->>R: RADIUS request
    R->>O: Ask Okta to verify
    O->>O: Check password and MFA policy
    O-->>R: Accept or reject
    R-->>V: RADIUS answer
    V-->>P: Connection allowed or denied
    

The limits of old protocols

RADIUS was designed long before phone prompts and security keys existed, so it can only carry certain types of extra proof in a clumsy way. A push notification to a phone often works well. Some modern methods, such as phishing-resistant security keys, may not fit through an older VPN path. Check which methods your VPN and the Okta RADIUS agent support, and plan for a day when the VPN itself is replaced with a more modern access approach.

LDAP: the directory-style lookup

LDAP, the Lightweight Directory Access Protocol, is an old and very common way for software to ask a directory questions such as “does this user exist and is this password right?” Many older tools, such as printers, build systems, and internal applications, use LDAP. Okta offers an LDAP Interface that lets such software treat Okta like a directory. Instead of keeping a separate directory server only for these tools, you can point them at Okta and gain its policies and MFA.

Signing in is only half of the story. Accounts must also be created and removed, and for on-premises apps that needs its own bridge.

What provisioning is

Provisioning is the automatic creation, updating, and removal of user accounts in applications. When a new employee is hired, provisioning creates their accounts in every app they need. When they change roles, access is adjusted. When they leave, their accounts are disabled. Doing this by hand is slow and error-prone. Doing it automatically is a core promise of an identity system.

The on-premises challenge

For cloud apps, Okta talks to the app over the internet using a standard such as SCIM. For on-premises apps, the app sits inside the company network, where Okta cannot reach it directly. Once again an agent solves the problem. The on-premises provisioning agent receives account instructions from Okta over an outbound connection and passes them to a local connector that knows how to create accounts in the on-premises system, often through a SCIM interface or a database, depending on the application.

flowchart LR
    O["Okta lifecycle engine"] -- "outbound connection" --- PA["On-premises provisioning agent"]
    PA --> C["Connector"]
    C --> APP["On-premises application"]
    C --> DB["Application database or directory"]
    

The joiner, mover, leaver cycle

Keeping the data consistent

Provisioning depends on good data. If the HR system has the wrong department, the wrong group will be assigned. Many hybrid problems that look like “Okta bugs” are really data quality problems. Before turning on automation, check the quality of the attributes that rules depend on, such as department, location, and employment status.

The most powerful accounts in a company are not those used to read email. They are those used to log in to servers and change infrastructure. Hybrid identity must cover them too.

Why server access is special

System administrators connect to servers using protocols like SSH on Linux or remote desktop on Windows. In older setups, each server has local accounts, shared passwords, or long-lived keys copied between machines. This is difficult to control and nearly impossible to audit properly. When someone leaves, their key may still sit on dozens of servers. In hybrid environments, servers live in the data center, in cloud accounts, and sometimes in both, making the problem larger.

Bringing identity to servers

Okta offers privileged access capabilities, which have previously been marketed under the name Advanced Server Access and have since been repositioned under newer privileged access offerings. The exact product naming changes, so verify it in the current documentation. The idea stays the same. Instead of permanent keys and shared passwords, an administrator signs in through Okta, passes multi-factor checks, and receives short-lived credentials valid only for a brief period and only for the servers their role allows. When time is up, the credentials expire on their own, and a record shows who connected to what.

flowchart TD
    ADM["Administrator"] --> OK["Sign in to Okta with MFA"]
    OK --> POL{"Is the person in an allowed group?"}
    POL -- "No" --> DEN["Denied"]
    POL -- "Yes" --> CRED["Short-lived credential issued"]
    CRED --> SRV["Server in data center or cloud"]
    SRV --> LOG["Session recorded and audited"]
    CRED --> EXP["Credential expires automatically"]
    

When a company rents computing power from cloud providers, the people who manage those environments hold great power. Okta can be the single door to all of them.

The problem with cloud accounts

Each cloud provider has its own way of creating users and controlling their power. If administrators have separate cloud usernames and passwords, they multiply quickly across accounts, projects, and subscriptions. Departed employees can leave behind live accounts that nobody remembers. Federation avoids this by letting Okta vouch for the person, so the cloud provider has no separate password to guard.

How federation works in outline

Okta is set up as the trusted identity provider for the cloud account. A person signs in to Okta, then chooses the cloud platform tile. Okta sends a signed assertion, using SAML or OIDC, saying who the person is and which groups they belong to. The cloud platform reads the groups and maps them to roles, the sets of permissions it understands. A person in the “Cloud-Admins” group in Okta receives the matching administrator role in the cloud. The role is typically assumed temporarily, which makes access time-limited.

flowchart LR
    P["Cloud engineer"] --> O["Okta sign-in with MFA"]
    O --> A["Signed assertion with group names"]
    A --> C["Cloud platform trust configuration"]
    C --> M["Map groups to roles"]
    M --> R["Temporary role session"]
    

Design choices that matter

• Groups drive roles. Manage who has power by changing group membership in Okta, never by editing the cloud account by hand.
• Separate by environment. Use different groups for production and for testing, so a developer does not accidentally receive production power.
• Least privilege. Prefer narrow roles for daily work and keep powerful roles for rare occasions, with stronger checks.
• Plan for the escape hatch. Cloud accounts need a protected emergency path in case the identity provider is unreachable, with a locked-away credential and strict alerting on any use.
• Machines are identities too. Programs that run in the cloud need their own safe credentials, which are separate from people’s sign-in.

Most hybrid companies run Microsoft products somewhere. Understanding how Okta and Microsoft’s identity services share the stage prevents the most common confusion.

Two identity worlds

Microsoft’s cloud identity service is called Microsoft Entra ID, which was formerly known as Azure Active Directory. It stands behind Microsoft 365, the family that includes Outlook, Teams, and SharePoint. Many companies also still use on-premises Active Directory. So a company may already have two Microsoft identity systems, the old one in the building and the cloud one, linked by synchronization. Adding Okta creates a third element. The question is how they should relate.

Common ways to combine them

flowchart TD
    P["Person"] --> OK["Okta sign-in and MFA"]
    OK --> M365["Microsoft 365 through federation"]
    OK --> OTHER["Non-Microsoft apps"]
    AD["On-premises Active Directory"] -- "agent import" --> OK
    AD -- "sync" --> ENTRA["Microsoft Entra ID"]
    ENTRA --> M365
    

Important points to plan

• One policy owner. Decide which system holds the final say on conditions for each application. Two systems both trying to enforce rules can produce loops, double prompts, or gaps.
• Device trust across both. Windows computers joined to the company directory behave differently from personal devices. Test each device type with each pattern.
• Hybrid-joined devices. Many companies have computers joined to both on-premises AD and Entra. Okta’s device and desktop features need to be tested against that setup.
• Break-glass accounts. If Microsoft 365 trusts Okta, then an Okta outage can affect access to email. Microsoft administrators need emergency accounts that do not rely on Okta.
• Licensing and roles. Check which features each vendor’s licenses include before designing around them, since offerings overlap and change.

A password proves what a person knows. It says little about the machine in front of them. In a hybrid world, the health of the device matters just as much.

Why devices matter

Two sign-ins using the same correct password can have very different risk. One comes from a company laptop that is encrypted, patched, and managed. The other comes from an unknown computer in a café that may carry malware. If your policy cannot tell them apart, you must either trust both or distrust both. Device awareness lets policy trust the first more than the second.

Okta Verify and device signals

Okta Verify is Okta’s application for phones and computers. It can deliver push prompts for multi-factor checks, and when installed on a computer it can also act as a signal about the device. Combined with device management tools, it helps Okta recognize registered or managed devices. Device assurance policies then describe what a healthy device looks like, such as a minimum operating system version, a screen lock, or disk encryption, and sign-in rules can require a device to meet that description for sensitive apps.

flowchart TD
    S["Sign-in attempt"] --> D{"Device known and managed?"}
    D -- "Yes" --> H{"Device meets health requirements?"}
    D -- "No" --> UN["Limited access or extra proof"]
    H -- "Yes" --> OK["Normal access"]
    H -- "No" --> FIX["Block sensitive apps and show how to fix"]
    

Protecting the computer login itself

Okta also offers features that bring multi-factor authentication to the moment a person signs in to their Windows or Mac computer, a capability often called desktop MFA or device access. This matters in hybrid settings because the computer login is the front door to everything on the local network. Adding a second factor there closes a gap that web-only protections leave open. These features have conditions, such as how they behave when the computer is offline, so test the offline experience carefully before rolling them out widely.

Managed and unmanaged devices

“Zero Trust” is a popular phrase with a simple heart. In a hybrid environment it changes how you think about the old network boundary.

The old castle model

Traditional security worked like a castle with a moat. Anyone inside the company network was trusted, and anyone outside was not. Firewalls guarded the walls. This worked while all people and systems sat inside one building. Today staff work from homes, systems live in clouds, and attackers who get past the wall by stealing a password can roam freely inside. The wall no longer matches the reality.

The Zero Trust idea

Zero Trust says that being inside the network earns no automatic trust. Every request must show who is asking, whether their device is healthy, and what they are trying to reach, and each request is checked against policy. Access is limited to what is needed. Decisions are based on identity and context, not location. Okta supports this by acting as the policy decision point for who gets in, with what proof, on which devices.

What hybrid adds to the challenge

Zero Trust is easy to draw on a slide when everything is in the cloud. Hybrid makes it harder because some systems physically cannot take part in modern checks. The gateway, the RADIUS agent, the LDAP interface, and short-lived server credentials are the practical tools for pushing Zero Trust ideas into those places. The aim is not perfection on day one but steady removal of “trusted because of the network” exceptions.

flowchart LR
    REQ["Access request"] --> PDP["Okta policy decision: identity, device, context"]
    PDP -- "Allow with conditions" --> RES["Resource: app, server, network"]
    PDP -- "Step up proof" --> MFA["Extra verification"]
    MFA --> PDP
    PDP -- "Deny" --> BLK["Blocked and logged"]
    RES --> LOG["Activity logged for review"]
    

Giving people access is easy. Taking it away at the right time, and proving that you did, is where many hybrid companies struggle.

The dangers of drift

In a hybrid company, access is granted in many places: groups in AD, roles in cloud accounts, accounts in SaaS tools, local users on old servers. Over time people change jobs and projects end, but the access stays. This build-up of unneeded access is called privilege creep, and it is one of the most common causes of serious breaches and failed audits.

Making Okta the control point

The best defense is to route as much access as possible through groups and rules managed in one place. When access is driven by group membership, and group membership is driven by facts such as department and job title from the HR system, then a job change automatically adjusts access everywhere. Okta’s lifecycle tools and governance features, which include access requests and periodic access reviews in its identity governance offerings, add human checkpoints: managers confirm that access is still needed, and anything not confirmed is removed.

The orphans that hide

Some accounts never appear in the central picture: a local user created by hand on a server, a shared password for a legacy tool, a service account nobody owns. These orphan accounts are favorite targets for attackers because nobody is watching them. A hybrid governance project should include a hunt for these hidden accounts, assign owners, and either bring them under Okta’s control or remove them.

Identity systems are the master keys of the company. Attackers aim for them first. A hybrid design must protect not just the apps but every piece of the identity machinery.

The crown jewels

Think about what an attacker would love to control: the Okta administrator accounts, the Active Directory domain controllers, the servers running Okta agents, the gateway, the signing keys used for federation, and the credentials of the accounts that connect these pieces. Control of any of them can mean control of everything behind them. They deserve the highest level of care in the company.

Certificates deserve their own warning

Federation between systems depends on certificates, digital files that prove a message really came from the right sender. Certificates expire. When the certificate that signs a sign-in message runs out on a quiet Sunday, every sign-in to that application can fail at once, and the cause is often found only after hours of confusion. Keep a list of every certificate with its owner and expiry date, add reminders weeks ahead, and practice the replacement steps so they are routine.

Stay aware of how attackers actually behave

Real attackers often skip clever hacking and instead trick people. They phone help desks pretending to be locked-out staff, flood users with approval prompts hoping someone taps yes, or steal browser sessions. Good hybrid design therefore includes phishing-resistant methods for the most sensitive people, strict identity checks for password and factor resets, and monitoring for unusual sign-in patterns. Okta publishes security guidance and advisories, and administrators should follow them and apply recommended hardening steps promptly.

When the identity system sits in front of everything, its availability becomes the availability of the whole company. Plan for failure at every layer.

The chain and its weakest link

A sign-in in a hybrid company travels a chain: the person’s device, the internet, Okta’s service, the agent, the corporate network, the domain controller, and finally the application. If any link fails, the sign-in fails. Reliability work is therefore the work of finding every link, asking what happens when it breaks, and strengthening the weakest ones.

flowchart LR
    DEV["Device"] --> NET["Internet"]
    NET --> OKTA["Okta service"]
    OKTA --> AGT["Agents"]
    AGT --> LAN["Corporate network"]
    LAN --> DC["Domain controllers"]
    OKTA --> APP["Application"]
    

Strengthening each link

What if Okta itself is unavailable?

Okta publishes a service level agreement and a public status page showing service health, and it runs its platform with significant redundancy. Still, no cloud service is immune from problems, and your own design should answer an uncomfortable question: what happens to our company if people cannot sign in through Okta for an hour? Answers vary by system. People who already have active sessions may continue working for a while. Some applications may offer a local emergency login. Computers may let already-known users sign in using cached credentials. Administrators need emergency accounts that work without Okta. The point is to know the answer in advance, write it in a runbook, and test the emergency paths.

Geography and disaster planning

If a whole data center is lost to fire, flood, or power failure, can people still sign in to cloud apps? If your only agents live in that data center, the answer may be no, even though the apps themselves are fine in the cloud. Place agents and gateways in more than one site, and include identity services in your disaster recovery exercises, not only business applications.

Walking through failures on paper is far cheaper than discovering them live. Here are the scenarios that hybrid teams meet most often, with what people see and what to do.

Scenario 1: every agent for a directory goes offline

People using delegated authentication can no longer have their passwords checked, so they cannot sign in to Okta. People with active sessions may keep working until those sessions end. The Admin Console shows agents as inactive. Recovery means restoring at least one agent: check the server, the network path to Okta, and the service status. If this is a recurring risk, add agents in another site. Meanwhile, consider whether a documented emergency method, such as temporary password reset to Okta-managed passwords for critical staff, is acceptable under your policy.

Scenario 2: domain controllers are slow or unreachable

The agent is running but its questions to AD time out. Sign-ins become slow and some fail. Imports also stall. Check domain controller health, network latency between the agent and the controllers, and whether the agent is configured to reach more than one controller. The fix is often better placement of agents close to healthy controllers.

Scenario 3: a federation certificate expires

Sign-in to one application suddenly fails for everyone, often with a message about invalid signatures. Rotate the certificate in Okta and upload the new one to the application, in the right order to avoid a gap, and follow the application’s instructions about overlap. Prevent this with an inventory and early reminders.

Scenario 4: provisioning token or connection expires

New hires do not get accounts in a connected app, but sign-in is not affected. Often the problem is only noticed when someone complains, which may be days later. Monitor provisioning errors and alert on them, and track the expiry of any tokens used by connections.

Scenario 5: a network or firewall change blocks the agents

A well-meaning change tightens outbound rules, and agents suddenly cannot reach Okta. This looks like Scenario 1, but the servers are fine. Keep a documented list of the addresses and ports agents need, and make firewall teams aware that these flows are business critical.

flowchart TD
    I["Incident: sign-in failing"] --> Q1{"Only AD-backed users?"}
    Q1 -- "Yes" --> A1["Check agents and domain controllers"]
    Q1 -- "No" --> Q2{"Only one application?"}
    Q2 -- "Yes" --> A2["Check app config, certificate, gateway"]
    Q2 -- "No" --> Q3{"All users and apps?"}
    Q3 -- "Yes" --> A3["Check Okta status, policies, network to Okta"]
    A1 --> FIX["Fix, verify with a test user, record lesson"]
    A2 --> FIX
    A3 --> FIX
    

A design that works for two hundred people may feel slow at twenty thousand. Scale tests the weak points of a hybrid system in specific ways.

Where time is spent

A sign-in is only as fast as its slowest step. Typically the heavy parts are the trip between Okta and the agent, the agent’s questions to the domain controller, any extra MFA step where a human must tap their phone, and the final redirect back to the application. People notice delay most at the busiest moments, such as nine o’clock on a Monday morning, when a whole building signs in within minutes.

Peak loads to plan for

Practical ways to keep things fast

• Place agents near controllers. A short, fast network path between the agent and a healthy domain controller cuts delay on every password check.
• Add agents for capacity. More agents spread load and provide protection against failure at the same time.
• Scope imports. Import only the organizational units and groups you truly need, not the entire directory by default.
• Tidy the directory. Stale accounts, nested groups, and thousands of unused objects slow imports and confuse access rules.
• Mind rate limits. Okta applies limits to the number of API requests, so automation that makes huge numbers of calls should be paced and designed to handle “slow down” responses politely.
• Test with realistic volumes. A pilot of fifty users says little about behavior at fifty thousand. Run load tests or staged rollouts to learn the real curve.

A hybrid system has many moving parts spread over many places. You cannot manage what you cannot see, so decide early what to watch and where to look.

Three sources of truth

Visibility comes from three places. First, the Okta System Log, which records sign-ins, policy decisions, administrator actions, and provisioning events. Second, the agent and gateway health information, shown in the Admin Console and in the logs on the servers themselves. Third, the logs of the connected systems, such as domain controllers, firewalls, VPN servers, and cloud platforms. The most valuable insights come from combining all three, which is why many companies stream Okta’s logs into a central security monitoring platform.

flowchart LR
    OL["Okta System Log"] --> SIEM["Central monitoring platform"]
    AL["Agent and gateway logs"] --> SIEM
    DL["Domain controller logs"] --> SIEM
    NL["VPN and firewall logs"] --> SIEM
    CL["Cloud platform logs"] --> SIEM
    SIEM --> DASH["Dashboards"]
    SIEM --> ALR["Alerts to on-call team"]
    

Metrics worth tracking

Alerts that earn their keep

• An agent becomes inactive or the number of healthy agents drops below two.
• A certificate is within a set number of weeks of expiring.
• Provisioning errors rise above normal, or an import fails.
• A sharp rise in failed sign-ins for one application or one directory.
• Any change to administrator roles, policies, or federation settings.
• Any use of an emergency account.
• Many MFA push prompts sent to one user in a short time, which can signal an attack trying to wear someone down.

Make reports for people, not just machines

Auditors, managers, and leaders need clear summaries, not raw log lines. Prepare regular reports such as “who has administrator power”, “which applications have no MFA”, “accounts not used for ninety days”, and “access reviews completed on time”. These reports show that controls are real, and they find the cleanup tasks that keep the environment healthy.

Almost nobody builds this on an empty site. The real art is changing a running system a piece at a time while the company keeps working.

Do not do a big bang

A “big bang” migration changes everything at a single moment. It is tempting because it promises a clear finish line, yet it concentrates all the risk into one day. If anything unexpected happens, thousands of people are affected at once and rolling back may be impossible. Experienced teams avoid it. They move in small, reversible steps.

The strangler approach

A well-known pattern, called the strangler pattern, is named for a vine that slowly grows around a tree until it replaces it. You put the new identity layer in front of the old one, move one application or group of users at a time to the new path, and keep the old path working in the meantime. Over months, less and less traffic uses the old way, until it can safely be turned off.

flowchart LR
    S0["Start: apps use their own logins"] --> S1["Wave 1: modern cloud apps via SSO"]
    S1 --> S2["Wave 2: MFA and device policy"]
    S2 --> S3["Wave 3: legacy apps behind gateway"]
    S3 --> S4["Wave 4: lifecycle automation"]
    S4 --> S5["End: old logins retired"]
    

Decide the end state honestly

Some companies aim to remove on-premises Active Directory entirely. Others keep it for the long term, because certain Windows services, factory systems, or contracts require it. Both are legitimate. The mistake is to leave the end state undefined, since then temporary bridges quietly become permanent, and the company ends up running two of everything forever. Write down what “done” looks like, even if the date is far away.

Patterns are proven shapes that solve recurring problems. Recognizing them helps you design faster and explain your design clearly.

Two patterns in more depth

The identity hub. Picture a train station where lines from many towns meet. Instead of building a direct track between every pair of towns, which would need an enormous number of tracks, each town connects once to the hub. In identity, each system connects once to Okta instead of to every other system. The number of connections stays small and manageable, and adding a new application means adding one spoke.

Group-driven access. Rather than telling Okta “give Maria access to these twelve apps”, you say “members of the Finance group get these twelve apps”, and you let HR facts decide who is in Finance. When Maria joins, moves, or leaves, her access follows automatically. The advantage is predictability: you can read the rules and know who has what, without hunting through twelve places.

flowchart TD
    HR["HR fact: department equals Finance"] --> G["Group: Finance"]
    G --> A1["Accounting app"]
    G --> A2["Expense app"]
    G --> A3["Finance shared drive"]
    G --> A4["Cloud finance role"]
    

These habits are common, tempting, and costly. Recognizing them early saves months of trouble.

A hybrid identity design is a set of choices, and every choice trades one good thing for another. Naming the trade-offs helps you pick on purpose instead of by accident.

Key trade-offs in detail

Convenience versus control

Every security step adds a little friction and every convenience removes a little protection. Hybrid designs add a special twist: the old systems cannot always support the strongest controls, so you must choose where to tolerate weaker protection for a time and where to insist on the best. A useful approach is to sort applications by sensitivity and match the strength of controls to that sorting, rather than applying one rule to everything.

If you can only remember a few habits from this guide, these are the ones that prevent the most trouble.

Best practices

Common mistakes

• Treating agents as an afterthought. They are core infrastructure and need the same care as any critical server.
• Forgetting service accounts and machines. Non-human identities hold power and are often left out of reviews.
• Leaving old paths open. A new protected route is useless if the old unprotected one still works.
• Skipping data cleanup. Bad source data turns automation into automatic mistakes.
• Under-communicating. Surprised users and help desks create resistance and noise during rollouts.
• No end state. Bridges and exceptions stay forever when nobody defined what “finished” looks like.
• Assuming vendor products fit together magically. Check versions, licenses, and limits, and test integrations.

Let us put the pieces together for a made-up company. Contoso Manufacturing has twelve thousand employees, three factories, and a head office. All names and numbers here are invented for teaching.

Starting point

Contoso has on-premises Active Directory with two domains, a customer-order system written fifteen years ago, a quality-inspection web app with its own passwords, a VPN for remote staff, about eighty cloud and SaaS apps, and engineers who manage servers in the factories and in a cloud account. HR uses a cloud HR product. Staff complain about many passwords, auditors have flagged shared server accounts, and a former employee’s account was found active three months after leaving.

Target design

flowchart TD
    HR["Cloud HR system"] --> OK["Okta Universal Directory"]
    AD["Two AD domains"] -- "redundant agents" --> OK
    OK --> SAAS["80 cloud and SaaS apps via SSO and SCIM"]
    OK --> GW["Access Gateway cluster"]
    GW --> ORD["Customer-order system"]
    GW --> QUA["Quality-inspection app"]
    OK --> RAD["RADIUS agents"]
    RAD --> VPN["VPN"]
    OK --> PRIV["Short-lived server access"]
    PRIV --> SRV["Factory servers and cloud VMs"]
    OK --> CLD["Cloud account roles via federation"]
    OK --> SIEM["Central monitoring"]
    

The plan, wave by wave

Risks the team watched

• Factory networks with slow links. Placing an agent at one factory kept password checks local and fast.
• Shared factory computers. Shorter sessions and kiosk-friendly rules were used instead of strict device requirements.
• The old order system’s headers. Network rules were tightened so only the gateway could reach it, preventing spoofed headers.
• Certificates. A shared sheet tracked each federation certificate with an owner and a reminder six weeks before expiry.

The result

After the final wave, staff sign in once and open nearly everything. Remote access uses MFA. The old shared server accounts are gone, and the auditors can see exactly who connected to which server and when. A departure in HR now ends access across the company within minutes. No single trick made this possible. It was inventory, redundancy, careful sequencing, protection of the identity plane, and a team that kept learning from every wave.

A design that works technically must also satisfy auditors and fit a budget. These two forces shape many practical decisions.

What auditors look for

Frameworks such as SOC 2, ISO 27001, and rules for financial reporting expect strong control over privileged and sensitive access. Auditors typically ask who holds powerful access, how it is approved, how often it is reviewed, how quickly it is removed when someone leaves, and how you know it was not abused. A hybrid design built on groups, approvals, reviews, and central logs answers these questions with evidence. Remember that compliance belongs to the whole organization, not to a product. Okta provides controls and records, and your processes make them effective.

Data location and privacy

Identity data includes names, emails, and sign-in history, which are personal data under many privacy laws. Companies in some regions must consider where such data is stored and who may see it. Check Okta’s available regions and data handling documentation for your needs, limit what attributes you place in the identity system to what is truly needed, and apply scoped administrator roles so staff see only the data their job requires.

Thinking about cost honestly

Costs fall into several buckets. There are license costs for Okta products and any add-ons such as the gateway or governance features. There are infrastructure costs for the servers that host agents and gateways, including redundancy. There is staff time for design, migration, and ongoing care. And there are the savings: fewer help desk calls, less manual account work, retired software, and avoided incidents. A fair comparison counts both sides.

When something breaks across many systems, panic is the enemy. A calm method finds the cause faster than guessing.

Hybrid IT is the normal state of most companies. A well-designed identity layer turns that mixture from a source of risk into something you can manage calmly.