To understand why Zero Trust exists, we first need to look at the model it replaces, and at the changes in how we work that broke it.

The Castle and Moat

For decades, network security followed the castle-and-moat idea. Picture a medieval castle. It has thick walls, a moat, and one drawbridge with guards. Anyone outside is a possible enemy. Anyone inside is a friend. All the effort goes into strengthening the walls and guarding the gate.

In a company, the walls were firewalls, the drawbridge was the VPN, and the guards were passwords. The key assumption was that all the important things, such as servers, data, and people, lived in one place: the office and its data center. If you were on the office network, you were probably an employee. If you were outside, you were probably not.

What Changed

That assumption stopped being true, slowly and then suddenly. Four changes did the damage.

The Flat Network Problem

A flat network is one where, once you are connected, you can reach almost everything. Security people call the attacker’s roaming lateral movement, meaning moving sideways from one machine to the next. In a flat network, one stolen password can become a whole-company disaster, because there are no inner doors.

flowchart LR
    subgraph OLD["Castle and moat"]
        direction TB
        A1["Attacker with stolen password"] --> A2["VPN gateway"]
        A2 --> A3["Flat internal network"]
        A3 --> A4["Finance system"]
        A3 --> A5["HR system"]
        A3 --> A6["Warehouse system"]
    end
    subgraph NEW["Zero Trust"]
        direction TB
        B1["Attacker with stolen password"] --> B2["Identity checks at every request"]
        B2 -->|"Denied: unknown device"| B3["Blocked"]
        B2 -->|"Allowed: one app only"| B4["Single app"]
    end
    

Zero Trust is often sold as a product. It is not. It is a way of thinking, and a set of design rules, that many products can help you follow.

A Short History

The term Zero Trust was popularized around 2010 by John Kindervag, an analyst at Forrester Research, who argued that companies should stop treating any part of the network as automatically trustworthy. At about the same time, Google was dealing with a serious attack on its own systems, publicly known as Operation Aurora. Google responded by redesigning how its employees reach internal tools, so that access depended on the user and the device and not on being inside the office network. Google later described this approach, called BeyondCorp, in research papers starting in 2014.

In August 2020, the U.S. National Institute of Standards and Technology, known as NIST, published Special Publication 800-207, a formal description of Zero Trust Architecture. In January 2022, the U.S. federal government issued a memo requiring its agencies to move toward Zero Trust goals. Since then, the idea has moved from a niche opinion to a mainstream expectation in many industries.

The Core Rules

Different documents word it differently, but nearly all of them boil down to the same handful of rules.

Zero Trust Is a Journey, Not a Switch

No company flips a switch and becomes “Zero Trust” overnight. Nobody finishes. It is a direction of travel. You start with the highest risks, such as admin accounts and your most sensitive apps, and widen the circle over months and years. Because of this, the useful question is never “Are we Zero Trust?” but “Are we more verified, less privileged, and better at noticing problems than we were last quarter?”

Zero Trust conversations use a lot of short, specific words. Here are the ones we will rely on, each explained in plain language with a picture in your mind.

The Brain and the Gate

The last concept pair is the most important. Imagine a nightclub. At the door, a guard checks IDs. But the guard does not make up the rules. The manager decided the rules in advance: over 21, not on the banned list, dress code applies. The guard is the enforcement point. The manager’s rule book and the checking process together act as the decision point.

Splitting the two matters. When the brain and the gate are separate, you can change the rules in one place and every gate follows. You can also put gates in front of many different resources, while keeping one consistent brain.

Zero Trust spreads across identity, devices, networks, apps, and data. Okta focuses on one of these, identity, but it is the one that every other part leans on.

What Okta Does

Okta is an identity provider, or IdP: a service that stores user identities, checks their proof, and tells apps who is signing in. Companies use it as the central front door for workers, partners, and sometimes customers. When you click a tile on a work dashboard and land in an app without a second password prompt, an identity provider has done that for you.

Why Identity Becomes the Control Plane

A control plane is the place from which you steer a system, as opposed to the place where the work happens. In a world with no trusted network, the one thing that follows a request everywhere is the identity attached to it. Network addresses change. Devices change. But “this request is from Maria, on this laptop, using this app” is a stable question that every system can ask. That is why identity has become the control plane for Zero Trust. Okta describes this as the “identity layer,” and many other vendors say much the same.

The Big Picture

flowchart TB
    subgraph SIG["Evidence sources"]
        D1["Device management and endpoint security"]
        D2["Network location and behavior"]
        D3["Threat intelligence"]
        D4["HR system as source of truth"]
    end
    subgraph OKTA["Okta identity layer"]
        U["Universal Directory"]
        P["Policy engine"]
        A["Authentication and MFA"]
        L["Lifecycle and governance"]
    end
    subgraph RES["Protected resources"]
        R1["SaaS apps"]
        R2["Internal web apps"]
        R3["APIs and services"]
        R4["Servers and infrastructure"]
    end
    D1 --> P
    D2 --> P
    D3 --> P
    D4 --> L
    L --> U
    U --> P
    A --> P
    P --> R1
    P --> R2
    P --> R3
    P --> R4
    

Mapping NIST Ideas to Okta Features

NIST describes the brain and the gate as separate parts. The table below shows a loose mapping to Okta, to help you build a mental picture. Real deployments mix these roles, so treat the table as a guide and not a strict rule.

Okta is a family of services. Here are the pieces most often used in a Zero Trust plan, each described by the job it does.

How They Work Together

No single block gives you Zero Trust. The pattern is that the directory holds the facts, the lifecycle tools keep those facts correct, the policies read the facts and the live signals, the authenticators collect the proof, and the monitoring tools watch the result. If any one of these is weak, the chain is weaker than it looks. For example, perfect MFA does not help if a former employee’s account was never removed.

Let us follow one real request from start to finish. This is the heart of the whole subject: what the system asks, in what order, and what it does with the answers.

The Story of One Sign-In

Priya works in finance at Bluebird Logistics. On Wednesday morning she opens her laptop and clicks the tile for the payroll app. Here is what happens in the next second or two.

sequenceDiagram
    participant P as Priya
    participant B as Browser
    participant A as Payroll App
    participant O as Okta
    participant S as Signal Sources
    P->>B: Click payroll tile
    B->>A: Open app
    A-->>B: Redirect to Okta
    B->>O: Sign-in request
    O->>S: Ask for device and risk signals
    S-->>O: Device is managed and healthy
    O->>O: Evaluate policy rules in order
    O-->>B: Ask for fingerprint approval
    P->>B: Approve
    B->>O: Proof of approval
    O-->>B: Redirect with short-lived token
    B->>A: Present token
    A-->>P: Access granted
    O->>O: Write event to System Log
    

Why Order Matters

Notice that the evidence is gathered before the decision, and the decision is made before the proof is requested. This is smart design. If the policy already knows the request is coming from a blocked country, there is no point asking for a fingerprint. If the policy knows the device is fully trusted and healthy, it can ask for less. Good Zero Trust feels easy for good situations and hard for risky ones.

Everything in Zero Trust depends on believing that the person is who they claim to be. That belief is only as good as the proof. This chapter explains the main kinds of proof and why some are far better than others.

The Three Families of Proof

Security people group proof into three families. A strong login uses at least two different families together, which is what the word “multi-factor” means.

Not All Second Factors Are Equal

Many people think “I turned on MFA, so I am safe.” But attackers have adapted. They build fake sign-in pages that relay what you type, including your one-time code, to the real site in real time. They also flood users with approval prompts until someone taps “yes” to make it stop, a trick called MFA fatigue or prompt bombing. These attacks beat weaker factors. The industry term for the better kind of factor is phishing-resistant: one that cannot be tricked into working on the wrong site.

What Makes FIDO2 and FastPass Different

FIDO2 is an open standard for passwordless sign-in. Its web part is called WebAuthn. When you register, your device creates a pair of keys: a public key that the website stores, and a private key that never leaves your device. When you sign in, the website sends a challenge, and your device signs it with the private key, after you unlock it with a fingerprint or PIN. Crucially, the signature is tied to the website’s real address. A fake site at a different address cannot get a valid signature, so phishing simply fails. A passkey is the friendly name for this kind of credential, often synced between your devices by a trusted cloud service.

Okta FastPass follows a similar idea. Okta Verify on your device holds a key, and when you sign in, the device proves itself to Okta by signing a challenge, checking that you are present with a biometric or PIN, and reporting device facts. Because the proof is bound to the real Okta address, a look-alike page cannot collect it.

Policies are where Zero Trust becomes real. They are the written rules that the policy engine follows on every request. This chapter explains how Okta structures them, and how to think about writing good ones.

The Main Kinds of Policy

Okta separates its rules into several policy types, each with its own job. The exact names in the admin screens can change between releases, so check current documentation, but the ideas stay stable.

How Rules Are Read

Inside a policy there is an ordered list of rules. Okta reads them from the top. The first rule whose conditions all match is used, and the rest are ignored. At the bottom there is always a catch-all rule that applies when nothing else matched. The order and the catch-all are both critical, so let us look at each.

flowchart TD
    S["Sign-in request arrives"] --> R1{"Rule 1: admin group?"}
    R1 -->|"Match"| O1["Require phishing-resistant factor and managed device"]
    R1 -->|"No match"| R2{"Rule 2: managed device on trusted network?"}
    R2 -->|"Match"| O2["Allow with one strong factor"]
    R2 -->|"No match"| R3{"Rule 3: unmanaged device?"}
    R3 -->|"Match"| O3["Require two factors and limit the session"]
    R3 -->|"No match"| C["Catch-all rule: deny or require strongest proof"]
    

Write Specific Rules First

Because the first match wins, the most specific rules belong at the top and the general ones below. A rule for “all administrators” should sit above a rule for “all employees,” or administrators will be caught by the weaker rule. This is one of the most common reasons a policy does not behave as expected.

Take the Catch-All Seriously

The catch-all rule is the safety net for anything you did not think of. A weak catch-all quietly becomes a back door. For sensitive apps, set the catch-all to deny or to require the strongest proof, and then add specific allow rules for the cases you want. This “deny by default” posture is a hallmark of Zero Trust.

Policy Design Tips

• Use groups, not individuals. Rules based on groups are easier to understand and audit than rules listing hundreds of names.
• Give each sensitivity level its own policy. A small number of reusable policies, such as “standard,” “sensitive,” and “critical,” beats a unique rule for every app.
• Name rules clearly. A rule called “Admins – phishing-resistant only” explains itself during an incident.
• Test before you enforce. Run new rules for a small pilot group, and use the System Log to see what would have happened.
• Keep a break-glass account. Maintain one or two emergency accounts with very strong, offline-protected credentials, excluded from risky dependencies, so you can still get in when something breaks.

A trusted person on an untrusted device is still a risk. If the laptop has malware, the attacker can use the user’s own session. Zero Trust therefore asks about the device as well as the identity.

Managed and Unmanaged Devices

A managed device is one the company controls through management software, often called MDM, short for mobile device management, or an endpoint management tool. Such tools can enforce disk encryption, install updates, and install security software. An unmanaged device is one the company does not control, such as a personal phone or a contractor’s laptop. Both exist in real life, and Zero Trust policies treat them differently without banning either.

What Okta Can Learn About a Device

Okta Verify, installed on the device, can report facts directly, such as the operating system version, whether the screen lock is enabled, and whether the disk is encrypted. Okta can also connect to management and endpoint security tools to confirm that a device is enrolled and meets the company’s standards. Together, these facts let a policy say things like “managed and encrypted devices may open the finance app; others may only open the intranet.”

Okta groups these checks under the idea of device assurance: a named set of minimum requirements, such as a minimum operating system version and a required screen lock, that you attach to policies. When a new security update is released, you raise the minimum version in one place, and every policy that uses it follows.

A Tiered Approach

Zero Trust does not ignore the network. It simply refuses to treat the network as the main reason to trust. Network facts become one clue among many.

Network Zones

A network zone in Okta is a named group of network locations, such as your office addresses, or the ranges of a partner. Policies can say “allow from this zone,” “block from that zone,” or “require stronger proof when outside this zone.” You can also create zones for known bad sources, such as anonymizing services that hide a user’s real location, and block them from sensitive apps.

Zones can also be dynamic, meaning they are based on facts about the connection, such as the country or whether it comes from a known proxy, instead of a fixed list of addresses. This is helpful when you want to say “block sign-ins from countries where we have no staff” without maintaining an address list.

Behavior and Risk

Behavior detection compares a sign-in to a person’s usual pattern. Does it come from a new city? A new device? A travel distance that would be impossible? Has the time of day changed a lot? When something looks off, the sign-in can be marked as higher risk, and the policy can respond by asking for stronger proof or blocking.

ThreatInsight and Password Spraying

Password spraying is an attack in which a criminal tries one or two very common passwords against thousands of accounts, slowly, to avoid lockouts. Credential stuffing is a related attack that tries passwords leaked from other websites. Okta’s ThreatInsight looks at patterns across sign-in attempts, including data across many customers, to spot and block suspicious sources before they succeed. It is a good example of a shared defensive signal: the more systems contribute, the sooner a new attack becomes visible.

Proving who someone is does not decide what they should reach. Least privilege is the discipline of giving each person the smallest useful set of access, and taking it back when it is no longer needed.

Why Extra Access Is Dangerous

Every permission someone holds is a permission an attacker gains if that person’s account is stolen. Staff who have changed teams four times and kept all their old access are a classic example. Security people call this privilege creep, and it is one of the quiet reasons small breaches grow large.

Joiner, Mover, Leaver

The usual way to describe access over a person’s career is joiner, mover, leaver. Each stage needs its own care.

Role-Based and Attribute-Based Access

Role-based access control, or RBAC, gives permissions through groups that represent jobs, such as “Finance Analyst.” Attribute-based access control, or ABAC, uses facts about the user and situation, such as department, country, or device state. Real systems blend both: groups for the broad grant, and conditions for the fine print. In Okta, groups usually carry the “what,” and policies add the “when and how.”

Access Requests and Reviews

Some access should not be automatic. For sensitive systems, people can request it, a manager approves, and the grant can expire after a set time. Periodic access reviews ask managers to confirm each person’s access list, so stale entries are removed. Okta’s governance features support these flows, and similar tools exist elsewhere.

Privileged Accounts Deserve Extra Care

Administrators and service accounts hold the strongest permissions, which makes them the favorite targets. Good practice includes separate admin accounts used only for admin work, phishing-resistant factors, short-lived elevated access granted just in time, and tight limits on who can change Okta policies themselves. Okta lets you split admin duties into narrow roles, so that the person who resets passwords cannot also rewrite the security policy.

A sign-in is a single moment. But a session can last for hours, and a lot can change in that time. Zero Trust treats trust as something that can fade, and builds ways to notice and react.

The Problem With “Sign In Once”

Suppose Priya signs in at 9:00 a.m. with a healthy laptop. At 10:30, malware lands on her machine through a bad download. If the system only checked at 9:00, it would keep trusting her until the session ends. An attacker could steal the session and keep using it. Zero Trust asks: how do we notice that something changed, and how do we cut off access quickly?

Three Tools for Staying Current

The Loop

flowchart LR
    A["Sign in with policy check"] --> B["Active session"]
    B --> C["Watch signals: device, behavior, threat feeds"]
    C --> D{"Risk changed?"}
    D -->|"No"| B
    D -->|"Yes"| E["Respond: step up proof, reduce access, or end session"]
    E --> F["Log the event and notify security"]
    F --> A
    

Automated Responses

Speed matters. A human analyst may need an hour to notice an alert and respond. A prepared automated response can act in seconds. Using Okta Workflows or integrations with security tools, teams build simple “if this, then that” responses. For example: if the endpoint security tool flags a device as compromised, end the user’s sessions, require a fresh sign-in with a strong factor, and open a ticket for the security team. Automated actions should be tested carefully and used in proportion, because a wrong automatic action can lock out honest staff at a bad moment.

People are not the only ones making requests. Apps call other apps, and services call APIs. Zero Trust applies to these machine-to-machine conversations too.

Standards That Carry Identity

Modern apps use a small set of shared standards to receive identity from a provider like Okta. OAuth 2.0 is a framework for granting limited access without sharing passwords. OpenID Connect, or OIDC, adds a standard way to say who the user is. SAML is an older XML-based standard still common in business software. All three let an app trust Okta’s signed statement instead of keeping its own password list.

Tokens and Their Limits

A token is a small, signed package of facts that proves a request is allowed. Good tokens are short-lived, narrow in scope, and meant for one specific audience. An access token lets a caller use an API. It carries scopes, which are named permissions such as “read invoices” or “write orders.” An API should check the signature, the issuer, the audience, the expiry, and the scopes on every call. This is Zero Trust at the API: it never assumes a call is safe just because it came from inside the network.

Machines Need Identities Too

A service account or workload identity is an identity for software, not a person. These are often forgotten, over-permissioned, and given passwords that never change. In a Zero Trust plan, they receive the same care as humans: a named owner, narrow permissions, automatically rotating secrets or short-lived credentials, and monitoring. Okta’s API access management can issue tokens to services using the client credentials flow, with scopes that you define.

Legacy Apps

Not every app speaks modern standards. Old in-house apps may only know a login form or a header. The common bridges are an access proxy or gateway placed in front of the app, which acts as the enforcement point, and which asks Okta before letting requests through. Okta integrates with several such gateway products. This approach lets old apps benefit from modern policy without being rewritten.

flowchart LR
    U["User with device"] --> G["Access gateway: enforcement point"]
    G --> O["Okta: decision point"]
    O -->|"Allow with token"| G
    G --> L["Legacy internal app"]
    S["Service client"] --> T["Okta authorization server"]
    T -->|"Short-lived scoped token"| S
    S --> API["Orders API"]
    API --> V["API checks issuer, audience, scope, expiry"]
    

Zero Trust is a strong approach, but it is not free. A fair look at both sides helps you plan, and helps you explain the project honestly to others.

The Key Trade-offs

When Zero Trust Is a Good Fit

Almost every company with cloud apps and remote staff benefits. The more sensitive your data and the more apps you use, the larger the benefit. For a very small team with a handful of apps, a lightweight version still helps: strong MFA, single sign-on, and prompt offboarding give most of the return for little effort.

If identity is the control plane, then the identity platform is the most valuable lock to protect. It would be strange to build a Zero Trust plan on top of an unguarded front door.

Why Identity Providers Are Targets

An attacker who controls your identity provider can sign in as anyone, change policies, and open every connected app. For this reason, identity systems of all vendors are high-value targets, and the people who run them must take extra care. Okta itself has disclosed security incidents over the years, including a 2023 incident in which attackers used a stolen credential to reach its customer support case system and view files that customers had uploaded, such as browser recordings used for troubleshooting. Okta published guidance afterwards, including advice to remove sensitive session data from files shared with support. The lesson for customers is not to panic, but to treat the identity layer as critical infrastructure and to follow vendor security guidance closely.

A Hardening Checklist

“Assume breach” only works if you can see what is happening. Logs are the memory of your identity system, and metrics tell you whether your Zero Trust program is actually improving.

The Okta System Log

The System Log records events in your org: sign-ins, failed attempts, factor enrollments, policy evaluations, password resets, admin actions, and more. Each entry says who did what, from where, when, and with what result. It is the first place to look during an investigation. Because the log inside Okta keeps events for a limited time, most companies stream it to an outside system for long-term storage and alerting. Okta supports log streaming to major cloud services and security platforms.

Where to Send the Logs

A SIEM, short for security information and event management tool, collects logs from many systems, correlates them, and raises alerts. Sending Okta events to a SIEM lets analysts connect identity events with network, endpoint, and cloud events. A sign-in from a new country, followed by a mailbox rule change, followed by a large download, tells a story that no single log tells alone.

Metrics That Show Progress

Patterns are shapes that work again and again. Anti-patterns are the tempting shortcuts that cause trouble later. Knowing both saves months.

Patterns That Work

Anti-patterns to Avoid

The best way to eat an elephant is one bite at a time. Here is a path that moves from the quickest, highest-value steps to the deeper work, and keeps users on your side.

Phase 0: Know What You Have

Before you change anything, make lists. Which apps do people use? Which are already behind single sign-on, and which still have their own passwords? Who are your administrators? Which devices connect? Which service accounts exist? You cannot protect what you cannot see, and this inventory often reveals surprises, such as forgotten apps with active logins for former staff.

flowchart LR
    P0["Inventory"] --> P1["Foundation: SSO, MFA, admin protection, logs"]
    P1 --> P2["Strong proof: FastPass and keys"]
    P2 --> P3["Device and context policies"]
    P3 --> P4["Lifecycle, governance, automation"]
    P4 --> P5["APIs, legacy, infrastructure"]
    P5 --> P6["Measure and refine"]
    P6 -.-> P3
    

Where to Put Limited Time First

If you can only do three things this month, do these: protect administrators with phishing-resistant sign-in, connect the HR system so leavers lose access at once, and send identity logs to a place where someone is looking at them. These three steps cut a large share of real-world risk for modest effort.

Most Zero Trust projects fail for human reasons, not technical ones. People who feel blocked will find ways around controls. People who understand the reason and see a smooth experience will help you.

Explain the Why

Staff accept inconvenience more readily when they know the reason. A short message such as “We are moving to passwordless sign-in because stolen passwords are the number one way companies get breached, and this change makes your day faster, not slower” works better than a long policy notice. Use real, simple stories, and avoid scary language.

Design for the Good Day

The sign-in a person sees most is the ordinary one, from their own managed laptop at their usual place. Make that path almost invisible, with FastPass or a fingerprint and no extra prompts. Spend the friction budget on unusual cases. A person who signs in 20 times a week will judge the whole program by those 20 moments.

Support the Help Desk

The help desk becomes a front line. Give them a clear script for lost phones, new laptops, and failed device checks. Equip them with ways to verify identity that attackers cannot easily fake. Track the most common tickets and fix their causes, because a repeated ticket is a design problem in disguise.

Executive Support

Leaders must follow the same rules. If executives are exempt, the rest of the company notices, and attackers love to target exempt accounts. Include leaders early, listen to their friction, and make the experience smooth for them. Their visible cooperation sets the tone.

A short checklist of habits to copy, and traps to dodge.

Best Practices

• Protect administrators first. Their accounts are the keys to everything else.
• Prefer phishing-resistant factors. Move toward FastPass, security keys, and passkeys, and retire SMS where you can.
• Make HR the source of truth. Let real job changes drive access.
• Group apps into tiers. A few reusable policies are easier to defend than hundreds of custom ones.
• End every policy with a safe catch-all. Deny by default and allow known good.
• Check devices, not only people. Use device assurance to raise the bar for sensitive apps.
• Keep sessions as short as users can bear. Shorter for sensitive apps, longer for ordinary ones.
• Log everything and watch it. Stream logs to a SIEM and build alerts for admin changes.
• Automate carefully. Begin with reversible actions and grow from there.
• Practice failure. Run drills for lost admin access, stolen sessions, and identity platform outages.
• Review often. Check access lists and policies on a calendar, not only after incidents.

Common Mistakes

Two practical questions follow every Zero Trust project. How do we show auditors that the controls are real? And what do we do when a user says “I cannot get in”?

Evidence for Auditors

Auditors who review a company for standards such as SOC 2, ISO 27001, or industry rules like PCI DSS and HIPAA ask similar questions about identity. Who can access this system? How do you know they still need it? How do you stop a leaver? How do you protect administrators? How do you detect misuse? A central identity platform answers these from one place, which is a quiet benefit of Zero Trust: the same controls that reduce risk also produce proof.

Collect this evidence continuously instead of in a panic before the audit. A monthly saved report, kept in a shared folder with a date, turns a stressful audit week into a calm afternoon.

Troubleshooting a Blocked User

When a person is blocked, the System Log is the best friend of the help desk. Each sign-in attempt records which policy and rule matched and why the result was allow or deny. Work through a few simple questions in order.

flowchart TD
    A["User cannot sign in"] --> B{"Account active and in right groups?"}
    B -->|"No"| B1["Fix status or group, check HR data"]
    B -->|"Yes"| C{"Log shows device check failed?"}
    C -->|"Yes"| C1["Update system or enroll device"]
    C -->|"No"| D{"Log shows zone or location block?"}
    D -->|"Yes"| D1["Review zone rule, grant temporary exception with end date"]
    D -->|"No"| E{"Factor missing or lost?"}
    E -->|"Yes"| E1["Verified recovery and re-enrollment"]
    E -->|"No"| F["Review policy rule order and escalate"]
    

Zero Trust ideas appear differently in different industries. These examples show the shape of the thinking. Company names are used only where they have publicly described their approach, and details may have changed.

A Worked Example in Numbers

Let us do a small planning exercise for Bluebird Logistics. The company has 3,000 employees, 60 business apps, and 25 administrators. In the first 30 days, the team connects the HR system and puts the top 20 apps behind single sign-on. By day 60, all 25 administrators and the 200 people in finance and engineering use phishing-resistant sign-in. By day 90, the 600 laptops managed by IT meet a device assurance standard, and the remaining 40 apps are moved behind single sign-on in two waves.

At the start, offboarding took about three days because a human checklist had to be followed across many apps. After automation, a departure entered in the HR system suspends access across connected apps within minutes. Before the project, only 8 percent of sign-ins came from managed devices with strong factors. After six months, 70 percent of sign-ins to sensitive apps did. These numbers are illustrative, but they show the kind of measurable change a team should aim for.

Short answers to the questions people ask most when they first meet Zero Trust with Okta.

Zero Trust replaces “trust the network” with “verify each request.” Okta gives you a strong place to make those decisions, because every request carries an identity, and identity is the one thing you can check everywhere.